From cabo@tzi.org Thu Dec 1 00:35: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 8EF9D21F8B9C for ; Thu, 1 Dec 2011 00:35:44 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6QCdlZyxPpS for ; Thu, 1 Dec 2011 00:35:44 -0800 (PST) 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 B622F21F8BB8 for ; Thu, 1 Dec 2011 00:35:43 -0800 (PST) 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 pB18ZSRP009491; Thu, 1 Dec 2011 09:35:28 +0100 (CET) Received: from [192.168.217.112] (p54899BA5.dip.t-dialin.net [84.137.155.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9CA29896; Thu, 1 Dec 2011 09:35:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <3615F3CCD55F054395A882F51C6E5FDA1820A06E@szxeml513-mbx.china.huawei.com> Date: Thu, 1 Dec 2011 09:35:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <99F67A51-170A-4194-B3B4-FFA3C0FEC8B6@tzi.org> References: <031DD135F9160444ABBE3B0C36CED61801E4B5@011-DB3MPN1-012.MGDPHG.emi.philips.com> <2D66A4A2-17A1-4F47-9465-4901C0172F2E@koanlogic.com> <3615F3CCD55F054395A882F51C6E5FDA1820A06E@szxeml513-mbx.china.huawei.com> To: TianLinyi X-Mailer: Apple Mail (2.1251.1) Cc: "core@ietf.org" Subject: Re: [core] Clarification of coap-08 multicast security requirements 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, 01 Dec 2011 08:35:44 -0000 Indeed, this is an interesting discussion. Let me try to expand on that. Why do we specify properties of a protocol? Normally, we do this so the peer instance can rely on some behavior. This will enable it to plan its actions appropriately and to correctly = interpret responses. Let's call this the "functional" reason for a mandate. Another reason to mandate something is to protect nodes or the network. Here, the specification is indeed not trying to help the peer instance. This is about packets that don't authenticate. The whole point of section 10.3.3 is to protect *other* nodes from = becoming a victim of amplification attacks. So this is not a "functional" mandate, it is a "protective" one. These are typically stronger -- third party nodes won't care if a node = fails on a functional level, but they may be disrupted by a failure on a = protective mandate. (For a physical-life analogy, when repairing cars there are stronger = mandates on fixing your brakes than fixing your motor.) Note that the current text says SHOULD NOT, not MUST NOT. So it says = there may be a reason to not heed this mandate. But, by the meaning of = "SHOULD NOT", this reason must exist, and it must outweigh the reasons = given for the SHOULD NOT. (The draft is however lacking in explaining = what those reasons could be -- as a general rule, reasons SHOULD be = given for not heeding a SHOULD/SHOULD NOT, otherwise it SHOULD be a = MUST/MUST NOT.) =20 Note also that the mandate is not specific on how the "authenticate" is = achieved, so if there is some other way the CoAP server can ascertain = that the request is not an attack, it can respond fine. Specifically, = on a network with L2 access protection, I would usually consider that = level of source authentication to be implied for a packet that is using = a local multicast scope. We may want to expand on that. BTW, "MAY NOT" is not very helpful anyway, as with that the sender of an = un-authenticated multicast then simply doesn't know whether the desired = nodes will reply or not. Gr=FC=DFe, Carsten From esko.dijk@philips.com Thu Dec 1 01:51: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 1BD4B21F844F for ; Thu, 1 Dec 2011 01:51:05 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWCbXaaLXwSp for ; Thu, 1 Dec 2011 01:51:02 -0800 (PST) Received: from VA3EHSOBE004.bigfish.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBA621F8C15 for ; Thu, 1 Dec 2011 01:51:01 -0800 (PST) Received: from mail97-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Dec 2011 09:50:58 +0000 Received: from mail97-va3 (localhost [127.0.0.1]) by mail97-va3-R.bigfish.com (Postfix) with ESMTP id BB6A14402FD; Thu, 1 Dec 2011 09:50:58 +0000 (UTC) X-SpamScore: -41 X-BigFish: VPS-41(zz217bL15d6O9251Jc89bh146fK542Mzz1202hzz1033IL8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail97-va3 (localhost.localdomain [127.0.0.1]) by mail97-va3 (MessageSwitch) id 1322733058382850_21457; Thu, 1 Dec 2011 09:50:58 +0000 (UTC) Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.248]) by mail97-va3.bigfish.com (Postfix) with ESMTP id 4A021620049; Thu, 1 Dec 2011 09:50:58 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 1 Dec 2011 09:50:54 +0000 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.218]) by 011-DB3MMR1-009.MGDPHG.emi.philips.com ([10.128.28.48]) with mapi id 14.01.0355.003; Thu, 1 Dec 2011 09:50:27 +0000 From: "Dijk, Esko" To: Carsten Bormann , TianLinyi Thread-Topic: [core] Clarification of coap-08 multicast security requirements Thread-Index: Acyt5r3U+HC0kyPrSr6e6lkqM/bsngAEPN6AAAT3NwAAeA79gAAGGL+AAAIRhpA= Date: Thu, 1 Dec 2011 09:50:27 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61801ED22@011-DB3MPN1-012.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED61801E4B5@011-DB3MPN1-012.MGDPHG.emi.philips.com> <2D66A4A2-17A1-4F47-9465-4901C0172F2E@koanlogic.com> <3615F3CCD55F054395A882F51C6E5FDA1820A06E@szxeml513-mbx.china.huawei.com> <99F67A51-170A-4194-B3B4-FFA3C0FEC8B6@tzi.org> In-Reply-To: <99F67A51-170A-4194-B3B4-FFA3C0FEC8B6@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.94.216.29] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] Clarification of coap-08 multicast security requirements 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, 01 Dec 2011 09:51:05 -0000 Thanks Carsten, convincing arguments. Thinking about this, the SHOULD NOT gives CoAP server implementers a clear = rule how to configure its default behaviour towards the safe side, which is= good. Only with good reasons a server can then respond to multicast reques= ts e.g. in NoSec mode. I was thinking of some good example reasons: 1. to be able to use multicast at all in a system, if NoSec mode is used an= d if no further authentication means are available. 2. responding to multicast requests on /.well-known/core during initial con= figuration/commissioning of a system. In this configuration phase, security= contexts may not have yet been established so nodes possibly have to rely = on NoSec mode and multicast to be discoverable. 3. In order to implement CoAP servers that act as intermediaries to very co= nstrained sensor nodes as in draft-arkko-core-sleepy-sensors. The sensors m= ay not have any security/authentication mechanisms on board and yet they ne= ed to send out multicast. In this light a 'SHOULD NOT' seems to be the best for the protective reason= s mentioned. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Thursday 1 December 2011 9:35 To: TianLinyi Cc: core@ietf.org Subject: Re: [core] Clarification of coap-08 multicast security requirement= s Indeed, this is an interesting discussion. Let me try to expand on that. Why do we specify properties of a protocol? Normally, we do this so the peer instance can rely on some behavior. This will enable it to plan its actions appropriately and to correctly inte= rpret responses. Let's call this the "functional" reason for a mandate. Another reason to mandate something is to protect nodes or the network. Here, the specification is indeed not trying to help the peer instance. This is about packets that don't authenticate. The whole point of section 10.3.3 is to protect *other* nodes from becoming= a victim of amplification attacks. So this is not a "functional" mandate, it is a "protective" one. These are typically stronger -- third party nodes won't care if a node fail= s on a functional level, but they may be disrupted by a failure on a protec= tive mandate. (For a physical-life analogy, when repairing cars there are stronger mandat= es on fixing your brakes than fixing your motor.) Note that the current text says SHOULD NOT, not MUST NOT. So it says there= may be a reason to not heed this mandate. But, by the meaning of "SHOULD = NOT", this reason must exist, and it must outweigh the reasons given for th= e SHOULD NOT. (The draft is however lacking in explaining what those reaso= ns could be -- as a general rule, reasons SHOULD be given for not heeding a= SHOULD/SHOULD NOT, otherwise it SHOULD be a MUST/MUST NOT.) Note also that the mandate is not specific on how the "authenticate" is ach= ieved, so if there is some other way the CoAP server can ascertain that the= request is not an attack, it can respond fine. Specifically, on a network= with L2 access protection, I would usually consider that level of source a= uthentication to be implied for a packet that is using a local multicast sc= ope. We may want to expand on that. BTW, "MAY NOT" is not very helpful anyway, as with that the sender of an un= -authenticated multicast then simply doesn't know whether the desired nodes= will reply or not. Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ 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. From tho@koanlogic.com Thu Dec 1 02:32:48 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 987C321F84B5 for ; Thu, 1 Dec 2011 02:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4z6Nhmt4ydAB for ; Thu, 1 Dec 2011 02:32:48 -0800 (PST) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 1056B21F8AA8 for ; Thu, 1 Dec 2011 02:32:47 -0800 (PST) Received: from host12-49-dynamic.56-79-r.retail.telecomitalia.it ([79.56.49.12]:50661 helo=t.home) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RW3wL-0004bK-Qe; Thu, 01 Dec 2011 05:32:40 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <99F67A51-170A-4194-B3B4-FFA3C0FEC8B6@tzi.org> Date: Thu, 1 Dec 2011 11:31:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85E8CCF5-2F94-46E3-8C19-E83F056E210D@koanlogic.com> References: <031DD135F9160444ABBE3B0C36CED61801E4B5@011-DB3MPN1-012.MGDPHG.emi.philips.com> <2D66A4A2-17A1-4F47-9465-4901C0172F2E@koanlogic.com> <3615F3CCD55F054395A882F51C6E5FDA1820A06E@szxeml513-mbx.china.huawei.com> <99F67A51-170A-4194-B3B4-FFA3C0FEC8B6@tzi.org> To: Carsten Bormann , Esko Dijk X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.56.49.12 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: "core@ietf.org" Subject: Re: [core] Clarification of coap-08 multicast security requirements 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, 01 Dec 2011 10:32:48 -0000 Carsten, Linyi, Kerry, Esko, On Dec 1, 2011, at 9:35 AM, Carsten Bormann wrote: > Indeed, this is an interesting discussion. > Let me try to expand on that. >=20 > Why do we specify properties of a protocol? > Normally, we do this so the peer instance can rely on some behavior. > This will enable it to plan its actions appropriately and to correctly = interpret responses. > Let's call this the "functional" reason for a mandate. >=20 > Another reason to mandate something is to protect nodes or the = network. > Here, the specification is indeed not trying to help the peer = instance. > This is about packets that don't authenticate. > The whole point of section 10.3.3 is to protect *other* nodes from = becoming a victim of amplification attacks. > So this is not a "functional" mandate, it is a "protective" one. > These are typically stronger -- third party nodes won't care if a node = fails on a functional level, but they may be disrupted by a failure on a = protective mandate. > (For a physical-life analogy, when repairing cars there are stronger = mandates on fixing your brakes than fixing your motor.) as a matter of taste, I don't like very much the idea that a protocol = specification mandates a policy. I'd prefer the spec to give us just a = set of tools and a companion security analysis that clearly highlights = the issues that may impact a deployment in case a given threat comes = true. It's an easier, cleaner, and more adaptive approach IMHO. That's why in the first place I agreed with Esko. The amplification attack that you want to counteract with the SHOULD NOT = is in fact just one of the possible threats on the constrained = nodes/network, which may or may not be real depending on the threat = model of your specific deployment. Another deployment may be particularly sensitive to unicast spoofing = attacks, in which case crypto based authentication would help a lot in = repelling the attacker. Yet we don't say anywhere that unauthenticated = unicast messages SHOULD NOT be accepted; that's because we correctly = identify any countermeasure as a local policy matter. And also, we've = put a notice in the security consideration section that tells the CoAP = implementer that there is a risk there, so that she is warned and may = armor her implementation, if needed. My two cents.= From zach@sensinode.com Thu Dec 1 13:22:50 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 A76B621F9426 for ; Thu, 1 Dec 2011 13:22:50 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE-l2GL1guJs for ; Thu, 1 Dec 2011 13:22:50 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id DF2C81F0C86 for ; Thu, 1 Dec 2011 13:22:47 -0800 (PST) Received: from [10.59.3.5] (oul314-99.netplaza.fi [188.64.2.99]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id pB1LMafO021780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Dec 2011 23:22:37 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-105-869973209; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <423A9692-1B3B-4919-B93A-E3ED5D0956D4@koanlogic.com> Date: Thu, 1 Dec 2011 23:22:36 +0200 Message-Id: <5D525845-9759-41D5-96D9-8D7FBF64989E@sensinode.com> References: <4224466B-89A8-4A20-9D57-A5C29772E2A8@koanlogic.com> <031DD135F9160444ABBE3B0C36CED61801E7B0@011-DB3MPN1-012.MGDPHG.emi.philips.com> <423A9692-1B3B-4919-B93A-E3ED5D0956D4@koanlogic.com> To: Thomas Fossati X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" Subject: Re: [core] Uri-Port option really needed ? 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, 01 Dec 2011 21:22:50 -0000 --Apple-Mail-105-869973209 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 29, 2011, at 6:48 PM, Thomas Fossati wrote: > While searching more carefully into the spec for "Uri-Port" I could = find a couple of references to "virtual hosting", which seems to be the = base rationale for having a possibly different port value. It seems = that the port is retained for full analogy with the Host header in HTTP. That is correct.=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-869973209 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb +JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh 5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL 7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7 btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4 mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9 OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1 qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEyMDEy MTIyMzdaMCMGCSqGSIb3DQEJBDEWBBTW3EIj4LSsjf0aagMnx5qsKyzv1jCCAQMGCSsGAQQBgjcQ BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6 Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd uDANBgkqhkiG9w0BAQEFAASCAQDHQnRUO3uw+wt3JQg8UPyZQcwE2t6ycJtXl6NEjN3jvfulUIXE 9zO507pcFXTDAR3cRucCF9UqH86878Hx66+b8JO+m5jsA6pAVlPg56q64lcs7NYGInGjR2Vx2Bbq +bQTqc4GkHw1fGs0G0AfGTusz0CKpxheaFBIWnJGXrJNpNbKBxoZL7zuaIK751n1Iw+U2Bc3gE5R id3xvhBiqjFh5LL0iB6Q/8LNoV4YXW1tf2g3h1UE/Ch85Cj9i19nXQY3036bSPIdHCxYlIKMJ92M UVXkon7AjaPRAo6uzApj+1k0KblOX4zayULunrq8fs/9+JwI5+WAY1fXJfIj+9SJAAAAAAAA --Apple-Mail-105-869973209-- From cabo@tzi.org Fri Dec 2 12:40: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 6FDE211E810F for ; Fri, 2 Dec 2011 12:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.249 X-Spam-Level: X-Spam-Status: No, score=-108.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46xNHqZIWzUh for ; Fri, 2 Dec 2011 12:40:47 -0800 (PST) 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 5210C21F8B94 for ; Fri, 2 Dec 2011 12:40:45 -0800 (PST) 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 pB2KebkT022296 for ; Fri, 2 Dec 2011 21:40:37 +0100 (CET) Received: from [192.168.217.110] (p5B3E7CA4.dip.t-dialin.net [91.62.124.164]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3F5221E9; Fri, 2 Dec 2011 21:40:37 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Dec 2011 21:40:36 +0100 To: "core@ietf.org WG" Message-Id: <077E0AAD-AD02-41F1-8275-59F0F1B98F70@tzi.org> Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [core] Invitation for a trip to the distant past: 2010-08-25 virtual interim minutes are up 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, 02 Dec 2011 20:40:47 -0000 The minutes for the 2010-08-25 (yes! not a typo) interim meeting are (in = a slightly mangled form) at: = http://www.ietf.org/proceedings/interim/2010/08/25/core/minutes/core.txt If you are old enough to have been around when this "virtual interim" = took place, you may want to check how badly I misrepresented your = contribution in those minutes. Enjoy! Gr=FC=DFe, Carsten From stpeter@stpeter.im Fri Dec 2 12:44:50 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 49F6111E810F for ; Fri, 2 Dec 2011 12:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.981 X-Spam-Level: X-Spam-Status: No, score=-102.981 tagged_above=-999 required=5 tests=[AWL=1.618, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYm83TmCuz0K for ; Fri, 2 Dec 2011 12:44:49 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B520D11E80F3 for ; Fri, 2 Dec 2011 12:44:49 -0800 (PST) Received: from dhcp-64-101-72-230.cisco.com (unknown [64.101.72.230]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E05394224C; Fri, 2 Dec 2011 13:51:47 -0700 (MST) Message-ID: <4ED938BB.5040507@stpeter.im> Date: Fri, 02 Dec 2011 13:44:43 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Carsten Bormann References: <077E0AAD-AD02-41F1-8275-59F0F1B98F70@tzi.org> In-Reply-To: <077E0AAD-AD02-41F1-8275-59F0F1B98F70@tzi.org> X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "core@ietf.org WG" Subject: Re: [core] Invitation for a trip to the distant past: 2010-08-25 virtual interim minutes are up 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, 02 Dec 2011 20:44:50 -0000 On 12/2/11 1:40 PM, Carsten Bormann wrote: > The minutes for the 2010-08-25 (yes! not a typo) interim meeting are (in a slightly mangled form) at: > > http://www.ietf.org/proceedings/interim/2010/08/25/core/minutes/core.txt > > If you are old enough to have been around when this "virtual interim" took place, you may want to check how badly I misrepresented your contribution in those minutes. Thanks, Carsten! I'll check them out now. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri Dec 2 15:13: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 1173C21F848F for ; Fri, 2 Dec 2011 15:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.34 X-Spam-Level: X-Spam-Status: No, score=-105.34 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luFKAOSfdHcB for ; Fri, 2 Dec 2011 15:13:17 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 88B8321F845C for ; Fri, 2 Dec 2011 15:13:17 -0800 (PST) Received: from dhcp-64-101-72-189.cisco.com (unknown [64.101.72.189]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C9EDD42305; Fri, 2 Dec 2011 16:20:20 -0700 (MST) Message-ID: <4ED95B8B.2070106@stpeter.im> Date: Fri, 02 Dec 2011 16:13:15 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Carsten Bormann References: <077E0AAD-AD02-41F1-8275-59F0F1B98F70@tzi.org> <4ED938BB.5040507@stpeter.im> In-Reply-To: <4ED938BB.5040507@stpeter.im> X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "core@ietf.org WG" Subject: Re: [core] Invitation for a trip to the distant past: 2010-08-25 virtual interim minutes are up 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, 02 Dec 2011 23:13:18 -0000 On 12/2/11 1:44 PM, Peter Saint-Andre wrote: > On 12/2/11 1:40 PM, Carsten Bormann wrote: >> The minutes for the 2010-08-25 (yes! not a typo) interim meeting are (in a slightly mangled form) at: >> >> http://www.ietf.org/proceedings/interim/2010/08/25/core/minutes/core.txt >> >> If you are old enough to have been around when this "virtual interim" took place, you may want to check how badly I misrepresented your contribution in those minutes. > > Thanks, Carsten! I'll check them out now. BTW those look good to me. More comprehensive than I expected. :) /psa From Akbar.Rahman@InterDigital.com Fri Dec 2 15:34: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 1CFC41F0C52 for ; Fri, 2 Dec 2011 15:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.948 X-Spam-Level: X-Spam-Status: No, score=-3.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2HEXuh0EXke for ; Fri, 2 Dec 2011 15:34:19 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 629D51F0C4F for ; Fri, 2 Dec 2011 15:34:19 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Dec 2011 18:34:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCB14A.E942D216" Date: Fri, 2 Dec 2011 18:33:55 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [core] Invitation for a trip to the distant past: 2010-08-25 virtual interim minutes are up Thread-index: AcyxR/xhy1nCS6UTTWu/UF9oRKwwhgAAghTYAAAxtbA= References: <077E0AAD-AD02-41F1-8275-59F0F1B98F70@tzi.org><4ED938BB.5040507@stpeter.im> From: "Rahman, Akbar" To: "Peter Saint-Andre" , "Carsten Bormann" , X-OriginalArrivalTime: 02 Dec 2011 23:34:18.0382 (UTC) FILETIME=[E92082E0:01CCB14A] Subject: Re: [core] Invitation for a trip to the distant past: 2010-08-25 virtual interim minutes are up 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, 02 Dec 2011 23:34:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB14A.E942D216 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 IA0KDQpIaSBDYXJzdGVuLA0KDQpUaGFua3MuIEkgcmV2aWV3ZWQgdGhlIG5vdGVzLCBhbmQgZXNw ZWNpYWxseSB0aGUgc2VjdGlvbnMgbXVsdGljYXN0IGFuZCBzbGVlcGluZyBub2RlcyB0aGF0IEkg cHJlc2VudGVkLiBUaGUgbm90ZXMgYWxpZ24gd2VsbCB3aXRoIG15IG1lbW9yeS4gU28gSSBhZ3Jl ZSB3aXRoIHRoZW0uDQoNCkFrYmFyDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogUGV0ZXIgU2FpbnQtQW5kcmUgW3N0cGV0ZXJAc3RwZXRlci5pbV0NClNlbnQ6IEZyaWRh eSwgRGVjZW1iZXIgMDIsIDIwMTEgMDY6MTMgUE0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQpUbzog Q2Fyc3RlbiBCb3JtYW5uDQpDYzogY29yZUBpZXRmLm9yZyBXRw0KU3ViamVjdDogUmU6IFtjb3Jl XSBJbnZpdGF0aW9uIGZvciBhIHRyaXAgdG8gdGhlIGRpc3RhbnQgcGFzdDogMjAxMC0wOC0yNSB2 aXJ0dWFsIGludGVyaW0gbWludXRlcyBhcmUgdXANCg0KDQoNCg0KT24gMTIvMi8xMSAxOjQ0IFBN LCBQZXRlciBTYWludC1BbmRyZSB3cm90ZToNCj4gT24gMTIvMi8xMSAxOjQwIFBNLCBDYXJzdGVu IEJvcm1hbm4gd3JvdGU6DQo+PiBUaGUgbWludXRlcyBmb3IgdGhlIDIwMTAtMDgtMjUgKHllcyEg bm90IGEgdHlwbykgaW50ZXJpbSBtZWV0aW5nIGFyZSAoaW4gYSBzbGlnaHRseSBtYW5nbGVkIGZv cm0pIGF0Og0KPj4NCj4+ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRl cmltLzIwMTAvMDgvMjUvY29yZS9taW51dGVzL2NvcmUudHh0DQo+Pg0KPj4gSWYgeW91IGFyZSBv bGQgZW5vdWdoIHRvIGhhdmUgYmVlbiBhcm91bmQgd2hlbiB0aGlzICJ2aXJ0dWFsIGludGVyaW0i IHRvb2sgcGxhY2UsIHlvdSBtYXkgd2FudCB0byBjaGVjayBob3cgYmFkbHkgSSBtaXNyZXByZXNl bnRlZCB5b3VyIGNvbnRyaWJ1dGlvbiBpbiB0aG9zZSBtaW51dGVzLg0KPg0KPiBUaGFua3MsIENh cnN0ZW4hIEknbGwgY2hlY2sgdGhlbSBvdXQgbm93Lg0KDQpCVFcgdGhvc2UgbG9vayBnb29kIHRv IG1lLiBNb3JlIGNvbXByZWhlbnNpdmUgdGhhbiBJIGV4cGVjdGVkLiA6KQ0KDQovcHNhDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxp bmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb3JlDQoNCg== ------_=_NextPart_001_01CCB14A.E942D216 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHRpdGxlPlJlOiBbY29yZV0g SW52aXRhdGlvbiBmb3IgYSB0cmlwIHRvIHRoZSBkaXN0YW50IHBhc3Q6IDIwMTAtMDgtMjUgdmly dHVhbCBpbnRlcmltIG1pbnV0ZXMgYXJlIHVwPC90aXRsZT48c3R5bGU+PCEtLQ0KLyogRm9udCBE ZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9z ZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBs aW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+SGkgQ2Fyc3Rl biw8YnI+PGJyPlRoYW5rcy4gSSByZXZpZXdlZCB0aGUgbm90ZXMsIGFuZCBlc3BlY2lhbGx5IHRo ZSBzZWN0aW9ucyBtdWx0aWNhc3QgYW5kIHNsZWVwaW5nIG5vZGVzIHRoYXQgSSBwcmVzZW50ZWQu IFRoZSBub3RlcyBhbGlnbiB3ZWxsIHdpdGggbXkgbWVtb3J5LiBTbyBJIGFncmVlIHdpdGggdGhl bS48YnI+PGJyPkFrYmFyPGJyPjxicj48YnI+PGJyPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPjxiPkZyb206Jm5ic3A7PC9iPlBldGVyIFNhaW50LUFuZHJlIFs8YSBocmVmPSJtYWlsdG86 c3RwZXRlckBzdHBldGVyLmltIj5zdHBldGVyQHN0cGV0ZXIuaW08L2E+XTxicj48Yj5TZW50OiZu YnNwOzwvYj5GcmlkYXksIERlY2VtYmVyIDAyLCAyMDExIDA2OjEzIFBNIEVhc3Rlcm4gU3RhbmRh cmQgVGltZTxicj48Yj5UbzombmJzcDs8L2I+Q2Fyc3RlbiBCb3JtYW5uPGJyPjxiPkNjOiZuYnNw OzwvYj5jb3JlQGlldGYub3JnIFdHPGJyPjxiPlN1YmplY3Q6Jm5ic3A7PC9iPlJlOiBbY29yZV0g SW52aXRhdGlvbiBmb3IgYSB0cmlwIHRvIHRoZSBkaXN0YW50IHBhc3Q6IDIwMTAtMDgtMjUgdmly dHVhbCBpbnRlcmltIG1pbnV0ZXMgYXJlIHVwPGJyPjxicj48YnI+PG86cD48L286cD48L3A+PHA+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPk9uIDEyLzIvMTEgMTo0NCBQTSwgUGV0ZXIg U2FpbnQtQW5kcmUgd3JvdGU6PGJyPiZndDsgT24gMTIvMi8xMSAxOjQwIFBNLCBDYXJzdGVuIEJv cm1hbm4gd3JvdGU6PGJyPiZndDsmZ3Q7IFRoZSBtaW51dGVzIGZvciB0aGUgMjAxMC0wOC0yNSAo eWVzISBub3QgYSB0eXBvKSBpbnRlcmltIG1lZXRpbmcgYXJlIChpbiBhIHNsaWdodGx5IG1hbmds ZWQgZm9ybSkgYXQ6PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAx MC8wOC8yNS9jb3JlL21pbnV0ZXMvY29yZS50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvaW50ZXJpbS8yMDEwLzA4LzI1L2NvcmUvbWludXRlcy9jb3JlLnR4dDwvYT48YnI+Jmd0 OyZndDs8YnI+Jmd0OyZndDsgSWYgeW91IGFyZSBvbGQgZW5vdWdoIHRvIGhhdmUgYmVlbiBhcm91 bmQgd2hlbiB0aGlzICZxdW90O3ZpcnR1YWwgaW50ZXJpbSZxdW90OyB0b29rIHBsYWNlLCB5b3Ug bWF5IHdhbnQgdG8gY2hlY2sgaG93IGJhZGx5IEkgbWlzcmVwcmVzZW50ZWQgeW91ciBjb250cmli dXRpb24gaW4gdGhvc2UgbWludXRlcy48YnI+Jmd0Ozxicj4mZ3Q7IFRoYW5rcywgQ2Fyc3RlbiEg SSdsbCBjaGVjayB0aGVtIG91dCBub3cuPGJyPjxicj5CVFcgdGhvc2UgbG9vayBnb29kIHRvIG1l LiBNb3JlIGNvbXByZWhlbnNpdmUgdGhhbiBJIGV4cGVjdGVkLiA6KTxicj48YnI+L3BzYTxicj48 YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Y29y ZSBtYWlsaW5nIGxpc3Q8YnI+Y29yZUBpZXRmLm9yZzxicj48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY29yZTwvYT48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9ib2R5Pjwv aHRtbD4= ------_=_NextPart_001_01CCB14A.E942D216-- From zach@sensinode.com Mon Dec 5 07:10:57 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 0563821F8A57 for ; Mon, 5 Dec 2011 07:10:57 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLlsRgRlK3gO for ; Mon, 5 Dec 2011 07:10:55 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 667B421F861E for ; Mon, 5 Dec 2011 07:10:54 -0800 (PST) Received: from [192.168.1.101] (188-67-125-78.bb.dnainternet.fi [188.67.125.78]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id pB5FAos4012487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Dec 2011 17:10:51 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-71--954218629; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <031DD135F9160444ABBE3B0C36CED61801E1FD@011-DB3MPN1-012.MGDPHG.emi.philips.com> Date: Mon, 5 Dec 2011 17:10:48 +0200 Message-Id: References: <2F008BD6-3D3D-4772-8289-08A8AF098AAA@tzi.org> <031DD135F9160444ABBE3B0C36CED61801E1FD@011-DB3MPN1-012.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] Second WGLC for draft-ietf-core-link-format-09.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, 05 Dec 2011 15:10:57 -0000 --Apple-Mail-71--954218629 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Esko, Thanks again for the useful review, I see Carsten and others have = discussed most of these. Now I will be making what I can into tickets. = The editorial fixes I will make directly in the update. See some = comments in-line. On Nov 28, 2011, at 1:02 PM, Dijk, Esko wrote: > Dear Carsten, >=20 > I reviewed the changes (diff v3/v9) and text surrounding the changes; = see comments below. The first three points should be clarified or fixed = in my view. In general, the document looks in good shape. >=20 > ** Relation type: RFC5988 supports multiple relations in one = string/entry. Should we support this or explicitly (e.g. "SHOULD NOT") = exclude this in CoRE Link Format context? For example: > rel=3D"http://example.com/myRelationType1 = http://example.com/myRelationType2 describedby" >=20 > This may be an issue if a constrained client is looking for a = "describedby" relation using the byte-wise string comparison suggested = by core-link-format: it would not match to above string unfortunately. = Also, it causes problems if the "rel" value is stored on a CoRE server = as one key/value pair and if I would do a query with resource-param =3D = "rel" to look for a specific relation type such as "describedby", or = "copyright" or "http://example.com/myRelationType2". Again, this would = not match as it is not bytewise identical as defined in core-link-format = as the matching criterion. One solution would be to state in = core-link-format something like "the value of a "rel" parameter SHOULD = NOT contain more than one relation type" i.e. optimize the use of = RFC5988 a bit for constrained environments by constraining its = flexibility. Another solution approach is to provide more guidance in = how to do the matching in case of the "rel" attribute. Yet another = solution approach is to allow multiple relations in one "rel" value, but = add some mandatory implementation guidance that multiple, say N, = relations should be stored as N separate relations so these can be = individually found using filtering/querying. I really don't expect arbitrary relations types to be used much in CoRE, = and don't see the need for multiple at all. I agree that this can be = defined as a SHOULD NOT. Will make a ticket on this. > ** use of "quoted-string" in ABNF definitions - should be a regular = string, not "quoted-string" here? > link-extension =3D/ ( "rt=3D" quoted-string ) > link-extension =3D/ ( "if=3D" quoted-string ) I will reply to the thread on this one. >=20 > ** Unclear sentence (for me) "A query-pattern of "*" will match that = resource-param with an empty string value." > Was it intended that "*" matches to an empty string value as well as = to any other non-empty string ? Correct. I will clarify this as an editorial issue. > Or does this sentence intend to clarify that if the query is "*" then = the string prefix matching process will use an empty string as the = string to match all values against? (In which case, also all value = strings will match). > Or both? >=20 > ** Multicast and filtering: > "A multicast request with a query string MUST NOT be responded > to if filtering is not supported or if the filter does not match (to > avoid a needless response storm)." > I'm thinking if this could also be a "SHOULD NOT" requirement, but = perhaps there's a good reason why "MUST NOT" is used here. If anyone on = the list has further opinions on this, I would be interested. We discussed this a bit with Carsten, and there is a case where SHOULD = NOT makes sense. Not all POSIX interfaces are able to tell that the = source address was multicast. I suggest a ticket to change this to = SHOULD NOT, with an explanation of this exception. Will make this a = ticket. Thanks for the editorial comments below. Zach > ** Minor issues and typos > - Just a thought: In the intro e.g. section 1.1 or 1.2 we could add = explicitly that CoRE Link Format can be applied in for example HTTP = servers or CoAP servers. Some people may unconsciously and wrongly = associate "CoRE Link Format" to "CoAP link format" e.g. due to its = previous linkage to CoAP Content Types and "ct" attribute. >=20 > - "Removed the assumption of a default content-type assumption" >=20 > - "To express other relations a links can make use of" >=20 > - "To express other relations a links can make use of any registered > relation parameter or target attributes by including the relation = parameter." > So, a link can make use of a relation parameter by including the = relation parameter - does not seem to add much, it's obvious? If I = include something I use it. Or was it meant "...use of any registered = relation or target attributes..." ? >=20 > - In below text, the first and second example looks exactly the same, = contradicting the text: > """ > ;rt=3D"TemperatureC";if=3D"sensor", > ;rt=3D"LightLux";if=3D"sensor" > Without the linefeeds included for readability, the format actually > looks as follows. > ;rt=3D"TemperatureC";if=3D"sensor", > ;rt=3D"LightLux";if=3D"sensor" > """ >=20 > - "When using a transfer protocol like the Constrained Application > Protocol (CoAP) that supports multicast requests, special care is = taken." > Perhaps "is taken" -> "needs to be taken" ? >=20 > - "interface description" vs "Interface Description" - are they the = same thing? If so use same capitalization. >=20 > - "Resource registration can be archived by having each server POST" = -> ..."can be achieved" >=20 > best regards, > Esko >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Carsten Bormann > Sent: Thursday 17 November 2011 5:13 > To: core WG > Subject: [core] Second WGLC for draft-ietf-core-link-format-09.txt >=20 > On January 16 this year, core-link-format-02 finished working group = last call. > On March 15, the -03 draft incorporated the changes from the comments = received on this WGLC. >=20 > Since that update, the draft has experienced some Brownian motion. > Changes were made e.g. to adapt the examples to some coap-core = changes, to clarify the use of UTF-8, to address AD comments, and to = properly distribute the normative content between the different CoRE = specs. > With -09, we now have a version that passes all ID-Nits. > While I personally think it could be justified to send this on to the = IESG as is, I also think that might be considered bad form. >=20 > So I'm announcing today a >=20 > second working-group last call > for draft-ietf-core-link-format-09.txt >=20 > This is a one-week WGLC, but time does not pass during an IETF. > So please send in any comments to the CoRE list now, or latest until >=20 > 2011-11-28, 1200 UTC. >=20 > A short note of the form "I've re-read -09 and it's OK" would also be = very welcome. >=20 > Gruesse, Carsten >=20 > PS.: You can use > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-link-format-09&url1=3D= draft-ietf-core-link-format-03 > to review the changes since -03. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > ________________________________ > The information contained in this message may be confidential and = legally protected under applicable law. 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 is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. >=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-71--954218629 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb +JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh 5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL 7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7 btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4 mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9 OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1 qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEyMDUx NTEwNDhaMCMGCSqGSIb3DQEJBDEWBBSAtjauDvtaipjokg+nsd2ERrGJDzCCAQMGCSsGAQQBgjcQ BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6 Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd uDANBgkqhkiG9w0BAQEFAASCAQCwAA1Cqd15DOzXzkEg1U63fej66kN3m/L6o7ujUQ+jJtgT4M8I GGRvs7FuOKbNRrBu6M+pejWDA7vnOPBOtB9dlFRdYUDa3ILgDUpPzwg6+PaOj3bHOpJRSzTd7ldP 9CP1f4T3eBijJTm7sxqU6c65iF1idMChXdrngVLAAy2mGPWN+QVaJFPjUZePSrjqcdPz+w4keusM Y86ZTWDj9+xqqS8hDGLRgcI9HO5vN/SEYLdMZGTptQGSqLVtyxsqtOVQluBm3BJxdO6tKPVtd3xh Fc6tq2OQM1g+pwoOfaU+GU6bUy4Fo53cG/J7+LuBmBpWQmOgLDlhRfprsyUd8Nu3AAAAAAAA --Apple-Mail-71--954218629-- From zach@sensinode.com Mon Dec 5 07:19:21 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 D681021F8B66 for ; Mon, 5 Dec 2011 07:19:21 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hPbjwO-EJI2 for ; Mon, 5 Dec 2011 07:19:21 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCD121F8B26 for ; Mon, 5 Dec 2011 07:19:14 -0800 (PST) Received: from [192.168.1.101] (188-67-125-78.bb.dnainternet.fi [188.67.125.78]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id pB5FJ5DB017300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Dec 2011 17:19:09 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-72--953722502; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <031DD135F9160444ABBE3B0C36CED61801E256@011-DB3MPN1-012.MGDPHG.emi.philips.com> Date: Mon, 5 Dec 2011 17:19:04 +0200 Message-Id: <6A62CEA7-9ED7-4561-B9A7-ACE04CE4C7FA@sensinode.com> References: <2F008BD6-3D3D-4772-8289-08A8AF098AAA@tzi.org> <031DD135F9160444ABBE3B0C36CED61801E1FD@011-DB3MPN1-012.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61801E256@011-DB3MPN1-012.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] Second WGLC for draft-ietf-core-link-format-09.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, 05 Dec 2011 15:19:21 -0000 --Apple-Mail-72--953722502 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 28, 2011, at 2:34 PM, Dijk, Esko wrote: > Thanks Carsten, >=20 > My mistake; "quoted-string" does indeed occur in all the = application/link-format examples given. I wrote this after seeing = unquoted values in example queries (as in GET = /.well-known/core?rt=3DLightLux) in which the query pattern is a ptoken. >=20 > Thinking of this, I can in theory name a resource type like > rt=3D"outdoor temperature" > but querying it would not be possible like this (ptoken does not allow = space, char 0x20): > GET /.well-known/core?rt=3Doutdoor temperature > with current web server query conventions it could be phrased as: > GET /.well-known/core?rt=3Doutdoor+temperature >=20 > Maybe a preferred solution for such cases could be indicated in the = I-D? (One pragmatic solution is stating that values with whitespace = characters are to be avoided. Or maybe define a quoted-ptoken type?) Does this really affect us between CoAP end-points? Yes, obviously those = examples are a bit misleading as that would not be allowed in a = browser's URL line or in HTTP. But as we are normalizing this to UTF-8 = in the Uri-Query option the space (or other binary data) would just be = included there as UTF-8. An HTTP proxy would have to normalize this to = UTF-8 as well.=20 Zach >=20 > regards, > Esko >=20 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Monday 28 November 2011 12:36 > To: Dijk, Esko > Cc: core WG; Zach Shelby > Subject: Re: [core] Second WGLC for draft-ietf-core-link-format-09.txt >=20 > Hi Esko, >=20 > these are very useful comments. >=20 > I don't understand this one, though: >=20 > On Nov 28, 2011, at 12:02, Dijk, Esko wrote: >=20 >> ** use of "quoted-string" in ABNF definitions - should be a regular = string, not "quoted-string" here? >> link-extension =3D/ ( "rt=3D" quoted-string ) >> link-extension =3D/ ( "if=3D" quoted-string ) >=20 > =46rom RFC 2616 we import via RFC 5988: >=20 > A string of text is parsed as a single word if it is quoted using > double-quote marks. >=20 > quoted-string =3D ( <"> *(qdtext | quoted-pair ) <"> ) > qdtext =3D > >=20 > The backslash character ("\") MAY be used as a single-character > quoting mechanism only within quoted-string and comment constructs. >=20 > quoted-pair =3D "\" CHAR >=20 > Is this not exactly what we want to have? > As in: >=20 > ;rt=3D"TemperatureC";if=3D"sensor", > ;rt=3D"LightLux";if=3D"sensor" >=20 > An alternative would be ptoken, as in: >=20 > ;rt=3DTemperatureC;if=3Dsensor, > ;rt=3DLightLux;if=3Dsensor >=20 > Entirely switching to ptoken appears somewhat restrictive to me, but = could be argued for. Certainly the following looks a bit strange, but = would indeed be easy to parse. >=20 > = ;rt=3Dhttp://tzi.org/isq/temp&unit=3Dcentikelvin;if=3Dsenso= r, > ;rt=3DLightLux;if=3Dhttp://tzi.org/w/lightsensor.wadl >=20 > Allowing both ptoken and quoted-string appears to be unneeded = complexity. >=20 > Gr=FC=DFe, Carsten >=20 >=20 > ________________________________ > The information contained in this message may be confidential and = legally protected under applicable law. 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 is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. >=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-72--953722502 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb +JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh 5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL 7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7 btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4 mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9 OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1 qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEyMDUx NTE5MDVaMCMGCSqGSIb3DQEJBDEWBBSDKzAioSAypsNeTG0S4OFZKfPRaDCCAQMGCSsGAQQBgjcQ BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6 Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd uDANBgkqhkiG9w0BAQEFAASCAQCNX7twG3zyzptdQtMqxpC2Srmn/pM1HEo9zXg+hIaIM9VGYva1 7BFLgdz8jyDYeBZcLOIqaVRCLUdbZwo77L73matzY0quKWtbI7pqdxWFJ2XYXxbW1ukyhJhOC9gQ Vgx4BSnpw50Lsyluq1fK+TfMFTjq7B5EhFYPqWxCzNrJtopZ43lwG++Tfv0ECBFw4boVnYlRS4/U QDNf3eIuvqDr7hs7z6lTDRTrCgXTEtMknV653rp0pAsw6Y1+T4aFkJY5KRuFhwyn+E6No2FKujPa mqE6cmlO4Ia6FgubjhtfWpHKKsnvvlaMId1Ga51SJHqb8czMuORCRLlOCr3l/LN2AAAAAAAA --Apple-Mail-72--953722502-- From trac+core@trac.tools.ietf.org Mon Dec 5 07:29:50 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 7865421F8B9C for ; Mon, 5 Dec 2011 07:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-lj7SBhETKy for ; Mon, 5 Dec 2011 07:29:49 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A9D9D21F8B61 for ; Mon, 5 Dec 2011 07:29:49 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RXaUE-0008Mc-90; Mon, 05 Dec 2011 10:29:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Mon, 05 Dec 2011 15:29:45 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/178 Message-ID: <057.844edd48abdc531fbb6f5bee1c508a7c@trac.tools.ietf.org> X-Trac-Ticket-ID: 178 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 gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #178: Multiple relation types 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: Mon, 05 Dec 2011 15:29:50 -0000 #178: Multiple relation types This ticket is to explicitly state that multiple relation types SHOULD NOT be included in a CoRE Link Format rel= attribute. There are cases where multiple relation types may need to be included for example when an RFC5988 link is represented in CoRE Link Format. From Esko Dijk's WGLC review: ** Relation type: RFC5988 supports multiple relations in one string/entry. Should we support this or explicitly (e.g. "SHOULD NOT") exclude this in CoRE Link Format context? For example: rel="http://example.com/myRelationType1 http://example.com/myRelationType2 describedby" This may be an issue if a constrained client is looking for a "describedby" relation using the byte-wise string comparison suggested by core-link-format: it would not match to above string unfortunately. Also, it causes problems if the "rel" value is stored on a CoRE server as one key/value pair and if I would do a query with resource-param = "rel" to look for a specific relation type such as "describedby", or "copyright" or "http://example.com/myRelationType2". Again, this would not match as it is not bytewise identical as defined in core-link-format as the matching criterion. One solution would be to state in core-link-format something like "the value of a "rel" parameter SHOULD NOT contain more than one relation type" i.e. optimize the use of RFC5988 a bit for constrained environments by constraining its flexibility. Another solution approach is to provide more guidance in how to do the matching in case of the "rel" attribute. Yet another solution approach is to allow multiple relations in one "rel" value, but add some mandatory implementation guidance that multiple, say N, relations should be stored as N separate relations so these can be individually found using filtering/querying. -- ----------------------------------+-------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: new Priority: minor | Milestone: Component: link-format | Version: Severity: - | Keywords: ----------------------------------+-------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Dec 5 07:31:46 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 2C17721F8B6B for ; Mon, 5 Dec 2011 07:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzp9IweldozL for ; Mon, 5 Dec 2011 07:31:45 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id AFB7321F8B54 for ; Mon, 5 Dec 2011 07:31:45 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RXaW9-0003sR-DT; Mon, 05 Dec 2011 10:31:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Mon, 05 Dec 2011 15:31:45 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/core/trac/ticket/179 Message-ID: <057.b550ac0ced2490f3acc0108f7b943113@trac.tools.ietf.org> X-Trac-Ticket-ID: 179 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 gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #179: SHOULD NOT for multicast response repression 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: Mon, 05 Dec 2011 15:31:46 -0000 #179: SHOULD NOT for multicast response repression This ticket is to make multicast response repression a SHOULD NOT, as there are cases where some POSIX interfaces do not make multicast source address information available. From Esko Dijk's WGLC review: ** Multicast and filtering: "A multicast request with a query string MUST NOT be responded to if filtering is not supported or if the filter does not match (to avoid a needless response storm)." I'm thinking if this could also be a "SHOULD NOT" requirement, but perhaps there's a good reason why "MUST NOT" is used here. If anyone on the list has further opinions on this, I would be interested. -- ----------------------------------+-------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: new Priority: minor | Milestone: Component: link-format | Version: Severity: - | Keywords: ----------------------------------+-------------------- Ticket URL: core From esko.dijk@philips.com Mon Dec 5 07:33:14 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 C54F221F8B61 for ; Mon, 5 Dec 2011 07:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.839 X-Spam-Level: X-Spam-Status: No, score=-4.839 tagged_above=-999 required=5 tests=[AWL=1.760, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CO4Gna-yTap for ; Mon, 5 Dec 2011 07:33:13 -0800 (PST) Received: from TX2EHSOBE006.bigfish.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAD921F8BC3 for ; Mon, 5 Dec 2011 07:33:13 -0800 (PST) Received: from mail1-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Dec 2011 15:33:13 +0000 Received: from mail1-tx2 (localhost [127.0.0.1]) by mail1-tx2-R.bigfish.com (Postfix) with ESMTP id 23359200144; Mon, 5 Dec 2011 15:33:13 +0000 (UTC) X-SpamScore: -30 X-BigFish: VPS-30(zz217bL15d6O9371K9251Jc89bh542M1432N98dKzz1202hzz8275ch8275bh8275dhz2dhb2ch2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-FB-SS: 0, Received: from mail1-tx2 (localhost.localdomain [127.0.0.1]) by mail1-tx2 (MessageSwitch) id 1323099192865012_26827; Mon, 5 Dec 2011 15:33:12 +0000 (UTC) Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.242]) by mail1-tx2.bigfish.com (Postfix) with ESMTP id CE2DE600045; Mon, 5 Dec 2011 15:33:12 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 5 Dec 2011 15:33:11 +0000 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.218]) by 011-DB3MMR1-010.MGDPHG.emi.philips.com ([10.128.28.49]) with mapi id 14.01.0355.003; Mon, 5 Dec 2011 15:33:09 +0000 From: "Dijk, Esko" To: Zach Shelby Thread-Topic: [core] Second WGLC for draft-ietf-core-link-format-09.txt Thread-Index: AQHMpN8raIOMnRP2+EekD7Ivap+WRpXCIIeQgAAZiACAAAJVEIALPFAAgAACE2A= Date: Mon, 5 Dec 2011 15:33:09 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61801F48C@011-DB3MPN1-012.MGDPHG.emi.philips.com> References: <2F008BD6-3D3D-4772-8289-08A8AF098AAA@tzi.org> <031DD135F9160444ABBE3B0C36CED61801E1FD@011-DB3MPN1-012.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61801E256@011-DB3MPN1-012.MGDPHG.emi.philips.com> <6A62CEA7-9ED7-4561-B9A7-ACE04CE4C7FA@sensinode.com> In-Reply-To: <6A62CEA7-9ED7-4561-B9A7-ACE04CE4C7FA@sensinode.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: core WG Subject: Re: [core] Second WGLC for draft-ietf-core-link-format-09.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, 05 Dec 2011 15:33:14 -0000 To clarify ; the problem I still see is that section 4.1 defines the query = pattern to be a 'ptoken' type, which does not allow spaces nor arbitrary UT= F-8. So I assume a CoAP server implementer may decide to let his/her server= reply with error on any query pattern containing a space? Esko -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com]=20 Sent: Monday 5 December 2011 16:19 To: Dijk, Esko Cc: Carsten Bormann; core WG Subject: Re: [core] Second WGLC for draft-ietf-core-link-format-09.txt On Nov 28, 2011, at 2:34 PM, Dijk, Esko wrote: > Thanks Carsten, >=20 > My mistake; "quoted-string" does indeed occur in all the application/link= -format examples given. I wrote this after seeing unquoted values in exampl= e queries (as in GET /.well-known/core?rt=3DLightLux) in which the query pa= ttern is a ptoken. >=20 > Thinking of this, I can in theory name a resource type like > rt=3D"outdoor temperature" > but querying it would not be possible like this (ptoken does not allow sp= ace, char 0x20): > GET /.well-known/core?rt=3Doutdoor temperature > with current web server query conventions it could be phrased as: > GET /.well-known/core?rt=3Doutdoor+temperature >=20 > Maybe a preferred solution for such cases could be indicated in the I-D? = (One pragmatic solution is stating that values with whitespace characters a= re to be avoided. Or maybe define a quoted-ptoken type?) Does this really affect us between CoAP end-points? Yes, obviously those ex= amples are a bit misleading as that would not be allowed in a browser's URL= line or in HTTP. But as we are normalizing this to UTF-8 in the Uri-Query = option the space (or other binary data) would just be included there as UTF= -8. An HTTP proxy would have to normalize this to UTF-8 as well.=20 Zach >=20 > regards, > Esko >=20 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Monday 28 November 2011 12:36 > To: Dijk, Esko > Cc: core WG; Zach Shelby > Subject: Re: [core] Second WGLC for draft-ietf-core-link-format-09.txt >=20 > Hi Esko, >=20 > these are very useful comments. >=20 > I don't understand this one, though: >=20 > On Nov 28, 2011, at 12:02, Dijk, Esko wrote: >=20 >> ** use of "quoted-string" in ABNF definitions - should be a regular stri= ng, not "quoted-string" here? >> link-extension =3D/ ( "rt=3D" quoted-string ) >> link-extension =3D/ ( "if=3D" quoted-string ) >=20 > From RFC 2616 we import via RFC 5988: >=20 > A string of text is parsed as a single word if it is quoted using > double-quote marks. >=20 > quoted-string =3D ( <"> *(qdtext | quoted-pair ) <"> ) > qdtext =3D > >=20 > The backslash character ("\") MAY be used as a single-character > quoting mechanism only within quoted-string and comment constructs. >=20 > quoted-pair =3D "\" CHAR >=20 > Is this not exactly what we want to have? > As in: >=20 > ;rt=3D"TemperatureC";if=3D"sensor", > ;rt=3D"LightLux";if=3D"sensor" >=20 > An alternative would be ptoken, as in: >=20 > ;rt=3DTemperatureC;if=3Dsensor, > ;rt=3DLightLux;if=3Dsensor >=20 > Entirely switching to ptoken appears somewhat restrictive to me, but coul= d be argued for. Certainly the following looks a bit strange, but would in= deed be easy to parse. >=20 > ;rt=3Dhttp://tzi.org/isq/temp&unit=3Dcentikelvin;if=3Dse= nsor, > ;rt=3DLightLux;if=3Dhttp://tzi.org/w/lightsensor.wadl >=20 > Allowing both ptoken and quoted-string appears to be unneeded complexity. >=20 > Gr=FC=DFe, Carsten >=20 >=20 > ________________________________ > The information contained in this message may be confidential and legally= protected under applicable law. The message is intended solely for the add= ressee(s). If you are not the intended recipient, you are hereby notified t= hat any use, forwarding, dissemination, or reproduction of this message is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original message. >=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 From prvs=2321FA556D=guido.moritz@uni-rostock.de Tue Dec 6 03:17: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 C527421F8B10 for ; Tue, 6 Dec 2011 03:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eChw9yNb6ZM for ; Tue, 6 Dec 2011 03:17:06 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id B852621F8B0F for ; Tue, 6 Dec 2011 03:17:05 -0800 (PST) From: Guido Moritz To: References: <057.b550ac0ced2490f3acc0108f7b943113@trac.tools.ietf.org> In-Reply-To: <057.b550ac0ced2490f3acc0108f7b943113@trac.tools.ietf.org> Date: Tue, 6 Dec 2011 12:17:01 +0100 Message-ID: <002301ccb408$93a64ff0$baf2efd0$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJHNxfS5qxpmVKfa663eCoj4+Kx0ZTZnh2A Content-Language: de X-Originating-IP: [139.30.201.226] Subject: Re: [core] #179: SHOULD NOT for multicast response repression 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, 06 Dec 2011 11:17:06 -0000 I think the most important issue here is that the server supports = filtering only optionally. If the filter does not match there is no = response. Quite obvious for me. But what if the server does not support = filtering at all? The first thing that comes into my mind is how I would implement a = client. I am not sure, but does a client have a (obvious and straight = forward) possibility to find out if the server supports filtering? = Otherwise I would not use filtering in my client implementation, because = I may miss servers that don't implement it. Maybe a possible solution would be to separate those two cases (1) = filter does not match MUST NOT be responded and (2) filtering is not = supported SHOULD NOT be responded. But I am not sure if SHOULD NOT is = sufficient. It might still result in client implementations which do not = use filtering and this in turn causes a real response storm. Guido > -----Urspr=C3=BCngliche Nachricht----- > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von > core issue tracker > Gesendet: Montag, 5. Dezember 2011 16:32 > An: zach@sensinode.com > Cc: core@ietf.org > Betreff: [core] #179: SHOULD NOT for multicast response repression >=20 > #179: SHOULD NOT for multicast response repression >=20 > This ticket is to make multicast response repression a SHOULD NOT, as > there are cases where some POSIX interfaces do not make multicast = source > address information available. >=20 > From Esko Dijk's WGLC review: >=20 > ** Multicast and filtering: > "A multicast request with a query string MUST NOT be responded > to if filtering is not supported or if the filter does not match (to > avoid a needless response storm)." > I'm thinking if this could also be a "SHOULD NOT" requirement, but = perhaps > there's a good reason why "MUST NOT" is used here. If anyone on the = list > has further opinions on this, I would be interested. >=20 > -- > ----------------------------------+-------------------- > Reporter: zach@=E2=80=A6 | Owner: = zach@=E2=80=A6 > Type: protocol enhancement | Status: new > Priority: minor | Milestone: > Component: link-format | Version: > Severity: - | Keywords: > ----------------------------------+-------------------- >=20 > Ticket URL: > core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From stpeter@stpeter.im Wed Dec 7 14:26: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 1C1E521F8B53 for ; Wed, 7 Dec 2011 14:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.723 X-Spam-Level: X-Spam-Status: No, score=-102.723 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0skhj+cPO9ck for ; Wed, 7 Dec 2011 14:26:04 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB8F21F8B16 for ; Wed, 7 Dec 2011 14:26:04 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 187E84234D for ; Wed, 7 Dec 2011 15:33:22 -0700 (MST) Message-ID: <4EDFE7FA.7020000@stpeter.im> Date: Wed, 07 Dec 2011 15:26:02 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: core WG X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [core] review of draft-ietf-core-link-format 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, 07 Dec 2011 22:26:05 -0000 Herewith some comments on draft-ietf-core-link-format... Issues... 1. We define link as: Also called "typed links" in RFC5988. A link is a typed connection between two resources identified by URIs. Made up of a context URI, a link relation type, a target URI, and optional target attributes. However, RFC 5988 calls them IRIs, not URIs. Can these in fact be IRIs? What exactly is the internationalization story here? 2. Have we requested a review of the "application/link-format" media type on the ietf-types@ietf.org list, per RFC 4288? I don't see a message about it in the archives, but I know that the archives might not be fully reliable. http://www.ietf.org/mail-archive/web/ietf-types/current/maillist.html 3. Have we requested a review of the "core" well-known URL on the wellknown-uri-review@ietf.org list, per RFC 5785? I don't see a message about it in the archives: http://www.ietf.org/mail-archive/web/wellknown-uri-review/current/maillist.html 4. Have we requested a review of the "hosts" link relation type on the link-relations@ietf.org list, per RFC 5988? I don't see a message about it in the archives: http://www.ietf.org/mail-archive/web/link-relations/current/maillist.html 5. It seems that the request URI can contain somewhat sensitive information (e.g., a filter). How exactly is the request protected? Does this need to be specified more clearly in Section 6? Nits... It's "media type", not "MIME type". Please always include /.well-known/core in quotes within running text. There are some bad line breaks, so "/.well-known/core" is more readable. Please cite RFC 5785 on first mention of well-known URI. We say: As in [RFC5988], multiple link descriptions are separated by commas. Note that commas can also occur in quoted strings and URIs but do not end a description. Mightn't that cause confusion? Some examples would help in Section 2.1 ("Target and context URIs") and elsewhere. "When attributes are compared, they MUST be compared as strings." Do you mean byte-for-byte comparison, or something else? The URN examples are far-fetched. For example "urn:myapp:sensor" would never be assigned. See RFC 3406. The "Big" thing in Section 3.3 is kind of hacky. :) Peter -- Peter Saint-Andre https://stpeter.im/ From cabo@tzi.org Wed Dec 7 14:50: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 4848811E8099 for ; Wed, 7 Dec 2011 14:50:34 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2lLDHV9cU9R for ; Wed, 7 Dec 2011 14:50:33 -0800 (PST) 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 845D711E808B for ; Wed, 7 Dec 2011 14:50:33 -0800 (PST) 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 pB7MoNgR026074; Wed, 7 Dec 2011 23:50:23 +0100 (CET) Received: from [192.168.217.110] (p54899A34.dip.t-dialin.net [84.137.154.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A1F69765; Wed, 7 Dec 2011 23:50:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4EDFE7FA.7020000@stpeter.im> Date: Wed, 7 Dec 2011 23:50:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7A12608D-31B6-46C6-886E-8E6FEF8F17E5@tzi.org> References: <4EDFE7FA.7020000@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1251.1) Cc: core WG Subject: Re: [core] review of draft-ietf-core-link-format 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, 07 Dec 2011 22:50:34 -0000 On Dec 7, 2011, at 23:26, Peter Saint-Andre wrote: > We say: >=20 > As in [RFC5988], multiple link > descriptions are separated by commas. Note that commas can also > occur in quoted strings and URIs but do not end a description. >=20 > Mightn't that cause confusion? Yes, that's why it is a good idea to call this out explicitly. So, when you parse this stuff, you want to skip the and "quoted" = segments and only look for commas outside them. But that can be done with a very simple state machine. (At least we no longer have the comma-separated values for the ct=3D = attribute.) Gr=FC=DFe, Carsten From hannes.tschofenig@gmx.net Sat Dec 10 06:02:24 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 4224421F8B1D for ; Sat, 10 Dec 2011 06:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dd96mqaI1Jt3 for ; Sat, 10 Dec 2011 06:02:23 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1EEB221F8B1B for ; Sat, 10 Dec 2011 06:02:22 -0800 (PST) Received: (qmail invoked by alias); 10 Dec 2011 14:02:21 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.216.191] by mail.gmx.net (mp060) with SMTP; 10 Dec 2011 15:02:21 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1884GZV8J488JoJtnsuiot/x5KQRrc3bPeTRJf2kk 6yAMo84WkgdjwX Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Hannes Tschofenig Date: Sat, 10 Dec 2011 16:02:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24946D2C-456C-4DA9-90EE-2342D9E900A6@gmx.net> References: <83501846-AB99-4F88-98DB-122C96F2AA39@cisco.com> To: "core Environments) WG" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [core] Fwd: [TLS] Consensus for adoption of draft-wouters-tls-oob-pubkey-02 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, 10 Dec 2011 14:02:24 -0000 Joe has initiated a consensus call on the document that utilizes raw = public keys in TLS.=20 Please state your support for it on the TLS mailing list.=20 Thanks! Begin forwarded message: > From: Joe Salowey > Date: November 30, 2011 11:43:48 PM GMT+02:00 > To: tls@ietf.org > Subject: [TLS] Consensus for adoption of = draft-wouters-tls-oob-pubkey-02 >=20 > The chairs would like to confirm the consensus of the TLS working = group to adopt draft-wouters-tls-oob-pubkey-02 as a working group item. = There was strong interest in this document at previous IETF meetings and = the controversial options dealing with only providing public key hashes = have been removed. Please respond to the following questions by = December 14, 2011: >=20 > - Do you object to taking this draft on as working group item? (Please = state the reason for you objection) >=20 > - Would you contribute time to review and provide text for the = document when needed? >=20 > Thanks, >=20 > Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From prvs=9327EBA1AE=guido.moritz@uni-rostock.de Mon Dec 12 08:02: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 C3BD221F8B3C for ; Mon, 12 Dec 2011 08:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAe5teS0mt5T for ; Mon, 12 Dec 2011 08:02:23 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id C947921F8B33 for ; Mon, 12 Dec 2011 08:02:22 -0800 (PST) From: Guido Moritz To: 'core' Date: Mon, 12 Dec 2011 17:02:21 +0100 Message-ID: <006601ccb8e7$6e7aa7b0$4b6ff710$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acy45XvyMSra5o5YT9WDcS2xN9kaHg== Content-Language: de X-Originating-IP: [139.30.201.226] Subject: [core] Proxy Meda Type Conversion 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, 12 Dec 2011 16:02:23 -0000 Dear WG, I have a question I cannot answer myself and would be interested in your thoughts and comments. It is maybe somewhat strange, but might be important in the sense of usage of CoAP in existing environments. As far as I know there is currently no mechanism in CoAP to realize what I describe below. If I am wrong, please forget about this mail and do more important things (please can you give me a hint to the solution in this case anyway). Let's assume an application in the unconstrained world which is using HTTP and XML for the data representation. We don't want to change this implementation completely and so we advise the CoAP/HTTP Proxy to do the required conversions of CoAP and HTTP when communicating with the 6LoWPAN. But there are optimized encodings existing also for the XML part. EXI is a good candidate, but let's not limit to it. So we have several optimized serialization formats for one and the same data, which can also be mapped seamless, transparent and stateless in the proxy. Is there a mechanism in the proxy spec to advise the proxy to (re-)encode also the payload? Of course the endpoints have to advise the proxy explicitly, because the proxy is stateless over different request. I was thinking about some weird usage of the Accept-Option, but I didn't come to a comprehensive conclusion. Btw, please don't ask me about the specific application I have in mind. It is (again) about usage of SOAP in 6LoWPANs and related to the SOAP-over-CoAP idea. Hence, you will not like my answer to the question about the application scenario anyway. :) Regards, Guido From tianlinyi@huawei.com Mon Dec 12 21:20: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 A06DC11E809B for ; Mon, 12 Dec 2011 21:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDIKogXV5nQZ for ; Mon, 12 Dec 2011 21:20:55 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD4311E8099 for ; Mon, 12 Dec 2011 21:20:55 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW400JWGMTXTL@szxga05-in.huawei.com> for core@ietf.org; Tue, 13 Dec 2011 13:20:21 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW400IAFMT12L@szxga05-in.huawei.com> for core@ietf.org; Tue, 13 Dec 2011 13:20:21 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFQ19544; Tue, 13 Dec 2011 13:20:20 +0800 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Dec 2011 13:20:18 +0800 Received: from SZXEML513-MBS.china.huawei.com ([169.254.6.108]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Tue, 13 Dec 2011 13:20:19 +0800 Date: Tue, 13 Dec 2011 05:20:17 +0000 From: TianLinyi In-reply-to: <006601ccb8e7$6e7aa7b0$4b6ff710$@uni-rostock.de> X-Originating-IP: [10.70.109.97] To: Guido Moritz , 'core' Message-id: <3615F3CCD55F054395A882F51C6E5FDA1822178F@szxeml513-mbs.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] Proxy Meda Type Conversion Thread-index: Acy45XvyMSra5o5YT9WDcS2xN9kaHgAcI7UA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <006601ccb8e7$6e7aa7b0$4b6ff710$@uni-rostock.de> Subject: Re: [core] Proxy Meda Type Conversion 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, 13 Dec 2011 05:20:56 -0000 Hi, Guido It is not clear to me what the following question means. "Is there a mechanism in the proxy spec to advise the proxy to (re-)encode also the payload?" Do you mean that the proxy needs to parse the payload in Exi format to another format to be included in the coap message? There are some binary xml format, e.g. WBXML or EXI. The accept header indicates the MIME type expected by the sensor. When the proxy receives the message from outside, it has no idea what MIME type the sensors wants. This would only happen when proxy understand the service logic, but that would be too much for the proxy, right? Cheers, Linyi -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Guido Moritz Sent: Tuesday, December 13, 2011 12:02 AM To: 'core' Subject: [core] Proxy Meda Type Conversion Dear WG, I have a question I cannot answer myself and would be interested in your thoughts and comments. It is maybe somewhat strange, but might be important in the sense of usage of CoAP in existing environments. As far as I know there is currently no mechanism in CoAP to realize what I describe below. If I am wrong, please forget about this mail and do more important things (please can you give me a hint to the solution in this case anyway). Let's assume an application in the unconstrained world which is using HTTP and XML for the data representation. We don't want to change this implementation completely and so we advise the CoAP/HTTP Proxy to do the required conversions of CoAP and HTTP when communicating with the 6LoWPAN. But there are optimized encodings existing also for the XML part. EXI is a good candidate, but let's not limit to it. So we have several optimized serialization formats for one and the same data, which can also be mapped seamless, transparent and stateless in the proxy. Is there a mechanism in the proxy spec to advise the proxy to (re-)encode also the payload? Of course the endpoints have to advise the proxy explicitly, because the proxy is stateless over different request. I was thinking about some weird usage of the Accept-Option, but I didn't come to a comprehensive conclusion. Btw, please don't ask me about the specific application I have in mind. It is (again) about usage of SOAP in 6LoWPANs and related to the SOAP-over-CoAP idea. Hence, you will not like my answer to the question about the application scenario anyway. :) Regards, Guido _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From esko.dijk@philips.com Tue Dec 13 00:27: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 2BB8F21F8558 for ; Tue, 13 Dec 2011 00:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koQ+W2ES9uaW for ; Tue, 13 Dec 2011 00:27:27 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 2344C21F8548 for ; Tue, 13 Dec 2011 00:27:25 -0800 (PST) Received: from mail212-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Tue, 13 Dec 2011 08:27:21 +0000 Received: from mail212-ch1 (localhost [127.0.0.1]) by mail212-ch1-R.bigfish.com (Postfix) with ESMTP id 68E631000F6; Tue, 13 Dec 2011 08:27:21 +0000 (UTC) X-SpamScore: -39 X-BigFish: VPS-39(zz217bL15d6O9371I9251J542Mzz1202hzz1033IL8275dhz2dh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail212-ch1 (localhost.localdomain [127.0.0.1]) by mail212-ch1 (MessageSwitch) id 1323764839258900_23302; Tue, 13 Dec 2011 08:27:19 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.249]) by mail212-ch1.bigfish.com (Postfix) with ESMTP id 3A94C300046; Tue, 13 Dec 2011 08:27:19 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 13 Dec 2011 08:27:19 +0000 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.218]) by 011-DB3MMR1-004.MGDPHG.emi.philips.com ([10.128.28.54]) with mapi id 14.01.0355.003; Tue, 13 Dec 2011 08:27:20 +0000 From: "Dijk, Esko" To: TianLinyi , Guido Moritz Thread-Topic: [core] Proxy Meda Type Conversion Thread-Index: Acy45XvyMSra5o5YT9WDcS2xN9kaHgAcI7UAAAZsLfA= Date: Tue, 13 Dec 2011 08:27:47 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618020298@011-DB3MPN1-012.MGDPHG.emi.philips.com> References: <006601ccb8e7$6e7aa7b0$4b6ff710$@uni-rostock.de> <3615F3CCD55F054395A882F51C6E5FDA1822178F@szxeml513-mbs.china.huawei.com> In-Reply-To: <3615F3CCD55F054395A882F51C6E5FDA1822178F@szxeml513-mbs.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: 'core' Subject: Re: [core] Proxy Meda Type Conversion 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, 13 Dec 2011 08:27:28 -0000 Hi Guido, Indeed not specified at this moment. Of course one could go and build a cus= tom, modified CoAP-HTTP proxy that implements the functionality you describ= e. Although we have no use case yet it's interesting since it allows CoAP n= odes with binary xml support to communicate with 'legacy' Web services that= do not understand any binary xml formats. This might be a topic for a futu= re I-D ... ? For CoAP requests translated by a CoAP-HTTP proxy to uncompressed XML insid= e a HTTP request I can see it clearly; for HTTP requests with an xml payloa= d, sent via a HTTP-CoAP proxy to a CoAP end-point, I don't see clearly how = the proxy would know to what format to convert (as mentioned by Linyi). Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Tia= nLinyi Sent: Tuesday 13 December 2011 6:20 To: Guido Moritz; 'core' Subject: Re: [core] Proxy Meda Type Conversion Hi, Guido It is not clear to me what the following question means. "Is there a mechanism in the proxy spec to advise the proxy to (re-)encode = also the payload?" Do you mean that the proxy needs to parse the payload in Exi format to anot= her format to be included in the coap message? There are some binary xml fo= rmat, e.g. WBXML or EXI. The accept header indicates the MIME type expected= by the sensor. When the proxy receives the message from outside, it has no= idea what MIME type the sensors wants. This would only happen when proxy u= nderstand the service logic, but that would be too much for the proxy, righ= t? Cheers, Linyi -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Gui= do Moritz Sent: Tuesday, December 13, 2011 12:02 AM To: 'core' Subject: [core] Proxy Meda Type Conversion Dear WG, I have a question I cannot answer myself and would be interested in your thoughts and comments. It is maybe somewhat strange, but might be important in the sense of usage of CoAP in existing environments. As far as I know there is currently no mechanism in CoAP to realize what I describe below. I= f I am wrong, please forget about this mail and do more important things (please can you give me a hint to the solution in this case anyway). Let's assume an application in the unconstrained world which is using HTTP and XML for the data representation. We don't want to change this implementation completely and so we advise the CoAP/HTTP Proxy to do the required conversions of CoAP and HTTP when communicating with the 6LoWPAN. But there are optimized encodings existing also for the XML part. EXI is a good candidate, but let's not limit to it. So we have several optimized serialization formats for one and the same data, which can also be mapped seamless, transparent and stateless in the proxy. Is there a mechanism in the proxy spec to advise the proxy to (re-)encode also the payload? Of course the endpoints have to advise the proxy explicitly, because the proxy is stateless over different request. I was thinking about some weird usage of the Accept-Option, but I didn't come to a comprehensive conclusion. Btw, please don't ask me about the specific application I have in mind. It is (again) about usage of SOAP in 6LoWPANs and related to the SOAP-over-CoA= P idea. Hence, you will not like my answer to the question about the application scenario anyway. :) Regards, Guido _______________________________________________ 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 ________________________________ 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. From prvs=5328CD433B=guido.moritz@uni-rostock.de Tue Dec 13 00:58:11 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 D846721F88AB for ; Tue, 13 Dec 2011 00:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogBEWQfo2Dw1 for ; Tue, 13 Dec 2011 00:58:11 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 931A221F889A for ; Tue, 13 Dec 2011 00:58:10 -0800 (PST) From: Guido Moritz To: 'core' References: <006601ccb8e7$6e7aa7b0$4b6ff710$@uni-rostock.de> <3615F3CCD55F054395A882F51C6E5FDA1822178F@szxeml513-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED618020298@011-DB3MPN1-012.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618020298@011-DB3MPN1-012.MGDPHG.emi.philips.com> Date: Tue, 13 Dec 2011 09:58:08 +0100 Message-ID: <000501ccb975$557169f0$00543dd0$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMIdFaLyibYTMm16Pxm1bv8JN+UWAID3dJdAca5M0mTQ6jCUA== Content-Language: de X-Originating-IP: [139.30.201.226] Subject: Re: [core] Proxy Meda Type Conversion 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, 13 Dec 2011 08:58:12 -0000 You got exactly the point! We have the plan to implement such a proxy. = So we already have an EXI implementation for TelosB and we have a HTTP-CoAP = and CoAP-HTTP Proxy. Now the idea was to also implement a conversion of XML = to EXI and vice versa in the Proxy.=20 Off course the proxy is stateless and has no knowledge about which conversion has to be done for which endpoints. Hence, this information = must be somehow encoded in the request and response. How the endpoints = receive the knowledge about which formats are supported by the other side is out = of scope so far. This could be maybe performed during the discovery phase, static defined, etc. For our use case it is sufficient to perform the conversion statically.=20 The question was, if such a mechanism to advise the proxy to also do the data conversion already exists in CoAP. I was not sure, but it seems not = to be the case. Putting this issue (maybe including our use case) in an I-D seems reasonable...maybe I will find some time during Christmas days.=20 Nevertheless, more comments and ideas on that issue would be great! Best, Guido > -----Urspr=FCngliche Nachricht----- > Von: Dijk, Esko [mailto:esko.dijk@philips.com] > Gesendet: Dienstag, 13. Dezember 2011 09:28 > An: TianLinyi; Guido Moritz > Cc: 'core' > Betreff: RE: [core] Proxy Meda Type Conversion >=20 > Hi Guido, >=20 > Indeed not specified at this moment. Of course one could go and build = a > custom, modified CoAP-HTTP proxy that implements the functionality you > describe. Although we have no use case yet it's interesting since it allows CoAP > nodes with binary xml support to communicate with 'legacy' Web = services that > do not understand any binary xml formats. This might be a topic for a future I-D > ... ? >=20 > For CoAP requests translated by a CoAP-HTTP proxy to uncompressed XML > inside a HTTP request I can see it clearly; for HTTP requests with an = xml > payload, sent via a HTTP-CoAP proxy to a CoAP end-point, I don't see clearly > how the proxy would know to what format to convert (as mentioned by Linyi). >=20 > Esko >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of > TianLinyi > Sent: Tuesday 13 December 2011 6:20 > To: Guido Moritz; 'core' > Subject: Re: [core] Proxy Meda Type Conversion >=20 > Hi, Guido >=20 > It is not clear to me what the following question means. > "Is there a mechanism in the proxy spec to advise the proxy to = (re-)encode also > the payload?" >=20 > Do you mean that the proxy needs to parse the payload in Exi format to > another format to be included in the coap message? There are some = binary > xml format, e.g. WBXML or EXI. The accept header indicates the MIME = type > expected by the sensor. When the proxy receives the message from = outside, it > has no idea what MIME type the sensors wants. This would only happen = when > proxy understand the service logic, but that would be too much for the proxy, > right? >=20 > Cheers, > Linyi >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of > Guido Moritz > Sent: Tuesday, December 13, 2011 12:02 AM > To: 'core' > Subject: [core] Proxy Meda Type Conversion >=20 > Dear WG, >=20 > I have a question I cannot answer myself and would be interested in = your > thoughts and comments. It is maybe somewhat strange, but might be important > in the sense of usage of CoAP in existing environments. As far as I = know > there is currently no mechanism in CoAP to realize what I describe = below. If > I am wrong, please forget about this mail and do more important things > (please can you give me a hint to the solution in this case anyway). >=20 > Let's assume an application in the unconstrained world which is using = HTTP > and XML for the data representation. We don't want to change this > implementation completely and so we advise the CoAP/HTTP Proxy to do = the > required conversions of CoAP and HTTP when communicating with the > 6LoWPAN. > But there are optimized encodings existing also for the XML part. EXI = is a > good candidate, but let's not limit to it. So we have several = optimized > serialization formats for one and the same data, which can also be = mapped > seamless, transparent and stateless in the proxy. Is there a mechanism = in > the proxy spec to advise the proxy to (re-)encode also the payload? Of > course the endpoints have to advise the proxy explicitly, because the proxy > is stateless over different request. I was thinking about some weird = usage > of the Accept-Option, but I didn't come to a comprehensive conclusion. >=20 > Btw, please don't ask me about the specific application I have in = mind. It > is (again) about usage of SOAP in 6LoWPANs and related to the = SOAP-over- > CoAP > idea. Hence, you will not like my answer to the question about the > application scenario anyway. :) >=20 > Regards, > Guido >=20 >=20 > _______________________________________________ > 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 >=20 > ________________________________ > The information contained in this message may be confidential and = legally > protected under applicable law. 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 is strictly > prohibited and may be unlawful. If you are not the intended recipient, please > contact the sender by return e-mail and destroy all copies of the = original > message. From tho@koanlogic.com Tue Dec 13 01:52:43 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 7FFC721F84B6 for ; Tue, 13 Dec 2011 01:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.505 X-Spam-Level: ** X-Spam-Status: No, score=2.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, J_BACKHAIR_33=1, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVLBxPrFZJSg for ; Tue, 13 Dec 2011 01:52:43 -0800 (PST) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id F21D021F84B0 for ; Tue, 13 Dec 2011 01:52:42 -0800 (PST) Received: from host59-247-dynamic.53-79-r.retail.telecomitalia.it ([79.53.247.59]:52071 helo=t.home) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RaP2I-0003jN-6g; Tue, 13 Dec 2011 04:52:41 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <000501ccb975$557169f0$00543dd0$@uni-rostock.de> Date: Tue, 13 Dec 2011 10:52:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <006601ccb8e7$6e7aa7b0$4b6ff710$@uni-rostock.de> <3615F3CCD55F054395A882F51C6E5FDA1822178F@szxeml513-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED618020298@011-DB3MPN1-012.MGDPHG.emi.philips.com> <000501ccb975$557169f0$00543dd0$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.53.247.59 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: "core@ietf.org WG" Subject: Re: [core] Proxy Meda Type Conversion 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, 13 Dec 2011 09:52:43 -0000 Hi Guido, On Dec 13, 2011, at 9:58 AM, Guido Moritz wrote: > You got exactly the point! We have the plan to implement such a proxy. = So we > already have an EXI implementation for TelosB and we have a HTTP-CoAP = and > CoAP-HTTP Proxy. Now the idea was to also implement a conversion of = XML to > EXI and vice versa in the Proxy.=20 >=20 > Off course the proxy is stateless and has no knowledge about which > conversion has to be done for which endpoints. Hence, this information = must > be somehow encoded in the request and response. How the endpoints = receive > the knowledge about which formats are supported by the other side is = out of > scope so far. This could be maybe performed during the discovery = phase, > static defined, etc. For our use case it is sufficient to perform the > conversion statically.=20 >=20 > The question was, if such a mechanism to advise the proxy to also do = the > data conversion already exists in CoAP. I was not sure, but it seems = not to > be the case. Putting this issue (maybe including our use case) in an = I-D > seems reasonable...maybe I will find some time during Christmas days.=20= >=20 > Nevertheless, more comments and ideas on that issue would be great! I may have misunderstood your point, but *provided the existence of a = schema-less translation of XML to EXI* (and viceversa), couldn't the = intermediate node simply do "proxy" content negotiation, like this ? HTTP UA Proxy CoAP srv | | | +-------->| | Accept: text/xml, application/xml=20 | GET x | | | +-------->| Accept: application/xml, application/exi | | GET y | | | | and viceversa: CoAP cli Proxy HTTP origin | | | +-------->| | Accept: application/exi | GET a | | | +-------->| Accept: application/xml, text/xml, = Accept-Encoding: x-exi | | GET b | | | | handling the XML<->EXI conversions transparently. [The above scenario comprises an HTTP UA and origin who can do XML (the = origin may perhaps do EXI, see Accept-Encoding) and a CoAP client and = server who can only handle EXI encoded XML.]= From prvs=5328CD433B=guido.moritz@uni-rostock.de Tue Dec 13 02:17:46 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 4FD4021F8548 for ; Tue, 13 Dec 2011 02:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_BACKHAIR_33=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezxAtKQya+AW for ; Tue, 13 Dec 2011 02:17:45 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE8C21F851F for ; Tue, 13 Dec 2011 02:17:45 -0800 (PST) From: Guido Moritz To: 'Thomas Fossati' References: <006601ccb8e7$6e7aa7b0$4b6ff710$@uni-rostock.de> <3615F3CCD55F054395A882F51C6E5FDA1822178F@szxeml513-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED618020298@011-DB3MPN1-012.MGDPHG.emi.philips.com> <000501ccb975$557169f0$00543dd0$@uni-rostock.de> In-Reply-To: Date: Tue, 13 Dec 2011 11:17:42 +0100 Message-ID: <001801ccb980$72da18b0$588e4a10$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMIdFaLyibYTMm16Pxm1bv8JN+UWAID3dJdAca5M0kBIHMIQAHb2tpjkyvbmaA= Content-Language: de X-Originating-IP: [139.30.201.226] Cc: core@ietf.org Subject: Re: [core] Proxy Meda Type Conversion 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, 13 Dec 2011 10:17:46 -0000 Thomas, the problem is that in the case you described only the response can be optimized, as the proxy can indicate supported formats in the Accept = Option. But there is currently no way to do it also for the request. The only = way to it this is do always the conversion (which is so far OK for our use = case, but for sure not for all other use cases too). The scenario maybe explained more precisely: A XML over HTTP client = knows about a sensor to invoke and knows that the sensor supports EXI over = CoAP (maybe also XML over CoAP, but this is somewhat optimization already). = So for the request it uses a HTTP-CoAP proxy. But the proxy has no = knowledge about the supported formats of the sensor. So the HTTP client would like = to instruct the proxy also to do the format conversion. Let's turn this around: A EXI over CoAP client wants to deliver the data = to an XML over HTTP server. So it uses the CoAP-HTTP proxy. But the proxy = has no knowledge about the supported formats of the server. So the CoAP = client would like to instruct the proxy also to do the format conversion. Such a mechanism would be quite useful to integrate CoAP sensors in = existing applications, because no (not too many) changes have to be done in the existing implementations. The only new parts are the sensors and the = proxy including EXI/XML (and maybe more formats). And the proxy is still stateless, because it requires no knowledge about supported formats of = each single endpoint. Guido > -----Urspr=FCngliche Nachricht----- > Von: Thomas Fossati [mailto:tho@koanlogic.com] > Gesendet: Dienstag, 13. Dezember 2011 10:52 > An: Guido Moritz > Cc: core@ietf.org WG > Betreff: Re: [core] Proxy Meda Type Conversion >=20 > Hi Guido, >=20 > On Dec 13, 2011, at 9:58 AM, Guido Moritz wrote: > > You got exactly the point! We have the plan to implement such a = proxy. So we > > already have an EXI implementation for TelosB and we have a = HTTP-CoAP > and > > CoAP-HTTP Proxy. Now the idea was to also implement a conversion of = XML > to > > EXI and vice versa in the Proxy. > > > > Off course the proxy is stateless and has no knowledge about which > > conversion has to be done for which endpoints. Hence, this = information must > > be somehow encoded in the request and response. How the endpoints receive > > the knowledge about which formats are supported by the other side is = out of > > scope so far. This could be maybe performed during the discovery = phase, > > static defined, etc. For our use case it is sufficient to perform = the > > conversion statically. > > > > The question was, if such a mechanism to advise the proxy to also do = the > > data conversion already exists in CoAP. I was not sure, but it seems = not to > > be the case. Putting this issue (maybe including our use case) in an = I-D > > seems reasonable...maybe I will find some time during Christmas = days. > > > > Nevertheless, more comments and ideas on that issue would be great! >=20 > I may have misunderstood your point, but *provided the existence of a schema- > less translation of XML to EXI* (and viceversa), couldn't the = intermediate node > simply do "proxy" content negotiation, like this ? >=20 > HTTP UA Proxy CoAP srv > | | | > +-------->| | Accept: text/xml, application/xml > | GET x | | > | +-------->| Accept: application/xml, application/exi > | | GET y | > | | | >=20 > and viceversa: >=20 > CoAP cli Proxy HTTP origin > | | | > +-------->| | Accept: application/exi > | GET a | | > | +-------->| Accept: application/xml, text/xml, Accept-Encoding: x-exi > | | GET b | > | | | >=20 > handling the XML<->EXI conversions transparently. >=20 > [The above scenario comprises an HTTP UA and origin who can do XML = (the > origin may perhaps do EXI, see Accept-Encoding) and a CoAP client and server > who can only handle EXI encoded XML.]=3D From angelo.castellani@gmail.com Tue Dec 13 02:31: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 C5F8521F86A4 for ; Tue, 13 Dec 2011 02:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_33=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSaycaHN7sHq for ; Tue, 13 Dec 2011 02:31:31 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5663821F853A for ; Tue, 13 Dec 2011 02:31:31 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so10159649wgb.13 for ; Tue, 13 Dec 2011 02:31:30 -0800 (PST) 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 :content-transfer-encoding; bh=k3ry1LsrAKyRydeBNClFMoKpUA2DZcR1WjPfkCyYmzw=; b=h4LTLGTnK/ff4Gjd46gfCu7PVkNZMa8c3NsaL5gft2zXxGoSSYnjMbX79GpvAykaGl OQf8PmJKHHNtAbM94aHe2mjfvx+f65z5AvfJonD+fW0PRAFfbG1VzUYs/gEr0AXvLFNP 2vdVQTBgqiylVnbhAJT4VzhInWxta+ggXMZCI= Received: by 10.216.221.31 with SMTP id q31mr37757wep.33.1323772289350; Tue, 13 Dec 2011 02:31:29 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.62.8 with HTTP; Tue, 13 Dec 2011 02:30:48 -0800 (PST) In-Reply-To: <001801ccb980$72da18b0$588e4a10$@uni-rostock.de> References: <006601ccb8e7$6e7aa7b0$4b6ff710$@uni-rostock.de> <3615F3CCD55F054395A882F51C6E5FDA1822178F@szxeml513-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED618020298@011-DB3MPN1-012.MGDPHG.emi.philips.com> <000501ccb975$557169f0$00543dd0$@uni-rostock.de> <001801ccb980$72da18b0$588e4a10$@uni-rostock.de> From: "Angelo P. Castellani" Date: Tue, 13 Dec 2011 11:30:48 +0100 X-Google-Sender-Auth: -l5hnyzRFx9Q7eui24FZ6eEU8sE Message-ID: To: Guido Moritz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] Proxy Meda Type Conversion 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, 13 Dec 2011 10:31:32 -0000 Web proxies are not intended to convert application data, so probably this feature is missing for this reason. You can get around it as Thomas suggested to you, and you can even instantiate a long-lived observe session with that Accept options.. In this way your ALG/proxy will also convert the payload even on push operations from nodes by remembering the state for that conversion. Otherwise we will need a special option for CoAP requests to specify application data conversion for an intermediate proxy, and handle all the complexities this leads to... I doubt that this will be done in the WG, anyway I personally think that it may be useful because I may have similar needs too. Are there other options to get around this? Best, Angelo On Tue, Dec 13, 2011 at 11:17, Guido Moritz w= rote: > Thomas, > > the problem is that in the case you described only the response can be > optimized, as the proxy can indicate supported formats in the Accept Opti= on. > But there is currently no way to do it also for the request. The only way= to > it this is do always the conversion (which is so far OK for our use case, > but for sure not for all other use cases too). > > The scenario maybe explained more precisely: A XML over HTTP client knows > about a sensor to invoke and knows that the sensor supports EXI over CoAP > (maybe also XML over CoAP, but this is somewhat optimization already). So > for the request it uses a HTTP-CoAP proxy. But the proxy has no knowledge > about the supported formats of the sensor. So the HTTP client would like = to > instruct the proxy also to do the format conversion. > > Let's turn this around: A EXI over CoAP client wants to deliver the data = to > an XML over HTTP server. So it uses the CoAP-HTTP proxy. But the proxy ha= s > no knowledge about the supported formats of the server. So the CoAP clien= t > would like to instruct the proxy also to do the format conversion. > > Such a mechanism would be quite useful to integrate CoAP sensors in exist= ing > applications, because no (not too many) changes have to be done in the > existing implementations. The only new parts are the sensors and the prox= y > including EXI/XML (and maybe more formats). And the proxy is still > stateless, because it requires no knowledge about supported formats of ea= ch > single endpoint. > > Guido > >> -----Urspr=C3=BCngliche Nachricht----- >> Von: Thomas Fossati [mailto:tho@koanlogic.com] >> Gesendet: Dienstag, 13. Dezember 2011 10:52 >> An: Guido Moritz >> Cc: core@ietf.org WG >> Betreff: Re: [core] Proxy Meda Type Conversion >> >> Hi Guido, >> >> On Dec 13, 2011, at 9:58 AM, Guido Moritz wrote: >> > You got exactly the point! We have the plan to implement such a proxy. > So we >> > already have an EXI implementation for TelosB and we have a HTTP-CoAP >> and >> > CoAP-HTTP Proxy. Now the idea was to also implement a conversion of XM= L >> to >> > EXI and vice versa in the Proxy. >> > >> > Off course the proxy is stateless and has no knowledge about which >> > conversion has to be done for which endpoints. Hence, this information > must >> > be somehow encoded in the request and response. How the endpoints > receive >> > the knowledge about which formats are supported by the other side is o= ut > of >> > scope so far. This could be maybe performed during the discovery phase= , >> > static defined, etc. For our use case it is sufficient to perform the >> > conversion statically. >> > >> > The question was, if such a mechanism to advise the proxy to also do t= he >> > data conversion already exists in CoAP. I was not sure, but it seems n= ot > to >> > be the case. Putting this issue (maybe including our use case) in an I= -D >> > seems reasonable...maybe I will find some time during Christmas days. >> > >> > Nevertheless, more comments and ideas on that issue would be great! >> >> I may have misunderstood your point, but *provided the existence of a > schema- >> less translation of XML to EXI* (and viceversa), couldn't the intermedia= te > node >> simply do "proxy" content negotiation, like this ? >> >> HTTP UA =C2=A0 Proxy =C2=A0 =C2=A0CoAP srv >> =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | >> =C2=A0 +-------->| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Accept: text/xml, appli= cation/xml >> =C2=A0 | =C2=A0GET x =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | >> =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-------->| Accept: application/xml= , application/exi >> =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0GET y =C2=A0| >> =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | >> >> and viceversa: >> >> CoAP cli =C2=A0Proxy =C2=A0 =C2=A0HTTP origin >> =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | >> =C2=A0 +-------->| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Accept: application/exi >> =C2=A0 | =C2=A0GET a =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | >> =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-------->| Accept: application/xml= , text/xml, > Accept-Encoding: x-exi >> =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0GET b =C2=A0| >> =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | >> >> handling the XML<->EXI conversions transparently. >> >> [The above scenario comprises an HTTP UA and origin who can do XML (the >> origin may perhaps do EXI, see Accept-Encoding) and a CoAP client and > server >> who can only handle EXI encoded XML.]=3D > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From tho@koanlogic.com Tue Dec 13 02:48:45 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 D0FA521F84BA for ; Tue, 13 Dec 2011 02:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.005 X-Spam-Level: ** X-Spam-Status: No, score=2.005 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6q-vUM22mU+Y for ; Tue, 13 Dec 2011 02:48:45 -0800 (PST) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 2F38821F84CE for ; Tue, 13 Dec 2011 02:48:45 -0800 (PST) Received: from host59-247-dynamic.53-79-r.retail.telecomitalia.it ([79.53.247.59]:52724 helo=t.home) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RaPuK-0003oq-Pz; Tue, 13 Dec 2011 05:48:32 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <001801ccb980$72da18b0$588e4a10$@uni-rostock.de> Date: Tue, 13 Dec 2011 11:47:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <006601ccb8e7$6e7aa7b0$4b6ff710$@uni-rostock.de> <3615F3CCD55F054395A882F51C6E5FDA1822178F@szxeml513-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED618020298@011-DB3MPN1-012.MGDPHG.emi.philips.com> <000501ccb975$557169f0$00543dd0$@uni-rostock.de> <001801ccb980$72da18b0$588e4a10$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.53.247.59 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: "core@ietf.org WG" Subject: Re: [core] Proxy Meda Type Conversion 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, 13 Dec 2011 10:48:46 -0000 Hi Guido, On Dec 13, 2011, at 11:17 AM, Guido Moritz wrote: > the problem is that in the case you described only the response can be > optimized, as the proxy can indicate supported formats in the Accept = Option. > But there is currently no way to do it also for the request. The only = way to > it this is do always the conversion (which is so far OK for our use = case, > but for sure not for all other use cases too). ok, or otherwise performing offline/online discovery of the resources = hosted by the target node, and cache its links and associated ct's. This needs a cooperative client of course, and an "intelligent" proxy = too. > The scenario maybe explained more precisely: A XML over HTTP client = knows > about a sensor to invoke and knows that the sensor supports EXI over = CoAP > (maybe also XML over CoAP, but this is somewhat optimization already). = So > for the request it uses a HTTP-CoAP proxy. But the proxy has no = knowledge > about the supported formats of the sensor. So the HTTP client would = like to > instruct the proxy also to do the format conversion. If the HTTP/XML UA knows in advance the specific encoding accepted by = the sensor, why couldn't it handle the correct encoding by itself ? > Let's turn this around: A EXI over CoAP client wants to deliver the = data to > an XML over HTTP server. So it uses the CoAP-HTTP proxy. But the proxy = has > no knowledge about the supported formats of the server. So the CoAP = client > would like to instruct the proxy also to do the format conversion. Ok, this could be more problematic than the previous case because we are = on the constrained side of the communication path. Here a = "Proxy-Transform" option could make sense. > Such a mechanism would be quite useful to integrate CoAP sensors in = existing > applications, because no (not too many) changes have to be done in the > existing implementations. The only new parts are the sensors and the = proxy > including EXI/XML (and maybe more formats). And the proxy is still > stateless, because it requires no knowledge about supported formats of = each > single endpoint. A cacheing proxy wouldn't be stateless anyway, but I agree with you that = translating-only intermediaries could benefit from such mechanism.=20= From prvs=4328A82D2A=guido.moritz@uni-rostock.de Tue Dec 13 02:50:27 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 298E921F86EE for ; Tue, 13 Dec 2011 02:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_BACKHAIR_33=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9z2vDprxJZJs for ; Tue, 13 Dec 2011 02:50:26 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id E15DF21F84BB for ; Tue, 13 Dec 2011 02:50:25 -0800 (PST) From: Guido Moritz To: "'Angelo P. Castellani'" References: <006601ccb8e7$6e7aa7b0$4b6ff710$@uni-rostock.de> <3615F3CCD55F054395A882F51C6E5FDA1822178F@szxeml513-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED618020298@011-DB3MPN1-012.MGDPHG.emi.philips.com> <000501ccb975$557169f0$00543dd0$@uni-rostock.de> <001801ccb980$72da18b0$588e4a10$@uni-rostock.de> In-Reply-To: Date: Tue, 13 Dec 2011 11:50:25 +0100 Message-ID: <002a01ccb985$04ee5960$0ecb0c20$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMIdFaLyibYTMm16Pxm1bv8JN+UWAID3dJdAca5M0kBIHMIQAHb2tpjAd4tbqQCWM+DkZMKMEIQ Content-Language: de X-Originating-IP: [139.30.201.226] Cc: core@ietf.org Subject: Re: [core] Proxy Meda Type Conversion 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, 13 Dec 2011 10:50:27 -0000 I agree with your point that application data conversion for an = intermediate proxy cannot be specified in CoRE. This would be in the = responsibility of other groups or even other standardization bodies.=20 But it would be the WG (if the WG is interested in) to provide and = define a protocol mechanism, which can be used for such purposes. Maybe = at the end this is only an option with an arbitrary data type, which can = be used by other bodies to express the type and way of conversion. If there is an existing solution for this I would be happy with it = anyway.=20 Best, Guido > -----Urspr=C3=BCngliche Nachricht----- > Von: angelo.castellani@gmail.com [mailto:angelo.castellani@gmail.com] = Im > Auftrag von Angelo P. Castellani > Gesendet: Dienstag, 13. Dezember 2011 11:31 > An: Guido Moritz > Cc: Thomas Fossati; core@ietf.org > Betreff: Re: [core] Proxy Meda Type Conversion >=20 > Web proxies are not intended to convert application data, so probably > this feature is missing for this reason. >=20 > You can get around it as Thomas suggested to you, and you can even > instantiate a long-lived observe session with that Accept options.. In > this way your ALG/proxy will also convert the payload even on push > operations from nodes by remembering the state for that conversion. >=20 > Otherwise we will need a special option for CoAP requests to specify > application data conversion for an intermediate proxy, and handle all > the complexities this leads to... I doubt that this will be done in > the WG, anyway I personally think that it may be useful because I may > have similar needs too. >=20 > Are there other options to get around this? >=20 > Best, > Angelo >=20 > On Tue, Dec 13, 2011 at 11:17, Guido Moritz = > wrote: > > Thomas, > > > > the problem is that in the case you described only the response can = be > > optimized, as the proxy can indicate supported formats in the Accept = Option. > > But there is currently no way to do it also for the request. The = only way to > > it this is do always the conversion (which is so far OK for our use = case, > > but for sure not for all other use cases too). > > > > The scenario maybe explained more precisely: A XML over HTTP client = knows > > about a sensor to invoke and knows that the sensor supports EXI over = CoAP > > (maybe also XML over CoAP, but this is somewhat optimization = already). So > > for the request it uses a HTTP-CoAP proxy. But the proxy has no = knowledge > > about the supported formats of the sensor. So the HTTP client would = like to > > instruct the proxy also to do the format conversion. > > > > Let's turn this around: A EXI over CoAP client wants to deliver the = data to > > an XML over HTTP server. So it uses the CoAP-HTTP proxy. But the = proxy has > > no knowledge about the supported formats of the server. So the CoAP = client > > would like to instruct the proxy also to do the format conversion. > > > > Such a mechanism would be quite useful to integrate CoAP sensors in = existing > > applications, because no (not too many) changes have to be done in = the > > existing implementations. The only new parts are the sensors and the = proxy > > including EXI/XML (and maybe more formats). And the proxy is still > > stateless, because it requires no knowledge about supported formats = of each > > single endpoint. > > > > Guido > > > >> -----Urspr=C3=BCngliche Nachricht----- > >> Von: Thomas Fossati [mailto:tho@koanlogic.com] > >> Gesendet: Dienstag, 13. Dezember 2011 10:52 > >> An: Guido Moritz > >> Cc: core@ietf.org WG > >> Betreff: Re: [core] Proxy Meda Type Conversion > >> > >> Hi Guido, > >> > >> On Dec 13, 2011, at 9:58 AM, Guido Moritz wrote: > >> > You got exactly the point! We have the plan to implement such a = proxy. > > So we > >> > already have an EXI implementation for TelosB and we have a = HTTP-CoAP > >> and > >> > CoAP-HTTP Proxy. Now the idea was to also implement a conversion = of > XML > >> to > >> > EXI and vice versa in the Proxy. > >> > > >> > Off course the proxy is stateless and has no knowledge about = which > >> > conversion has to be done for which endpoints. Hence, this = information > > must > >> > be somehow encoded in the request and response. How the endpoints > > receive > >> > the knowledge about which formats are supported by the other side = is out > > of > >> > scope so far. This could be maybe performed during the discovery = phase, > >> > static defined, etc. For our use case it is sufficient to perform = the > >> > conversion statically. > >> > > >> > The question was, if such a mechanism to advise the proxy to also = do the > >> > data conversion already exists in CoAP. I was not sure, but it = seems not > > to > >> > be the case. Putting this issue (maybe including our use case) in = an I-D > >> > seems reasonable...maybe I will find some time during Christmas = days. > >> > > >> > Nevertheless, more comments and ideas on that issue would be = great! > >> > >> I may have misunderstood your point, but *provided the existence of = a > > schema- > >> less translation of XML to EXI* (and viceversa), couldn't the = intermediate > > node > >> simply do "proxy" content negotiation, like this ? > >> > >> HTTP UA Proxy CoAP srv > >> | | | > >> +-------->| | Accept: text/xml, application/xml > >> | GET x | | > >> | +-------->| Accept: application/xml, application/exi > >> | | GET y | > >> | | | > >> > >> and viceversa: > >> > >> CoAP cli Proxy HTTP origin > >> | | | > >> +-------->| | Accept: application/exi > >> | GET a | | > >> | +-------->| Accept: application/xml, text/xml, > > Accept-Encoding: x-exi > >> | | GET b | > >> | | | > >> > >> handling the XML<->EXI conversions transparently. > >> > >> [The above scenario comprises an HTTP UA and origin who can do XML = (the > >> origin may perhaps do EXI, see Accept-Encoding) and a CoAP client = and > > server > >> who can only handle EXI encoded XML.]=3D > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core From prvs=132842D513=guido.moritz@uni-rostock.de Tue Dec 13 02:58: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 E4E4621F8496 for ; Tue, 13 Dec 2011 02:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4d68nhkTqFoH for ; Tue, 13 Dec 2011 02:58:51 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2E63221F8481 for ; Tue, 13 Dec 2011 02:58:47 -0800 (PST) From: Guido Moritz To: 'Thomas Fossati' References: <006601ccb8e7$6e7aa7b0$4b6ff710$@uni-rostock.de> <3615F3CCD55F054395A882F51C6E5FDA1822178F@szxeml513-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED618020298@011-DB3MPN1-012.MGDPHG.emi.philips.com> <000501ccb975$557169f0$00543dd0$@uni-rostock.de> <001801ccb980$72da18b0$588e4a10$@uni-rostock.de> In-Reply-To: Date: Tue, 13 Dec 2011 11:58:46 +0100 Message-ID: <002b01ccb986$2fbd67c0$8f383740$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMIdFaLyibYTMm16Pxm1bv8JN+UWAID3dJdAca5M0kBIHMIQAHb2tpjAd4tbqQCGdNPJ5MMKmYw Content-Language: de X-Originating-IP: [139.30.201.226] Cc: core@ietf.org Subject: Re: [core] Proxy Meda Type Conversion 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, 13 Dec 2011 10:58:52 -0000 > If the HTTP/XML UA knows in advance the specific encoding accepted by = the > sensor, why couldn't it handle the correct encoding by itself ? This is more or less a question about the application. Indeed, this is = to some extend only useful if one does not want or can change the = unconstrained part (HTTP, XML). So maybe I can answer with a question: If the HTTP/XML = UA knows in advance that the sensor only features CoAP and not HTTP, why = does it not uses CoAP directly but uses the proxy at all? After all the layers that can be compressed an optimized now (6LoWPAN, = UDP, CoAP...), a possible stateless conversion also for the payload is from = my point of view only the next (maybe the final) step to be done.=20 Guido > -----Urspr=FCngliche Nachricht----- > Von: Thomas Fossati [mailto:tho@koanlogic.com] > Gesendet: Dienstag, 13. Dezember 2011 11:48 > An: Guido Moritz > Cc: core@ietf.org WG > Betreff: Re: AW: [core] Proxy Meda Type Conversion >=20 > Hi Guido, >=20 > On Dec 13, 2011, at 11:17 AM, Guido Moritz wrote: > > the problem is that in the case you described only the response can = be > > optimized, as the proxy can indicate supported formats in the Accept Option. > > But there is currently no way to do it also for the request. The = only way to > > it this is do always the conversion (which is so far OK for our use case, > > but for sure not for all other use cases too). >=20 > ok, or otherwise performing offline/online discovery of the resources hosted by > the target node, and cache its links and associated ct's. > This needs a cooperative client of course, and an "intelligent" proxy = too. >=20 > > The scenario maybe explained more precisely: A XML over HTTP client knows > > about a sensor to invoke and knows that the sensor supports EXI over CoAP > > (maybe also XML over CoAP, but this is somewhat optimization = already). So > > for the request it uses a HTTP-CoAP proxy. But the proxy has no knowledge > > about the supported formats of the sensor. So the HTTP client would = like to > > instruct the proxy also to do the format conversion. >=20 > If the HTTP/XML UA knows in advance the specific encoding accepted by = the > sensor, why couldn't it handle the correct encoding by itself ? >=20 > > Let's turn this around: A EXI over CoAP client wants to deliver the = data to > > an XML over HTTP server. So it uses the CoAP-HTTP proxy. But the = proxy has > > no knowledge about the supported formats of the server. So the CoAP client > > would like to instruct the proxy also to do the format conversion. >=20 > Ok, this could be more problematic than the previous case because we = are on > the constrained side of the communication path. Here a = "Proxy-Transform" > option could make sense. >=20 > > Such a mechanism would be quite useful to integrate CoAP sensors in existing > > applications, because no (not too many) changes have to be done in = the > > existing implementations. The only new parts are the sensors and the proxy > > including EXI/XML (and maybe more formats). And the proxy is still > > stateless, because it requires no knowledge about supported formats = of each > > single endpoint. >=20 > A cacheing proxy wouldn't be stateless anyway, but I agree with you = that > translating-only intermediaries could benefit from such mechanism. From tho@koanlogic.com Tue Dec 13 03:02:22 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 77A2A21F8496 for ; Tue, 13 Dec 2011 03:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.755 X-Spam-Level: * X-Spam-Status: No, score=1.755 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnCQ6MgGRLin for ; Tue, 13 Dec 2011 03:02:21 -0800 (PST) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id A5C5421F849E for ; Tue, 13 Dec 2011 03:02:21 -0800 (PST) Received: from host59-247-dynamic.53-79-r.retail.telecomitalia.it ([79.53.247.59]:52832 helo=t.home) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RaQ7c-0003qR-11; Tue, 13 Dec 2011 06:02:17 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <002a01ccb985$04ee5960$0ecb0c20$@uni-rostock.de> Date: Tue, 13 Dec 2011 12:01:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <006601ccb8e7$6e7aa7b0$4b6ff710$@uni-rostock.de> <3615F3CCD55F054395A882F51C6E5FDA1822178F@szxeml513-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED618020298@011-DB3MPN1-012.MGDPHG.emi.philips.com> <000501ccb975$557169f0$00543dd0$@uni-rostock.de> <001801ccb980$72da18b0$588e4a10$@uni-rostock.de> <002a01ccb985$04ee5960$0ecb0c20$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.53.247.59 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: core@ietf.org Subject: Re: [core] Proxy Meda Type Conversion 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, 13 Dec 2011 11:02:22 -0000 On Dec 13, 2011, at 11:50 AM, Guido Moritz wrote: > I agree with your point that application data conversion for an = intermediate proxy cannot be specified in CoRE. This would be in the = responsibility of other groups or even other standardization bodies. Yes, and besides, being on the unconstrained side must have some = downsides too :-) But seriously, if the HTTP client knows which format the sensor is able = to consume, I think it is its responsibility to handle the correct = encoding. > But it would be the WG (if the WG is interested in) to provide and = define a protocol mechanism, which can be used for such purposes. Maybe = at the end this is only an option with an arbitrary data type, which can = be used by other bodies to express the type and way of conversion. I'm in favour of a new "Proxy-Translate", or similar, option. > If there is an existing solution for this I would be happy with it = anyway.=20 No currently defined option seems able to cleanly do the trick.= From yrz@anche.no Tue Dec 13 03:25:27 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 0725521F85A7 for ; Tue, 13 Dec 2011 03:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_33=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1oKK+Jjc2SB for ; Tue, 13 Dec 2011 03:25:26 -0800 (PST) Received: from rivolta.investici.org (rivolta.investici.org [78.46.89.173]) by ietfa.amsl.com (Postfix) with ESMTP id D8DFF21F889A for ; Tue, 13 Dec 2011 03:25:25 -0800 (PST) Received: from webmail8.autistici.org (localhost [127.0.0.1]) by rivolta.investici.org (Postfix) with ESMTP id 483E810A274 for ; Tue, 13 Dec 2011 11:25:20 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 rivolta.investici.org 483E810A274 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anche.no; s=stigmate; t=1323775520; bh=wMuwwsoVpJzc61EdKNx7kmOxLa7qO/0kaiAKhu3kXhg=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Date:From:To: Subject:In-Reply-To:References:Message-ID; b=TMIW70FTCCc183DxooDRWigq7B54+oANuZHnTa4hOMqEBJnqP8VAku46LzQ7DUxcB df0TFQYRKFOInY8bsrWWZhCpcCoFGfjQcAyiYbvc0Q9P9uiqLcuy0SvKAiDVNx3fVy XNQxiXFBuFfaevjzj1hoPharYbSm5t1Ys9r+5D7Y= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 13 Dec 2011 13:25:20 +0200 From: pierpaolo giacomin To: In-Reply-To: <002a01ccb985$04ee5960$0ecb0c20$@uni-rostock.de> References: <006601ccb8e7$6e7aa7b0$4b6ff710$@uni-rostock.de> <3615F3CCD55F054395A882F51C6E5FDA1822178F@szxeml513-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED618020298@011-DB3MPN1-012.MGDPHG.emi.philips.com> <000501ccb975$557169f0$00543dd0$@uni-rostock.de> <001801ccb980$72da18b0$588e4a10$@uni-rostock.de> <002a01ccb985$04ee5960$0ecb0c20$@uni-rostock.de> Message-ID: <31be9f671d88302bf0d4e1e47a289020@autistici.org> X-Sender: yrz@anche.no User-Agent: autistici.org webmail Subject: Re: [core] Proxy Meda Type Conversion 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, 13 Dec 2011 11:25:27 -0000 I was discussing yesterday with tho of handling application data conversion in the proxy. The objective of my proposal was having a coalesced cache for different content-types. This would violate heavily the concept of end-to-end, but still, it presents interesting pros, namely reducing communication between proxy and the cached resource, and memory usage in the proxy. Anyway, yesterday he convinced me to drop it, with a strong argument about origin preservation. Moreover, I've not enough background on xml, exi and json to state a possible translation 1:1 exists, or at least from a given format to two the others. If someone does I'll be happy to pursue the idea, and that could fix as well your needs. If a 1:1 translation is not available it would become definitely an application issue, moving away from "straight-proxy" scope. Still interesting to me, but no point to speak about it here. On 13.12.2011 12:50, Guido Moritz wrote: > I agree with your point that application data conversion for an > intermediate proxy cannot be specified in CoRE. This would be in the > responsibility of other groups or even other standardization bodies. > > But it would be the WG (if the WG is interested in) to provide and > define a protocol mechanism, which can be used for such purposes. > Maybe at the end this is only an option with an arbitrary data type, > which can be used by other bodies to express the type and way of > conversion. > > If there is an existing solution for this I would be happy with it > anyway. > > Best, > Guido > >> -----Ursprüngliche Nachricht----- >> Von: angelo.castellani@gmail.com >> [mailto:angelo.castellani@gmail.com] Im >> Auftrag von Angelo P. Castellani >> Gesendet: Dienstag, 13. Dezember 2011 11:31 >> An: Guido Moritz >> Cc: Thomas Fossati; core@ietf.org >> Betreff: Re: [core] Proxy Meda Type Conversion >> >> Web proxies are not intended to convert application data, so >> probably >> this feature is missing for this reason. >> >> You can get around it as Thomas suggested to you, and you can even >> instantiate a long-lived observe session with that Accept options.. >> In >> this way your ALG/proxy will also convert the payload even on push >> operations from nodes by remembering the state for that conversion. >> >> Otherwise we will need a special option for CoAP requests to specify >> application data conversion for an intermediate proxy, and handle >> all >> the complexities this leads to... I doubt that this will be done in >> the WG, anyway I personally think that it may be useful because I >> may >> have similar needs too. >> >> Are there other options to get around this? >> >> Best, >> Angelo >> >> On Tue, Dec 13, 2011 at 11:17, Guido Moritz >> >> wrote: >> > Thomas, >> > >> > the problem is that in the case you described only the response >> can be >> > optimized, as the proxy can indicate supported formats in the >> Accept Option. >> > But there is currently no way to do it also for the request. The >> only way to >> > it this is do always the conversion (which is so far OK for our >> use case, >> > but for sure not for all other use cases too). >> > >> > The scenario maybe explained more precisely: A XML over HTTP >> client knows >> > about a sensor to invoke and knows that the sensor supports EXI >> over CoAP >> > (maybe also XML over CoAP, but this is somewhat optimization >> already). So >> > for the request it uses a HTTP-CoAP proxy. But the proxy has no >> knowledge >> > about the supported formats of the sensor. So the HTTP client >> would like to >> > instruct the proxy also to do the format conversion. >> > >> > Let's turn this around: A EXI over CoAP client wants to deliver >> the data to >> > an XML over HTTP server. So it uses the CoAP-HTTP proxy. But the >> proxy has >> > no knowledge about the supported formats of the server. So the >> CoAP client >> > would like to instruct the proxy also to do the format conversion. >> > >> > Such a mechanism would be quite useful to integrate CoAP sensors >> in existing >> > applications, because no (not too many) changes have to be done in >> the >> > existing implementations. The only new parts are the sensors and >> the proxy >> > including EXI/XML (and maybe more formats). And the proxy is still >> > stateless, because it requires no knowledge about supported >> formats of each >> > single endpoint. >> > >> > Guido >> > >> >> -----Ursprüngliche Nachricht----- >> >> Von: Thomas Fossati [mailto:tho@koanlogic.com] >> >> Gesendet: Dienstag, 13. Dezember 2011 10:52 >> >> An: Guido Moritz >> >> Cc: core@ietf.org WG >> >> Betreff: Re: [core] Proxy Meda Type Conversion >> >> >> >> Hi Guido, >> >> >> >> On Dec 13, 2011, at 9:58 AM, Guido Moritz wrote: >> >> > You got exactly the point! We have the plan to implement such a >> proxy. >> > So we >> >> > already have an EXI implementation for TelosB and we have a >> HTTP-CoAP >> >> and >> >> > CoAP-HTTP Proxy. Now the idea was to also implement a >> conversion of >> XML >> >> to >> >> > EXI and vice versa in the Proxy. >> >> > >> >> > Off course the proxy is stateless and has no knowledge about >> which >> >> > conversion has to be done for which endpoints. Hence, this >> information >> > must >> >> > be somehow encoded in the request and response. How the >> endpoints >> > receive >> >> > the knowledge about which formats are supported by the other >> side is out >> > of >> >> > scope so far. This could be maybe performed during the >> discovery phase, >> >> > static defined, etc. For our use case it is sufficient to >> perform the >> >> > conversion statically. >> >> > >> >> > The question was, if such a mechanism to advise the proxy to >> also do the >> >> > data conversion already exists in CoAP. I was not sure, but it >> seems not >> > to >> >> > be the case. Putting this issue (maybe including our use case) >> in an I-D >> >> > seems reasonable...maybe I will find some time during Christmas >> days. >> >> > >> >> > Nevertheless, more comments and ideas on that issue would be >> great! >> >> >> >> I may have misunderstood your point, but *provided the existence >> of a >> > schema- >> >> less translation of XML to EXI* (and viceversa), couldn't the >> intermediate >> > node >> >> simply do "proxy" content negotiation, like this ? >> >> >> >> HTTP UA Proxy CoAP srv >> >> | | | >> >> +-------->| | Accept: text/xml, application/xml >> >> | GET x | | >> >> | +-------->| Accept: application/xml, application/exi >> >> | | GET y | >> >> | | | >> >> >> >> and viceversa: >> >> >> >> CoAP cli Proxy HTTP origin >> >> | | | >> >> +-------->| | Accept: application/exi >> >> | GET a | | >> >> | +-------->| Accept: application/xml, text/xml, >> > Accept-Encoding: x-exi >> >> | | GET b | >> >> | | | >> >> >> >> handling the XML<->EXI conversions transparently. >> >> >> >> [The above scenario comprises an HTTP UA and origin who can do >> XML (the >> >> origin may perhaps do EXI, see Accept-Encoding) and a CoAP client >> and >> > server >> >> who can only handle EXI encoded XML.]= >> > >> > _______________________________________________ >> > 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 yrz@anche.no Tue Dec 13 03:36: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 3FB9E21F8876 for ; Tue, 13 Dec 2011 03:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5vKFOTPgmHs for ; Tue, 13 Dec 2011 03:36:15 -0800 (PST) Received: from rivolta.investici.org (rivolta.investici.org [78.46.89.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8537121F85FF for ; Tue, 13 Dec 2011 03:36:15 -0800 (PST) Received: from webmail8.autistici.org (localhost [127.0.0.1]) by rivolta.investici.org (Postfix) with ESMTP id D3A2410A69E for ; Tue, 13 Dec 2011 11:36:13 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 rivolta.investici.org D3A2410A69E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anche.no; s=stigmate; t=1323776173; bh=Tv58noh4rDU4g4VIo0MhET1pssOrkwLGFUIbrMmx548=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Date:From:To: Subject:In-Reply-To:References:Message-ID; b=BXf63dwK4XBm4LxznYkHQjjrVo5jD0q9Hz6/u1ACG1eZf7b/Xk6yedRhPfMMaloYA ZXCi+4YVGRu2WozTlvfKusRUKtmvwb4Evuohn5RhBe5I4yUbQuvxPzLYllTqnxSRcl lxFl6dZloKw79emdwn/IT/IWz2CgPNxDW2n4oq9I= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 13 Dec 2011 13:36:13 +0200 From: pierpaolo giacomin To: In-Reply-To: References: <006601ccb8e7$6e7aa7b0$4b6ff710$@uni-rostock.de> <3615F3CCD55F054395A882F51C6E5FDA1822178F@szxeml513-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED618020298@011-DB3MPN1-012.MGDPHG.emi.philips.com> <000501ccb975$557169f0$00543dd0$@uni-rostock.de> <001801ccb980$72da18b0$588e4a10$@uni-rostock.de> <002a01ccb985$04ee5960$0ecb0c20$@uni-rostock.de> Message-ID: <8bad695da4449cf91213f8cd76c08a1d@autistici.org> X-Sender: yrz@anche.no User-Agent: autistici.org webmail Subject: Re: [core] Proxy Meda Type Conversion 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, 13 Dec 2011 11:36:16 -0000 -1 I'm against this "Proxy-Translate" option. The proxy receive in the "Accept" the palatable formats, the proxy should be aware which formats supported by the resource it is able to translate into the client's palatable ones. On 13.12.2011 13:01, Thomas Fossati wrote: > On Dec 13, 2011, at 11:50 AM, Guido Moritz wrote: >> I agree with your point that application data conversion for an >> intermediate proxy cannot be specified in CoRE. This would be in the >> responsibility of other groups or even other standardization bodies. > > Yes, and besides, being on the unconstrained side must have some > downsides too :-) > > But seriously, if the HTTP client knows which format the sensor is > able to consume, I think it is its responsibility to handle the > correct encoding. > >> But it would be the WG (if the WG is interested in) to provide and >> define a protocol mechanism, which can be used for such purposes. >> Maybe at the end this is only an option with an arbitrary data type, >> which can be used by other bodies to express the type and way of >> conversion. > > I'm in favour of a new "Proxy-Translate", or similar, option. > >> If there is an existing solution for this I would be happy with it >> anyway. > > No currently defined option seems able to cleanly do the trick. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From prvs=7328D0F3CC=guido.moritz@uni-rostock.de Tue Dec 13 03:43: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 C470B21F88B7 for ; Tue, 13 Dec 2011 03:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_BACKHAIR_33=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7xBoO-9O7OO for ; Tue, 13 Dec 2011 03:43:06 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2B90D21F88AB for ; Tue, 13 Dec 2011 03:43:06 -0800 (PST) From: Guido Moritz To: 'pierpaolo giacomin' , References: <006601ccb8e7$6e7aa7b0$4b6ff710$@uni-rostock.de> <3615F3CCD55F054395A882F51C6E5FDA1822178F@szxeml513-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED618020298@011-DB3MPN1-012.MGDPHG.emi.philips.com> <000501ccb975$557169f0$00543dd0$@uni-rostock.de> <001801ccb980$72da18b0$588e4a10$@uni-rostock.de> <002a01ccb985$04ee5960$0ecb0c20$@uni-rostock.de> <31be9f671d88302bf0d4e1e47a289020@autistici.org> In-Reply-To: <31be9f671d88302bf0d4e1e47a289020@autistici.org> Date: Tue, 13 Dec 2011 12:43:04 +0100 Message-ID: <003d01ccb98c$5fe1df20$1fa59d60$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMIdFaLyibYTMm16Pxm1bv8JN+UWAID3dJdAca5M0kBIHMIQAHb2tpjAd4tbqQCWM+DkQD4Q9DnAkzkPkuS8Bba4A== Content-Language: de X-Originating-IP: [139.30.201.226] Subject: Re: [core] Proxy Meda Type Conversion 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, 13 Dec 2011 11:43:07 -0000 > Moreover, I've not enough background on xml, exi and json to state a > possible translation 1:1 exists, or at least from a given format to = two > the others.=20 There are formats exist which can be converted into each other without = any state. For SOAP and thus XML-Infoset based documents the first which = come into my mind are native XML, EXI and Fast Infoset.=20 > If a 1:1 translation is not available it would become definitely an > application issue, moving away from "straight-proxy" scope. Still > interesting to me, but no point to speak about it here. Absolutely agree! Guido > -----Urspr=C3=BCngliche Nachricht----- > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von > pierpaolo giacomin > Gesendet: Dienstag, 13. Dezember 2011 12:25 > An: core@ietf.org > Betreff: Re: [core] Proxy Meda Type Conversion >=20 >=20 > I was discussing yesterday with tho of handling application data > conversion in the proxy. The objective of my proposal was having a > coalesced cache for different content-types. > This would violate heavily the concept of end-to-end, but still, it > presents interesting pros, namely reducing communication between proxy > and the cached resource, and memory usage in the proxy. > Anyway, yesterday he convinced me to drop it, with a strong argument > about origin preservation. > Moreover, I've not enough background on xml, exi and json to state a > possible translation 1:1 exists, or at least from a given format to = two > the others. If someone does I'll be happy to pursue the idea, and that > could fix as well your needs. > If a 1:1 translation is not available it would become definitely an > application issue, moving away from "straight-proxy" scope. Still > interesting to me, but no point to speak about it here. >=20 >=20 > On 13.12.2011 12:50, Guido Moritz wrote: > > I agree with your point that application data conversion for an > > intermediate proxy cannot be specified in CoRE. This would be in the > > responsibility of other groups or even other standardization bodies. > > > > But it would be the WG (if the WG is interested in) to provide and > > define a protocol mechanism, which can be used for such purposes. > > Maybe at the end this is only an option with an arbitrary data type, > > which can be used by other bodies to express the type and way of > > conversion. > > > > If there is an existing solution for this I would be happy with it > > anyway. > > > > Best, > > Guido > > > >> -----Urspr=C3=BCngliche Nachricht----- > >> Von: angelo.castellani@gmail.com > >> [mailto:angelo.castellani@gmail.com] Im > >> Auftrag von Angelo P. Castellani > >> Gesendet: Dienstag, 13. Dezember 2011 11:31 > >> An: Guido Moritz > >> Cc: Thomas Fossati; core@ietf.org > >> Betreff: Re: [core] Proxy Meda Type Conversion > >> > >> Web proxies are not intended to convert application data, so > >> probably > >> this feature is missing for this reason. > >> > >> You can get around it as Thomas suggested to you, and you can even > >> instantiate a long-lived observe session with that Accept options.. > >> In > >> this way your ALG/proxy will also convert the payload even on push > >> operations from nodes by remembering the state for that conversion. > >> > >> Otherwise we will need a special option for CoAP requests to = specify > >> application data conversion for an intermediate proxy, and handle > >> all > >> the complexities this leads to... I doubt that this will be done in > >> the WG, anyway I personally think that it may be useful because I > >> may > >> have similar needs too. > >> > >> Are there other options to get around this? > >> > >> Best, > >> Angelo > >> > >> On Tue, Dec 13, 2011 at 11:17, Guido Moritz > >> > >> wrote: > >> > Thomas, > >> > > >> > the problem is that in the case you described only the response > >> can be > >> > optimized, as the proxy can indicate supported formats in the > >> Accept Option. > >> > But there is currently no way to do it also for the request. The > >> only way to > >> > it this is do always the conversion (which is so far OK for our > >> use case, > >> > but for sure not for all other use cases too). > >> > > >> > The scenario maybe explained more precisely: A XML over HTTP > >> client knows > >> > about a sensor to invoke and knows that the sensor supports EXI > >> over CoAP > >> > (maybe also XML over CoAP, but this is somewhat optimization > >> already). So > >> > for the request it uses a HTTP-CoAP proxy. But the proxy has no > >> knowledge > >> > about the supported formats of the sensor. So the HTTP client > >> would like to > >> > instruct the proxy also to do the format conversion. > >> > > >> > Let's turn this around: A EXI over CoAP client wants to deliver > >> the data to > >> > an XML over HTTP server. So it uses the CoAP-HTTP proxy. But the > >> proxy has > >> > no knowledge about the supported formats of the server. So the > >> CoAP client > >> > would like to instruct the proxy also to do the format = conversion. > >> > > >> > Such a mechanism would be quite useful to integrate CoAP sensors > >> in existing > >> > applications, because no (not too many) changes have to be done = in > >> the > >> > existing implementations. The only new parts are the sensors and > >> the proxy > >> > including EXI/XML (and maybe more formats). And the proxy is = still > >> > stateless, because it requires no knowledge about supported > >> formats of each > >> > single endpoint. > >> > > >> > Guido > >> > > >> >> -----Urspr=C3=BCngliche Nachricht----- > >> >> Von: Thomas Fossati [mailto:tho@koanlogic.com] > >> >> Gesendet: Dienstag, 13. Dezember 2011 10:52 > >> >> An: Guido Moritz > >> >> Cc: core@ietf.org WG > >> >> Betreff: Re: [core] Proxy Meda Type Conversion > >> >> > >> >> Hi Guido, > >> >> > >> >> On Dec 13, 2011, at 9:58 AM, Guido Moritz wrote: > >> >> > You got exactly the point! We have the plan to implement such = a > >> proxy. > >> > So we > >> >> > already have an EXI implementation for TelosB and we have a > >> HTTP-CoAP > >> >> and > >> >> > CoAP-HTTP Proxy. Now the idea was to also implement a > >> conversion of > >> XML > >> >> to > >> >> > EXI and vice versa in the Proxy. > >> >> > > >> >> > Off course the proxy is stateless and has no knowledge about > >> which > >> >> > conversion has to be done for which endpoints. Hence, this > >> information > >> > must > >> >> > be somehow encoded in the request and response. How the > >> endpoints > >> > receive > >> >> > the knowledge about which formats are supported by the other > >> side is out > >> > of > >> >> > scope so far. This could be maybe performed during the > >> discovery phase, > >> >> > static defined, etc. For our use case it is sufficient to > >> perform the > >> >> > conversion statically. > >> >> > > >> >> > The question was, if such a mechanism to advise the proxy to > >> also do the > >> >> > data conversion already exists in CoAP. I was not sure, but it > >> seems not > >> > to > >> >> > be the case. Putting this issue (maybe including our use case) > >> in an I-D > >> >> > seems reasonable...maybe I will find some time during = Christmas > >> days. > >> >> > > >> >> > Nevertheless, more comments and ideas on that issue would be > >> great! > >> >> > >> >> I may have misunderstood your point, but *provided the existence > >> of a > >> > schema- > >> >> less translation of XML to EXI* (and viceversa), couldn't the > >> intermediate > >> > node > >> >> simply do "proxy" content negotiation, like this ? > >> >> > >> >> HTTP UA Proxy CoAP srv > >> >> | | | > >> >> +-------->| | Accept: text/xml, application/xml > >> >> | GET x | | > >> >> | +-------->| Accept: application/xml, application/exi > >> >> | | GET y | > >> >> | | | > >> >> > >> >> and viceversa: > >> >> > >> >> CoAP cli Proxy HTTP origin > >> >> | | | > >> >> +-------->| | Accept: application/exi > >> >> | GET a | | > >> >> | +-------->| Accept: application/xml, text/xml, > >> > Accept-Encoding: x-exi > >> >> | | GET b | > >> >> | | | > >> >> > >> >> handling the XML<->EXI conversions transparently. > >> >> > >> >> [The above scenario comprises an HTTP UA and origin who can do > >> XML (the > >> >> origin may perhaps do EXI, see Accept-Encoding) and a CoAP = client > >> and > >> > server > >> >> who can only handle EXI encoded XML.]=3D > >> > > >> > _______________________________________________ > >> > 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 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From tho@koanlogic.com Tue Dec 13 05:03:24 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 1A08C21F847B for ; Tue, 13 Dec 2011 05:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.672 X-Spam-Level: * X-Spam-Status: No, score=1.672 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q15ofaT6JM9m for ; Tue, 13 Dec 2011 05:03:23 -0800 (PST) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 878E621F847A for ; Tue, 13 Dec 2011 05:03:23 -0800 (PST) Received: from host59-247-dynamic.53-79-r.retail.telecomitalia.it ([79.53.247.59]:54079 helo=t.home) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RaS0n-0004Bv-SY; Tue, 13 Dec 2011 08:03:21 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <002a01ccb985$04ee5960$0ecb0c20$@uni-rostock.de> Date: Tue, 13 Dec 2011 14:02:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <788B7E53-BCC8-4107-B428-93C3883BD2B5@koanlogic.com> References: <006601ccb8e7$6e7aa7b0$4b6ff710$@uni-rostock.de> <3615F3CCD55F054395A882F51C6E5FDA1822178F@szxeml513-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED618020298@011-DB3MPN1-012.MGDPHG.emi.philips.com> <000501ccb975$557169f0$00543dd0$@uni-rostock.de> <001801ccb980$72da18b0$588e4a10$@uni-rostock.de> <002a01ccb985$04ee5960$0ecb0c20$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.53.247.59 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: core@ietf.org Subject: Re: [core] Proxy Meda Type Conversion 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, 13 Dec 2011 13:03:24 -0000 On Dec 13, 2011, at 11:50 AM, Guido Moritz wrote: > But it would be the WG (if the WG is interested in) to provide and = define a protocol mechanism, which can be used for such purposes. Maybe = at the end this is only an option with an arbitrary data type, which can = be used by other bodies to express the type and way of conversion. >=20 > If there is an existing solution for this I would be happy with it = anyway.=20 One further element. HTTP doesn't provide any way for the HTTP/CoAP = proxy to handle this situation transparently, see: =20 = http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-17#section-7.4.= 16 On a 415 response, the origin would not be forced to express any hint = about the supported media types to the failed proxy request. So, a transparent conversion handled by the proxy using a trial and = error strategy is not applicable in the general case, and a translation = hint provided by the CoAP client via option seems to fix this hole = nicely, IMHO.= From tho@koanlogic.com Tue Dec 13 06:27: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 282F421F8B11 for ; Tue, 13 Dec 2011 06:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.561 X-Spam-Level: X-Spam-Status: No, score=0.561 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KW2ILMxZ-mmp for ; Tue, 13 Dec 2011 06:27:22 -0800 (PST) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id B950221F8B10 for ; Tue, 13 Dec 2011 06:27:22 -0800 (PST) Received: from host59-247-dynamic.53-79-r.retail.telecomitalia.it ([79.53.247.59]:55150 helo=t.home) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RaTJj-0004OQ-7M for core@ietf.org; Tue, 13 Dec 2011 09:27:20 -0500 From: Thomas Fossati Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Dec 2011 15:26:13 +0100 Message-Id: <3AB4ED7E-F81F-47A3-85E4-F7FFE1F0A60F@koanlogic.com> To: "core@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.53.247.59 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Subject: [core] Accept option in 4.15 responses 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, 13 Dec 2011 14:27:23 -0000 Following up to the point raised by Guido, and given a related thread = that has been recently started on HTTPbis mailing list: http://lists.w3.org/Archives/Public/ietf-http-wg/2011OctDec/0455.html what's your opinion about having the Accept option added to responses = with 4.15 code ?= From prvs=03284951A4=guido.moritz@uni-rostock.de Tue Dec 13 08:03:58 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 D666B21F8A66 for ; Tue, 13 Dec 2011 08:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.822 X-Spam-Level: X-Spam-Status: No, score=-2.822 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BbxEQCSQYw9 for ; Tue, 13 Dec 2011 08:03:58 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id A879321F86C3 for ; Tue, 13 Dec 2011 08:03:57 -0800 (PST) From: Guido Moritz To: 'Thomas Fossati' , References: <3AB4ED7E-F81F-47A3-85E4-F7FFE1F0A60F@koanlogic.com> In-Reply-To: <3AB4ED7E-F81F-47A3-85E4-F7FFE1F0A60F@koanlogic.com> Date: Tue, 13 Dec 2011 17:03:54 +0100 Message-ID: <004e01ccb9b0$d04fdfe0$70ef9fa0$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+z1oevRQ27vUTOz5kWX/PudT8NpV1wsbA Content-Language: de X-Originating-IP: [139.30.201.226] Subject: Re: [core] Accept option in 4.15 responses 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, 13 Dec 2011 16:03:59 -0000 +1. Sounds reasonable for me. Guido > -----Urspr=FCngliche Nachricht----- > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von > Thomas Fossati > Gesendet: Dienstag, 13. Dezember 2011 15:26 > An: core@ietf.org WG > Betreff: [core] Accept option in 4.15 responses >=20 > Following up to the point raised by Guido, and given a related thread = that has > been recently started on HTTPbis mailing list: >=20 > = http://lists.w3.org/Archives/Public/ietf-http-wg/2011OctDec/0455.html >=20 > what's your opinion about having the Accept option added to responses = with > 4.15 code ? > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From isaidyep@gmail.com Tue Dec 13 08:08:04 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 5E9BE21F8B39 for ; Tue, 13 Dec 2011 08:08:04 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0s-pZOY6+DDS for ; Tue, 13 Dec 2011 08:08:03 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2149121F8B37 for ; Tue, 13 Dec 2011 08:08:02 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so10556486wgb.13 for ; Tue, 13 Dec 2011 08:08:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ggr7Gs0/buHFyDFrLsnyqdsEEzGN4EfABRfG0PUnRdo=; b=P9O66+bcBIu8uZlclfAwehiaKMc1z5IWEHtIEd61JK5Z8Ml8jrdS1rK9SItEfe36yt Qq4+RQ3n9kWNN3HLeaNkvoGhnD0dQVcwv1ihjI/pcfRZ9HRXAVCjLhao25oOxfSY3reI 83sinyF4h0s+4W3VNpgKYcqwtjMMPvATPqGac= MIME-Version: 1.0 Received: by 10.227.203.10 with SMTP id fg10mr17227626wbb.1.1323792480925; Tue, 13 Dec 2011 08:08:00 -0800 (PST) Received: by 10.180.107.99 with HTTP; Tue, 13 Dec 2011 08:08:00 -0800 (PST) In-Reply-To: <004e01ccb9b0$d04fdfe0$70ef9fa0$@uni-rostock.de> References: <3AB4ED7E-F81F-47A3-85E4-F7FFE1F0A60F@koanlogic.com> <004e01ccb9b0$d04fdfe0$70ef9fa0$@uni-rostock.de> Date: Tue, 13 Dec 2011 17:08:00 +0100 Message-ID: From: Mirko Rossini To: core@ietf.org Content-Type: multipart/alternative; boundary=000e0cd59fe094fa7a04b3fb7413 Subject: Re: [core] Accept option in 4.15 responses 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, 13 Dec 2011 16:08:04 -0000 --000e0cd59fe094fa7a04b3fb7413 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 2011/12/13 Guido Moritz > +1. Sounds reasonable for me. > > Guido > > > -----Urspr=FCngliche Nachricht----- > > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag vo= n > > Thomas Fossati > > Gesendet: Dienstag, 13. Dezember 2011 15:26 > > An: core@ietf.org WG > > Betreff: [core] Accept option in 4.15 responses > > > > Following up to the point raised by Guido, and given a related thread > that > has > > been recently started on HTTPbis mailing list: > > > > http://lists.w3.org/Archives/Public/ietf-http-wg/2011OctDec/0455.html > > > > what's your opinion about having the Accept option added to responses > with > > 4.15 code ? > > _______________________________________________ > > 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 > --000e0cd59fe094fa7a04b3fb7413 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

2011/12/13 Guido Moritz <guido.moritz@uni-ros= tock.de>
+1. Sounds reasonable for me.

Guido

> -----Urspr=FCngliche Nachricht-----
> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von
> Thomas Fossati
> Gesendet: Dienstag, 13. Dezember 2011 15:26
> An: core@ietf.org WG
> Betreff: [core] Accept option in 4.15 responses
>
> Following up to the point raised by Guido, and given a related thread = that
has
> been recently started on HTTPbis mailing list:
>
> =A0 http://lists.w3.org/Archives/Public/ietf-= http-wg/2011OctDec/0455.html
>
> what's your opinion about having the Accept option added to respon= ses with
> 4.15 code ?
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

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

--000e0cd59fe094fa7a04b3fb7413-- From cabo@tzi.org Tue Dec 13 09:29:46 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 6618321F89B8 for ; Tue, 13 Dec 2011 09:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.112 X-Spam-Level: X-Spam-Status: No, score=-105.112 tagged_above=-999 required=5 tests=[AWL=1.137, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3umYxEyS6LE for ; Tue, 13 Dec 2011 09:29:44 -0800 (PST) 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 2506321F891D for ; Tue, 13 Dec 2011 09:29:43 -0800 (PST) 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 pBDHTZri025346; Tue, 13 Dec 2011 18:29:36 +0100 (CET) Received: from dynamic-218-e.informatik.uni-bremen.de (dynamic-218-e.informatik.uni-bremen.de [134.102.218.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A82E1DF; Tue, 13 Dec 2011 18:29:35 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <3AB4ED7E-F81F-47A3-85E4-F7FFE1F0A60F@koanlogic.com> Date: Tue, 13 Dec 2011 18:29:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4A0ED0F3-B123-4760-94EA-9280EBA51947@tzi.org> References: <3AB4ED7E-F81F-47A3-85E4-F7FFE1F0A60F@koanlogic.com> To: Thomas Fossati X-Mailer: Apple Mail (2.1251.1) Cc: "core@ietf.org WG" Subject: Re: [core] Accept option in 4.15 responses 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, 13 Dec 2011 17:29:46 -0000 On Dec 13, 2011, at 15:26, Thomas Fossati wrote: > what's your opinion about having the Accept option added to responses = with 4.15 code ? I think we should see how the discussion on the related HTTP feature = converges. But yes, similar considerations do apply. Gr=FC=DFe, Carsten From dotis@mail-abuse.org Tue Dec 13 15:05: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 9CCF211E80AD; Tue, 13 Dec 2011 15:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.91 X-Spam-Level: X-Spam-Status: No, score=-101.91 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGaEUq9V0tmf; Tue, 13 Dec 2011 15:05:16 -0800 (PST) Received: from mailserv.mail-abuse.org (sjdc-maps-mail.trendmicro.com [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 48D0C11E80A4; Tue, 13 Dec 2011 15:05:16 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway1.sdi.trendnet.org [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id EE0E01740363; Tue, 13 Dec 2011 23:05:15 +0000 (UTC) Message-ID: <4EE7DA2A.3000704@mail-abuse.org> Date: Tue, 13 Dec 2011 15:05:14 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: core@ietf.org, Carsten Bormann , Cullen Jennings , domainrep References: <3AB4ED7E-F81F-47A3-85E4-F7FFE1F0A60F@koanlogic.com> <4A0ED0F3-B123-4760-94EA-9280EBA51947@tzi.org> In-Reply-To: <4A0ED0F3-B123-4760-94EA-9280EBA51947@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] Suitability of CoAP in supporting domain reputation queries as an alternative to DNS. 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, 13 Dec 2011 23:05:16 -0000 CoRE WG, Please note, this message is cross posted with the Repute WG mailing-list. The Repute WG seeks help in deciding whether CoAP offers a good solution for distribution of reputation reports that assess various message identities, such as those used within email. The current state of art uses DNS and "._label." to extend queries appended to the service domain. Often the extended query describes a domain being queried along with possible scopes. In addition, information returned is fairly undefined, although details might become rather extensive. These details might include various categories known about the identity, such as involvement with financial transactions, relative volume assessments, incident reports, etc. To get the ball rolling, it seems the restful nature of CoAP will work well in conjunction with Akamai like services. Section 2.3 of Constrained Application Protocol CoAP, defines response caching in addition to mapping between HTTP and CoAP. While the message format is defined using TLV structures, the payload could include JSON structures if desired. CoAP is bound to UDP and offers a minimum MTU of 1152 bytes that compares well against the 512 byte message size limitation often imposed on DNS. CoAP includes UTF-8 encoded strings, opaque byte sequences, variable byte non-negative integers, URI-Host, URI-Path, URI-Port, Content-Type, etc. CoAP uses 16 bit Message IDs analogous to that of the DNS Transaction ID in addition to a 1 to 8 byte optional Token. CoAP can also be secured using Datagram TLS (DTLS). -Doug From hvdsomp@gmail.com Tue Dec 13 18:05:39 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 B1A9C11E8093 for ; Tue, 13 Dec 2011 18:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCf0Pa+26ToJ for ; Tue, 13 Dec 2011 18:05:38 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3777011E8095 for ; Tue, 13 Dec 2011 18:05:38 -0800 (PST) Received: by dajz8 with SMTP id z8so304285daj.31 for ; Tue, 13 Dec 2011 18:05:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=z2844YlKYCEAru8ZsFyL/YdeG/t7hwahMvZxoRZAcDI=; b=irrmaW3Ol5fob36Gk6A5s8CUEVkhi48/OhsdO1fjYT2sZCzwl99Ch02bSZp/BVC4ow h8REQo1Yzlp7oD8E9ECupFGWncX3rUurdk7q6guu/+tC/Twi9WFQQO7W5PpfyUZcV7/Y v1ljFcneM5ORBtKlBfhKSS//pvqTM0ifMi03o= MIME-Version: 1.0 Received: by 10.68.73.65 with SMTP id j1mr382910pbv.80.1323828337987; Tue, 13 Dec 2011 18:05:37 -0800 (PST) Received: by 10.68.4.170 with HTTP; Tue, 13 Dec 2011 18:05:37 -0800 (PST) Date: Tue, 13 Dec 2011 19:05:37 -0700 Message-ID: From: Herbert van de Sompel To: core@ietf.org Content-Type: multipart/alternative; boundary=f46d041038b7d450fd04b403cd78 X-Mailman-Approved-At: Tue, 13 Dec 2011 23:07:04 -0800 Cc: yaojk@cccic.cn, azaroth42@gmail.com, mln@cs.odu.edu, barryleiba@computer.org, mnot@pobox.com Subject: [core] application/link-format & non CoRE applications 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, 14 Dec 2011 02:05:39 -0000 --f46d041038b7d450fd04b403cd78 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I am getting back to this list regarding the use of application/link-format documents in the Memento "Time Travel for the Web" framework [1,2]. I have posted to this list before: - To announce Memento's use of link-format documents [3]. - To point out that the determination of Context IRIs for links expressed in application/link-format documents as specified in the CoRE Link Format Internet Draft was problematic for Memento's use [4]. I never received any reaction to this mail. Having read the most recent version of the CoRE Link Format Internet Draft [5] carefully, I need to conclude that the specification has evolved in such a manner that use of the application/link-format media type in the Memento framework has become quite problematic. And I expect it would be problematic for many applications that are not CoRE. I find this application-specific approach generally inappropriate for a media type definition, and I find it especially cumbersome because I anticipate that - as Link headers will become increasingly used - other applications will encounter the need to express links in documents, not just in HTTP headers. I think it would be counter-productive if such applications would have to define their own media type based on the syntax specified for the HTTP Link header [6]. Hence, I hope it will still be possible to specify application/link-format in a more generic manner. These are specific issues I would like to point out that make use of the application/link-format media type problematic for applications other than CoRE ones: (a) Section 1 is entirely framed in terms of CoRE applications and states "This document specifies a link format for use in CoRE Resource Discovery" (b) Section 2 states "The CoRE Link Format is only expected to be supported in constrained networks and M2M systems." (c) As I expressed in [4], and as confirmed by the current version of the I-D, the determination of the Context IRI for a link in application/link-format documents is conceived in function of CoRE applications and is problematic for other uses. In Memento (and I anticipate in other potential applications), the Context IRI is not the base-URI of the Target URI nor the base-URI of the URI that delivered the links. As a matter of fact, for the large majority of links used by Memento, the Context IRI and Target IRI are in different domains. Hence, following the specification in Section 2.1, all such links would have to be expressed using an anchor: - Doing so, as such, yields an enormous overhead (Memento TimeMaps that use the link format can easily contain many hundreds of links; see e.g. http://mementoarchive.lanl.gov/list/timemap/link/http://lanlsource.lanl.gov/hello ). - To aggravate the situation, the wording regarding links with anchors in the I-D marginalizes this approach by stating: "A consuming implementation can however choose to ignore such links. It is not expected that all implementations will be able to derive useful information from explicitly anchored links." In [4], I described a proposal to allow specifying the Context IRI of links in application/link-format documents by means of a special-purpose link and a special-purpose relation type. I trust other approaches can be imagined; the bottom line however is that a mechanism that allows to elegantly deviate from the default determination of Context IRIs as currently specified in the I-D should be available. I would like to add that Memento's use of link-formatted documents is not marginal. I anticipate that by the end of 2012 such documents will be available to communicate the holdings of web archives, worldwide. That is over 10 billion links expressed using this format. Looking forward to a constructive discussion. Greetings Herbert Van de Sompel [1] http://mementoweb.org [2] https://datatracker.ietf.org/doc/draft-vandesompel-memento/ [3] http://www.ietf.org/mail-archive/web/core/current/msg01119.html [4] http://www.ietf.org/mail-archive/web/core/current/msg01824.html [5] http://tools.ietf.org/html/draft-ietf-core-link-format-09 [6] http://tools.ietf.org/html/rfc5988 -- Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ == --f46d041038b7d450fd04b403cd78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi all,

I am getting back to = this list regarding the use of application/link-format documents in the Mem= ento "Time Travel for the Web" framework [1,2].=A0

I have posted to this= list before:

- To announce Memento= 's use of link-format documents [3].

- To point out that t= he determination of Context IRIs for links expressed in application/link-fo= rmat documents as specified in the CoRE Link Format Internet Draft was prob= lematic for Memento's use [4]. I never received any reaction to this ma= il.

Having read the most = recent version of the CoRE Link Format Internet Draft [5] carefully, I need= to conclude that the specification has evolved in such a manner that use o= f the application/link-format media type in the Memento framework has becom= e quite problematic. And I expect it would be problematic for many applicat= ions that are not CoRE.=A0

I find this applicati= on-specific approach generally inappropriate for a media type definition, a= nd I find it especially cumbersome because I anticipate that - as Link head= ers will become increasingly used - other applications will encounter the n= eed to express links in documents, not just in HTTP headers. I think it wou= ld be counter-productive if such applications would have to define their ow= n media type based on the syntax specified for the HTTP Link header [6]. He= nce, I hope it will still be possible to specify application/link-format in= a more generic manner.=A0

These are specific is= sues I would like to point out that make use of the application/link-format= media type problematic for applications other than CoRE ones:

(a) Section 1 is enti= rely framed in terms of CoRE applications and states "This document sp= ecifies a link format for use in CoRE Resource Discovery"

(b) Section 2 states = "The CoRE Link Format is only expected to be supported in constrained = networks and M2M systems."

(c) As I expressed in= [4], and as confirmed by the current version of the I-D, the determination= of the Context IRI for a link in application/link-format documents is conc= eived in function of CoRE applications and is problematic for other uses.= =A0 In Memento (and I anticipate in other potential applications), the Cont= ext IRI is not the base-URI of the Target URI nor the base-URI of the URI t= hat delivered the links. As a matter of fact, for the large majority of lin= ks used by Memento, the Context IRI and Target IRI are in different domains= . Hence, following the specification in Section 2.1, all such links would h= ave to be expressed using an anchor:

- Doing so, as such, = yields an enormous overhead (Memento TimeMaps that use the link format can = easily contain many hundreds of links; see e.g. http://m= ementoarchive.lanl.gov/list/timemap/link/http://lanlsource.lanl.gov/hello).=A0

- To aggravate the si= tuation, the wording regarding links with anchors in the I-D marginalizes t= his approach by stating: "A consuming implementation can however choos= e to ignore such links. It is not expected that all implementations will be= able to derive useful information from explicitly anchored links." In= [4], I described a proposal to allow specifying the Context IRI of links i= n application/link-format documents by means of a special-purpose link and = a special-purpose relation type. I trust other approaches can be imagined; = the bottom line however is that a mechanism that allows to elegantly deviat= e from the default determination of Context IRIs as currently specified in = the I-D should be available.

I would like to add t= hat Memento's use of link-formatted documents is not marginal. I antici= pate that by the end of 2012 such documents will be available to communicat= e the holdings of web archives, worldwide. That is over 10 billion links ex= pressed using this format.

Looking forward to a = constructive discussion.

Greetings

Herbert Van de Sompel=

[1] http://mementoweb.org

[2] https://d= atatracker.ietf.org/doc/draft-vandesompel-memento/=A0

[3] http://www.ietf.= org/mail-archive/web/core/current/msg01119.html

[4] http://www.ietf.= org/mail-archive/web/core/current/msg01824.html

[5] http://tools.ietf.org/= html/draft-ietf-core-link-format-09

[6] http://tools.ietf.org/html/rfc5988


--
Herbert Van de Sompel
Digital Library = Research & Prototyping
Los Alamos National Laboratory, Research Libr= ary
http://publi= c.lanl.gov/herbertv/

=3D=3D

--f46d041038b7d450fd04b403cd78-- From cabo@tzi.org Tue Dec 13 23:50:09 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 E54831F0C48 for ; Tue, 13 Dec 2011 23:50:09 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KFXcOakr1So for ; Tue, 13 Dec 2011 23:50:08 -0800 (PST) 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 BD9331F0C38 for ; Tue, 13 Dec 2011 23:50:05 -0800 (PST) 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 pBE7nuR0028612; Wed, 14 Dec 2011 08:49:56 +0100 (CET) Received: from [192.168.217.112] (p54899AAB.dip.t-dialin.net [84.137.154.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C6C2F225; Wed, 14 Dec 2011 08:49:55 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 14 Dec 2011 08:49:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Herbert van de Sompel X-Mailer: Apple Mail (2.1251.1) Cc: "core@ietf.org WG" Subject: Re: [core] application/link-format & non CoRE applications 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, 14 Dec 2011 07:50:10 -0000 [Trimming CC list -- yours is long enough to get the message stuck in = the moderation queue.] Herbert, the CoRE WG has been working on using RFC 5988 Web Linking for its = resource discovery needs. The result is the link-format document that = just passed second WGLC (the WGLC comments from this round still need to = be processed). What have we done here? -- we have defined a way to ship link relations in a separate document = that has its own media type (link-format). -- we have defined the "hosts" link relation that is intended to be used = for the "/.well-known/core" type application we are interested in. Due to our application in constrained node/networks, we also are = interested in minimizing the complexity that implementations need to go = to. So we allow some simplifications. E.g., one WGLC comment was that = expressing multiple link relations in a space-separated list is some = complexity that is rarely needed in a CoRE application, so we are = looking for ways to avoid it. We will need to meet this kind of = requirements to make link-format useful for its intended applications. Note that the second-class status of anchored links wasn't invented by = link-format, but is explicitly called out in 5988 as well (section 5.2, = "Consuming implementations can choose to ignore links with an anchor = parameter..."). What you are proposing amounts to re-using the link-format specification = for a broader application. Of course, most of us would agree that = having multiple specifications for closely related purposes is rarely = the right approach, so I'd expect many in the WG to support this. So what is it that you need to re-purpose the link-format spec? As far as I understand, the only actual change you need is less with = link-format than with the context-IRI spec in 5988, which we aren't = changing in link-format. I'm a bit uneasy with specifying this change to the 5988 semantics (that = we inherit) in the form of just another link relation -- the link = relations in a link-format document are meant to be completely = independent of each other; splitting a link-format document in the = middle and conveying it as two documents should not change the semantics = at all. Maybe a different way is needed to influence the context-IRI of all = links in a link-format document (i.e., beyond adding an anchor parameter = per link). I could even imagine applications of such a facility in = CoRE, although in our space we would have to carefully weigh its = usefulness against the added complexity. Gr=FC=DFe, Carsten From esko.dijk@philips.com Wed Dec 14 01:37: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 8A9C921F8770 for ; Wed, 14 Dec 2011 01:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.127 X-Spam-Level: X-Spam-Status: No, score=-5.127 tagged_above=-999 required=5 tests=[AWL=1.472, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAr--IdwqPM3 for ; Wed, 14 Dec 2011 01:37:36 -0800 (PST) Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 22DF721F86FF for ; Wed, 14 Dec 2011 01:37:36 -0800 (PST) Received: from mail48-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Dec 2011 09:37:38 +0000 Received: from mail48-tx2 (localhost [127.0.0.1]) by mail48-tx2-R.bigfish.com (Postfix) with ESMTP id 415492602AC; Wed, 14 Dec 2011 09:37:38 +0000 (UTC) X-SpamScore: -51 X-BigFish: VPS-51(zz217bL15d6O9371I9251J146fK542M1432N98dKzz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-FB-SS: 0, Received: from mail48-tx2 (localhost.localdomain [127.0.0.1]) by mail48-tx2 (MessageSwitch) id 1323855416697397_18757; Wed, 14 Dec 2011 09:36:56 +0000 (UTC) Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.245]) by mail48-tx2.bigfish.com (Postfix) with ESMTP id A2D045E006F; Wed, 14 Dec 2011 09:36:56 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Dec 2011 09:36:55 +0000 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.218]) by 011-DB3MMR1-007.MGDPHG.emi.philips.com ([10.128.28.57]) with mapi id 14.01.0355.003; Wed, 14 Dec 2011 09:36:12 +0000 From: "Dijk, Esko" To: 'Zach Shelby' Thread-Topic: [core] Message ID sliding window Thread-Index: AcySPs1fMIoXMmmfQL2aZphhnV3ETAAqUrOACdaCTiA= Date: Wed, 14 Dec 2011 09:36:39 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180205CA@011-DB3MPN1-012.MGDPHG.emi.philips.com> References: <4E0BB964.3020806@piuha.net> <4E9C14CD.2010700@piuha.net> <84E14610-724C-41CB-8B9D-90146637EFDF@sensinode.com> <98663C38B11E52489875919E3E9565DEC5824B8223@NLCLUEXM03.connect1.local> In-Reply-To: <98663C38B11E52489875919E3E9565DEC5824B8223@NLCLUEXM03.connect1.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "'core@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: Wed, 14 Dec 2011 09:37:37 -0000 Hi Zach, to attempt to conclude this thread: does the proposed text below make sense= to you? The key arguments for including it are=20 1) make developers aware of this possibility for efficient implementation = of MID storage, assuming many CoAP end-points would use sequential MIDs;=20 2) suggest that developers use sequential MIDs if there's no reason to do = otherwise;=20 Esko -----Original Message----- From: Dijk, Esko=20 Sent: Tuesday 25 October 2011 9:46 To: Zach Shelby Cc: Jari Arkko; core@ietf.org Subject: RE: [core] Message ID sliding window Here is a proposal that can be added at the end of the paragraph "Several implementation strategies can be employed for generating Messag= e IDs ..... ........ RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT - 1) plus the expe= cted maximum round trip time." [proposal:] To support efficient Message ID storage implementations for duplicate me= ssage=20 detection (which is detailed below), an end-point MAY generate sequentia= l=20 Message IDs by increasing a Message ID variable by 1 each time a=20 new message is sent.=20 This does not prescribe one or multiple MID variables, this is left to impl= ementation strategies as stated in the current paragraph already. Specific implementation strategies are mentioned as a motivation for this o= ptional behaviour. The wrapping of value from highest to 0 is not explicitl= y mentioned but could be added. Esko -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com]=20 Sent: Monday 24 October 2011 13:24 To: Dijk, Esko Cc: Jari Arkko; core@ietf.org Subject: Re: [core] Message ID sliding window So to conclude on this thread with a concrete action on the draft (or not).= The current text says: "Several implementation strategies can be employed for generating Message I= Ds. In the simplest case a CoAP end-point generates Message IDs by keeping = a single Message ID variable, which is changed each time a new confirmable = message is sent regardless of the destination address or port." Esko is suggesting to make it more explicit that this MAY be sequentially i= ncremented. There doesn't seem to be push-back on that as long is it isn't = a SHOULD. Do you have a proposal for the new text that you think should be = added? So far I haven't been able to come up with MAY text that would make = much sense here considering the current text. Zach On Oct 17, 2011, at 5:56 PM, Dijk, Esko wrote: > Hi, >=20 >> We should not mandate that in any sense in the spec, however, because ot= herwise someone will start trusting that all devices behave that way. >=20 > this was one of the reasons for me to propose a 'MAY' here. It does not c= reate a barrier to interesting strategies e.g. as used in the tiny CoAP sen= sors. A 'SHOULD' is rather strong here ("but the full implications must be = understood and carefully weighed before choosing a different course", RFC 2= 119).=20 >=20 > A 'MAY' serves as a note to implementers "you could do it this way, with = these specific benefits" which should be enough push in the right direction= in applications where an implementer doesn't really care what MID generati= on strategy is applied e.g. as in unconstrained nodes.=20 > Interestingly a 'MAY' provides a _stronger_ requirement for CoAP nodes to= support non-sequential MIDs from other nodes. Because then, implementers w= ill not assume that everyone follows the 'SHOULD' from the spec. In fact th= ey MUST NOT assume that the optional feature is there, as RFC 2119 indicate= s for a 'MAY' :) >=20 > (Downside is that there is less incentive for implementers to care about = optimizing MID storage, though.) >=20 > regards, > Esko >=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Monday 17 October 2011 13:43 > To: Zach Shelby > Cc: Dijk, Esko; core@ietf.org > Subject: Re: [core] Message ID sliding window >=20 >=20 > The original proposal that started this thread was to make some recommend= ation on using sequential IDs. I am against that (even as a SHOULD), on the= grounds that it is unnecessary and any level of mandatory sequencing would= break some implementation strategies (such as the one I used on my tiny de= vice). Of course you can use any strategy you want, including sequencing. W= e should not mandate that in any sense in the spec, however, because otherw= ise someone will start trusting that all devices behave that way. >=20 > Anyway, I had a quick look at -07 and noticed this: >=20 >> End-points dealing with large numbers of >> transactions could keep multiple Message ID variables, for example >> per prefix or destination address. The initial variable value SHOULD >> be randomized. The same Message ID MUST NOT be re-used within the >> potential retransmission window, calculated as RESPONSE_TIMEOUT * >> RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT - 1) plus the expected >> maximum round trip time. >=20 > I think you should change s/window,/window to the same destination addres= s,/ because otherwise those multiple variables are not going to be very use= ful. >=20 > (Or possibly a combination of source/destination address.) >=20 > Jari >=20 > On 17.10.2011 12:46, Zach Shelby wrote: >> Esko, >>=20 >> Indeed, I do believe that sequential MIDs are going to be a common imple= mentation strategy (of course with a random initial value). This is allowed= by the current specification. What benefit do you see from adding MAY lang= uage around something that you may already do? >>=20 >> Seems instead we would need to point out to CoAP implementors that behav= ior could be used to optimize the storage of MIDs for duplication detection= . >>=20 >> Now I think the reason why Carsten suggested a SHOULD is that this would= make the optimization a whole lot more useful as it would encourage the ma= jority of implementations to be compatible with this optimization. That mak= es sense. >>=20 >> Zach >>=20 >> On Oct 7, 2011, at 5:49 PM, Dijk, Esko wrote: >>=20 >>> To continue this discussion from a while ago: I agree with Jari on the = freedom of assigning message IDs. >>> After a reboot the MID value is likely randomized and receiving CoAP no= des have to deal with that. And a sending node may wish to store only one M= ID counter for whatever reasons, or generated randomly if storing state is = expensive. >>>=20 >>> However, it can still be beneficial to suggest (MAY) using sequential M= IDs (mid++) for the regular operation between reboots. As an advice to be f= ollowed in case no special/random/stateless MID generation is required by a= sender. The reason is that this optionally enables to save RAM in receivin= g CoAP nodes that implement an optimized storage for MIDs close together, t= rading higher code complexity for lower RAM use. MIDs are stored then for d= eduplication purposes. >>>=20 >>> As Carsten phrased "if you believe supporting this specific optimizatio= n is worth it, we could RECOMMEND (i.e., mandate at the SHOULD level) to us= e message-IDs that are close (in modulo arithmetic) to recently used messag= e-IDs". I think it is worth it as OPTIONAL/MAY behaviour. >>> A use case may be a client sending a "toggle light" command to a CoAP (= server) lamp. >>>=20 >>> best regards, >>> Esko >>>=20 >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of= Jari Arkko >>> Sent: Thursday 30 June 2011 1:47 >>> To: core@ietf.org >>> Subject: Re: [core] Message ID sliding window >>>=20 >>> 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 t= o >>> have that freedom. As a hypothetical example, maybe I want to store onl= y >>> 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? >>>=20 >>> 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. >>>=20 >>> As a side note, I scanned the COAP draft today and did not find anythin= g >>> 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? >>>=20 >>> Jari >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>> The information contained in this message may be confidential and legal= ly protected under applicable law. The message is intended solely for the a= ddressee(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. >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >=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 From cabo@tzi.org Wed Dec 14 02:43:17 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 41D6221F8B54; Wed, 14 Dec 2011 02:43:17 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tE7QnNU6LHoU; Wed, 14 Dec 2011 02:43:16 -0800 (PST) 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 1455821F8B5C; Wed, 14 Dec 2011 02:43:11 -0800 (PST) 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 pBEAh3UG026545; Wed, 14 Dec 2011 11:43:03 +0100 (CET) Received: from [192.168.217.112] (p54899AAB.dip.t-dialin.net [84.137.154.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1836C3A9; Wed, 14 Dec 2011 11:43:03 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Carsten Bormann In-Reply-To: <4EE7DA2A.3000704@mail-abuse.org> Date: Wed, 14 Dec 2011 11:43:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5CCD2AD0-1949-4EB0-8C69-72DB410C9BAB@tzi.org> References: <3AB4ED7E-F81F-47A3-85E4-F7FFE1F0A60F@koanlogic.com> <4A0ED0F3-B123-4760-94EA-9280EBA51947@tzi.org> <4EE7DA2A.3000704@mail-abuse.org> To: Douglas Otis X-Mailer: Apple Mail (2.1251.1) Cc: domainrep , "core@ietf.org WG" Subject: Re: [core] Suitability of CoAP in supporting domain reputation queries as an alternative to DNS. 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, 14 Dec 2011 10:43:17 -0000 Hi Doug, thanks for taking to the mailing list what so far has happened mostly in = the IETF hallways. To really answer this question, it would be useful to examine some = documentation about your objectives ("requirements"). Until that happens, let me offer some observations. To a first level of approximation, CoAP provides the same service HTTP = does. If HTTP could solve your problem (performance considerations aside), and = the problem is simple enough for the simple-minded protocol that CoAP = is, then CoAP might be a good match. In particular, requests are based on URIs, and payloads make use of the = media type ("MIME type") architecture, so different kinds of resource = representations can be transferred. Of course, there are some differences to HTTP. As you note, CoAP is UDP-based, so it is indeed possible to build CoAP = servers that are completely stateless (not even keeping anything like = TCP state). For resource representations that are larger than the ~1KiB size that = can meaningfully be transported in one packet, we have the CoAP block = scheme. This still stays completely stateless on the server. = Fragmentation is never needed. (CoAP-block is not the optimal solution = for, say, retrieving a video, but variable-size things where a good part = of the distribution is inside a KiB work very well, with zero overhead = for the =E2=89=A4 ~ 1 KiB case.) On the security front, I have the following observations: -- we completely rely on lower- or higher-layer security if any is = needed. Higher-layer security could be object security (think CMS or = JOSE). For lower-layer security (i.e., communication security), our = mandatory-to-implement scheme is DTLS. Without knowing your = requirements on authentication, confidentiality etc., I have to stop = here. -- being based on UDP, CoAP has the same kind of amplification = properties that other protocols like DNS have, so Internet-facing CoAP = servers must be prepared to be implicated in DoS attacks. (This is = mitigated a bit by the ease of building a CoAP server such that it never = responds with more packets than it gets.) CoAP supports the same style of caching architecture that HTTP does -- = again, knowing more about your objectives would help us find out whether = this is a good match. We have defined CoAP to support REST on simple-minded nodes and = networks. The resulting simplicity is likely to bring some advantages = outside our space. We haven't really explored that, though (and as a = WG, we are chartered to focus on the inside). Gr=C3=BC=C3=9Fe, Carsten On Dec 14, 2011, at 00:05, Douglas Otis wrote: > CoRE WG, >=20 > Please note, this message is cross posted with the Repute WG = mailing-list. >=20 > The Repute WG seeks help in deciding whether CoAP offers a good = solution for distribution of reputation reports that assess various = message identities, such as those used within email. >=20 > The current state of art uses DNS and = "._label." to extend queries appended to the = service domain. Often the extended query describes a domain being = queried along with possible scopes. In addition, information returned = is fairly undefined, although details might become rather extensive. = These details might include various categories known about the identity, = such as involvement with financial transactions, relative volume = assessments, incident reports, etc. >=20 > To get the ball rolling, it seems the restful nature of CoAP will work = well in conjunction with Akamai like services. Section 2.3 of = Constrained Application Protocol CoAP, defines response caching in = addition to mapping between HTTP and CoAP. While the message format is = defined using TLV structures, the payload could include JSON structures = if desired. CoAP is bound to UDP and offers a minimum MTU of 1152 bytes = that compares well against the 512 byte message size limitation often = imposed on DNS. CoAP includes UTF-8 encoded strings, opaque byte = sequences, variable byte non-negative integers, URI-Host, URI-Path, = URI-Port, Content-Type, etc. CoAP uses 16 bit Message IDs analogous to = that of the DNS Transaction ID in addition to a 1 to 8 byte optional = Token. CoAP can also be secured using Datagram TLS (DTLS). >=20 > -Doug >=20 >=20 >=20 >=20 >=20 >=20 From cabo@tzi.org Wed Dec 14 02:45: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 63BF721F853A for ; Wed, 14 Dec 2011 02:45:15 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhlqA-koMXnQ for ; Wed, 14 Dec 2011 02:45:15 -0800 (PST) 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 A5CBC21F849B for ; Wed, 14 Dec 2011 02:45:14 -0800 (PST) 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 pBEAj7Zv027450; Wed, 14 Dec 2011 11:45:07 +0100 (CET) Received: from [192.168.217.112] (p54899AAB.dip.t-dialin.net [84.137.154.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 47EDC3AC; Wed, 14 Dec 2011 11:45:07 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180205CA@011-DB3MPN1-012.MGDPHG.emi.philips.com> Date: Wed, 14 Dec 2011 11:45:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0BB964.3020806@piuha.net> <4E9C14CD.2010700@piuha.net> <84E14610-724C-41CB-8B9D-90146637EFDF@sensinode.com> <98663C38B11E52489875919E3E9565DEC5824B8223@NLCLUEXM03.connect1.local> <031DD135F9160444ABBE3B0C36CED6180205CA@011-DB3MPN1-012.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1251.1) Cc: "'core@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: Wed, 14 Dec 2011 10:45:15 -0000 On Dec 14, 2011, at 10:36, Dijk, Esko wrote: > suggest that developers use sequential MIDs I think such a suggestion would work best if there also were a short = description of what the implementation benefits are. This description need not be in the CoAP spec -- I'd love to have a = paragraph or two about MID processing in the LWIG guidance document. Gr=FC=DFe, Carsten From esko.dijk@philips.com Wed Dec 14 04:13: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 9A8AD21F8B4A for ; Wed, 14 Dec 2011 04:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.311 X-Spam-Level: X-Spam-Status: No, score=-5.311 tagged_above=-999 required=5 tests=[AWL=1.288, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K59hHV6iskPV for ; Wed, 14 Dec 2011 04:13:06 -0800 (PST) Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB1721F8B43 for ; Wed, 14 Dec 2011 04:13:05 -0800 (PST) Received: from mail132-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Dec 2011 12:13:07 +0000 Received: from mail132-tx2 (localhost [127.0.0.1]) by mail132-tx2-R.bigfish.com (Postfix) with ESMTP id DC814600149; Wed, 14 Dec 2011 12:13:07 +0000 (UTC) X-SpamScore: -41 X-BigFish: VPS-41(zz217bL15d6O9251Jc89bh542M98dKzz1202hzz1033IL8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail132-tx2 (localhost.localdomain [127.0.0.1]) by mail132-tx2 (MessageSwitch) id 1323864787781966_17182; Wed, 14 Dec 2011 12:13:07 +0000 (UTC) Received: from TX2EHSMHS004.bigfish.com (unknown [10.9.14.253]) by mail132-tx2.bigfish.com (Postfix) with ESMTP id B8175540042; Wed, 14 Dec 2011 12:13:07 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS004.bigfish.com (10.9.99.104) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 14 Dec 2011 12:13:06 +0000 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.218]) by 011-DB3MMR1-009.MGDPHG.emi.philips.com ([10.128.28.48]) with mapi id 14.01.0355.003; Wed, 14 Dec 2011 12:13:30 +0000 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] Message ID sliding window Thread-Index: AcySPs1fMIoXMmmfQL2aZphhnV3ETAAqUrOACdaCTiAAAtPuAAADDT3w Date: Wed, 14 Dec 2011 12:13:29 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61802065A@011-DB3MPN1-012.MGDPHG.emi.philips.com> References: <4E0BB964.3020806@piuha.net> <4E9C14CD.2010700@piuha.net> <84E14610-724C-41CB-8B9D-90146637EFDF@sensinode.com> <98663C38B11E52489875919E3E9565DEC5824B8223@NLCLUEXM03.connect1.local> <031DD135F9160444ABBE3B0C36CED6180205CA@011-DB3MPN1-012.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "'core@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: Wed, 14 Dec 2011 12:13:07 -0000 Ok, I could produce some text for that in January. thanks Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Wednesday 14 December 2011 11:45 To: Dijk, Esko Cc: 'Zach Shelby'; 'core@ietf.org' Subject: Re: [core] Message ID sliding window On Dec 14, 2011, at 10:36, Dijk, Esko wrote: > suggest that developers use sequential MIDs I think such a suggestion would work best if there also were a short descri= ption of what the implementation benefits are. This description need not be in the CoAP spec -- I'd love to have a paragra= ph or two about MID processing in the LWIG guidance document. Gr=FC=DFe, 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. From esko.dijk@philips.com Wed Dec 14 04:59:04 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 E765821F8569 for ; Wed, 14 Dec 2011 04:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.954 X-Spam-Level: X-Spam-Status: No, score=-3.954 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npZ-TX8fGqTp for ; Wed, 14 Dec 2011 04:59:03 -0800 (PST) Received: from VA3EHSOBE008.bigfish.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id C57B821F8562 for ; Wed, 14 Dec 2011 04:59:02 -0800 (PST) Received: from mail117-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Dec 2011 12:59:04 +0000 Received: from mail117-va3 (localhost [127.0.0.1]) by mail117-va3-R.bigfish.com (Postfix) with ESMTP id E432D6A019A for ; Wed, 14 Dec 2011 12:59:04 +0000 (UTC) X-SpamScore: -12 X-BigFish: VPS-12(zz217bL15d6O9251Jc85fhzz1202hz31iz8275bhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail117-va3 (localhost.localdomain [127.0.0.1]) by mail117-va3 (MessageSwitch) id 1323867544463685_20406; Wed, 14 Dec 2011 12:59:04 +0000 (UTC) Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.250]) by mail117-va3.bigfish.com (Postfix) with ESMTP id 615B8600093 for ; Wed, 14 Dec 2011 12:59:04 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 14 Dec 2011 12:59:02 +0000 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.218]) by 011-DB3MMR1-008.MGDPHG.emi.philips.com ([10.128.28.47]) with mapi id 14.01.0355.003; Wed, 14 Dec 2011 12:58:58 +0000 From: "Dijk, Esko" To: "'core@ietf.org'" Thread-Topic: Multicast response suppression, random back-off (ticket #177) Thread-Index: Acy6YCPt5k4/LtC+R0WV3JdIw73Qmg== Date: Wed, 14 Dec 2011 12:59:25 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED61802069D011DB3MPN1012MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] Multicast response suppression, random back-off (ticket #177) 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, 14 Dec 2011 12:59:05 -0000 --_000_031DD135F9160444ABBE3B0C36CED61802069D011DB3MPN1012MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, If I'm correct it was mentioned in the Taipei CoRE meeting to add a mechani= sm such as a random back-off period for responses to multicast CoAP request= s, in the base CoAP spec. (An additional mechanism is not sending a respon= se at all in certain cases; see ticket #177 text). Considering the wide range of (1) multicast use cases and (2) constrained n= etwork topologies/characteristics that CoAP may be used in , it would be be= st probably to make a back-off period configurable to adapt to the needs. I= f multiple multicast applications/end-points reside on a CoAP node (say e.g= ., lighting control and parameters update) it should even be possible I thi= nk to configure different intervals per application - in the example a shor= t interval for lighting control and a longer interval for parameters update= . Anyone thoughts on what functionality we need to specify for responding to = multicast requests? regards Esko Esko Dijk Philips Corporate Technologies, Research High Tech Campus 34, Eindhoven, The Netherlands esko.dijk@philips.com ________________________________ 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_031DD135F9160444ABBE3B0C36CED61802069D011DB3MPN1012MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

If I’m correct it was mentioned in the Taipei = CoRE meeting to add a mechanism such as a random back-off period for respon= ses to multicast CoAP requests, in the base CoAP spec.  (An additional= mechanism is not sending a response at all in certain cases; see ticket #177 text).

 

Considering the wide range of (1) multicast use case= s and (2) constrained network topologies/characteristics that CoAP may be u= sed in , it would be best probably to make a back-off period configurable t= o adapt to the needs. If multiple multicast applications/end-points reside on a CoAP node (say e.g., lightin= g control and parameters update) it should even be possible I think to conf= igure different intervals per application – in the example a short in= terval for lighting control and a longer interval for parameters update.

 

Anyone thoughts on what functionality we need to spe= cify for responding to multicast requests?

 

regards

Esko

 

 

Esko Dijk

 

Philips Corporate Technologies, Research

High Tech Campus 34, Eindhoven, The Netherlands

esko.dijk@philips.com

 

 

 

 


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_031DD135F9160444ABBE3B0C36CED61802069D011DB3MPN1012MGDP_-- From prvs=0329DDDEC4=guido.moritz@uni-rostock.de Wed Dec 14 08:22: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 0F38E21F8B10 for ; Wed, 14 Dec 2011 08:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.875 X-Spam-Level: X-Spam-Status: No, score=-2.875 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRpenfW8QbAN for ; Wed, 14 Dec 2011 08:22:08 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 143F921F8B0F for ; Wed, 14 Dec 2011 08:22:04 -0800 (PST) From: Guido Moritz To: "'Dijk, Esko'" , References: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> Date: Wed, 14 Dec 2011 17:22:01 +0100 Message-ID: <003901ccba7c$82ce7020$886b5060$@uni-rostock.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01CCBA84.E49437B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHHgOp6fsBnbfnA6sRhL7ZT7FlFCpXl9eHg Content-Language: de X-Originating-IP: [139.30.201.226] Subject: Re: [core] Multicast response suppression, random back-off (ticket #177) 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, 14 Dec 2011 16:22:10 -0000 ------=_NextPart_000_003A_01CCBA84.E49437B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What is the idea how to negotiate the back-off period to be used for the response? Is it to be sent together with the request? Otherwise, to stay compliant, implementers may choose always the lowest possible period as defined in the spec, which leads to a higher independency over different applications. Guido Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von Dijk, Esko Gesendet: Mittwoch, 14. Dezember 2011 13:59 An: 'core@ietf.org' Betreff: [core] Multicast response suppression, random back-off (ticket #177) Dear all, If I'm correct it was mentioned in the Taipei CoRE meeting to add a mechanism such as a random back-off period for responses to multicast CoAP requests, in the base CoAP spec. (An additional mechanism is not sending a response at all in certain cases; see ticket #177 text). Considering the wide range of (1) multicast use cases and (2) constrained network topologies/characteristics that CoAP may be used in , it would be best probably to make a back-off period configurable to adapt to the needs. If multiple multicast applications/end-points reside on a CoAP node (say e.g., lighting control and parameters update) it should even be possible I think to configure different intervals per application - in the example a short interval for lighting control and a longer interval for parameters update. Anyone thoughts on what functionality we need to specify for responding to multicast requests? regards Esko Esko Dijk Philips Corporate Technologies, Research High Tech Campus 34, Eindhoven, The Netherlands esko.dijk@philips.com _____ The information contained in this message may be confidential and legally protected under applicable law. 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 is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. ------=_NextPart_000_003A_01CCBA84.E49437B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What is the idea how to negotiate = the back-off period to be used for the response? Is it to be sent = together with the request? Otherwise, to stay compliant, implementers = may choose always the lowest possible period as defined in the spec, = which leads to a higher independency over different = applications.

 

Guido

 

Von:<= /b> = core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von = Dijk, Esko
Gesendet: Mittwoch, 14. Dezember 2011 = 13:59
An: 'core@ietf.org'
Betreff: [core] Multicast = response suppression, random back-off (ticket = #177)

 

Dear all,

 

If I’m correct it was mentioned in the Taipei CoRE = meeting to add a mechanism such as a random back-off period for = responses to multicast CoAP requests, in the base CoAP spec.  (An = additional mechanism is not sending a response at all in certain cases; = see ticket #177 text).

 

Considering the wide range of (1) multicast use cases and = (2) constrained network topologies/characteristics that CoAP may be used = in , it would be best probably to make a back-off period configurable to = adapt to the needs. If multiple multicast applications/end-points reside = on a CoAP node (say e.g., lighting control and parameters update) it = should even be possible I think to configure different intervals per = application – in the example a short interval for lighting control = and a longer interval for parameters update.

 

Anyone thoughts on what = functionality we need to specify for responding to multicast = requests?

 

regards

Esko

 

 

Esko = Dijk

 

Philips = Corporate Technologies, Research

High Tech = Campus 34, Eindhoven, The Netherlands

esko.dijk@philips.com

 

 

 

 

 

The= information contained in this message may be confidential and legally = protected under applicable law. 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 is strictly prohibited and may be unlawful. If you are not = the intended recipient, please contact the sender by return e-mail and = destroy all copies of the original message.

------=_NextPart_000_003A_01CCBA84.E49437B0-- From hvdsomp@gmail.com Wed Dec 14 12:52:52 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 B198921F8AB0 for ; Wed, 14 Dec 2011 12:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.348 X-Spam-Level: X-Spam-Status: No, score=-5.348 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZe-BCAlDtVF for ; Wed, 14 Dec 2011 12:52:51 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7676F21F8AAF for ; Wed, 14 Dec 2011 12:52:51 -0800 (PST) Received: by dajz8 with SMTP id z8so1264247daj.31 for ; Wed, 14 Dec 2011 12:52:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SlgFa56lGBrtdJc4nSobh5DrANzoJQms0qB+Nc9Mjv4=; b=fMeYjWnJiurdbLNxJ3k7o4I4+uEXZX5ImQb/t1YI1UFO/Dmyau/fLY77joQudMGxkl /XGCY5Sl4E5eCFhCBCKYkgU+qxMGFKaT16UujZIYi44b6fgWx+u/FiV0Y+ovAdkrOKAD dG/kDSDA5qUQbQwvHRYO+O7GVHe5aFWfeUfO4= MIME-Version: 1.0 Received: by 10.68.73.65 with SMTP id j1mr5210739pbv.80.1323895971052; Wed, 14 Dec 2011 12:52:51 -0800 (PST) Received: by 10.68.4.170 with HTTP; Wed, 14 Dec 2011 12:52:51 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Dec 2011 13:52:51 -0700 Message-ID: From: Herbert van de Sompel To: Carsten Bormann Content-Type: multipart/alternative; boundary=f46d041038b712fbe604b4138d4b Cc: "core@ietf.org WG" Subject: Re: [core] application/link-format & non CoRE applications 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, 14 Dec 2011 20:52:52 -0000 --f46d041038b712fbe604b4138d4b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Carsten, Many thanks for your response. You are correct in stating that what we are looking for is the ability to use the link format in applications other than CoRE. As I indicated, I think it is a fair expectation for media types to be defined in a relatively generic, not application-specific, manner. In the Memento framework, link-formatted TimeMaps have been in use for more than a year, and I suggest that is an indication of interest in the format beyond CoRE. I do not agree with your perspective that our problem is with Context IRIs as per RFC 5988. Rather it is with CoRE's approach to determine Context IRIs for link-formatted documents: 1. In RFC 5988, the Context IRI of a link is by default that of the responding URI. Because any URI can respond with a Link header, this allows any URI to be Context IRI. 2. When defining the application/link-format media type for stand-alone documents, CoRE significantly limits the kind of URIs that can function as Context IRIs by: 2.1. Introducing the notion of base URI as Context IRI. 2.2. Deciding to marginalize anchored links. 3. In addition: 3.1. CoRE's default choice whereby the Context IRI is the base URI of Target IRI is arbitrary, i.e. not based on RFC 5988. 3.2. The fallback choice whereby the Context IRI is the base URI of the responding resource is not aligned with the logic of RFC 5988, according to which the responding URI itself would have to be the Context IRI. 4. Because, as you indicate, RFC 5988 _allows_ applications to marginalize anchored links, and because CoRE decides to effectively marginalize them, their use becomes really problematic in any application/link-format document. Based on the above, I conclude that what is needed to allow the application/link-format media type to be used in applications beyond CoRE is indeed what you describe as "a way to influence the Context IRI of all links in a link-format document, different than adding anchors to links." In addition to allowing any URI to be Context IRI, this ability would yield self-containdeness of link-formatted documents: no information external to a document would be needed in order to correctly interpret links. Note that CoRE's approach (3.2) relies on external information, i.e. the base URI of the responding URI. My proposal to use a special-purpose link and link relation type was an attempt at an approach to explicitly convey the Context IRI in link-formatted documents. I agree with your argument that this makes the interpretation of links dependent on another link; that is indeed not a great idea and is at odds with RFC 5988 semantics. However, as I indicated in my previous mail, other approaches can be imagined. Just as examples: - The Context IRI could simply be stated in the first line of a link-formatted document. - A link-formatted document could use the HTTP header format using two HTTP headers, i.e. Content-Location to express Context IRI and Link to express links. Greetings Herbert Van de Sompel On Wed, Dec 14, 2011 at 12:49 AM, Carsten Bormann wrote: > [Trimming CC list -- yours is long enough to get the message stuck in the > moderation queue.] > > Herbert, > > the CoRE WG has been working on using RFC 5988 Web Linking for its > resource discovery needs. The result is the link-format document that ju= st > passed second WGLC (the WGLC comments from this round still need to be > processed). > > What have we done here? > -- we have defined a way to ship link relations in a separate document > that has its own media type (link-format). > -- we have defined the "hosts" link relation that is intended to be used > for the "/.well-known/core" type application we are interested in. > > Due to our application in constrained node/networks, we also are > interested in minimizing the complexity that implementations need to go t= o. > So we allow some simplifications. E.g., one WGLC comment was that > expressing multiple link relations in a space-separated list is some > complexity that is rarely needed in a CoRE application, so we are looking > for ways to avoid it. We will need to meet this kind of requirements to > make link-format useful for its intended applications. > > Note that the second-class status of anchored links wasn't invented by > link-format, but is explicitly called out in 5988 as well (section 5.2, > "Consuming implementations can choose to ignore links with an anchor > parameter..."). > > What you are proposing amounts to re-using the link-format specification > for a broader application. Of course, most of us would agree that having > multiple specifications for closely related purposes is rarely the right > approach, so I'd expect many in the WG to support this. > > So what is it that you need to re-purpose the link-format spec? > > As far as I understand, the only actual change you need is less with > link-format than with the context-IRI spec in 5988, which we aren't > changing in link-format. > I'm a bit uneasy with specifying this change to the 5988 semantics (that > we inherit) in the form of just another link relation -- the link relatio= ns > in a link-format document are meant to be completely independent of each > other; splitting a link-format document in the middle and conveying it as > two documents should not change the semantics at all. > > Maybe a different way is needed to influence the context-IRI of all links > in a link-format document (i.e., beyond adding an anchor parameter per > link). I could even imagine applications of such a facility in CoRE, > although in our space we would have to carefully weigh its usefulness > against the added complexity. > > Gr=FC=DFe, Carsten > > --=20 Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ =3D=3D --f46d041038b712fbe604b4138d4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Dear Ca= rsten,


Many th= anks for your response.


You are= correct in stating that what we are looking for is the ability to use the = link format in applications other than CoRE. As I indicated, I think it is = a fair expectation for media types to be defined in a relatively generic, n= ot application-specific, manner. In the Memento framework, link-formatted T= imeMaps have been in use for more than a year, and I suggest that is an ind= ication of interest in the format beyond CoRE.


I do no= t agree with your perspective that our problem is with Context IRIs as per = RFC 5988. Rather it is with CoRE's approach to determine Context IRIs f= or link-formatted documents:


1. In R= FC 5988, the Context IRI of a link is by default that of the responding URI= . Because any URI can respond with a Link header, this allows any URI to be= Context IRI.=A0


2. When= defining the application/link-format media type for stand-alone documents,= CoRE significantly limits the kind of URIs that can function as Context IR= Is by:

2.1. In= troducing the notion of base URI as Context IRI.

2.2. De= ciding to marginalize anchored links.


3. In a= ddition:

3.1. Co= RE's default choice whereby the Context IRI is the base URI of Target I= RI is arbitrary, i.e. not based on RFC 5988.=A0

3.2. Th= e fallback choice whereby the Context IRI is the base URI of the responding= resource is not aligned with the logic of RFC 5988,=A0 according to which = the responding URI itself would have to be the Context IRI.=A0


4. Beca= use, as you indicate, RFC 5988 _allows_ applications to marginalize anchore= d links, and because CoRE decides to effectively marginalize them, their us= e becomes really problematic in any application/link-format document.=A0


Based o= n the above, I conclude that what is needed to allow the application/link-f= ormat media type to be used in applications beyond CoRE is indeed what you = describe as "a way to influence the Context IRI of all links in a link= -format document, different than adding anchors to links." In addition= to allowing any URI to be Context IRI, this ability would yield self-conta= indeness of link-formatted documents: no information external to a document= would be needed in order to correctly interpret links. Note that CoRE'= s approach (3.2) relies on external information, i.e. the base URI of the r= esponding URI.=A0


My prop= osal to use a special-purpose link and link relation type was an attempt at= an approach to explicitly convey the Context IRI in link-formatted documen= ts. I agree with your argument that this makes the interpretation of links = dependent on another link; that is indeed not a great idea and is at odds w= ith RFC 5988 semantics. However, as I indicated in my previous mail, other = approaches can be imagined. Just as examples:

- The C= ontext IRI could simply be stated in the first line of a link-formatted doc= ument.

- A lin= k-formatted document could use the HTTP header format using two HTTP header= s, i.e. Content-Location to express Context IRI and Link to express links.<= /p>


Greetin= gs


Herbert= Van de Sompel


On Wed, Dec 14, 2011 at 12= :49 AM, Carsten Bormann <cabo@tzi.org> wrote:
[Trimming CC list -- yours is long enough to= get the message stuck in the moderation queue.]

Herbert,

the CoRE WG has been working on using RFC 5988 Web Linking for its resource= discovery needs. =A0The result is the link-format document that just passe= d second WGLC (the WGLC comments from this round still need to be processed= ).

What have we done here?
-- we have defined a way to ship link relations in a separate document that= has its own media type (link-format).
-- we have defined the "hosts" link relation that is intended to = be used for the "/.well-known/core" type application we are inter= ested in.

Due to our application in constrained node/networks, we also are interested= in minimizing the complexity that implementations need to go to. =A0So we = allow some simplifications. =A0E.g., one WGLC comment was that expressing m= ultiple link relations in a space-separated list is some complexity that is= rarely needed in a CoRE application, so we are looking for ways to avoid i= t. =A0We will need to meet this kind of requirements to make link-format us= eful for its intended applications.

Note that the second-class status of anchored links wasn't invented by = link-format, but is explicitly called out in 5988 as well (section 5.2, &qu= ot;Consuming implementations can choose to ignore links with an anchor para= meter...").

What you are proposing amounts to re-using the link-format specification fo= r a broader application. =A0Of course, most of us would agree that having m= ultiple specifications for closely related purposes is rarely the right app= roach, so I'd expect many in the WG to support this.

So what is it that you need to re-purpose the link-format spec?

As far as I understand, the only actual change you need is less with link-f= ormat than with the context-IRI spec in 5988, which we aren't changing = in link-format.
I'm a bit uneasy with specifying this change to the 5988 semantics (tha= t we inherit) in the form of just another link relation -- the link relatio= ns in a link-format document are meant to be completely independent of each= other; splitting a link-format document in the middle and conveying it as = two documents should not change the semantics at all.

Maybe a different way is needed to influence the context-IRI of all links i= n a link-format document (i.e., beyond adding an anchor parameter per link)= . =A0I could even imagine applications of such a facility in CoRE, although= in our space we would have to carefully weigh its usefulness against the a= dded complexity.

Gr=FC=DFe, Carsten




--
Herbert= Van de Sompel
Digital Library Research & Prototyping
Los Alamo= s National Laboratory, Research Library
http://public.lanl.gov/herbertv/

=3D=3D

--f46d041038b712fbe604b4138d4b-- From cabo@tzi.org Wed Dec 14 14:31: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 9261511E80D8 for ; Wed, 14 Dec 2011 14:31:28 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IziEJGjC7Mbw for ; Wed, 14 Dec 2011 14:31:28 -0800 (PST) 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 A90CD11E80D4 for ; Wed, 14 Dec 2011 14:31:27 -0800 (PST) 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 pBEMVIMn023050; Wed, 14 Dec 2011 23:31:18 +0100 (CET) Received: from [192.168.217.110] (p54899AAB.dip.t-dialin.net [84.137.154.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EF4DA784; Wed, 14 Dec 2011 23:31:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Wed, 14 Dec 2011 23:31:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4FE4D8F8-046C-4960-9472-336258C4A4EF@tzi.org> References: To: Herbert van de Sompel X-Mailer: Apple Mail (2.1251.1) Cc: "core@ietf.org WG" Subject: Re: [core] application/link-format & non CoRE applications 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, 14 Dec 2011 22:31:28 -0000 Herbert, I definitely applaud you for trying not to re-invent the wheel. To stay in the figure: I'm just not so sure your truck will run well on our bicycle wheels. (And I would like them to stay bicycle wheels.) But then I don't know much about your truck. Continuing on as an interested WG member: > 1. In RFC 5988, the Context IRI of a link is by default that of the = responding URI. Indeed, we could have done the same thing, without "abbreviating away" = the "/.well-known/core" part, at the cost of requiring anchors in almost = everyone of our links (see below). > Because any URI can respond with a Link header, this allows any URI to = be Context IRI.=20 Almost equivalently, you can put a link-format resource anywhere. But I think you are objecting to that URI being subjected to some = special treatment in link-format section 2.1. > 2. When defining the application/link-format media type for = stand-alone documents, CoRE significantly limits the kind of URIs that = can function as Context IRIs by: > 2.1. Introducing the notion of base URI as Context IRI. (I now think I understand -- you are objecting to the processing rules = in link-format section 2.1 that lead to the value of the base-URI, not = to the notion itself.) > 2.2. Deciding to marginalize anchored links. That might be the bicycle part. (But then 5 of the 16 examples in the spec do use anchors!) > 3. In addition: > 3.1. CoRE's default choice whereby the Context IRI is the base URI of = Target IRI is arbitrary, i.e. not based on RFC 5988.=20 True. > 3.2. The fallback choice whereby the Context IRI is the base URI of = the responding resource is not aligned with the logic of RFC 5988, = according to which the responding URI itself would have to be the = Context IRI.=20 (Bicyles=85) True. For relative-refs, this is the natural thing for the "hosts" relation, = as the resource is hosted by the server, not by the links document. For full URIs in the target-URI, our examples strangely all have an = explicit anchor parameter. But I think the rule is motivated by a = resource directory talking about other servers. (That kind of example = should be added to the spec, I think.) [=85] So how about making the same media format useful for both our trucks and = bicycles: > - The Context IRI could simply be stated in the first line of a = link-formatted document. We deliberately don't have the concept of lines so far, and I would like = to avoid introducing them. > - A link-formatted document could use the HTTP header format using two = HTTP headers, i.e. Content-Location to express Context IRI and Link to = express links. This would need lines, and also add complexity for the simple case of a = sensor node (note also that link-format is UTF-8 and not = RFC2231-saddled). Not being able to cover your objectives with the same media-type that we = use does cause cognitive dissonance in this WG member, so I would be = interested in other approaches. (Note that a valid link-format always = starts with a "<", so I can think about some simple syntactical hacks, = e.g. just optionally prepending the context-IRI. I'm not sure that I = like what I can come up with in 10 minutes, though.) The alternative would be to have two media types, one for trucks and one = for bicycles. They still could both be round (e.g., share the same ABNF and most of = the processing rules). Gr=FC=DFe, Carsten From cabo@tzi.org Wed Dec 14 15:25: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 A58BC21F8AFD for ; Wed, 14 Dec 2011 15:25:54 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmUN7FCFSoKj for ; Wed, 14 Dec 2011 15:25:54 -0800 (PST) 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 E308321F8AF5 for ; Wed, 14 Dec 2011 15:25:53 -0800 (PST) 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 pBENPk8d011583; Thu, 15 Dec 2011 00:25:46 +0100 (CET) Received: from [192.168.217.110] (p54899AAB.dip.t-dialin.net [84.137.154.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CBC16797; Thu, 15 Dec 2011 00:25:45 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <4FE4D8F8-046C-4960-9472-336258C4A4EF@tzi.org> Date: Thu, 15 Dec 2011 00:25:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7C52D84C-21C5-4422-A0AF-B265B752F0BF@tzi.org> References: <4FE4D8F8-046C-4960-9472-336258C4A4EF@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1251.1) Subject: Re: [core] application/link-format & non CoRE applications 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, 14 Dec 2011 23:25:54 -0000 On Dec 14, 2011, at 23:31, Carsten Bormann wrote: > For relative-refs, this is the natural thing for the "hosts" relation, = as the resource is hosted by the server, not by the links document. Hmm. Food for thought: We could make the path-stripping semantics a = property of the "hosts" relation. (No, I haven't thought this through. Too late in the day for that.) Can people please throw some recent CoRE link-format documents out of = their real-life implementations at me/at the mailing list? I'd like to make sure we actually do have the right fittings soldered to = our bicycle wheels. Thanks. Gr=FC=DFe, Carsten From dotis@mail-abuse.org Wed Dec 14 16:41:22 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 48C891F0C4F; Wed, 14 Dec 2011 16:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.313 X-Spam-Level: X-Spam-Status: No, score=-102.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrS71T4mQhpg; Wed, 14 Dec 2011 16:41:21 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id A0D931F0C47; Wed, 14 Dec 2011 16:41:21 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway1.sdi.trendnet.org [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id EF26C17404B8; Thu, 15 Dec 2011 00:41:20 +0000 (UTC) Message-ID: <4EE9422E.2030301@mail-abuse.org> Date: Wed, 14 Dec 2011 16:41:18 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Carsten Bormann References: <3AB4ED7E-F81F-47A3-85E4-F7FFE1F0A60F@koanlogic.com> <4A0ED0F3-B123-4760-94EA-9280EBA51947@tzi.org> <4EE7DA2A.3000704@mail-abuse.org> <5CCD2AD0-1949-4EB0-8C69-72DB410C9BAB@tzi.org> In-Reply-To: <5CCD2AD0-1949-4EB0-8C69-72DB410C9BAB@tzi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: domainrep , "core@ietf.org WG" Subject: Re: [core] Suitability of CoAP in supporting domain reputation queries as an alternative to DNS. 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, 15 Dec 2011 00:41:22 -0000 On 12/14/11 2:43 AM, Carsten Bormann wrote: > Hi Doug, > > thanks for taking to the mailing list what so far has happened mostly in the IETF hallways. > > To really answer this question, it would be useful to examine some documentation about your objectives ("requirements"). > Until that happens, let me offer some observations. > > To a first level of approximation, CoAP provides the same service HTTP does. > If HTTP could solve your problem (performance considerations aside), and the problem is simple enough for the simple-minded protocol that CoAP is, then CoAP might be a good match. > In particular, requests are based on URIs, and payloads make use of the media type ("MIME type") architecture, so different kinds of resource representations can be transferred. Many have suggested DNS can be (ab)used to provide URI based Get/Response exchanges where CoAP provides similar overheads. In format comparison, JSON offers advantages for moderately complex exchanges. IMHO, to retain single packet exchanges, XML and HTTP represent a poor choice, and this speaks well for CoAP. > Of course, there are some differences to HTTP. > As you note, CoAP is UDP-based, so it is indeed possible to build CoAP servers that are completely stateless (not even keeping anything like TCP state). > For resource representations that are larger than the ~1KiB size that can meaningfully be transported in one packet, we have the CoAP block scheme. This still stays completely stateless on the server. Fragmentation is never needed. (CoAP-block is not the optimal solution for, say, retrieving a video, but variable-size things where a good part of the distribution is inside a KiB work very well, with zero overhead for the ≤ ~ 1 KiB case.) When large file transfers are required, rsync offers a better solution IMHO. CoAP over UDP should be easier to deploy. Ease of deployment is likely the greatest determining factor. For mid-range services, network overhead and latency is often the greater concern. When inbound servers become overwhelmed, reputation services are intended to mitigate this which represents >90% abuse. As such caching helps which is also supported by CoAP, but unfortunately aliases used in abuse to be stealthy offer poor caching characteristics. As such, round trip times related with UDP is significantly better than what is offered by TCP. A better alternative would use SCTP data framing for sustained virtual long term sessions, but I suspect there is not enough requisite background to support this approach. > On the security front, I have the following observations: > > -- we completely rely on lower- or higher-layer security if any is needed. Higher-layer security could be object security (think CMS or JOSE). For lower-layer security (i.e., communication security), our mandatory-to-implement scheme is DTLS. Without knowing your requirements on authentication, confidentiality etc., I have to stop here. > -- being based on UDP, CoAP has the same kind of amplification properties that other protocols like DNS have, so Internet-facing CoAP servers must be prepared to be implicated in DoS attacks. (This is mitigated a bit by the ease of building a CoAP server such that it never responds with more packets than it gets.) > > CoAP supports the same style of caching architecture that HTTP does -- again, knowing more about your objectives would help us find out whether this is a good match. Some customers will want the DTLS feature. In most cases, the Token exchange would be fairly ideal for our purposes. As such, CoAP looks rather attractive. > We have defined CoAP to support REST on simple-minded nodes and networks. The resulting simplicity is likely to bring some advantages outside our space. We haven't really explored that, though (and as a WG, we are chartered to focus on the inside). I would also suspect that 99% of transactions will be Get where other transaction types would be limited to authenticated sessions and used for maintenance and updates. -Doug From zach@sensinode.com Thu Dec 15 10:53:22 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 DDD4621F84C5 for ; Thu, 15 Dec 2011 10:53:22 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sC8equ9tkjiK for ; Thu, 15 Dec 2011 10:53:22 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id D1A8B21F84BA for ; Thu, 15 Dec 2011 10:53:21 -0800 (PST) Received: from [192.168.1.101] (188-67-37-207.bb.dnainternet.fi [188.67.37.207]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id pBFIrGZk029443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Dec 2011 20:53:17 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <7C52D84C-21C5-4422-A0AF-B265B752F0BF@tzi.org> Date: Thu, 15 Dec 2011 20:53:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <609BD48E-4BE6-4964-BC2B-E7301E629BAD@sensinode.com> References: <4FE4D8F8-046C-4960-9472-336258C4A4EF@tzi.org> <7C52D84C-21C5-4422-A0AF-B265B752F0BF@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" Subject: Re: [core] application/link-format & non CoRE applications 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, 15 Dec 2011 18:53:23 -0000 On Dec 15, 2011, at 1:25 AM, Carsten Bormann wrote: > On Dec 14, 2011, at 23:31, Carsten Bormann wrote: >=20 >> For relative-refs, this is the natural thing for the "hosts" = relation, as the resource is hosted by the server, not by the links = document. >=20 > Hmm. Food for thought: We could make the path-stripping semantics a = property of the "hosts" relation. > (No, I haven't thought this through. Too late in the day for that.) Yes, the same thing came to mind for me when reading the TimeMap = situation. We could very well narrow the scope of the base-URI to apply = only to the "hosts" relation, that is sufficient for CoRE.=20 However, that doesn't really solve their problem. The Context was the = requested URI in RFC5988 as links are defined for use in the HTTP = header, where obviously the Context can be something meaningful (a web = page). But how RFC5988 defines the Context for the HTTP Link header, has = no relevance to the context of links in a link document. For the case = of a link document, that obviously is not very useful, unless your only = purpose is to describe relations between that link document and other = resources (usecase?). =20 So what would be the Context of other relations (other than hosts) for = links in a link document? Obviously the Anchor attribute was meant for = this purpose as defined in RFC5988, and there is nothing we do to = prevent the use of them. We just point out the fact that constrained = implementations will usually ignore them. I do agree that Anchors are = inefficient, but at the same time we don't need to use Anchors very = often in CoRE, so that is not a problem. I could understand that in a = large link document repeating an anchor in every link is not so smart.=20= As with Carsten, I am a bit hesitant to try to solve the problems of all = possible link document applications in this WG. Of course we don't want = to prevent people from re-using our work. If we can make a couple small = changes so as not to prevent other uses, without affecting efficiency = for CoRE, then I am happy to help. Regarding the idea of specifying a "sticky anchor" that applies to all = links in a document, I think that would be nice. But that mechanism = probably should be described in some other document? Zach=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 From cabo@tzi.org Thu Dec 15 12:35:48 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 3709911E8093 for ; Thu, 15 Dec 2011 12:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.787 X-Spam-Level: X-Spam-Status: No, score=-105.787 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRoKw2aOB++S for ; Thu, 15 Dec 2011 12:35:47 -0800 (PST) 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 3F0EF21F8532 for ; Thu, 15 Dec 2011 12:35:46 -0800 (PST) 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 pBFKZdsk006714 for ; Thu, 15 Dec 2011 21:35:39 +0100 (CET) Received: from [192.168.217.112] (p5B3E7FEC.dip.t-dialin.net [91.62.127.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C601ED18; Thu, 15 Dec 2011 21:35:38 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Dec 2011 21:35:36 +0100 To: "core@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [core] Link-format query URIs and ptoken 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, 15 Dec 2011 20:35:48 -0000 Esko's comments on the link-format document got Zach and me thinking = about our usage of ptoken again. In link-format-09, the syntax for the queries in the URIs says: filter-query =3D resource-param "=3D" query-pattern resource-param =3D "uri" / parmname query-pattern =3D ptoken [ "*" ] ptoken =3D Now, 5988 defines ptoken for use in an RFC822-style (RFC2616) header, = not in a URI. Looking more closely: ptoken =3D 1*ptokenchar ptokenchar =3D "!" | "#" | "$" | "%" | "&" | "'" | "(" | ")" | "*" | "+" | "-" | "." | "/" | DIGIT | ":" | "<" | "=3D" | ">" | "?" | "@" | ALPHA | "[" | "]" | "^" | "_" | "`" | "{" | "|" | "}" | "~" Oops, that actually includes "*" and "&"! There also is no mention of percent-encoding (of course not, because = RFC2616 does not percent-encode headers). So what we really want to import here is RFC3986 ABNF, not = RFC2616/RFC5988 ABNF. First attempt: query-pattern =3D search-token [ "*" ] search-token =3D *pchar But pchar (RFC3986) includes subdelims: pchar =3D unreserved / pct-encoded / sub-delims / ":" / "@" query =3D *( pchar / "/" / "?" ) pct-encoded =3D "%" HEXDIG HEXDIG unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" sub-delims =3D "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=3D" =85 which includes "*" and "&". So, to do this right, let's mix this properly: query-pattern =3D search-token [ "*" ] search-token =3D *search-char search-char =3D unreserved / pct-encoded / ":" / "@" ; from pchar / "/" / "?" ; from query / "!" / "$" / "'" / "(" / ")" / "+" / "," / ";" / "=3D" ; from sub-delims :@/?!$'()+,;=3D indeed. This makes it possible to say something like: GET /.well-known/core?rt=3Doutdoor%20temperature After the percent-decoding defined in core-coap's URI parsing (section = 6.4), the server will see: Uri-Path .well-known Uri-Path core Uri-Query rt=3Doutdoor temperature which sounds about right. The parser in the server will now just have to 1) search for the first "=3D" and use that to delimit the parameter name = from the search-token 2) check for a trailing "*" and remove that, if present, indicating a = prefix match. Would I use spaces for rt values? Probably not, but there are still = good reasons for staying general here. As the percent-decoding is already done when the server sees it, there = is no cost to this generality, either. Esko: Does this change resolve that part of your comment? Syntax is hard, let's go christmas shopping. Gr=FC=DFe, Carsten From hvdsomp@gmail.com Thu Dec 15 13:50: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 9F00E11E8096 for ; Thu, 15 Dec 2011 13:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.765 X-Spam-Level: X-Spam-Status: No, score=-4.765 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UYhJw39TTek for ; Thu, 15 Dec 2011 13:50:44 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0D76511E8089 for ; Thu, 15 Dec 2011 13:50:43 -0800 (PST) Received: by pbdd12 with SMTP id d12so1888830pbd.31 for ; Thu, 15 Dec 2011 13:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VuxFAZ7x3KzRXba2IKFYgS5dXYM2kiL9z1SIeWdXQdU=; b=DYKIDLwP0LF49isUReLKvyknXThQsADPLQHP7iFpaHz5SKijzPz+mjd20bw7jUKwQ8 4A+ueMhDpxBvUKoyHABXALyAAE1QQh40dPnNNySFlWXapZOAZef7dJfVHc84wRKT1kN9 tTM/MzDzKhDZFidPyqgeYjVAAH+AdlC7eYb3k= MIME-Version: 1.0 Received: by 10.68.197.5 with SMTP id iq5mr1894036pbc.101.1323985843528; Thu, 15 Dec 2011 13:50:43 -0800 (PST) Received: by 10.68.72.194 with HTTP; Thu, 15 Dec 2011 13:50:43 -0800 (PST) In-Reply-To: <609BD48E-4BE6-4964-BC2B-E7301E629BAD@sensinode.com> References: <4FE4D8F8-046C-4960-9472-336258C4A4EF@tzi.org> <7C52D84C-21C5-4422-A0AF-B265B752F0BF@tzi.org> <609BD48E-4BE6-4964-BC2B-E7301E629BAD@sensinode.com> Date: Thu, 15 Dec 2011 14:50:43 -0700 Message-ID: From: Herbert van de Sompel To: Zach Shelby , Carsten Bormann Content-Type: multipart/alternative; boundary=e89a8ff1c8ece4229504b4287915 Cc: "core@ietf.org WG" Subject: Re: [core] application/link-format & non CoRE applications 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, 15 Dec 2011 21:50:47 -0000 --e89a8ff1c8ece4229504b4287915 Content-Type: text/plain; charset=ISO-8859-1 Dear Carsten, Zach, Thanks for your supportive responses. I understand your use case and the constraints it implies. As such I understand that the quest is for a small change aimed at specifying a "sticky anchor" (thanks Zach!) in link-format documents. I discussed the problem with colleagues and we think there are two types of solutions: 1. Approach that allows using an off-the-shelf Link header parser This approach requires that the content of an application/link-format document fully conforms to the "link-value" production rule of the ABNF of RFC 5988. As a result, whatever is put in place to implement the "sticky anchor" will be interpreted as a link. My original proposal fits into this category, but probably was inappropriate because the add-on I proposed looked too much like a "real" link. Maybe it's better to go for something that conforms to the syntax of a link but doesn't really make sense as a link, i.e. does not introduce the risk of applications interpreting it as a "real" link. Within this category, we thought the following could work: <> ; anchor="the-actual-Context-IRI" , link, link, link, ... 2. Approach that requires some changes to an off-the-shelf Link header parser In this case, we could go beyond the syntax defined in the ABNF in order to add the "sticky anchor". Devising a solution then comes down to finding a verbose syntax that remains easy to parse. The latter includes deciding on an appropriate delimiter. Understanding Carsten doesn't want "lines", maybe using e.g. a pipe character "|" as a delimiter could be an approach: | the-actual-Context-IRI | link, link, link, ... or, if extensibility regarding metadata to these files would be required, even: | ContextIRI the-Context-IRI | Date the-date | link, link, link, ... Ideas? Greetings Herbert On Thu, Dec 15, 2011 at 11:53 AM, Zach Shelby wrote: > On Dec 15, 2011, at 1:25 AM, Carsten Bormann wrote: > > > On Dec 14, 2011, at 23:31, Carsten Bormann wrote: > > > >> For relative-refs, this is the natural thing for the "hosts" relation, > as the resource is hosted by the server, not by the links document. > > > > Hmm. Food for thought: We could make the path-stripping semantics a > property of the "hosts" relation. > > (No, I haven't thought this through. Too late in the day for that.) > > Yes, the same thing came to mind for me when reading the TimeMap > situation. We could very well narrow the scope of the base-URI to apply > only to the "hosts" relation, that is sufficient for CoRE. > > However, that doesn't really solve their problem. The Context was the > requested URI in RFC5988 as links are defined for use in the HTTP header, > where obviously the Context can be something meaningful (a web page). But > how RFC5988 defines the Context for the HTTP Link header, has no relevance > to the context of links in a link document. For the case of a link > document, that obviously is not very useful, unless your only purpose is to > describe relations between that link document and other resources > (usecase?). > > So what would be the Context of other relations (other than hosts) for > links in a link document? Obviously the Anchor attribute was meant for this > purpose as defined in RFC5988, and there is nothing we do to prevent the > use of them. We just point out the fact that constrained implementations > will usually ignore them. I do agree that Anchors are inefficient, but at > the same time we don't need to use Anchors very often in CoRE, so that is > not a problem. I could understand that in a large link document repeating > an anchor in every link is not so smart. > > As with Carsten, I am a bit hesitant to try to solve the problems of all > possible link document applications in this WG. Of course we don't want to > prevent people from re-using our work. If we can make a couple small > changes so as not to prevent other uses, without affecting efficiency for > CoRE, then I am happy to help. > > Regarding the idea of specifying a "sticky anchor" that applies to all > links in a document, I think that would be nice. But that mechanism > probably should be described in some other document? > > 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 > -- Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ == --e89a8ff1c8ece4229504b4287915 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Dear Carsten, Zac= h,


Thanks for your s= upportive responses. I understand your use case and the constraints it impl= ies. As such I understand that the quest is for a small change aimed at spe= cifying a "sticky anchor" (thanks Zach!) in link-format documents= .


I discussed the p= roblem with colleagues and we think there are two types of solutions:


1. Approach that = allows using an off-the-shelf Link header parser


This approach req= uires that the content of an application/link-format document fully conform= s to the "link-value" production rule of the ABNF of RFC 5988. As= a result, whatever is put in place to implement the "sticky anchor&qu= ot; will be interpreted as a link.=A0


My original propo= sal fits into this category, but probably was inappropriate because the add= -on I proposed looked too much like a "real" link. Maybe it's= better to go for something that conforms to the syntax of a link but doesn= 't really make sense as a link, i.e. does not introduce the risk of app= lications interpreting it as a "real" link.=A0


Within this categ= ory, we thought the following could work:


<> ; anchor= =3D"the-actual-Context-IRI" , link, link, link, ...


2. Approach that = requires some changes to an off-the-shelf Link header parser


In this case, we = could go beyond the syntax defined in the ABNF in order to add the "st= icky anchor". Devising a solution then comes down to finding a verbose= syntax that remains easy to parse. The latter includes deciding on an appr= opriate delimiter. Understanding Carsten doesn't want "lines"= , maybe using e.g. a pipe character "|" as a delimiter could be a= n approach:


| the-actual-Cont= ext-IRI | link, link, link, ...


or, if extensibil= ity regarding metadata to these files would be required, even:


| ContextIRI the-= Context-IRI | Date the-date | link, link, link, ...


Ideas?


Greetings


Herbert


On Thu, Dec 15, 2011 at 11:53 AM, Zach Shelby <zach@sensinode.com<= /a>> wrote:
On Dec 15, 2011, at 1:25 A= M, Carsten Bormann wrote:

> On Dec 14, 2011, at 23:31, Carsten Bormann wrote:
>
>> For relative-refs, this is the natural thing for the "hosts&q= uot; relation, as the resource is hosted by the server, not by the links do= cument.
>
> Hmm. =A0Food for thought: We could make the path-stripping semantics a= property of the "hosts" relation.
> (No, I haven't thought this through. Too late in the day for that.= )

Yes, the same thing came to mind for me when reading the TimeMap situ= ation. We could very well narrow the scope of the base-URI to apply only to= the "hosts" relation, that is sufficient for CoRE.

However, that doesn't really solve their problem. The Context was the r= equested URI in RFC5988 as links are defined for use in the HTTP header, wh= ere obviously the Context can be something meaningful (a web page). But how= RFC5988 defines the Context for the HTTP Link header, has no relevance to = the context of links in a link document. =A0For the case of a link document= , that obviously is not very useful, unless your only purpose is to describ= e relations between that link document and other resources (usecase?).

So what would be the Context of other relations (other than hosts) for link= s in a link document? Obviously the Anchor attribute was meant for this pur= pose as defined in RFC5988, and there is nothing we do to prevent the use o= f them. We just point out the fact that constrained implementations will us= ually ignore them. I do agree that Anchors are inefficient, but at the same= time we don't need to use Anchors very often in CoRE, so that is not a= problem. I could understand that in a large link document repeating an anc= hor in every link is not so smart.

As with Carsten, I am a bit hesitant to try to solve the problems of all po= ssible link document applications in this WG. Of course we don't want t= o prevent people from re-using our work. If we can make a couple small chan= ges so as not to prevent other uses, without affecting efficiency for CoRE,= then I am happy to help.

Regarding the idea of specifying a "sticky anchor" that applies t= o all links in a document, I think that would be nice. But that mechanism p= robably should be described in some other document?

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



--
Herbert Van de Sompel
Digital Library Research & Prototypin= g
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbert= v/

=3D=3D

--e89a8ff1c8ece4229504b4287915-- From esko.dijk@philips.com Fri Dec 16 01:19: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 A930621F8488 for ; Fri, 16 Dec 2011 01:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.619 X-Spam-Level: X-Spam-Status: No, score=-3.619 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oj67GmO0OA3h for ; Fri, 16 Dec 2011 01:19:25 -0800 (PST) Received: from VA3EHSOBE003.bigfish.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 52FFA21F8481 for ; Fri, 16 Dec 2011 01:19:14 -0800 (PST) Received: from mail67-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 16 Dec 2011 09:19:13 +0000 Received: from mail67-va3 (localhost [127.0.0.1]) by mail67-va3-R.bigfish.com (Postfix) with ESMTP id 4B1EE70013D; Fri, 16 Dec 2011 09:19:22 +0000 (UTC) X-SpamScore: -38 X-BigFish: VPS-38(zz217bL15d6O9251Jc89bh542Mzz1202hzz1033IL8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail67-va3 (localhost.localdomain [127.0.0.1]) by mail67-va3 (MessageSwitch) id 1324027161832688_4467; Fri, 16 Dec 2011 09:19:21 +0000 (UTC) Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.246]) by mail67-va3.bigfish.com (Postfix) with ESMTP id C4EB6400225; Fri, 16 Dec 2011 09:19:21 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 16 Dec 2011 09:19:07 +0000 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.218]) by 011-DB3MMR1-009.MGDPHG.emi.philips.com ([10.128.28.48]) with mapi id 14.01.0355.003; Fri, 16 Dec 2011 09:19:37 +0000 From: "Dijk, Esko" To: Carsten Bormann , "core@ietf.org WG" Thread-Topic: [core] Link-format query URIs and ptoken Thread-Index: AQHMu2kpAnFxvkfek02zOghB9e0FA5XeKiRQ Date: Fri, 16 Dec 2011 09:19:36 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618021669@011-DB3MPN1-012.MGDPHG.emi.philips.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] Link-format query URIs and ptoken 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, 16 Dec 2011 09:19:25 -0000 Yes, that resolves it, thanks. Another point for the updated definition is the use of 'parmname'. This see= ms not defined in the text, in the ABNF sense, nor explicitly imported fro= m RFC 5988 or 5987 where it is defined. As the definition of parmname there= allows # and & in the name, that seems a bit risky for URL parsing ;) GET /.well-known/core?my&attribute=3Dvalue So it seems that although a lot of freedom is given in defining attribute n= ames, we may have to limit this in the queries? Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Thursday 15 December 2011 21:36 To: core@ietf.org WG Subject: [core] Link-format query URIs and ptoken Esko's comments on the link-format document got Zach and me thinking about = our usage of ptoken again. In link-format-09, the syntax for the queries in the URIs says: filter-query =3D resource-param "=3D" query-pattern resource-param =3D "uri" / parmname query-pattern =3D ptoken [ "*" ] ptoken =3D Now, 5988 defines ptoken for use in an RFC822-style (RFC2616) header, not i= n a URI. Looking more closely: ptoken =3D 1*ptokenchar ptokenchar =3D "!" | "#" | "$" | "%" | "&" | "'" | "(" | ")" | "*" | "+" | "-" | "." | "/" | DIGIT | ":" | "<" | "=3D" | ">" | "?" | "@" | ALPHA | "[" | "]" | "^" | "_" | "`" | "{" | "|" | "}" | "~" Oops, that actually includes "*" and "&"! There also is no mention of percent-encoding (of course not, because RFC261= 6 does not percent-encode headers). So what we really want to import here is RFC3986 ABNF, not RFC2616/RFC5988 = ABNF. First attempt: query-pattern =3D search-token [ "*" ] search-token =3D *pchar But pchar (RFC3986) includes subdelims: pchar =3D unreserved / pct-encoded / sub-delims / ":" / "@" query =3D *( pchar / "/" / "?" ) pct-encoded =3D "%" HEXDIG HEXDIG unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" sub-delims =3D "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=3D" ... which includes "*" and "&". So, to do this right, let's mix this properly: query-pattern =3D search-token [ "*" ] search-token =3D *search-char search-char =3D unreserved / pct-encoded / ":" / "@" ; from pchar / "/" / "?" ; from query / "!" / "$" / "'" / "(" / ")" / "+" / "," / ";" / "=3D" ; from sub-delims :@/?!$'()+,;=3D indeed. This makes it possible to say something like: GET /.well-known/core?rt=3Doutdoor%20temperature After the percent-decoding defined in core-coap's URI parsing (section 6.4)= , the server will see: Uri-Path .well-known Uri-Path core Uri-Query rt=3Doutdoor temperature which sounds about right. The parser in the server will now just have to 1) search for the first "=3D" and use that to delimit the parameter name fr= om the search-token 2) check for a trailing "*" and remove that, if present, indicating a prefi= x match. Would I use spaces for rt values? Probably not, but there are still good r= easons for staying general here. As the percent-decoding is already done when the server sees it, there is n= o cost to this generality, either. Esko: Does this change resolve that part of your comment? Syntax is hard, let's go christmas shopping. Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ 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. From esko.dijk@philips.com Fri Dec 16 06:39:27 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 AA60221F8B7E for ; Fri, 16 Dec 2011 06:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.863 X-Spam-Level: X-Spam-Status: No, score=-3.863 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5-55ltpfKIS for ; Fri, 16 Dec 2011 06:39:27 -0800 (PST) Received: from VA3EHSOBE004.bigfish.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id B2F6521F8B3F for ; Fri, 16 Dec 2011 06:39:26 -0800 (PST) Received: from mail161-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 16 Dec 2011 14:39:25 +0000 Received: from mail161-va3 (localhost [127.0.0.1]) by mail161-va3-R.bigfish.com (Postfix) with ESMTP id E99F4620402; Fri, 16 Dec 2011 14:39:34 +0000 (UTC) X-SpamScore: -33 X-BigFish: VPS-33(zz217bL15d6O9251Jzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail161-va3 (localhost.localdomain [127.0.0.1]) by mail161-va3 (MessageSwitch) id 1324046373196948_23273; Fri, 16 Dec 2011 14:39:33 +0000 (UTC) Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.253]) by mail161-va3.bigfish.com (Postfix) with ESMTP id 2B51D4E0046; Fri, 16 Dec 2011 14:39:33 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 16 Dec 2011 14:39:22 +0000 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.218]) by 011-DB3MMR1-007.MGDPHG.emi.philips.com ([10.128.28.57]) with mapi id 14.01.0355.003; Fri, 16 Dec 2011 14:38:55 +0000 From: "Dijk, Esko" To: Guido Moritz , "core@ietf.org" Thread-Topic: [core] Multicast response suppression, random back-off (ticket #177) Thread-Index: Acy6YCPt5k4/LtC+R0WV3JdIw73QmgAHF5GAAFZvwUA= Date: Fri, 16 Dec 2011 14:39:24 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180217F3@011-DB3MPN1-012.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> <003901ccba7c$82ce7020$886b5060$@uni-rostock.de> In-Reply-To: <003901ccba7c$82ce7020$886b5060$@uni-rostock.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] Multicast response suppression, random back-off (ticket #177) 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, 16 Dec 2011 14:39:27 -0000 Hi Guido, all, at the very least the back-off period should be configurable at a server, w= hich in itself does not require negotiation features in the CoAP protocol. Preferably CoAP would also provide a way for the client to include, if requ= ired, a preference for the maximum back-off value inside a multicast reques= t CoAP message (e.g. as a CoAP Option "Backoff-Period" as below, value in m= illiseconds).=20 +-----+----------+----------------+--------+---------+-------------+ | No. | C/E | Name | Format | Length | Default | +-----+----------+----------------+--------+---------+-------------+ | 16 | Elective | Backoff-Period | uint | 0-4 B | TBD | Furthermore, different multicast use cases typically require different resp= onse suppression behaviour. Preferably a CoAP client can request i.e. indic= ate preference for suppression of specific responses. As an example below a= n 8-bit field in an Option is used to indicate such preferences for non-con= firmable multicast requests: [Default value: No additional suppression e.g. do as in current CoAP spec] Bit 0: If set, suppress 2.xx success responses Bit 1: If set, suppress 4.xx client error responses=20 Bit 2: If set, suppress 5.xx server error responses Bit 3: If set, suppress query responses with a size zero result set Bit 4: If set, suppress any responses with empty payload [Of course any combination of bits/flags is thus possible.] +-----+----------+----------------------+----------+---------+-----------= --+ | No. | C/E | Name | Format | Length | Default = | +-----+----------+----------------------+----------+---------+-----------= --+ | 18 | Elective | Response-Suppression | bitfield | 1 B | 0b00000000= | As additional configuration (rather than negotiation) mechanisms on top of = the base spec we could have a CoAP MIB that exposes all configurable parame= ters and enables local and remote configuration of these. The MIB could be= exposed also as a specific resource e.g. under .well-known/core , allocate= d for storage/retrieval of multicast related parameter values. Any feedback would be most welcome! We should discuss how to best accommoda= te scalability/multicast control functions in CoAP, given the current state= of the CoAP base spec. regards, Esko ------------ From: Guido Moritz [mailto:guido.moritz@uni-rostock.de]=20 Sent: Wednesday 14 December 2011 17:22 To: Dijk, Esko; core@ietf.org Subject: AW: [core] Multicast response suppression, random back-off (ticket= #177) What is the idea how to negotiate the back-off period to be used for the re= sponse? Is it to be sent together with the request? Otherwise, to stay comp= liant, implementers may choose always the lowest possible period as defined= in the spec, which leads to a higher independency over different applicati= ons. Guido Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von Di= jk, Esko Gesendet: Mittwoch, 14. Dezember 2011 13:59 An: 'core@ietf.org' Betreff: [core] Multicast response suppression, random back-off (ticket #17= 7) Dear all, =A0 If I'm correct it was mentioned in the Taipei CoRE meeting to add a mechani= sm such as a random back-off period for responses to multicast CoAP request= s, in the base CoAP spec. =A0(An additional mechanism is not sending a resp= onse at all in certain cases; see ticket #177 text). =A0 Considering the wide range of (1) multicast use cases and (2) constrained n= etwork topologies/characteristics that CoAP may be used in , it would be be= st probably to make a back-off period configurable to adapt to the needs. I= f multiple multicast applications/end-points reside on a CoAP node (say e.g= ., lighting control and parameters update) it should even be possible I thi= nk to configure different intervals per application - in the example a shor= t interval for lighting control and a longer interval for parameters update= . =A0 Anyone thoughts on what functionality we need to specify for responding to = multicast requests? =A0 regards Esko =A0 =A0 Esko Dijk =A0 Philips Corporate Technologies, Research High Tech Campus 34, Eindhoven, The Netherlands esko.dijk@philips.com =A0 =A0 =A0 =A0 ________________________________________ 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. From prvs=33316EABC0=guido.moritz@uni-rostock.de Fri Dec 16 06:59:38 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 6E97B21F8B24 for ; Fri, 16 Dec 2011 06:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sht2g6Mt5hd for ; Fri, 16 Dec 2011 06:59:37 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 30FCE21F8B0F for ; Fri, 16 Dec 2011 06:59:37 -0800 (PST) From: Guido Moritz To: "'Dijk, Esko'" , References: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> <003901ccba7c$82ce7020$886b5060$@uni-rostock.de> <031DD135F9160444ABBE3B0C36CED6180217F3@011-DB3MPN1-012.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180217F3@011-DB3MPN1-012.MGDPHG.emi.philips.com> Date: Fri, 16 Dec 2011 15:59:39 +0100 Message-ID: <005f01ccbc03$559bf630$00d3e290$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHHgOp6fsBnbfnA6sRhL7ZT7FlFCgFl1dFJAk9rQk6Vy1cvEA== Content-Language: de X-Originating-IP: [139.30.201.226] Subject: Re: [core] Multicast response suppression, random back-off (ticket #177) 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, 16 Dec 2011 14:59:38 -0000 Esko, I see two problems here. First, neither the client nor the server knows how long the message transport took. So what is a good value for the back-off? Second, from a client perspective, how long should I wait for an = incoming response? When is the right time to consider the request/response as finished and go with whatever follows. It's up to the server. In worst = case, as a client I would always have to wait for the maximum back-off time defined in the spec. Hence, if the back-off is variable, the client has = to indicate the maximum amount of time for receiving responses. I am not sure if a response suppression mechanism would be way to = complex from the implementation perspective. I am not sure, it's just a feeling. = If no response is received at the client side, was the response suppressed = or got the response lost on the path? So the client has no knowledge about = the result of the request. Further I guess response suppression is against a main design criteria, which is the request/response pattern based on the REST principals.=20 Best, Guido > -----Urspr=FCngliche Nachricht----- > Von: Dijk, Esko [mailto:esko.dijk@philips.com] > Gesendet: Freitag, 16. Dezember 2011 15:39 > An: Guido Moritz; core@ietf.org > Betreff: RE: [core] Multicast response suppression, random back-off (ticket > #177) >=20 > Hi Guido, all, >=20 > at the very least the back-off period should be configurable at a = server, which > in itself does not require negotiation features in the CoAP protocol. >=20 > Preferably CoAP would also provide a way for the client to include, if required, > a preference for the maximum back-off value inside a multicast request CoAP > message (e.g. as a CoAP Option "Backoff-Period" as below, value in > milliseconds). > +-----+----------+----------------+--------+---------+-------------+ > | No. | C/E | Name | Format | Length | Default | > +-----+----------+----------------+--------+---------+-------------+ > | 16 | Elective | Backoff-Period | uint | 0-4 B | TBD | >=20 > Furthermore, different multicast use cases typically require different response > suppression behaviour. Preferably a CoAP client can request i.e. = indicate > preference for suppression of specific responses. As an example below = an 8-bit > field in an Option is used to indicate such preferences for non-confirmable > multicast requests: >=20 > [Default value: No additional suppression e.g. do as in current CoAP = spec] > Bit 0: If set, suppress 2.xx success responses > Bit 1: If set, suppress 4.xx client error responses > Bit 2: If set, suppress 5.xx server error responses > Bit 3: If set, suppress query responses with a size zero result set > Bit 4: If set, suppress any responses with empty payload > [Of course any combination of bits/flags is thus possible.] >=20 > +-----+----------+----------------------+----------+---------+-----------= --+ > | No. | C/E | Name | Format | Length | = Default | > +-----+----------+----------------------+----------+---------+-----------= --+ > | 18 | Elective | Response-Suppression | bitfield | 1 B | 0b00000000 | >=20 > As additional configuration (rather than negotiation) mechanisms on = top of the > base spec we could have a CoAP MIB that exposes all configurable parameters > and enables local and remote configuration of these. The MIB could be > exposed also as a specific resource e.g. under .well-known/core , allocated for > storage/retrieval of multicast related parameter values. >=20 > Any feedback would be most welcome! We should discuss how to best > accommodate scalability/multicast control functions in CoAP, given the current > state of the CoAP base spec. >=20 > regards, > Esko >=20 > ------------ > From: Guido Moritz [mailto:guido.moritz@uni-rostock.de] > Sent: Wednesday 14 December 2011 17:22 > To: Dijk, Esko; core@ietf.org > Subject: AW: [core] Multicast response suppression, random back-off (ticket > #177) >=20 > What is the idea how to negotiate the back-off period to be used for = the > response? Is it to be sent together with the request? Otherwise, to = stay > compliant, implementers may choose always the lowest possible period = as > defined in the spec, which leads to a higher independency over = different > applications. >=20 > Guido >=20 > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von > Dijk, Esko > Gesendet: Mittwoch, 14. Dezember 2011 13:59 > An: 'core@ietf.org' > Betreff: [core] Multicast response suppression, random back-off = (ticket #177) >=20 > Dear all, >=20 > If I'm correct it was mentioned in the Taipei CoRE meeting to add a mechanism > such as a random back-off period for responses to multicast CoAP = requests, in > the base CoAP spec. =A0(An additional mechanism is not sending a = response at all > in certain cases; see ticket #177 text). >=20 > Considering the wide range of (1) multicast use cases and (2) = constrained > network topologies/characteristics that CoAP may be used in , it would = be best > probably to make a back-off period configurable to adapt to the needs. = If > multiple multicast applications/end-points reside on a CoAP node (say e.g., > lighting control and parameters update) it should even be possible I = think to > configure different intervals per application - in the example a short interval > for lighting control and a longer interval for parameters update. >=20 > Anyone thoughts on what functionality we need to specify for = responding to > multicast requests? >=20 > regards > Esko >=20 >=20 > Esko Dijk >=20 > Philips Corporate Technologies, Research > High Tech Campus 34, Eindhoven, The Netherlands > esko.dijk@philips.com >=20 >=20 >=20 >=20 >=20 > ________________________________________ > The information contained in this message may be confidential and = legally > protected under applicable law. 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 is strictly > prohibited and may be unlawful. If you are not the intended recipient, please > contact the sender by return e-mail and destroy all copies of the = original > message. From cabo@tzi.org Fri Dec 16 09:33: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 80BE521F87A4 for ; Fri, 16 Dec 2011 09:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.339 X-Spam-Level: X-Spam-Status: No, score=-105.339 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FukwPfCytlys for ; Fri, 16 Dec 2011 09:33:46 -0800 (PST) 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 51D3621F8753 for ; Fri, 16 Dec 2011 09:33:45 -0800 (PST) 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 pBGHXa0n014355; Fri, 16 Dec 2011 18:33:36 +0100 (CET) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AAEAE15A; Fri, 16 Dec 2011 18:33:36 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <005f01ccbc03$559bf630$00d3e290$@uni-rostock.de> Date: Fri, 16 Dec 2011 18:33:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> <003901ccba7c$82ce7020$886b5060$@uni-rostock.de> <031DD135F9160444ABBE3B0C36CED6180217F3@011-DB3MPN1-012.MGDPHG.emi.philips.com> <005f01ccbc03$559bf630$00d3e290$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1251.1) Cc: core@ietf.org Subject: Re: [core] Multicast response suppression, random back-off (ticket #177) 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, 16 Dec 2011 17:33:47 -0000 On Dec 16, 2011, at 15:59, Guido Moritz wrote: > Second, from a client perspective, how long should I wait for an = incoming > response?=20 Exactly. We had a couple of situations already where conveying that = information from the client to the server is useful in a unicast = situation as well. So we would have an elective "Reponse-most-useful-within" option = (measured in, say, seconds), and (for the unicast case) a "sorry I'm not = that quick" response code in case the server understands that option and = can say that it won't make that deadline. For the multicast case, the same option would provide the upper bound = for the response delay randomly chosen by each server within the range = [0, RMUW[ (the randomness need not and should not be restricted to = entire seconds). The duration expressed in the option would be approximate; the client = would have to factor in network latencies. For more sampling-oriented applications of multicast, it would also be = useful to provide a Bolot-Turletti-Wakeman (Sigcomm '94) key/keysize to = control the probability of responding/the subset responding. I'm not = sure we need to go that far. Gr=FC=DFe, Carsten From hannes.tschofenig@nsn.com Sun Dec 18 02:47:21 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 E43B521F8432 for ; Sun, 18 Dec 2011 02:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.819 X-Spam-Level: X-Spam-Status: No, score=-105.819 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JE-4hlbKtAno for ; Sun, 18 Dec 2011 02:47:21 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2D14121F842F for ; Sun, 18 Dec 2011 02:47:21 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBIAlKX4004396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 18 Dec 2011 11:47:20 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBIAlJkB029326 for ; Sun, 18 Dec 2011 11:47:20 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Dec 2011 11:45:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {C92536A1-4D08-4685-A219-1F61D281C20A} x-cr-hashedpuzzle: BJue CKR2 EIRW EVpN GR7z II3z If9A I2og JLOO JTqs Jvqp Karu Kozc K9Ch LtxA L+KZ; 1; YwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {C92536A1-4D08-4685-A219-1F61D281C20A}; aABhAG4AbgBlAHMALgB0AHMAYwBoAG8AZgBlAG4AaQBnAEAAbgBzAG4ALgBjAG8AbQA=; Sun, 18 Dec 2011 10:47:20 GMT; UwBlAGMAdQByAGkAdAB5ACAAKABhAGcAYQBpAG4AKQA= Content-class: urn:content-classes:message Date: Sun, 18 Dec 2011 12:47:20 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE38076@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Security (again) Thread-Index: Acy9cmqzDnfltlZ+QZCGqphB/3V1cg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 18 Dec 2011 10:45:30.0349 (UTC) FILETIME=[294941D0:01CCBD72] X-Mailman-Approved-At: Sun, 18 Dec 2011 03:57:48 -0800 Subject: [core] Security (again) 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: Sun, 18 Dec 2011 10:47:22 -0000 Hi all, since you may not be subscribed to the TLS working group mailing list I thought I should share some information about ongoing activities with relevance to you.=20 During the Taipei IETF TLS meeting to remove the functionality of conveying a public key fingerprint from draft-wouters-tls-oob-pubkey. I did that already during that meeting with the submission of http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-02. I had posted a mail about this the currently ongoing consensus call (see http://www.ietf.org/mail-archive/web/tls/current/msg08290.html).=20 The removed functionality is not gone but rather part of a different document, namely http://tools.ietf.org/html/draft-ietf-tls-cached-info-10 >From the abstract of the draft: " This extension allows the TLS client to inform a server of cached information from previous TLS handshakes, allowing the server to omit sending cached static information to the client during the TLS handshake protocol exchange. " This functionality is useful for the constrained environments you guys are working on. Receiving feedback from this community would be great. If you get confused by all this TLS stuff drop me a mail.=20 Ciao Hannes From hannes.tschofenig@nsn.com Sun Dec 18 04:14:24 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 A24FA21F84DF for ; Sun, 18 Dec 2011 04:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.948 X-Spam-Level: X-Spam-Status: No, score=-105.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rAIaExjf2Ge for ; Sun, 18 Dec 2011 04:14:24 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8107421F84DB for ; Sun, 18 Dec 2011 04:14:23 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBICEJYZ016264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 18 Dec 2011 13:14:19 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBICEHZ2029417 for ; Sun, 18 Dec 2011 13:14:19 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Dec 2011 13:14:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBD7E.905ACFE1" x-cr-puzzleid: {41F0EE4B-9EBB-4B69-A33A-81B445D2DBEF} x-cr-hashedpuzzle: Agyg BtYW CUC0 CuGK CwiU C7Gi EAWH ED/n EU+k EsDo F2ZF H/wj IQeI JnK+ J8Qz KG5q; 1; YwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {41F0EE4B-9EBB-4B69-A33A-81B445D2DBEF}; aABhAG4AbgBlAHMALgB0AHMAYwBoAG8AZgBlAG4AaQBnAEAAbgBzAG4ALgBjAG8AbQA=; Sun, 18 Dec 2011 12:16:10 GMT; VABMAFMAIABDAGEAYwBoAGUAZAAgAEkAbgBmAG8A Content-class: urn:content-classes:message Date: Sun, 18 Dec 2011 14:16:10 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE38085@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS Cached Info Thread-Index: Acy9ftOPDh5N9RDnSx20Whcxqspp1A== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 18 Dec 2011 12:14:17.0466 (UTC) FILETIME=[907ECDA0:01CCBD7E] Subject: [core] TLS Cached Info 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: Sun, 18 Dec 2011 12:14:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBD7E.905ACFE1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, since you may not be subscribed to the TLS working group mailing list I thought I should share some information about ongoing activities with relevance to you.=20 During the Taipei IETF TLS meeting to remove the functionality of conveying a public key fingerprint from draft-wouters-tls-oob-pubkey. I did that already during that meeting with the submission of http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-02. I had posted a mail about this the currently ongoing consensus call (see http://www.ietf.org/mail-archive/web/tls/current/msg08290.html).=20 The removed functionality is not gone but rather part of a different document, namely http://tools.ietf.org/html/draft-ietf-tls-cached-info-10 >From the abstract of the draft: " This extension allows the TLS client to inform a server of cached information from previous TLS handshakes, allowing the server to omit sending cached static information to the client during the TLS handshake protocol exchange. " This functionality is useful for the constrained environments you guys are working on. Receiving feedback from this community would be great. If you get confused by all this TLS stuff drop me a mail.=20 Ciao Hannes ------_=_NextPart_001_01CCBD7E.905ACFE1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TLS Cached Info

Hi all,

since you may = not be subscribed to the TLS working group mailing list I thought I should share some information about = ongoing activities with relevance to you.

During the = Taipei IETF TLS meeting to remove the functionality of conveying a = public key fingerprint from draft-wouters-tls-oob-pubkey. I did that = already during that meeting with the = submission of http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey= -02. I had = posted a mail about this the currently ongoing consensus call = (see <= SPAN LANG=3D"fi">http://www.ietf.org/mail-archive/web/tls/current/msg082= 90.html). =

The removed = functionality is not gone but rather part = of a different document, namely = http://tools.ietf.org/html/draft-ietf-tls-cached-info-1= 0

From the = abstract of the draft:

"

   = This extension allows the TLS client to inform a

   = server of cached information from previous TLS handshakes, = allowing

   = the server to omit sending cached static information to the = client

   = during the TLS handshake protocol exchange.

"

This = functionality is useful for the constrained environments you guys are working on.

Receiving = feedback from this community would be great. If you get confused by all = this TLS stuff drop me a mail.

Ciao

Hannes


------_=_NextPart_001_01CCBD7E.905ACFE1-- From salvatore.loreto@ericsson.com Sun Dec 18 04:18: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 AD3CE21F84B9 for ; Sun, 18 Dec 2011 04:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG2M+bVCbuGu for ; Sun, 18 Dec 2011 04:18:26 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D521A21F84BB for ; Sun, 18 Dec 2011 04:18:25 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-b1-4eedda10ce97 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5A.86.23425.01ADDEE4; Sun, 18 Dec 2011 13:18:24 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Sun, 18 Dec 2011 13:18:23 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C7281230C for ; Sun, 18 Dec 2011 14:18:23 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6927551CE8 for ; Sun, 18 Dec 2011 14:18:23 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1FBF651B05 for ; Sun, 18 Dec 2011 14:18:23 +0200 (EET) Message-ID: <4EEDDA0E.2030507@ericsson.com> Date: Sun, 18 Dec 2011 14:18:22 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: core@ietf.org References: <3AB4ED7E-F81F-47A3-85E4-F7FFE1F0A60F@koanlogic.com> <4A0ED0F3-B123-4760-94EA-9280EBA51947@tzi.org> In-Reply-To: <4A0ED0F3-B123-4760-94EA-9280EBA51947@tzi.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] Accept option in 4.15 responses 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: Sun, 18 Dec 2011 12:18:26 -0000 I fully agree with Carsten, if the idea flies in HTTP we should consider the same for CoAP Salvatore On 12/13/11 7:29 PM, Carsten Bormann wrote: > On Dec 13, 2011, at 15:26, Thomas Fossati wrote: > >> what's your opinion about having the Accept option added to responses with 4.15 code ? > I think we should see how the discussion on the related HTTP feature converges. > > But yes, similar considerations do apply. > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From likepeng@huawei.com Sun Dec 18 17:36:11 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 0FB3721F8B1B for ; Sun, 18 Dec 2011 17:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlhkxivdki+J for ; Sun, 18 Dec 2011 17:36:09 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4209521F8B13 for ; Sun, 18 Dec 2011 17:36:09 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWF00HXJGG44F@szxga05-in.huawei.com> for core@ietf.org; Mon, 19 Dec 2011 09:36:04 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWF0043TGG4P9@szxga05-in.huawei.com> for core@ietf.org; Mon, 19 Dec 2011 09:36:04 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFT80366; Mon, 19 Dec 2011 09:35:53 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Dec 2011 09:35:51 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0323.003; Mon, 19 Dec 2011 09:35:51 +0800 Date: Mon, 19 Dec 2011 01:35:51 +0000 From: Likepeng In-reply-to: <031DD135F9160444ABBE3B0C36CED6180217F3@011-DB3MPN1-012.MGDPHG.emi.philips.com> X-Originating-IP: [10.70.109.81] To: "Dijk, Esko" , "core@ietf.org" Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2D32E1F@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: zh-CN, en-US Thread-topic: [core] Multicast response suppression, random back-off (ticket #177) Thread-index: AQHMvACLn3adYSdFokGGftuRMKFhD5XiZHIA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> <003901ccba7c$82ce7020$886b5060$@uni-rostock.de> <031DD135F9160444ABBE3B0C36CED6180217F3@011-DB3MPN1-012.MGDPHG.emi.philips.com> Subject: Re: [core] Multicast response suppression, random back-off (ticket #177) 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, 19 Dec 2011 01:36:11 -0000 Hi Esko, Your proposed "Backoff-Period" Option seems to be similar with what I propo= sed in the request-timeout draft: http://tools.ietf.org/id/draft-li-core-coap-request-timeout-option-00.txt Maybe we can work together to add your use case to the draft? Thanks, Kind Regards Kepeng -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Dij= k, Esko Sent: Friday, December 16, 2011 10:39 PM To: Guido Moritz; core@ietf.org Subject: Re: [core] Multicast response suppression, random back-off (ticket= #177) Hi Guido, all, at the very least the back-off period should be configurable at a server, w= hich in itself does not require negotiation features in the CoAP protocol. Preferably CoAP would also provide a way for the client to include, if requ= ired, a preference for the maximum back-off value inside a multicast reques= t CoAP message (e.g. as a CoAP Option "Backoff-Period" as below, value in m= illiseconds).=20 +-----+----------+----------------+--------+---------+-------------+ | No. | C/E | Name | Format | Length | Default | +-----+----------+----------------+--------+---------+-------------+ | 16 | Elective | Backoff-Period | uint | 0-4 B | TBD | Furthermore, different multicast use cases typically require different resp= onse suppression behaviour. Preferably a CoAP client can request i.e. indic= ate preference for suppression of specific responses. As an example below a= n 8-bit field in an Option is used to indicate such preferences for non-con= firmable multicast requests: [Default value: No additional suppression e.g. do as in current CoAP spec] Bit 0: If set, suppress 2.xx success responses Bit 1: If set, suppress 4.xx client error responses=20 Bit 2: If set, suppress 5.xx server error responses Bit 3: If set, suppress query responses with a size zero result set Bit 4: If set, suppress any responses with empty payload [Of course any combination of bits/flags is thus possible.] +-----+----------+----------------------+----------+---------+-----------= --+ | No. | C/E | Name | Format | Length | Default = | +-----+----------+----------------------+----------+---------+-----------= --+ | 18 | Elective | Response-Suppression | bitfield | 1 B | 0b00000000= | As additional configuration (rather than negotiation) mechanisms on top of = the base spec we could have a CoAP MIB that exposes all configurable parame= ters and enables local and remote configuration of these. The MIB could be= exposed also as a specific resource e.g. under .well-known/core , allocate= d for storage/retrieval of multicast related parameter values. Any feedback would be most welcome! We should discuss how to best accommoda= te scalability/multicast control functions in CoAP, given the current state= of the CoAP base spec. regards, Esko ------------ From: Guido Moritz [mailto:guido.moritz@uni-rostock.de]=20 Sent: Wednesday 14 December 2011 17:22 To: Dijk, Esko; core@ietf.org Subject: AW: [core] Multicast response suppression, random back-off (ticket= #177) What is the idea how to negotiate the back-off period to be used for the re= sponse? Is it to be sent together with the request? Otherwise, to stay comp= liant, implementers may choose always the lowest possible period as defined= in the spec, which leads to a higher independency over different applicati= ons. Guido Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von Di= jk, Esko Gesendet: Mittwoch, 14. Dezember 2011 13:59 An: 'core@ietf.org' Betreff: [core] Multicast response suppression, random back-off (ticket #17= 7) Dear all, =A0 If I'm correct it was mentioned in the Taipei CoRE meeting to add a mechani= sm such as a random back-off period for responses to multicast CoAP request= s, in the base CoAP spec. =A0(An additional mechanism is not sending a resp= onse at all in certain cases; see ticket #177 text). =A0 Considering the wide range of (1) multicast use cases and (2) constrained n= etwork topologies/characteristics that CoAP may be used in , it would be be= st probably to make a back-off period configurable to adapt to the needs. I= f multiple multicast applications/end-points reside on a CoAP node (say e.g= ., lighting control and parameters update) it should even be possible I thi= nk to configure different intervals per application - in the example a shor= t interval for lighting control and a longer interval for parameters update= . =A0 Anyone thoughts on what functionality we need to specify for responding to = multicast requests? =A0 regards Esko =A0 =A0 Esko Dijk =A0 Philips Corporate Technologies, Research High Tech Campus 34, Eindhoven, The Netherlands esko.dijk@philips.com =A0 =A0 =A0 =A0 ________________________________________ 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. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From alper.yegin@yegin.org Mon Dec 19 02:26:02 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 A120021F8B55 for ; Mon, 19 Dec 2011 02:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsUet+q5YatD for ; Mon, 19 Dec 2011 02:26:02 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 0513621F8B46 for ; Mon, 19 Dec 2011 02:26:02 -0800 (PST) Received: from [192.168.2.6] (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Mdaw0-1RM9UX0caC-00Pn0a; Mon, 19 Dec 2011 05:26:00 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: Date: Mon, 19 Dec 2011 12:25:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <590937FD-3BAD-47CC-B250-C4A3FA5224CE@yegin.org> References: <0E08042A-74F3-452A-B255-E5B654C01283@yegin.org> <17AB9640-613B-4AAD-B6F4-882DEDCF9122@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1251.1) X-Provags-ID: V02:K0:LQX/luXq2hveEkP+ChiyDKmGVvLC+qnV5ZcFkshodEp Ie1rg5fa+r0F5Ks+y/MkJXmxu1HiIsNUeUORpfaXuxANr3Avqe B7o7Fycw72xbY2IdKfEqsF0UJ0xnp3G3d7DSKjhZxeT5QuAcvi kfCPRG8JYZO1ybzegUrnxexGjKDTilfsYdMd0057NP00IB5UcB xkZO5tL77VWYlj8FqwvWeCmJGfg7uA34Wg4/EJwtz/gWXIG8// NMn3YWqhzQoDONMKwnRlb9kV/cMYxReQ0VECnVEtkvZaBMtNPg 6XaI2mc+xsIA9fWQjSj3lX1qFfKqPe0X51cbUMHCAI8/HP1t+z I7A3URk0uZ4bJOzFjbmTLQf/nSmUUYRakNUcokyYXQBVcrjoXv zWL+0QtqcX6uw== Cc: core WG Subject: Re: [core] RawPublicKeys 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, 19 Dec 2011 10:26:02 -0000 This issue and what Rene brought up appear to be still open=85 Any thoughts, folks? On Nov 18, 2011, at 3:21 AM, Alper Yegin wrote: > Hi Carsten, >=20 > On Nov 17, 2011, at 7:15 PM, Carsten Bormann wrote: >=20 >> On Nov 17, 2011, at 23:22, Alper Yegin wrote: >>=20 >>> The above text explains how the network node = authenticates/authorizes the device. >>> But, how does the device authenticate/authorize the network node? = For that, the "identity" of the network node's public key needs to be = known to the device. But how? >>=20 >> Hi Alper, >>=20 >> what is a "network node" in the context of CoAP? >> (I read "device" to include both the client and server roles, so from = the point of CoAP, there is nothing else. But maybe I'm missing = something here.) >>=20 >=20 >=20 > In the context of a "home deployment" for example, the network node is = the home gateway that one needs to configure when bringing in a new = device to home. ACL on the home gateway needs to be updated with the = device ID for access control. But this is just one side of the story. = The other side is, how does the new device identify the network (the = home gateway)? >=20 >=20 >=20 >> Gr=FC=DFe, Carsten >>=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From esko.dijk@philips.com Mon Dec 19 05:23:35 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 C358A21F8B72 for ; Mon, 19 Dec 2011 05:23:35 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfrKB1jj5SSi for ; Mon, 19 Dec 2011 05:23:34 -0800 (PST) Received: from AM1EHSOBE005.bigfish.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 3906421F8AC3 for ; Mon, 19 Dec 2011 05:23:33 -0800 (PST) Received: from mail15-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 19 Dec 2011 13:23:26 +0000 Received: from mail15-am1 (localhost [127.0.0.1]) by mail15-am1-R.bigfish.com (Postfix) with ESMTP id A67D91001CB; Mon, 19 Dec 2011 13:23:51 +0000 (UTC) X-SpamScore: -44 X-BigFish: VPS-44(zz217bL15d6O9371I9251J1be0I542M4015Lzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-FB-SS: 13, Received: from mail15-am1 (localhost.localdomain [127.0.0.1]) by mail15-am1 (MessageSwitch) id 1324301031447730_17177; Mon, 19 Dec 2011 13:23:51 +0000 (UTC) Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.251]) by mail15-am1.bigfish.com (Postfix) with ESMTP id 68503240046; Mon, 19 Dec 2011 13:23:51 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 19 Dec 2011 13:23:25 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.22]) by 011-DB3MMR1-010.MGDPHG.emi.philips.com ([10.128.28.49]) with mapi id 14.01.0355.003; Mon, 19 Dec 2011 13:23:31 +0000 From: "Dijk, Esko" To: Likepeng , "core@ietf.org" , Carsten Bormann Thread-Topic: [core] Multicast response suppression, random back-off (ticket #177) Thread-Index: Acy6YCPt5k4/LtC+R0WV3JdIw73QmgAHF5GAAFZvwUAAhhJRgAAPrWpA Date: Mon, 19 Dec 2011 13:23:30 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61802AA5A@011-DB3MPN1-013.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> <003901ccba7c$82ce7020$886b5060$@uni-rostock.de> <031DD135F9160444ABBE3B0C36CED6180217F3@011-DB3MPN1-012.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D32E1F@szxeml525-mbs.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F2D32E1F@szxeml525-mbs.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] Multicast response suppression, random back-off (ticket #177) 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, 19 Dec 2011 13:23:35 -0000 Hello Kepeng, indeed let's try to merge the proposals for Request-Timeout and Backoff-Per= iod. Carsten also suggested that one option could be used for both purposes= . However Carsten suggested both the whole second units and fractional seco= nd unit formats. Using two different formats for the indicated time could b= e selectable by a single bit in the option's value. Or perhaps cleaner to u= se two different Option codes for that? For Request-Timeout the proposed timeout is 2^T ms with T=3D0..255, seems n= ot optimal for most use cases. For example I can select 128 ms or 256 ms, b= ut nothing in between say 200ms. On the other hand the large values are not= needed (T=3D68 gives the estimated age of the universe, already :) One proposal could be to have a large variety of range and resolution achie= vable within a one byte value, from 8 ms up to 34 minutes: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | T | TX| +-+-+-+-+-+-+-+-+ T =3D Time TX =3D Time Exponent where the timeout is calculated as=20 timeout =3D 2^(TX * 4 + 3) * T that appears a bit more complex than 2^T but in code it's quite efficient t= o implement: T <<=3D ( (TX << 2) + 3); With an option value e.g. 25 I get my timeout=3D200 ms. Other schemes are o= f course very well possible, and we could add an extra byte here as well if= we need additional variety or simplicity. regards, Esko -----Original Message----- From: Likepeng [mailto:likepeng@huawei.com]=20 Sent: Monday 19 December 2011 2:36 To: Dijk, Esko; core@ietf.org Subject: RE: [core] Multicast response suppression, random back-off (ticket= #177) Hi Esko, Your proposed "Backoff-Period" Option seems to be similar with what I propo= sed in the request-timeout draft: http://tools.ietf.org/id/draft-li-core-coap-request-timeout-option-00.txt Maybe we can work together to add your use case to the draft? Thanks, Kind Regards Kepeng -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Dij= k, Esko Sent: Friday, December 16, 2011 10:39 PM To: Guido Moritz; core@ietf.org Subject: Re: [core] Multicast response suppression, random back-off (ticket= #177) Hi Guido, all, at the very least the back-off period should be configurable at a server, w= hich in itself does not require negotiation features in the CoAP protocol. Preferably CoAP would also provide a way for the client to include, if requ= ired, a preference for the maximum back-off value inside a multicast reques= t CoAP message (e.g. as a CoAP Option "Backoff-Period" as below, value in m= illiseconds).=20 +-----+----------+----------------+--------+---------+-------------+ | No. | C/E | Name | Format | Length | Default | +-----+----------+----------------+--------+---------+-------------+ | 16 | Elective | Backoff-Period | uint | 0-4 B | TBD | Furthermore, different multicast use cases typically require different resp= onse suppression behaviour. Preferably a CoAP client can request i.e. indic= ate preference for suppression of specific responses. As an example below a= n 8-bit field in an Option is used to indicate such preferences for non-con= firmable multicast requests: [Default value: No additional suppression e.g. do as in current CoAP spec] Bit 0: If set, suppress 2.xx success responses Bit 1: If set, suppress 4.xx client error responses=20 Bit 2: If set, suppress 5.xx server error responses Bit 3: If set, suppress query responses with a size zero result set Bit 4: If set, suppress any responses with empty payload [Of course any combination of bits/flags is thus possible.] +-----+----------+----------------------+----------+---------+-----------= --+ | No. | C/E | Name | Format | Length | Default = | +-----+----------+----------------------+----------+---------+-----------= --+ | 18 | Elective | Response-Suppression | bitfield | 1 B | 0b00000000= | As additional configuration (rather than negotiation) mechanisms on top of = the base spec we could have a CoAP MIB that exposes all configurable parame= ters and enables local and remote configuration of these. The MIB could be= exposed also as a specific resource e.g. under .well-known/core , allocate= d for storage/retrieval of multicast related parameter values. Any feedback would be most welcome! We should discuss how to best accommoda= te scalability/multicast control functions in CoAP, given the current state= of the CoAP base spec. regards, Esko ------------ From: Guido Moritz [mailto:guido.moritz@uni-rostock.de]=20 Sent: Wednesday 14 December 2011 17:22 To: Dijk, Esko; core@ietf.org Subject: AW: [core] Multicast response suppression, random back-off (ticket= #177) What is the idea how to negotiate the back-off period to be used for the re= sponse? Is it to be sent together with the request? Otherwise, to stay comp= liant, implementers may choose always the lowest possible period as defined= in the spec, which leads to a higher independency over different applicati= ons. Guido Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von Di= jk, Esko Gesendet: Mittwoch, 14. Dezember 2011 13:59 An: 'core@ietf.org' Betreff: [core] Multicast response suppression, random back-off (ticket #17= 7) Dear all, =A0 If I'm correct it was mentioned in the Taipei CoRE meeting to add a mechani= sm such as a random back-off period for responses to multicast CoAP request= s, in the base CoAP spec. =A0(An additional mechanism is not sending a resp= onse at all in certain cases; see ticket #177 text). =A0 Considering the wide range of (1) multicast use cases and (2) constrained n= etwork topologies/characteristics that CoAP may be used in , it would be be= st probably to make a back-off period configurable to adapt to the needs. I= f multiple multicast applications/end-points reside on a CoAP node (say e.g= ., lighting control and parameters update) it should even be possible I thi= nk to configure different intervals per application - in the example a shor= t interval for lighting control and a longer interval for parameters update= . =A0 Anyone thoughts on what functionality we need to specify for responding to = multicast requests? =A0 regards Esko =A0 =A0 Esko Dijk =A0 Philips Corporate Technologies, Research High Tech Campus 34, Eindhoven, The Netherlands esko.dijk@philips.com =A0 =A0 =A0 =A0 ________________________________________ 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. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Mon Dec 19 05:47:11 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 60C2221F84BD for ; Mon, 19 Dec 2011 05:47:11 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czP+gp-HTzEe for ; Mon, 19 Dec 2011 05:47:11 -0800 (PST) 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 79D0021F84A5 for ; Mon, 19 Dec 2011 05:47:10 -0800 (PST) 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 pBJDkp1V013231; Mon, 19 Dec 2011 14:46:51 +0100 (CET) Received: from eduroam-0454.wlan.uni-bremen.de (eduroam-0454.wlan.uni-bremen.de [134.102.17.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 90E377D4; Mon, 19 Dec 2011 14:46:51 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED61802AA5A@011-DB3MPN1-013.MGDPHG.emi.philips.com> Date: Mon, 19 Dec 2011 14:46:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> <003901ccba7c$82ce7020$886b5060$@uni-rostock.de> <031DD135F9160444ABBE3B0C36CED6180217F3@011-DB3MPN1-012.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D32E1F@szxeml525-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61802AA5A@011-DB3MPN1-013.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1251.1) Cc: "core@ietf.org" Subject: Re: [core] Multicast response suppression, random back-off (ticket #177) 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, 19 Dec 2011 13:47:11 -0000 Before we rathole on the duration data type for this, let me point out: -- we had a long discussion of such data types previously (around max-age), see http://tools.ietf.org/html/draft-bormann-coap-misc-10#appendix-B.2 and following. Some people didn't like the floating-point type at the time because it is not "closed under subtraction" (of course it's not, as it is non-negative, but there was some concern that people wouldn't be able to handle the accumulation of rounding errors during repeated reduction of the value). -- if you need granularity below a second (why?), milliseconds is a bad base, in particular if you want to do binary floating point on top of it. Better: mibiseconds (1/1024 s). But before we nail down the data type representation, let's discuss semantics first (and then maybe requirements on the data type). Gr=FC=DFe, Carsten From rstruik.ext@gmail.com Mon Dec 19 07:52:09 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 2E90521F848C; Mon, 19 Dec 2011 07:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jxg+Bgkh4k23; Mon, 19 Dec 2011 07:52:08 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 851A421F8495; Mon, 19 Dec 2011 07:52:07 -0800 (PST) Received: by laah2 with SMTP id h2so2480225laa.31 for ; Mon, 19 Dec 2011 07:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=wlOrjcn5UmfGFtGqQ9ahgZ0AU/4YT6M0sDheTWfaQyI=; b=NO1W+L0EnWgVbKSaFSxNnG6fDmTMC0hTSQYjBW0CHxorrWDVELOA5D4a2KHSsTkJmA +4pNSIytteSgRj49uZZ63JSzhP+mJKy1+djlh75cNuj9ahrcvgX7JvFC9PyZjnM0MuNY 8KkEElKvvZ+LvX+dyEFqlgO2Y3eK/jRFK3CgI= Received: by 10.152.111.1 with SMTP id ie1mr17123004lab.7.1324309919782; Mon, 19 Dec 2011 07:51:59 -0800 (PST) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [173.34.96.176]) by mx.google.com with ESMTPS id lr3sm17189610lab.17.2011.12.19.07.51.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Dec 2011 07:51:57 -0800 (PST) Message-ID: <4EEF5D92.5020503@gmail.com> Date: Mon, 19 Dec 2011 10:51:46 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ren=E9_Hummen?= , core , hipsec@ietf.org References: <04D43087-E2BF-464F-BE5E-D57FC3FFA746@cs.rwth-aachen.de> <4EC15495.3000700@gmail.com> <4EC5B600.1040700@gmail.com> In-Reply-To: <4EC5B600.1040700@gmail.com> X-Enigmail-Version: 1.3.4 Content-Type: multipart/alternative; boundary="------------000205090008030802040707" Subject: Re: [core] [hiprg] Research topics discussion - meeting suggestion: Wednesday 7:30pm 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, 19 Dec 2011 15:52:09 -0000 This is a multi-part message in MIME format. --------------000205090008030802040707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Perhaps, worth some thoughts under the Christmas tree and then getting back on this one after New Year. On 17/11/2011 8:33 PM, Rene Struik wrote: > Hi fellow-Rene: > > If you have some papers, I would appreciate. Distributing those would > also help removing hurdles to more wide-scale use of HIP (I saw the > slides on lack of adoption of HIP). > > Best regards, Rene > > > On 14/11/2011 12:49 PM, Rene Struik wrote: >> Hi fellow-Rene: >> >> Just curious: is there any research paper outside IETF/IRTF realm >> that delves into HIP-related matter? On a tangent: same question, but >> now re cryptographically generated addresses? This may help people to >> appreciate this effort better, without having to delve into hundreds >> of pages of specification text that sometimes seems to obscure seeing >> the forest for the trees (if I translate this properly). I, for one, >> would love to see 2-3 academic papers that make this subject matter >> clearer, including security properties, ease-of-use considerations. >> >> Best regards, Rene >> >> On 14/11/2011 12:38 PM, René Hummen wrote: >>> Hello everyone, >>> >>> we already had a few discussions on this list about new topics and research directions that would foster collaboration within the context of the hiprg. Hierarchical HITs, IoT-related protocol variants, and middlebox awareness have been mentioned there among others. In my opinion, an informal meeting before the hiprg meeting on Thursdays would be a great opportunity to further discuss about these topics. Furthermore, such a meeting would enable us see who is interested in which field and which are the pros and cons of the different topics as perceived by people in a more comfortable and less hurried way than in an RG meeting. >>> >>> As most of us will probably be at the social event tomorrow evening, I suggest to meet for dinner/a drink on Wednesday evening at 7:30pm in order to get some discussion going. Due to the lack of knowledge about a better place, let's meet up at the entrance of the convention center (TICC). Please email me if you are interested. >>> >>> BR >>> René >>> >>> >>> >>> -- >>> Dipl.-Inform. Rene Hummen, Ph.D. Student >>> Chair of Communication and Distributed Systems >>> RWTH Aachen University, Germany >>> tel: +49 241 80 20772 >>> web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ >>> >>> >>> >>> _______________________________________________ >>> hiprg mailing list >>> hiprg@irtf.org >>> https://www.irtf.org/mailman/listinfo/hiprg >> >> >> -- >> email: rstruik.ext@gmail.com >> Skype: rstruik >> cell: +1 (647) 867-5658 >> USA Google voice: +1 (415) 690-7363 > > > -- > email: rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 --------------000205090008030802040707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Perhaps, worth some thoughts under the Christmas tree and then getting back on this one after New Year.

On 17/11/2011 8:33 PM, Rene Struik wrote:
Hi fellow-Rene:

If you have some papers, I would appreciate. Distributing those would also help removing hurdles to more wide-scale use of HIP (I saw the slides on lack of adoption of HIP).

Best regards, Rene


On 14/11/2011 12:49 PM, Rene Struik wrote:
Hi fellow-Rene:

Just curious: is there any research paper outside IETF/IRTF realm that delves into HIP-related matter? On a tangent: same question, but now re cryptographically generated addresses? This may help people to appreciate this effort better, without having to delve into hundreds of pages of specification text that sometimes seems to obscure seeing the forest for the trees (if I translate this properly). I, for one, would love to see 2-3 academic papers that make this subject matter clearer, including security properties, ease-of-use considerations.

Best regards, Rene

On 14/11/2011 12:38 PM, René Hummen wrote: 
Hello everyone,

we already had a few discussions on this list about new topics and research directions that would foster collaboration within the context of the hiprg. Hierarchical HITs, IoT-related protocol variants, and middlebox awareness have been mentioned there among others. In my opinion, an informal meeting before the hiprg meeting on Thursdays would be a great opportunity to further discuss about these topics. Furthermore, such a meeting would enable us see who is interested in which field and which are the pros and cons of the different topics as perceived by people in a more comfortable and less hurried way than in an RG meeting.

As most of us will probably be at the social event tomorrow evening, I suggest to meet for dinner/a drink on Wednesday evening at 7:30pm in order to get some discussion going. Due to the lack of knowledge about a better place, let's meet up at the entrance of the convention center (TICC). Please email me if you are interested.

BR
René



--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 20772
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/




_______________________________________________
hiprg mailing list
hiprg@irtf.org
https://www.irtf.org/mailman/listinfo/hiprg



-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363
--------------000205090008030802040707-- From rstruik.ext@gmail.com Mon Dec 19 09:16:04 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 8AD0511E8097 for ; Mon, 19 Dec 2011 09:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.704 X-Spam-Level: X-Spam-Status: No, score=-2.704 tagged_above=-999 required=5 tests=[AWL=0.894, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GP-rbQcAXDzp for ; Mon, 19 Dec 2011 09:16:03 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 260FA11E8093 for ; Mon, 19 Dec 2011 09:16:02 -0800 (PST) Received: by laah2 with SMTP id h2so2517046laa.31 for ; Mon, 19 Dec 2011 09:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=1EhJwGEWXFx4h2zBvOQrlauzzgC7vNB77Etb4PJZxFU=; b=XoIZm/JTxUXtsdD6vo5pCme1l/O6cE7gxilnHEiikukzDrnDbURUznGbDM2pkXVZqJ qvImKuUHE9CDkCa1niFANJ/+9RSKjEj014sLWF6rReZRnHZ7e7O/tRZPot/fvh6+rO1E fxbGCDrii5LphaYNKHBEsacQigjZJ2p2DXRZs= Received: by 10.152.130.8 with SMTP id oa8mr16261064lab.5.1324314962074; Mon, 19 Dec 2011 09:16:02 -0800 (PST) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [173.34.96.176]) by mx.google.com with ESMTPS id nu4sm10354471lab.4.2011.12.19.09.15.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Dec 2011 09:15:59 -0800 (PST) Message-ID: <4EEF7149.2020400@gmail.com> Date: Mon, 19 Dec 2011 12:15:53 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Alper Yegin References: <0E08042A-74F3-452A-B255-E5B654C01283@yegin.org> <17AB9640-613B-4AAD-B6F4-882DEDCF9122@tzi.org> <590937FD-3BAD-47CC-B250-C4A3FA5224CE@yegin.org> In-Reply-To: <590937FD-3BAD-47CC-B250-C4A3FA5224CE@yegin.org> X-Enigmail-Version: 1.3.4 Content-Type: multipart/alternative; boundary="------------030305040002090900010602" Cc: core WG Subject: Re: [core] RawPublicKeys 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, 19 Dec 2011 17:16:04 -0000 This is a multi-part message in MIME format. --------------030305040002090900010602 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Dear colleagues: For your convenience, I copied below the issue that Alper Yegin attributed to me and that I brought up originally during IETF-82 (Thu Nov 17th). Perhaps, we can reflect on this after the New Year. Meanwhile, I wish you all a Happy Christmas and an inspirational and creative 2012. Best regards, Rene On 19/12/2011 5:25 AM, Alper Yegin wrote: > This issue and what Rene brought up appear to be still open… > Any thoughts, folks? -------- Original Message -------- Subject: Re: [core] RawPublicKeys Date: Thu, 17 Nov 2011 10:50:40 -0500 From: Rene Struik To: Alper Yegin CC: core WG Dear colleagues: Alper's question definitely has merit. I have another one, though: Having public-key derived identities printed on a device presumes that a device's public key will never change over its lifecycle. Moreover, it assumes that the public key is available prior to printing the bar code. Could you please explain how this would work from a lifecycle perspective? (chip production, module manuacturing, public key "registration", "certification", "revocation", etc.) [Note - even if public keys are not certified by a CA using a certificate, one should still consider registration/certification/revocation, aspects] These devices are assumed to have no trusted platform on board. What if someone else clones a device, produces a million copies, and pollutes the market place this way (one of the scenarios described in draft-garcia-core-security-03 (Section 3.1)). It seems that one is just out of luck then. >From the text in Appendix D.1 it seems one just hashes bare public keys, without any policy oriented info or time validity period. How does this relate to security policies? What are those policies? Rene > > On Nov 18, 2011, at 3:21 AM, Alper Yegin wrote: > >> Hi Carsten, >> >> On Nov 17, 2011, at 7:15 PM, Carsten Bormann wrote: >> >>> On Nov 17, 2011, at 23:22, Alper Yegin wrote: >>> >>>> The above text explains how the network node authenticates/authorizes the device. >>>> But, how does the device authenticate/authorize the network node? For that, the "identity" of the network node's public key needs to be known to the device. But how? >>> Hi Alper, >>> >>> what is a "network node" in the context of CoAP? >>> (I read "device" to include both the client and server roles, so from the point of CoAP, there is nothing else. But maybe I'm missing something here.) >>> >> >> In the context of a "home deployment" for example, the network node is the home gateway that one needs to configure when bringing in a new device to home. ACL on the home gateway needs to be updated with the device ID for access control. But this is just one side of the story. The other side is, how does the new device identify the network (the home gateway)? >> >> >> >>> Grüße, 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 -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 --------------030305040002090900010602 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Dear colleagues:

For your convenience,  I copied below the issue that Alper Yegin attributed to me and that I brought up originally during IETF-82 (Thu Nov 17th).

Perhaps, we can reflect on this after the New Year. Meanwhile, I wish you all a Happy Christmas and an inspirational and creative 2012.

Best regards, Rene

On 19/12/2011 5:25 AM, Alper Yegin wrote:

This issue and what Rene brought up appear to be still open…
Any thoughts, folks?

-------- Original Message --------
Subject: Re: [core] RawPublicKeys
Date: Thu, 17 Nov 2011 10:50:40 -0500
From: Rene Struik <rstruik.ext@gmail.com>
To: Alper Yegin <alper.yegin@yegin.org>
CC: core WG <core@ietf.org>


Dear colleagues:

Alper's question definitely has merit. I have another one, though:

Having public-key derived identities printed on a device presumes that a device's public key will never change over its lifecycle. Moreover, it assumes that the public key is available prior to printing the bar code.

Could you please explain how this would work from a lifecycle perspective? (chip production, module manuacturing, public key "registration", "certification", "revocation", etc.)
[Note - even if public keys are not certified by a CA using a certificate, one should still consider registration/certification/revocation, aspects]

These devices are assumed to have no trusted platform on board. What if someone else clones a device, produces a million copies, and pollutes the market place this way (one of the scenarios described in draft-garcia-core-security-03 (Section 3.1)). It seems that one is just out of luck then.

From the text in Appendix D.1 it seems one just hashes bare public keys, without any policy oriented info or time validity period. How does this relate to security policies? What are those policies?

Rene


On Nov 18, 2011, at 3:21 AM, Alper Yegin wrote:


Hi Carsten,

On Nov 17, 2011, at 7:15 PM, Carsten Bormann wrote:


On Nov 17, 2011, at 23:22, Alper Yegin wrote:


The above text explains how the network node authenticates/authorizes the device.
But, how does the device authenticate/authorize the network node? For that, the "identity" of the network node's public key needs to be known to the device. But how?

Hi Alper,

what is a "network node" in the context of CoAP?
(I read "device" to include both the client and server roles, so from the point of CoAP, there is nothing else.  But maybe I'm missing something here.)



In the context of a "home deployment" for example, the network node is the home gateway that one needs to configure when bringing in a new device to home. ACL on the home gateway needs to be updated with the device ID for access control. But this is just one side of the story. The other side is, how does the new device identify the network (the home gateway)?




Grüße, 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



-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363
--------------030305040002090900010602-- From likepeng@huawei.com Mon Dec 19 16:41: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 37B9421F8479 for ; Mon, 19 Dec 2011 16:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asPYEV-mFYlk for ; Mon, 19 Dec 2011 16:41:04 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD2B21F8462 for ; Mon, 19 Dec 2011 16:41:04 -0800 (PST) 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 <0LWH0081V8KEHO@szxga03-in.huawei.com> for core@ietf.org; Tue, 20 Dec 2011 08:41:02 +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 <0LWH008NH8KDY3@szxga03-in.huawei.com> for core@ietf.org; Tue, 20 Dec 2011 08:41:01 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFU52997; Tue, 20 Dec 2011 08:41:01 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Dec 2011 08:40:59 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.55]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Tue, 20 Dec 2011 08:40:59 +0800 Date: Tue, 20 Dec 2011 00:40:58 +0000 From: Likepeng In-reply-to: <031DD135F9160444ABBE3B0C36CED61802AA5A@011-DB3MPN1-013.MGDPHG.emi.philips.com> X-Originating-IP: [10.70.109.81] To: "Dijk, Esko" , "core@ietf.org" , Carsten Bormann Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2D35269@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: zh-CN, en-US Thread-topic: [core] Multicast response suppression, random back-off (ticket #177) Thread-index: AQHMvACLn3adYSdFokGGftuRMKFhD5XiZHIAgABAPACAAUIZMA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> <003901ccba7c$82ce7020$886b5060$@uni-rostock.de> <031DD135F9160444ABBE3B0C36CED6180217F3@011-DB3MPN1-012.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D32E1F@szxeml525-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61802AA5A@011-DB3MPN1-013.MGDPHG.emi.philips.com> Subject: Re: [core] Multicast response suppression, random back-off (ticket #177) 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, 20 Dec 2011 00:41:05 -0000 Hello Carsten and Esko, Thanks for your suggestions and proposals. We are trying to implement this feature in our implementation, and we will = try different alternative ways to see which one is more efficient. And also let's wait for more requirements for that from the industry. Thanks, Kind Regards Kepeng -----Original Message----- From: Dijk, Esko [mailto:esko.dijk@philips.com]=20 Sent: Monday, December 19, 2011 9:24 PM To: Likepeng; core@ietf.org; Carsten Bormann Subject: RE: [core] Multicast response suppression, random back-off (ticket= #177) Hello Kepeng, indeed let's try to merge the proposals for Request-Timeout and Backoff-Per= iod. Carsten also suggested that one option could be used for both purposes= . However Carsten suggested both the whole second units and fractional seco= nd unit formats. Using two different formats for the indicated time could b= e selectable by a single bit in the option's value. Or perhaps cleaner to u= se two different Option codes for that? For Request-Timeout the proposed timeout is 2^T ms with T=3D0..255, seems n= ot optimal for most use cases. For example I can select 128 ms or 256 ms, b= ut nothing in between say 200ms. On the other hand the large values are not= needed (T=3D68 gives the estimated age of the universe, already :) One proposal could be to have a large variety of range and resolution achie= vable within a one byte value, from 8 ms up to 34 minutes: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | T | TX| +-+-+-+-+-+-+-+-+ T =3D Time TX =3D Time Exponent where the timeout is calculated as=20 timeout =3D 2^(TX * 4 + 3) * T that appears a bit more complex than 2^T but in code it's quite efficient t= o implement: T <<=3D ( (TX << 2) + 3); With an option value e.g. 25 I get my timeout=3D200 ms. Other schemes are o= f course very well possible, and we could add an extra byte here as well if= we need additional variety or simplicity. regards, Esko -----Original Message----- From: Likepeng [mailto:likepeng@huawei.com]=20 Sent: Monday 19 December 2011 2:36 To: Dijk, Esko; core@ietf.org Subject: RE: [core] Multicast response suppression, random back-off (ticket= #177) Hi Esko, Your proposed "Backoff-Period" Option seems to be similar with what I propo= sed in the request-timeout draft: http://tools.ietf.org/id/draft-li-core-coap-request-timeout-option-00.txt Maybe we can work together to add your use case to the draft? Thanks, Kind Regards Kepeng -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Dij= k, Esko Sent: Friday, December 16, 2011 10:39 PM To: Guido Moritz; core@ietf.org Subject: Re: [core] Multicast response suppression, random back-off (ticket= #177) Hi Guido, all, at the very least the back-off period should be configurable at a server, w= hich in itself does not require negotiation features in the CoAP protocol. Preferably CoAP would also provide a way for the client to include, if requ= ired, a preference for the maximum back-off value inside a multicast reques= t CoAP message (e.g. as a CoAP Option "Backoff-Period" as below, value in m= illiseconds).=20 +-----+----------+----------------+--------+---------+-------------+ | No. | C/E | Name | Format | Length | Default | +-----+----------+----------------+--------+---------+-------------+ | 16 | Elective | Backoff-Period | uint | 0-4 B | TBD | Furthermore, different multicast use cases typically require different resp= onse suppression behaviour. Preferably a CoAP client can request i.e. indic= ate preference for suppression of specific responses. As an example below a= n 8-bit field in an Option is used to indicate such preferences for non-con= firmable multicast requests: [Default value: No additional suppression e.g. do as in current CoAP spec] Bit 0: If set, suppress 2.xx success responses Bit 1: If set, suppress 4.xx client error responses=20 Bit 2: If set, suppress 5.xx server error responses Bit 3: If set, suppress query responses with a size zero result set Bit 4: If set, suppress any responses with empty payload [Of course any combination of bits/flags is thus possible.] +-----+----------+----------------------+----------+---------+-----------= --+ | No. | C/E | Name | Format | Length | Default = | +-----+----------+----------------------+----------+---------+-----------= --+ | 18 | Elective | Response-Suppression | bitfield | 1 B | 0b00000000= | As additional configuration (rather than negotiation) mechanisms on top of = the base spec we could have a CoAP MIB that exposes all configurable parame= ters and enables local and remote configuration of these. The MIB could be= exposed also as a specific resource e.g. under .well-known/core , allocate= d for storage/retrieval of multicast related parameter values. Any feedback would be most welcome! We should discuss how to best accommoda= te scalability/multicast control functions in CoAP, given the current state= of the CoAP base spec. regards, Esko ------------ From: Guido Moritz [mailto:guido.moritz@uni-rostock.de]=20 Sent: Wednesday 14 December 2011 17:22 To: Dijk, Esko; core@ietf.org Subject: AW: [core] Multicast response suppression, random back-off (ticket= #177) What is the idea how to negotiate the back-off period to be used for the re= sponse? Is it to be sent together with the request? Otherwise, to stay comp= liant, implementers may choose always the lowest possible period as defined= in the spec, which leads to a higher independency over different applicati= ons. Guido Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von Di= jk, Esko Gesendet: Mittwoch, 14. Dezember 2011 13:59 An: 'core@ietf.org' Betreff: [core] Multicast response suppression, random back-off (ticket #17= 7) Dear all, =A0 If I'm correct it was mentioned in the Taipei CoRE meeting to add a mechani= sm such as a random back-off period for responses to multicast CoAP request= s, in the base CoAP spec. =A0(An additional mechanism is not sending a resp= onse at all in certain cases; see ticket #177 text). =A0 Considering the wide range of (1) multicast use cases and (2) constrained n= etwork topologies/characteristics that CoAP may be used in , it would be be= st probably to make a back-off period configurable to adapt to the needs. I= f multiple multicast applications/end-points reside on a CoAP node (say e.g= ., lighting control and parameters update) it should even be possible I thi= nk to configure different intervals per application - in the example a shor= t interval for lighting control and a longer interval for parameters update= . =A0 Anyone thoughts on what functionality we need to specify for responding to = multicast requests? =A0 regards Esko =A0 =A0 Esko Dijk =A0 Philips Corporate Technologies, Research High Tech Campus 34, Eindhoven, The Netherlands esko.dijk@philips.com =A0 =A0 =A0 =A0 ________________________________________ 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. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From esko.dijk@philips.com Tue Dec 20 01:39: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 1158E21F8906 for ; Tue, 20 Dec 2011 01:39:07 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EJKttvdxFf6 for ; Tue, 20 Dec 2011 01:39:06 -0800 (PST) Received: from VA3EHSOBE005.bigfish.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5592E21F88AB for ; Tue, 20 Dec 2011 01:39:06 -0800 (PST) Received: from mail168-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 20 Dec 2011 09:38:58 +0000 Received: from mail168-va3 (localhost [127.0.0.1]) by mail168-va3-R.bigfish.com (Postfix) with ESMTP id 1353C1E025C; Tue, 20 Dec 2011 09:40:04 +0000 (UTC) X-SpamScore: -43 X-BigFish: VPS-43(zz217bL15d6O9251Jc89bh1447M542Mzz1202hzz1033IL8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail168-va3 (localhost.localdomain [127.0.0.1]) by mail168-va3 (MessageSwitch) id 1324374003868127_20905; Tue, 20 Dec 2011 09:40:03 +0000 (UTC) Received: from VA3EHSMHS032.bigfish.com (unknown [10.7.14.253]) by mail168-va3.bigfish.com (Postfix) with ESMTP id C318D140044; Tue, 20 Dec 2011 09:40:03 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS032.bigfish.com (10.7.99.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 20 Dec 2011 09:38:57 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.22]) by 011-DB3MMR1-004.MGDPHG.emi.philips.com ([10.128.28.54]) with mapi id 14.01.0355.003; Tue, 20 Dec 2011 09:38:32 +0000 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] Multicast response suppression, random back-off (ticket #177) Thread-Index: Acy6YCPt5k4/LtC+R0WV3JdIw73QmgAHF5GAAFZvwUAAhhJRgAAPrWpAAAnaFgAAJj/0cA== Date: Tue, 20 Dec 2011 09:38:31 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61802BC3C@011-DB3MPN1-013.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> <003901ccba7c$82ce7020$886b5060$@uni-rostock.de> <031DD135F9160444ABBE3B0C36CED6180217F3@011-DB3MPN1-012.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D32E1F@szxeml525-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61802AA5A@011-DB3MPN1-013.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] Multicast response suppression, random back-off (ticket #177) 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, 20 Dec 2011 09:39:07 -0000 Hello Carsten, thanks for the pointer; indeed my proposal is an (8,2) pseudo-FP type that = denotes time in units of 8 ms (or alternatively, 8/1024 s) About the semantics: There is a clearly different semantics between "respon= se is most useful before time T" and "if possible please delay your respons= e by a random time within [0,T]". The first is an application concern, whil= e the second is more to 'engineer' the network traffic patterns to an accep= table behaviour i.e. related to the CoAP messaging 'sublayer'. Under the fi= rst semantics there's no reason to delay anything while under the second se= mantics this is the key point. There was also an open question from Salvatore on the list (June 29) on Req= uest-Timeout: what if the sensor is not able to handle a POST/PUT request i= n the requested interval of time, should it discard the request entirely or= only cancel the sending of the response. regards, Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Monday 19 December 2011 14:47 To: Dijk, Esko Cc: Likepeng; core@ietf.org Subject: Re: [core] Multicast response suppression, random back-off (ticket= #177) Before we rathole on the duration data type for this, let me point out: -- we had a long discussion of such data types previously (around max-age), see http://tools.ietf.org/html/draft-bormann-coap-misc-10#appendix-B.2 and following. Some people didn't like the floating-point type at the time because it is not "closed under subtraction" (of course it's not, as it is non-negative, but there was some concern that people wouldn't be able to handle the accumulation of rounding errors during repeated reduction of the value). -- if you need granularity below a second (why?), milliseconds is a bad base, in particular if you want to do binary floating point on top of it. Better: mibiseconds (1/1024 s). But before we nail down the data type representation, let's discuss semantics first (and then maybe requirements on the data type). Gr=FC=DFe, 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. From hannes.tschofenig@nsn.com Tue Dec 20 02:33:43 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 ACCF721F8B08 for ; Tue, 20 Dec 2011 02:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.32 X-Spam-Level: X-Spam-Status: No, score=-106.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1gSI7VqVDpy for ; Tue, 20 Dec 2011 02:33:40 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 91ADC21F8A80 for ; Tue, 20 Dec 2011 02:33:39 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBKAXVkd023380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Dec 2011 11:33:31 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBKAXSBH026469; Tue, 20 Dec 2011 11:33:31 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Dec 2011 11:33:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBF02.CFB0988B" Date: Tue, 20 Dec 2011 12:33:27 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE7C0AA@FIESEXC035.nsn-intra.net> In-Reply-To: <4EEF7149.2020400@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] RawPublicKeys Thread-Index: Acy+ceaFPnDRhiHsQpyz8SS39pubIgAjrsTQ References: <0E08042A-74F3-452A-B255-E5B654C01283@yegin.org><17AB9640-613B-4AAD-B6F4-882DEDCF9122@tzi.org><590937FD-3BAD-47CC-B250-C4A3FA5224CE@yegin.org> <4EEF7149.2020400@gmail.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Rene Struik" , "Alper Yegin" X-OriginalArrivalTime: 20 Dec 2011 10:33:29.0323 (UTC) FILETIME=[D058EBB0:01CCBF02] Cc: core WG Subject: Re: [core] RawPublicKeys 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, 20 Dec 2011 10:33:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBF02.CFB0988B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rene, Hi Alper,=20 =20 Thank you for the question.=20 =20 You both are asking of how the trust infrastructure for smart objects = could work.=20 =20 There are a few independent aspects, namely:=20 =20 1. How to bind a name to a key 2. What are the policies associated with a key (such as lifetime) 3. What to use the key for 4. How to create an access control list =20 One possible design that some of you had mentioned to me is to print the = fingerprint of the public key on the device(sensor) and to then, when = you introduce the device into your network, to verify the fingerprint on = the device with the value shown on the server for inclusion in the = access control list. This works nicely in a smaller environment, such as = a home network.=20 =20 In such a scenario the fingerprint is the name of the key, it may not be = anticipated to change the key (because it is "hardwired" into the = device), the usage is limited to the functionality of the device and the = key is added to the ACL based on human involvement.=20 =20 For other scenarios this may not be good enough. If you have additional = requirements then you those will lead to more complexity, more code, and = additional performance requirements. There is no free lunch.=20 =20 When it comes to documenting some of these aspects I doubt that there is = a desire to develop a one-size-fits-all solution. Leaving everything = open may not be useful either. =20 So, what could you do?=20 =20 I believe it makes sense to=20 =B7 Develop some building blocks, as we are already doing. For = those it will be difficult to specify a mandatory-to-implement security = solution.=20 =B7 Document at least one architectural description to see how = the different building blocks actually work together and that there are = no gaps. Jari had made one attempt with = http://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-01. Maybe = there is a possibility to do better?!=20 =20 =20 Ciao Hannes =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = ext Rene Struik Sent: Monday, December 19, 2011 7:16 PM To: Alper Yegin Cc: core WG Subject: Re: [core] RawPublicKeys =20 Dear colleagues: For your convenience, I copied below the issue that Alper Yegin = attributed to me and that I brought up originally during IETF-82 (Thu = Nov 17th). Perhaps, we can reflect on this after the New Year. Meanwhile, I wish = you all a Happy Christmas and an inspirational and creative 2012. Best regards, Rene On 19/12/2011 5:25 AM, Alper Yegin wrote: =20 This issue and what Rene brought up appear to be still open... Any thoughts, folks? -------- Original Message --------=20 Subject:=20 Re: [core] RawPublicKeys Date:=20 Thu, 17 Nov 2011 10:50:40 -0500 From:=20 Rene Struik =20 To:=20 Alper Yegin =20 CC:=20 core WG =20 Dear colleagues: Alper's question definitely has merit. I have another one, though: Having public-key derived identities printed on a device presumes that a = device's public key will never change over its lifecycle. Moreover, it = assumes that the public key is available prior to printing the bar code. = Could you please explain how this would work from a lifecycle = perspective? (chip production, module manuacturing, public key = "registration", "certification", "revocation", etc.)=20 [Note - even if public keys are not certified by a CA using a = certificate, one should still consider = registration/certification/revocation, aspects] These devices are assumed to have no trusted platform on board. What if = someone else clones a device, produces a million copies, and pollutes = the market place this way (one of the scenarios described in = draft-garcia-core-security-03 (Section 3.1)). It seems that one is just = out of luck then. >From the text in Appendix D.1 it seems one just hashes bare public keys, = without any policy oriented info or time validity period. How does this = relate to security policies? What are those policies? Rene =20 =20 On Nov 18, 2011, at 3:21 AM, Alper Yegin wrote: =20 Hi Carsten, =20 On Nov 17, 2011, at 7:15 PM, Carsten Bormann wrote: =20 On Nov 17, 2011, at 23:22, Alper Yegin wrote: =20 The above text explains how the network node authenticates/authorizes = the device. But, how does the device authenticate/authorize the network node? For = that, the "identity" of the network node's public key needs to be known = to the device. But how? =20 Hi Alper, =20 what is a "network node" in the context of CoAP? (I read "device" to include both the client and server roles, so from = the point of CoAP, there is nothing else. But maybe I'm missing = something here.) =20 =20 =20 In the context of a "home deployment" for example, the network node is = the home gateway that one needs to configure when bringing in a new = device to home. ACL on the home gateway needs to be updated with the = device ID for access control. But this is just one side of the story. = The other side is, how does the new device identify the network (the = home gateway)? =20 =20 =20 Gr=FC=DFe, Carsten =20 =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --=20 email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 ------_=_NextPart_001_01CCBF02.CFB0988B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Rene, Hi Alper,

 

Thank you for the question.

 

You both are asking of how the trust infrastructure for = smart objects could work.

 

There are a few independent aspects, namely: =

 

1.      How to bind a name to a key

2.      What are the policies associated with a key (such as = lifetime)

3.      What to use the key for

4.      How to create an access control = list

 

One possible design that some of you had mentioned to me = is to print the fingerprint of the public key on the device(sensor) and to = then, when you introduce the device into your network, to verify the fingerprint on = the device with the value shown on the server for inclusion in the access = control list. This works nicely in a smaller environment, such as a home = network.

 

In such a scenario the fingerprint is the name of the = key, it may not be anticipated to change the key (because it is = “hardwired” into the device), the usage is limited to the functionality of the = device and the key is added to the ACL based on human involvement. =

 

For other scenarios this may not be good enough. If you = have additional requirements then you those will lead to more complexity, = more code, and additional performance requirements. There is no free lunch. =

 

When it comes to documenting some of these aspects I = doubt that there is a desire to develop a one-size-fits-all solution. Leaving = everything open may not be useful either.

 

So, what could you do?

 

I believe it makes sense to

=B7        Develop some building blocks, as we are already doing. = For those it will be difficult to specify a mandatory-to-implement security = solution.

=B7        Document at least one architectural description to see = how the different building blocks actually work together and that there are no = gaps. Jari had made one attempt with ht= tp://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-01. Maybe there is a possibility to do better?!

=A0

 

Ciao
Hannes

 

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of ext Rene Struik
Sent: Monday, December 19, 2011 7:16 PM
To: Alper Yegin
Cc: core WG
Subject: Re: [core] RawPublicKeys

 

Dear colleagues:

For your convenience,  I copied below the issue that Alper Yegin attributed to me and that I brought up originally during IETF-82 (Thu = Nov 17th).

Perhaps, we can reflect on this after the New Year. Meanwhile, I wish = you all a Happy Christmas and an inspirational and creative 2012.

Best regards, Rene

On 19/12/2011 5:25 AM, Alper Yegin wrote:


 
This issue and what Rene brought up =
appear to be still open…
Any thoughts, =
folks?


-------- Original Message --------

Subject:

Re: [core] RawPublicKeys

Date: =

Thu, 17 Nov 2011 10:50:40 -0500

From: =

Rene Struik <rstruik.ext@gmail.com>

To: =

Alper Yegin <alper.yegin@yegin.org>

CC: =

core WG <core@ietf.org>



Dear colleagues:

Alper's question definitely has merit. I have another one, though:

Having public-key derived identities printed on a device presumes that a device's public key will never change over its lifecycle. Moreover, it = assumes that the public key is available prior to printing the bar code.

Could you please explain how this would work from a lifecycle = perspective? (chip production, module manuacturing, public key = "registration", "certification", "revocation", etc.)
[Note - even if public keys are not certified by a CA using a = certificate, one should still consider registration/certification/revocation, = aspects]

These devices are assumed to have no trusted platform on board. What if = someone else clones a device, produces a million copies, and pollutes the market = place this way (one of the scenarios described in = draft-garcia-core-security-03 (Section 3.1)). It seems that one is just out of luck then.

>From the text in Appendix D.1 it seems one just hashes bare public keys, without any policy oriented info or time validity period. How does this = relate to security policies? What are those policies?

Rene


 
 
On Nov 18, =
2011, at 3:21 AM, Alper Yegin =
wrote:
 
Hi =
Carsten,
 
On Nov 17, =
2011, at 7:15 PM, Carsten Bormann =
wrote:
 
On Nov =
17, 2011, at 23:22, Alper Yegin =
wrote:
 
The =
above text explains how the network node authenticates/authorizes the =
device.
But, how does the device =
authenticate/authorize the network node? For that, the =
"identity" of the network node's public key needs to be known =
to the device. But how?
 
Hi =
Alper,
 
what is a =
"network node" in the context of CoAP?
(I =
read "device" to include both the client and server roles, so =
from the point of CoAP, there is nothing else.=A0 But maybe I'm missing =
something =
here.)
 
 
 
In the =
context of a "home deployment" for example, the network node =
is the home gateway that one needs to configure when bringing in a new =
device to home. ACL on the home gateway needs to be updated with the =
device ID for access control. But this is just one side of the story. =
The other side is, how does the new device identify the network (the =
home =
gateway)?
 
 
 
Gr=FC=DFe, =
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




-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) =
867-5658
USA Google voice: +1 (415) =
690-7363
------_=_NextPart_001_01CCBF02.CFB0988B-- From cabo@tzi.org Tue Dec 20 04:08:33 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 2AD0E21F8A7E for ; Tue, 20 Dec 2011 04:08:33 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArvuyqRu8GJd for ; Tue, 20 Dec 2011 04:08:32 -0800 (PST) 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 4E44221F8B2F for ; Tue, 20 Dec 2011 04:08:32 -0800 (PST) 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 pBKC84CK012731; Tue, 20 Dec 2011 13:08:04 +0100 (CET) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7DC92C73; Tue, 20 Dec 2011 13:08:04 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED61802BC3C@011-DB3MPN1-013.MGDPHG.emi.philips.com> Date: Tue, 20 Dec 2011 13:08:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> <003901ccba7c$82ce7020$886b5060$@uni-rostock.de> <031DD135F9160444ABBE3B0C36CED6180217F3@011-DB3MPN1-012.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D32E1F@szxeml525-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61802AA5A@011-DB3MPN1-013.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61802BC3C@011-DB3MPN1-013.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1251.1) Cc: "core@ietf.org" Subject: Re: [core] Multicast response suppression, random back-off (ticket #177) 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, 20 Dec 2011 12:08:33 -0000 On Dec 20, 2011, at 10:38, Dijk, Esko wrote: > About the semantics: There is a clearly different semantics between = "response is most useful before time T" and "if possible please delay = your response by a random time within [0,T]". The first is an = application concern, while the second is more to 'engineer' the network = traffic patterns to an acceptable behaviour i.e. related to the CoAP = messaging 'sublayer'. Under the first semantics there's no reason to = delay anything while under the second semantics this is the key point. While this is true, the difference is in the unicast (reply now) vs. = multicast (reply with a dithered delay) semantics, not in the semantics = of the option that is giving the desired time frame. So I would still be happy to have a single option for response time = frame for both cases. > There was also an open question from Salvatore on the list (June 29) = on Request-Timeout: what if the sensor is not able to handle a POST/PUT = request in the requested interval of time, should it discard the request = entirely or only cancel the sending of the response. If you haven't ACKed yet, you want to quench the retransmissions. The = obvious way to do this would be to send some 4.xx/5.xx response. (I'm = not entirely sure which of those is right.) If you did ACK and then find out you can't respond in time, you have = promised to respond. It sounds impolite not to heed this promise, so = you should be sending a separate 4.xx/5.xx response as soon as you know = that. (The client can't rely on this behavior because the server may = not find out in time and because the response time frame option is = likely to remain Elective.) Gr=FC=DFe, Carsten From alper.yegin@yegin.org Wed Dec 21 01:30:09 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 CB0F521F84E5 for ; Wed, 21 Dec 2011 01:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBsqOX+aFpWR for ; Wed, 21 Dec 2011 01:30:08 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4B521F84B8 for ; Wed, 21 Dec 2011 01:30:08 -0800 (PST) Received: from [192.168.2.5] (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Lreg1-1Qgcwc36rN-013rUG; Wed, 21 Dec 2011 04:30:04 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_68319921-0F67-429D-A67D-859EA03E1657" From: Alper Yegin In-Reply-To: <999913AB42CC9341B05A99BBF358718DE7C0AA@FIESEXC035.nsn-intra.net> Date: Wed, 21 Dec 2011 11:29:45 +0200 Message-Id: <06384DD1-323F-49A4-8D83-2D88F91D666A@yegin.org> References: <0E08042A-74F3-452A-B255-E5B654C01283@yegin.org><17AB9640-613B-4AAD-B6F4-882DEDCF9122@tzi.org><590937FD-3BAD-47CC-B250-C4A3FA5224CE@yegin.org> <4EEF7149.2020400@gmail.com> <999913AB42CC9341B05A99BBF358718DE7C0AA@FIESEXC035.nsn-intra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" X-Mailer: Apple Mail (2.1251.1) X-Provags-ID: V02:K0:gF7HPDVgMFrWmxc5tjXgQxgbwYdKSzTQZhORsCczgoV BlLSWUJYm99h1pVPwEMhZK7lPq0akmxHeWysWSNykS8FF4RLwj yjrjdA/DmaBtER0u6YSOSFGCQ0X2fqWPEeG2cKtcW5QWnBQkix vD3ESZDGnS30UjykKK8IF1W8eoOP4A3tSdpKltg8uNLHT61d8J GxkdNChAN3Ld0v2B63LfO6tMJCmVhkQOqhj5yDWoTt0VdJ5/6o wtv96eI5PQS1USR6/2/fN4NA9AwsrPnDy059N9rpABfCn9pwzu yw9lUWQvyIFfSCcmIxPRKUKBcpthbL9RhnxeyreipWtpjvMQ25 7exayhOCXlUOsQiIdXW9oQLqmRYyWU72qrl3RToLSW1mBkyzLa ES2xZjMh6L1KQ== Cc: core WG Subject: Re: [core] RawPublicKeys 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, 21 Dec 2011 09:30:09 -0000 --Apple-Mail=_68319921-0F67-429D-A67D-859EA03E1657 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Hannes, On Dec 20, 2011, at 12:33 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Rene, Hi Alper, > =20 > Thank you for the question. > =20 > You both are asking of how the trust infrastructure for smart objects = could work. > =20 > There are a few independent aspects, namely: > =20 > 1. How to bind a name to a key > 2. What are the policies associated with a key (such as lifetime) > 3. What to use the key for > 4. How to create an access control list > =20 > One possible design that some of you had mentioned to me is to print = the fingerprint of the public key on the device(sensor) and to then, = when you introduce the device into your network, to verify the = fingerprint on the device with the value shown on the server for = inclusion in the access control list. This works nicely in a smaller = environment, such as a home network. > =20 > In such a scenario the fingerprint is the name of the key, it may not = be anticipated to change the key (because it is =93hardwired=94 into the = device), the usage is limited to the functionality of the device and the = key is added to the ACL based on human involvement. The issue I'm raising is that, there story has two sides. We gotta be = talking about not only how the network authorizes the device, but also = how the device authorizes the network. What you describe above is the = former, latter one is missing. It's not like the device will/shall be OK to talk to anyone who wants to = talk to itself. Device needs to authenticate and authorize the other end = as well, using ACLs etc.=20 How do we introduce the ACL into such devices? There's gotta be an = interface for that. Note that this is an issue for asymmetric-crypto. With the symmetric = crypto, device can assume whoever holds the same PSK is already = authorized hence I don't also need to maintain an ACL. Symmetric crypto = has other issues though (e.g., how did you get the PSK here and there?) Alper > =20 > For other scenarios this may not be good enough. If you have = additional requirements then you those will lead to more complexity, = more code, and additional performance requirements. There is no free = lunch. > =20 > When it comes to documenting some of these aspects I doubt that there = is a desire to develop a one-size-fits-all solution. Leaving everything = open may not be useful either. > =20 > So, what could you do? > =20 > I believe it makes sense to > =B7 Develop some building blocks, as we are already doing. For = those it will be difficult to specify a mandatory-to-implement security = solution. > =B7 Document at least one architectural description to see how = the different building blocks actually work together and that there are = no gaps. Jari had made one attempt = withhttp://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-01. Maybe = there is a possibility to do better?! > =20 > =20 > Ciao > Hannes > =20 > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of ext Rene Struik > Sent: Monday, December 19, 2011 7:16 PM > To: Alper Yegin > Cc: core WG > Subject: Re: [core] RawPublicKeys > =20 > Dear colleagues: >=20 > For your convenience, I copied below the issue that Alper Yegin = attributed to me and that I brought up originally during IETF-82 (Thu = Nov 17th). >=20 > Perhaps, we can reflect on this after the New Year. Meanwhile, I wish = you all a Happy Christmas and an inspirational and creative 2012. >=20 > Best regards, Rene >=20 > On 19/12/2011 5:25 AM, Alper Yegin wrote: >=20 >=20 > =20 > This issue and what Rene brought up appear to be still open=85 > Any thoughts, folks? >=20 > -------- Original Message -------- > Subject: > Re: [core] RawPublicKeys > Date: > Thu, 17 Nov 2011 10:50:40 -0500 > From: > Rene Struik > To: > Alper Yegin > CC: > core WG >=20 >=20 > Dear colleagues: >=20 > Alper's question definitely has merit. I have another one, though: >=20 > Having public-key derived identities printed on a device presumes that = a device's public key will never change over its lifecycle. Moreover, it = assumes that the public key is available prior to printing the bar code.=20= >=20 > Could you please explain how this would work from a lifecycle = perspective? (chip production, module manuacturing, public key = "registration", "certification", "revocation", etc.)=20 > [Note - even if public keys are not certified by a CA using a = certificate, one should still consider = registration/certification/revocation, aspects] >=20 > These devices are assumed to have no trusted platform on board. What = if someone else clones a device, produces a million copies, and pollutes = the market place this way (one of the scenarios described in = draft-garcia-core-security-03 (Section 3.1)). It seems that one is just = out of luck then. >=20 > =46rom the text in Appendix D.1 it seems one just hashes bare public = keys, without any policy oriented info or time validity period. How does = this relate to security policies? What are those policies? >=20 > Rene >=20 >=20 > =20 > =20 > On Nov 18, 2011, at 3:21 AM, Alper Yegin wrote: > =20 > Hi Carsten, > =20 > On Nov 17, 2011, at 7:15 PM, Carsten Bormann wrote: > =20 > On Nov 17, 2011, at 23:22, Alper Yegin wrote: > =20 > The above text explains how the network node authenticates/authorizes = the device. > But, how does the device authenticate/authorize the network node? For = that, the "identity" of the network node's public key needs to be known = to the device. But how? > =20 > Hi Alper, > =20 > what is a "network node" in the context of CoAP? > (I read "device" to include both the client and server roles, so from = the point of CoAP, there is nothing else. But maybe I'm missing = something here.) > =20 > =20 > =20 > In the context of a "home deployment" for example, the network node is = the home gateway that one needs to configure when bringing in a new = device to home. ACL on the home gateway needs to be updated with the = device ID for access control. But this is just one side of the story. = The other side is, how does the new device identify the network (the = home gateway)? > =20 > =20 > =20 > Gr=FC=DFe, Carsten > =20 > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 >=20 > --=20 > email: rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 --Apple-Mail=_68319921-0F67-429D-A67D-859EA03E1657 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Hannes,


On Dec = 20, 2011, at 12:33 PM, Tschofenig, Hannes (NSN - FI/Espoo) = wrote:

Hi Rene, Hi = Alper,
 
Thank you = for the question.
 
You both = are asking of how the trust infrastructure for smart objects could = work.
 
There are a = few independent aspects, namely:
1. How to bind a name to a = key
2. What are the policies associated with a key (such as = lifetime)
3. What to use the key for
4.      How to create an access control = list
 
One = possible design that some of you had mentioned to me is to print the = fingerprint of the public key on the device(sensor) and to then, when = you introduce the device into your network, to verify the fingerprint on = the device with the value shown on the server for inclusion in the = access control list. This works nicely in a smaller environment, such as = a home network.
 
In such a = scenario the fingerprint is the name of the key, it may not be = anticipated to change the key (because it is =93hardwired=94 into the = device), the usage is limited to the functionality of the device and the = key is added to the ACL based on human = involvement.
 
For other = scenarios this may not be good enough. If you have additional = requirements then you those will lead to more complexity, more code, and = additional performance requirements. There is no free = lunch.
 
When it = comes to documenting some of these aspects I doubt that there is a = desire to develop a one-size-fits-all solution. Leaving everything open = may not be useful either.
 
So, what = could you do?
 
I believe = it makes sense to
=B7 Develop some building blocks, as we are already = doing. For those it will be difficult to specify a = mandatory-to-implement security solution.
        Document at least one architectural description to = see how the different building blocks actually work together and that = there are no gaps. Jari had made one attempt with 
 core-bounces@ietf.org = [mailto:core-bounces@ietf.org] On Behalf Of ext Rene = Struik
Sent: Monday, December 19, 2011 = 7:16 PM
To: Alper = Yegin
Cc: core= WG
Subject: Re: [core] = RawPublicKeys
Dear = colleagues:

For your convenience,  I copied below the issue = that Alper Yegin attributed to me and that I brought up originally = during IETF-82 (Thu Nov 17th).

Perhaps, we can reflect on this = after the New Year. Meanwhile, I wish you all a Happy Christmas and an = inspirational and creative 2012.

Best regards, Rene

On = 19/12/2011 5:25 AM, Alper Yegin wrote:


 
This issue and what =
Rene brought up appear to be still open=85
Any thoughts, folks?

-------- Original Message = --------
Subject:
Re: [core] = RawPublicKeys
Thu, 17 Nov 2011 10:50:40 = -0500
Rene Struik 
To:
Alper Yegin 
CC:


Dear colleagues:

Alper's = question definitely has merit. I have another one, though:

Having = public-key derived identities printed on a device presumes that a = device's public key will never change over its lifecycle. Moreover, it = assumes that the public key is available prior to printing the bar = code. 

Could = you please explain how this would work from a lifecycle perspective? = (chip production, module manuacturing, public key "registration", = "certification", "revocation", etc.) 
[Note - even if public = keys are not certified by a CA using a certificate, one should still = consider registration/certification/revocation, aspects]

These = devices are assumed to have no trusted platform on board. What if = someone else clones a device, produces a million copies, and pollutes = the market place this way (one of the scenarios described in = draft-garcia-core-security-03 (Section 3.1)). It seems that one is just = out of luck then.

=46rom the text in Appendix D.1 it seems one = just hashes bare public keys, without any policy oriented info or time = validity period. How does this relate to security policies? What are = those policies?

Rene


 
On Nov 18, 2011, at 3:21 AM, =
Alper Yegin wrote:
Hi Carsten,
 
On Nov 17, 2011, at =
7:15 PM, Carsten Bormann wrote:
On Nov 17, 2011, at 23:22, Alper Yegin =
wrote:
 
The above =
text explains how the network node authenticates/authorizes the =
device.
But, how does the device =
authenticate/authorize the network node? For that, the "identity" of the =
network node's public key needs to be known to the device. But =
how?
Hi =
Alper,
 
what is a "network node" in the context of =
CoAP?
(I read "device" to include both the =
client and server roles, so from the point of CoAP, there is nothing =
else.  But maybe I'm missing something here.)
 
 
In the context of a "home =
deployment" for example, the network node is the home gateway that one =
needs to configure when bringing in a new device to home. ACL on the =
home gateway needs to be updated with the device ID for access control. =
But this is just one side of the story. The other side is, how does the =
new device identify the network (the home gateway)?
 
Gr=FC=DFe, Carsten
 
 
core mailing list
core@ietf.org
 
core mailing list
core@ietf.org



-- 
email: Skype: =
rstruik
cell: +1 (647) =
867-5658
USA Google voice: +1 (415) =
690-7363

= --Apple-Mail=_68319921-0F67-429D-A67D-859EA03E1657-- From hannes.tschofenig@nsn.com Wed Dec 21 01:58: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 3091821F84DD for ; Wed, 21 Dec 2011 01:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.355 X-Spam-Level: X-Spam-Status: No, score=-106.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7tsvFmAgcXT for ; Wed, 21 Dec 2011 01:58:32 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 91F9321F848D for ; Wed, 21 Dec 2011 01:58:31 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBL9wQZh015134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Dec 2011 10:58:26 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBL9wPTK010280; Wed, 21 Dec 2011 10:58:25 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Dec 2011 10:58:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBFC7.0FD5456B" Date: Wed, 21 Dec 2011 11:58:16 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE7C529@FIESEXC035.nsn-intra.net> In-Reply-To: <06384DD1-323F-49A4-8D83-2D88F91D666A@yegin.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] RawPublicKeys Thread-Index: Acy/wy0XifFavlrvTCqZN0gMCORYyAAAinMA References: <0E08042A-74F3-452A-B255-E5B654C01283@yegin.org><17AB9640-613B-4AAD-B6F4-882DEDCF9122@tzi.org><590937FD-3BAD-47CC-B250-C4A3FA5224CE@yegin.org> <4EEF7149.2020400@gmail.com> <999913AB42CC9341B05A99BBF358718DE7C0AA@FIESEXC035.nsn-intra.net> <06384DD1-323F-49A4-8D83-2D88F91D666A@yegin.org> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Alper Yegin" X-OriginalArrivalTime: 21 Dec 2011 09:58:17.0528 (UTC) FILETIME=[10085380:01CCBFC7] Cc: core WG Subject: Re: [core] RawPublicKeys 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, 21 Dec 2011 09:58:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBFC7.0FD5456B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alper,=20 =20 Thanks for the quick feedback. See my comments below.=20 =20 ~snip~ =20 The issue I'm raising is that, there story has two sides. We gotta be = talking about not only how the network authorizes the device, but also = how the device authorizes the network. What you describe above is the = former, latter one is missing. =20 With the work on TLS raw public key and the cached information extension = I was actually more focusing on the communication between two = applications rather than security for network access authentication.=20 =20 But your issue is also valid for an application scenario and the answer = depends a bit on the device capabilities itself and the expected = behavior.=20 =20 For example, with a picture frame you have a UI and with a temperature = sensor you probably don't have one. With an Internet radio you have a = small UI and actually, for more elaborate configuration, you can also = connect to the device via a Web browser. Some devices have certain = parameters pre-configured (like my Internet radio fetches a list of = available Internet radio stations from a pre-configured URL).=20 =20 So, there is no single answer. It really varies a lot but maybe you can = cluster the different scenarios in some form to offer a meaningful = description. =20 =20 It's not like the device will/shall be OK to talk to anyone who wants to = talk to itself. Device needs to authenticate and authorize the other end = as well, using ACLs etc.=20 It depends. When I look at Jari's draft then I believe his model is more = than the device just blasts the info out into the network using a = multicast address. That may not be desirable for every scenario but = could be OK for his use case.=20 =20 =20 How do we introduce the ACL into such devices? There's gotta be an = interface for that. =20 There are quite likely these cases:=20 =20 =B7 No ACL needed (Jari's case) =B7 ACL based on pre-configuation (device talks only to some = servers in the service provider's network) =B7 Configurable ACLs using a user interface (via a display) =B7 Indirect configuration via some protocols (think of software = update mechanisms, device configuration)=20 =20 Note that this is an issue for asymmetric-crypto. With the symmetric = crypto, device can assume whoever holds the same PSK is already = authorized hence I don't also need to maintain an ACL. Symmetric crypto = has other issues though (e.g., how did you get the PSK here and there?) =20 Well. Even with asymmetric crypto (like the raw public keys) you could, = if you want to, treat them like symmetric keys.=20 =20 Ciao Hannes =20 =20 Alper =20 =20 =20 =20 =20 =20 For other scenarios this may not be good enough. If you have additional = requirements then you those will lead to more complexity, more code, and = additional performance requirements. There is no free lunch. =20 When it comes to documenting some of these aspects I doubt that there is = a desire to develop a one-size-fits-all solution. Leaving everything = open may not be useful either. =20 So, what could you do? =20 I believe it makes sense to =B7 Develop some building blocks, as we are already doing. For = those it will be difficult to specify a mandatory-to-implement security = solution. =B7 Document at least one architectural description to see how = the different building blocks actually work together and that there are = no gaps. Jari had made one attempt = withhttp://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-01. Maybe = there is a possibility to do better?! =20 =20 Ciao Hannes =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = ext Rene Struik Sent: Monday, December 19, 2011 7:16 PM To: Alper Yegin Cc: core WG Subject: Re: [core] RawPublicKeys =20 Dear colleagues: For your convenience, I copied below the issue that Alper Yegin = attributed to me and that I brought up originally during IETF-82 (Thu = Nov 17th). Perhaps, we can reflect on this after the New Year. Meanwhile, I wish = you all a Happy Christmas and an inspirational and creative 2012. Best regards, Rene On 19/12/2011 5:25 AM, Alper Yegin wrote: =20 This issue and what Rene brought up appear to be still open... Any thoughts, folks? -------- Original Message -------- Subject: Re: [core] RawPublicKeys Date: Thu, 17 Nov 2011 10:50:40 -0500 From: Rene Struik =20 To: Alper Yegin =20 CC: core WG =20 Dear colleagues: Alper's question definitely has merit. I have another one, though: Having public-key derived identities printed on a device presumes that a = device's public key will never change over its lifecycle. Moreover, it = assumes that the public key is available prior to printing the bar code. = Could you please explain how this would work from a lifecycle = perspective? (chip production, module manuacturing, public key = "registration", "certification", "revocation", etc.)=20 [Note - even if public keys are not certified by a CA using a = certificate, one should still consider = registration/certification/revocation, aspects] These devices are assumed to have no trusted platform on board. What if = someone else clones a device, produces a million copies, and pollutes = the market place this way (one of the scenarios described in = draft-garcia-core-security-03 (Section 3.1)). It seems that one is just = out of luck then. >From the text in Appendix D.1 it seems one just hashes bare public keys, = without any policy oriented info or time validity period. How does this = relate to security policies? What are those policies? Rene =20 =20 On Nov 18, 2011, at 3:21 AM, Alper Yegin wrote: =20 Hi Carsten, =20 On Nov 17, 2011, at 7:15 PM, Carsten Bormann wrote: =20 On Nov 17, 2011, at 23:22, Alper Yegin wrote: =20 The above text explains how the network node authenticates/authorizes = the device. But, how does the device authenticate/authorize the network node? For = that, the "identity" of the network node's public key needs to be known = to the device. But how? =20 Hi Alper, =20 what is a "network node" in the context of CoAP? (I read "device" to include both the client and server roles, so from = the point of CoAP, there is nothing else. But maybe I'm missing = something here.) =20 =20 =20 In the context of a "home deployment" for example, the network node is = the home gateway that one needs to configure when bringing in a new = device to home. ACL on the home gateway needs to be updated with the = device ID for access control. But this is just one side of the story. = The other side is, how does the new device identify the network (the = home gateway)? =20 =20 =20 Gr=FC=DFe, Carsten =20 =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --=20 email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 =20 ------_=_NextPart_001_01CCBFC7.0FD5456B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Alper,

 

Thanks for the quick feedback. See my comments below. =

 

~snip~

 

The issue I'm raising is that, there story has two = sides. We gotta be talking about not only how the network authorizes the device, = but also how the device authorizes the network. What you describe above is the = former, latter one is missing.

 

With the work on TLS raw public key and the cached = information extension I was actually more focusing on the communication between two = applications rather than security for network access authentication. =

 

But your issue is = also valid for an application scenario and the answer depends a bit on the device = capabilities itself and the expected behavior.

 

For example, with a picture frame you have a UI and with = a temperature sensor you probably don’t have one. With an Internet radio you = have a small UI and actually, for more elaborate configuration, you can also = connect to the device via a Web browser. Some devices have certain parameters pre-configured (like my Internet radio fetches a list of available = Internet radio stations from a pre-configured URL).

 

So, there is no single answer. It really varies a lot but = maybe you can cluster the different scenarios in some form to offer a = meaningful description. =A0

 

It's not like the device will/shall be OK to talk = to anyone who wants to talk to itself. Device needs to authenticate and authorize = the other end as well, using ACLs etc. 

It depends. When I look at Jari’s draft then I = believe his model is more than the device just blasts the info out into the network = using a multicast address. That may not be desirable for every scenario but = could be OK for his use case.

 

 

How do we introduce the ACL into such devices? = There's gotta be an interface for that.

 

There are quite likely these cases: =

 

=B7        No ACL needed (Jari’s case)

=B7        ACL based on pre-configuation (device talks only to some = servers in the service provider’s network)

=B7        Configurable ACLs using a user interface (via a = display)

=B7        Indirect configuration via some protocols (think of = software update mechanisms, device configuration)

 

Note that this is an issue for asymmetric-crypto. = With the symmetric crypto, device can assume whoever holds the same PSK is = already authorized hence I don't also need to maintain an ACL. Symmetric crypto = has other issues though (e.g., how did you get the PSK here and = there?)

 

Well. Even with asymmetric crypto (like the raw public = keys) you could, if you want to, treat them like symmetric keys. =

 

Ciao

Hannes

 

 

Alper

 

 

 

 

 



 

For other scenarios this may not be good enough. If you = have additional requirements then you those will lead to more complexity, = more code, and additional performance requirements. There is no free = lunch.

 

When it comes to documenting some of these aspects I = doubt that there is a desire to develop a one-size-fits-all solution. Leaving = everything open may not be useful either.

 

So, what could you do?

 

I believe it makes sense to

=B7        Develop some building = blocks, as we are already doing. For those it will be difficult to specify a mandatory-to-implement security solution.

 

 

Ciao
Hannes

 

From:=  core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of ext Rene = Struik
Sent: Monday, = December 19, 2011 7:16 PM
To: Alper = Yegin
Cc: core WG
Subject: Re: = [core] RawPublicKeys

 

Dear colleagues:

For your convenience,  I copied below the issue that Alper Yegin attributed to me and that I brought up originally during IETF-82 (Thu = Nov 17th).

Perhaps, we can reflect on this after the New Year. Meanwhile, I wish = you all a Happy Christmas and an inspirational and creative 2012.

Best regards, Rene

On 19/12/2011 5:25 AM, Alper Yegin wrote:



 
This issue and what Rene brought up appear to be =
still open…
Any thoughts, folks?


-------- Original Message --------

Subject:

Re: [core] = RawPublicKeys

Date:

Thu, 17 Nov 2011 = 10:50:40 -0500

From:

To:

CC:

core WG <core@ietf.org>=



Dear colleagues:

Alper's question definitely has merit. I have another one, though:

Having public-key derived identities printed on a device presumes that a device's public key will never change over its lifecycle. Moreover, it = assumes that the public key is available prior to printing the bar code. 

Could you please explain how this would work from a lifecycle = perspective? (chip production, module manuacturing, public key = "registration", "certification", "revocation", etc.) 
[Note - even if public keys are not certified by a CA using a = certificate, one should still consider registration/certification/revocation, = aspects]

These devices are assumed to have no trusted platform on board. What if = someone else clones a device, produces a million copies, and pollutes the market = place this way (one of the scenarios described in = draft-garcia-core-security-03 (Section 3.1)). It seems that one is just out of luck then.

>From the text in Appendix D.1 it seems one just hashes bare public keys, without any policy oriented info or time validity period. How does this = relate to security policies? What are those policies?

Rene



 
 
On Nov 18, 2011, at 3:21 AM, Alper Yegin =
wrote:
 
Hi Carsten,
 
On Nov 17, 2011, at 7:15 PM, Carsten Bormann =
wrote:
 
On Nov 17, 2011, at 23:22, Alper Yegin =
wrote:
 
The above text explains how the network node =
authenticates/authorizes the device.
But, how does the device authenticate/authorize =
the network node? For that, the "identity" of the network =
node's public key needs to be known to the device. But =
how?
 
Hi Alper,
 
what is a "network node" in the context =
of CoAP?
(I read "device" to include both the =
client and server roles, so from the point of CoAP, there is nothing =
else.  But maybe I'm missing something =
here.)
 
 
 
In the context of a "home deployment" =
for example, the network node is the home gateway that one needs to =
configure when bringing in a new device to home. ACL on the home gateway =
needs to be updated with the device ID for access control. But this is =
just one side of the story. The other side is, how does the new device =
identify the network (the home =
gateway)?
 
 
 
Gr=FC=DFe, =
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 





-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) =
867-5658
USA Google voice: +1 (415) =
690-7363

 

------_=_NextPart_001_01CCBFC7.0FD5456B-- From dgiannakop@ceid.upatras.gr Wed Dec 21 02:58:21 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 514A721F856F for ; Wed, 21 Dec 2011 02:58:21 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQmtkYv4F2pj for ; Wed, 21 Dec 2011 02:58:20 -0800 (PST) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by ietfa.amsl.com (Postfix) with ESMTP id AB35F21F8540 for ; Wed, 21 Dec 2011 02:58:20 -0800 (PST) Received: from mail.ceid.upatras.gr (mail.ceid.upatras.gr [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 4F7DDEB4E8B for ; Wed, 21 Dec 2011 12:58:15 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id EC0CC2A0755 for ; Wed, 21 Dec 2011 12:58:14 +0200 (EET) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BylnQwU17wVk for ; Wed, 21 Dec 2011 12:58:14 +0200 (EET) Received: from webmail.ceid.upatras.gr (europa.ceid.upatras.gr [150.140.141.143]) by mail.ceid.upatras.gr (Postfix) with ESMTPSA id BCC222A00ED for ; Wed, 21 Dec 2011 12:58:14 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 21 Dec 2011 12:58:14 +0200 From: Giannakopoulos Dimitrios To: Message-ID: <0e64a71bf8405be044c59b9241d55a57@ceid.upatras.gr> X-Sender: dgiannakop@ceid.upatras.gr User-Agent: Roundcube Webmail/0.5.3 Subject: [core] About Max-OFE option 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, 21 Dec 2011 10:58:21 -0000 Hi, There is a small issue with Max-OFE option in Observe. It is assigned to option number 14, while in CoAP option number 14 is used for "fenceposting". We should state in CoAP, that option 14 could be used for a non-empty option, and only if it's empty use it as fence post. As long as Max-OFE is registered at option number 14, I think this should be clarified in CoAP draft. Jim -- Giannakopoulos Dimitrios Undergraduate Student Computer Engineering and Informatics Department, University of Patras Email: dgiannakop@ceid.upatras.gr From salvatore.loreto@ericsson.com Wed Dec 21 09:29: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 AC0CC21F8A4E for ; Wed, 21 Dec 2011 09:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTqhjia1qIoq for ; Wed, 21 Dec 2011 09:29:19 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id EFCBE21F851A for ; Wed, 21 Dec 2011 09:29:18 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-b8-4ef2176bd8f5 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E8.B0.09514.B6712FE4; Wed, 21 Dec 2011 18:29:15 +0100 (CET) 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; Wed, 21 Dec 2011 18:29:15 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B879422EF for ; Wed, 21 Dec 2011 19:29:14 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 65DA151D59 for ; Wed, 21 Dec 2011 19:29:14 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C55185195F for ; Wed, 21 Dec 2011 19:29:13 +0200 (EET) Message-ID: <4EF21769.3090409@ericsson.com> Date: Wed, 21 Dec 2011 18:29:13 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: core@ietf.org References: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> <003901ccba7c$82ce7020$886b5060$@uni-rostock.de> <031DD135F9160444ABBE3B0C36CED6180217F3@011-DB3MPN1-012.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D32E1F@szxeml525-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61802AA5A@011-DB3MPN1-013.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61802BC3C@011-DB3MPN1-013.MGDPHG.emi.philips.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] Multicast response suppression, random back-off (ticket #177) 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, 21 Dec 2011 17:29:20 -0000 Hi there, some consideration in line On 12/20/11 1:08 PM, Carsten Bormann wrote: > On Dec 20, 2011, at 10:38, Dijk, Esko wrote: > >> About the semantics: There is a clearly different semantics between "response is most useful before time T" and "if possible please delay your response by a random time within [0,T]". The first is an application concern, while the second is more to 'engineer' the network traffic patterns to an acceptable behaviour i.e. related to the CoAP messaging 'sublayer'. Under the first semantics there's no reason to delay anything while under the second semantics this is the key point. > While this is true, the difference is in the unicast (reply now) vs. multicast (reply with a dithered delay) semantics, not in the semantics of the option that is giving the desired time frame. just for the sake to try to understand better the scenario and the semantic: could the "response is most useful before time T" semantic be somehow useful also for multicast request? > So I would still be happy to have a single option for response time frame for both cases. if we can define clear and distinct use case/semantic for unicast and multicast I would also prefer to have a single option > >> There was also an open question from Salvatore on the list (June 29) on Request-Timeout: what if the sensor is not able to handle a POST/PUT request in the requested interval of time, should it discard the request entirely or only cancel the sending of the response. thanks for the quotation/reminder Esko :-) > If you haven't ACKed yet, you want to quench the retransmissions. The obvious way to do this would be to send some 4.xx/5.xx response. (I'm not entirely sure which of those is right.) > > If you did ACK and then find out you can't respond in time, you have promised to respond. It sounds impolite not to heed this promise, so you should be sending a separate 4.xx/5.xx response as soon as you know that. (The client can't rely on this behavior because the server may not find out in time and because the response time frame option is likely to remain Elective.) which class of response to use 4.xx/5.xx is a good question 4.xx should be used in the scenario where is impossible in general for the server to answer within the requested interval; e.g. the time to calculate the answer is >> Request-timeout 5.xx should be used when the impossibility to answer in time is due to the fact that the server is busy/overloaded with other stuff having said that, my question was slightly different: most likely the server can not figure it out in advance whether or not it will be able to honor the request-timeout it will only discover that once it has already started to elaborate the POST/PUT request however both POST and PUT request are not save, POST is not idempotent while PUT is idempotent. so we have to think carefully how to apply the Request-Timeout (or whatever this option will finally named) for POST/PUT methods cheers Salvatore -- Salvatore Loreto www.sloreto.com From cabo@tzi.org Wed Dec 21 10:59: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 C666711E8089 for ; Wed, 21 Dec 2011 10:59:10 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LB3pXs3TBuh for ; Wed, 21 Dec 2011 10:59:10 -0800 (PST) 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 D042411E8073 for ; Wed, 21 Dec 2011 10:59:09 -0800 (PST) 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 pBLIx0nE000894; Wed, 21 Dec 2011 19:59:01 +0100 (CET) Received: from [192.168.217.110] (p5B3E7ECF.dip.t-dialin.net [91.62.126.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6397D52F; Wed, 21 Dec 2011 19:59:00 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <4EF21769.3090409@ericsson.com> Date: Wed, 21 Dec 2011 19:58:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5292A655-FD4A-453F-A8F8-9684F51E9FBC@tzi.org> References: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> <003901ccba7c$82ce7020$886b5060$@uni-rostock.de> <031DD135F9160444ABBE3B0C36CED6180217F3@011-DB3MPN1-012.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D32E1F@szxeml525-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61802AA5A@011-DB3MPN1-013.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61802BC3C@011-DB3MPN1-013.MGDPHG.emi.philips.com> <4EF21769.3090409@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1251.1) Cc: core@ietf.org Subject: Re: [core] Multicast response suppression, random back-off (ticket #177) 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, 21 Dec 2011 18:59:10 -0000 >>> About the semantics: There is a clearly different semantics between = "response is most useful before time T" and "if possible please delay = your response by a random time within [0,T]". The first is an = application concern, while the second is more to 'engineer' the network = traffic patterns to an acceptable behaviour i.e. related to the CoAP = messaging 'sublayer'. Under the first semantics there's no reason to = delay anything while under the second semantics this is the key point. >> While this is true, the difference is in the unicast (reply now) vs. = multicast (reply with a dithered delay) semantics, not in the semantics = of the option that is giving the desired time frame. >=20 >=20 > just for the sake to try to understand better the scenario and the = semantic: > could the "response is most useful before time T" semantic be somehow = useful also for multicast request? I was trying to argue that the two time frames (client patience, server = dithering) are exactly the same ones: In the multicast case, the server would try to dither within the exactly = the time frame that the requester is prepared to wait. So there is never a good reason to indicate another time frame. (Note that, in all cases, the time is extended by network latency. = There also should be some exhortation that a retransmitting sender = *should* adjust the time if that is indeed what the sender wants.) > most likely the server can not figure it out in advance whether or not = it will be able to honor the request-timeout > it will only discover that once it has already started to elaborate = the POST/PUT request > however both POST and PUT request are not save, POST is not idempotent = while PUT is idempotent. >=20 > so we have to think carefully how to apply the Request-Timeout (or = whatever this option will finally named) for POST/PUT methods Right. =20 But I'm pretty sure in the end what we write there will amount to "the = server should do the right thing"=85 The semantics are just too different in different applications and kinds = of resources. Gr=FC=DFe, Carsten PS.: Maybe "Patience" is indeed the right name for that option... From salvatore.loreto@ericsson.com Wed Dec 21 11:02:04 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 51B2311E80B0 for ; Wed, 21 Dec 2011 11:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.166 X-Spam-Level: X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS24UlmeBe5P for ; Wed, 21 Dec 2011 11:02:03 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6CC11E809F for ; Wed, 21 Dec 2011 11:02:03 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-6d-4ef22d2883c4 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9B.86.09514.82D22FE4; Wed, 21 Dec 2011 20:02:00 +0100 (CET) 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; Wed, 21 Dec 2011 20:01:52 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BBDE322EF; Wed, 21 Dec 2011 21:01:51 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7E04951D59; Wed, 21 Dec 2011 21:01:51 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E76CD5195F; Wed, 21 Dec 2011 21:01:50 +0200 (EET) Message-ID: <4EF22D1E.6070203@ericsson.com> Date: Wed, 21 Dec 2011 20:01:50 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Carsten Bormann References: <031DD135F9160444ABBE3B0C36CED61802069D@011-DB3MPN1-012.MGDPHG.emi.philips.com> <003901ccba7c$82ce7020$886b5060$@uni-rostock.de> <031DD135F9160444ABBE3B0C36CED6180217F3@011-DB3MPN1-012.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2D32E1F@szxeml525-mbs.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61802AA5A@011-DB3MPN1-013.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61802BC3C@011-DB3MPN1-013.MGDPHG.emi.philips.com> <4EF21769.3090409@ericsson.com> <5292A655-FD4A-453F-A8F8-9684F51E9FBC@tzi.org> In-Reply-To: <5292A655-FD4A-453F-A8F8-9684F51E9FBC@tzi.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: "core@ietf.org" Subject: Re: [core] Multicast response suppression, random back-off (ticket #177) 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, 21 Dec 2011 19:02:04 -0000 On 12/21/11 7:58 PM, Carsten Bormann wrote: >>>> About the semantics: There is a clearly different semantics between "response is most useful before time T" and "if possible please delay your response by a random time within [0,T]". The first is an application concern, while the second is more to 'engineer' the network traffic patterns to an acceptable behaviour i.e. related to the CoAP messaging 'sublayer'. Under the first semantics there's no reason to delay anything while under the second semantics this is the key point. >>> While this is true, the difference is in the unicast (reply now) vs. multicast (reply with a dithered delay) semantics, not in the semantics of the option that is giving the desired time frame. >> >> just for the sake to try to understand better the scenario and the semantic: >> could the "response is most useful before time T" semantic be somehow useful also for multicast request? > I was trying to argue that the two time frames (client patience, server dithering) are exactly the same ones: > In the multicast case, the server would try to dither within the exactly the time frame that the requester is prepared to wait. > So there is never a good reason to indicate another time frame. > (Note that, in all cases, the time is extended by network latency. There also should be some exhortation that a retransmitting sender *should* adjust the time if that is indeed what the sender wants.) > >> most likely the server can not figure it out in advance whether or not it will be able to honor the request-timeout >> it will only discover that once it has already started to elaborate the POST/PUT request >> however both POST and PUT request are not save, POST is not idempotent while PUT is idempotent. >> >> so we have to think carefully how to apply the Request-Timeout (or whatever this option will finally named) for POST/PUT methods > Right. > But I'm pretty sure in the end what we write there will amount to "the server should do the right thing"… > The semantics are just too different in different applications and kinds of resources. > > Grüße, Carsten > > PS.: Maybe "Patience" is indeed the right name for that option... > +1 for "Patience" option :-) From alper.yegin@yegin.org Thu Dec 22 00:02: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 C037611E80CA for ; Thu, 22 Dec 2011 00:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEha2pxLYPXf for ; Thu, 22 Dec 2011 00:02:24 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id DD99C21F8B44 for ; Thu, 22 Dec 2011 00:02:23 -0800 (PST) Received: from [192.168.2.5] (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M5dlA-1QkSga2WIC-00xXJg; Thu, 22 Dec 2011 03:02:21 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_30D67620-D4CF-4FEC-B4E1-1D856967ECE0" From: Alper Yegin In-Reply-To: <999913AB42CC9341B05A99BBF358718DE7C529@FIESEXC035.nsn-intra.net> Date: Thu, 22 Dec 2011 10:02:02 +0200 Message-Id: References: <0E08042A-74F3-452A-B255-E5B654C01283@yegin.org><17AB9640-613B-4AAD-B6F4-882DEDCF9122@tzi.org><590937FD-3BAD-47CC-B250-C4A3FA5224CE@yegin.org> <4EEF7149.2020400@gmail.com> <999913AB42CC9341B05A99BBF358718DE7C0AA@FIESEXC035.nsn-intra.net> <06384DD1-323F-49A4-8D83-2D88F91D666A@yegin.org> <999913AB42CC9341B05A99BBF358718DE7C529@FIESEXC035.nsn-intra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" X-Mailer: Apple Mail (2.1251.1) X-Provags-ID: V02:K0:3Jt2Tm30qyBxH0rDZ/YcUHhsin4LRaONeaVQJJViXa5 5dMwbl/4aCuXqgCDl+TnNpzz0228uFLbo4y9TPy90xRWg1POS0 8JIdmT3juYKeVOZLiU17cu5WhcqgztARfa+1qwEM3RZiphauF5 AJe+VD2AXD9qRGc2nABDonFf294AzooviZRn/0aSO5Bim3APen PjbJGYJnq4ltjDzIYSIcAzbBrwHrjO+Zbbq5L/q9Vid2zkPEu7 czCma0ryhHYL/tZnJAFrbX9ducn4/gN50AfEUmG8oag4bIUMZ7 keUvP8FxMbWlA8yiWcQ0E7SIoK/SnbF99XZVX72blfdqTXj5+8 9TrtbTW7O2dCq9rf65s5wMVgKDerKPMOTgDpZRTERIp9xOtKbs lI5GbsC+xG5Dg== Cc: core WG Subject: Re: [core] RawPublicKeys 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, 22 Dec 2011 08:02:26 -0000 --Apple-Mail=_30D67620-D4CF-4FEC-B4E1-1D856967ECE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Hannes, > ~snip~ > =20 > The issue I'm raising is that, there story has two sides. We gotta be = talking about not only how the network authorizes the device, but also = how the device authorizes the network. What you describe above is the = former, latter one is missing. > =20 > With the work on TLS raw public key and the cached information = extension I was actually more focusing on the communication between two = applications rather than security for network access authentication. Alper> I was not talking about "network access authentication". I was = just walking over a physical example where people bring in a new device = to home and it needs to start talking CoAP to the gateway at home. This = is the scenario where people talk about "reading an ID from a stickier = on the device and typing it in an ACL (on the gateway)". Or reading that = ID over the phone to the service provider who enters it into the ACL = database, etc. Alper> Note: Same credential is likely to be used for both network = access and app auth, but we can ignore that aspect for this discussion. > =20 > But your issue is also valid for an application scenario and the = answer depends a bit on the device capabilities itself and the expected = behavior. > =20 > For example, with a picture frame you have a UI and with a temperature = sensor you probably don=92t have one. With an Internet radio you have a = small UI and actually, for more elaborate configuration, you can also = connect to the device via a Web browser. Some devices have certain = parameters pre-configured (like my Internet radio fetches a list of = available Internet radio stations from a pre-configured URL). > =20 > So, there is no single answer. Alper> I thought we were trying to solve the problem of "dealing with = interface-less devices".=20 Alper> Maybe we shall re-state the problem statement, if that's not it. > It really varies a lot but maybe you can cluster the different = scenarios in some form to offer a meaningful description. =20 > =20 > It's not like the device will/shall be OK to talk to anyone who wants = to talk to itself. Device needs to authenticate and authorize the other = end as well, using ACLs etc.=20 > It depends. When I look at Jari=92s draft then I believe his model is = more than the device just blasts the info out into the network using a = multicast address. That may not be desirable for every scenario but = could be OK for his use case. > =20 > =20 > How do we introduce the ACL into such devices? There's gotta be an = interface for that. > =20 > There are quite likely these cases: > =20 > =B7 No ACL needed (Jari=92s case) Alper> Is that the case where device is just a sensor (not controlled), = and whatever it senses/delivers is not confidential? Only in that case = we are OK with the one-sided authentication/authorization. > =B7 ACL based on pre-configuation (device talks only to some = servers in the service provider=92s network) > =B7 Configurable ACLs using a user interface (via a display) > =B7 Indirect configuration via some protocols (think of = software update mechanisms, device configuration) > =20 Alper> Yes, this is an enumeration of numerous scenarios. I think our = difference is in the understanding of the problem statement.=20 > Note that this is an issue for asymmetric-crypto. With the symmetric = crypto, device can assume whoever holds the same PSK is already = authorized hence I don't also need to maintain an ACL. Symmetric crypto = has other issues though (e.g., how did you get the PSK here and there?) > =20 > Well. Even with asymmetric crypto (like the raw public keys) you = could, if you want to, treat them like symmetric keys. > =20 Alper> Only if you install an ACL on the device=85=20 Alper> Unless the device knows the list of authorized IDs, it can only = authenticate the other end-points but it cannot authorize them. Alper> With the PSK, device can say "oh, OK, whoever has a copy of my = PSK is inherently authorized to talk with me" Alper > Ciao > Hannes > =20 > =20 > Alper > =20 > =20 > =20 > =20 > =20 >=20 >=20 > =20 > For other scenarios this may not be good enough. If you have = additional requirements then you those will lead to more complexity, = more code, and additional performance requirements. There is no free = lunch. > =20 > When it comes to documenting some of these aspects I doubt that there = is a desire to develop a one-size-fits-all solution. Leaving everything = open may not be useful either. > =20 > So, what could you do? > =20 > I believe it makes sense to > =B7 Develop some building blocks, as we are already doing. For = those it will be difficult to specify a mandatory-to-implement security = solution. > =B7 Document at least one architectural description to see how = the different building blocks actually work together and that there are = no gaps. Jari had made one attempt = withhttp://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-01. Maybe = there is a possibility to do better?! > =20 > =20 > Ciao > Hannes > =20 > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of ext Rene Struik > Sent: Monday, December 19, 2011 7:16 PM > To: Alper Yegin > Cc: core WG > Subject: Re: [core] RawPublicKeys > =20 > Dear colleagues: >=20 > For your convenience, I copied below the issue that Alper Yegin = attributed to me and that I brought up originally during IETF-82 (Thu = Nov 17th). >=20 > Perhaps, we can reflect on this after the New Year. Meanwhile, I wish = you all a Happy Christmas and an inspirational and creative 2012. >=20 > Best regards, Rene >=20 > On 19/12/2011 5:25 AM, Alper Yegin wrote: >=20 >=20 >=20 > =20 > This issue and what Rene brought up appear to be still open=85 > Any thoughts, folks? >=20 > -------- Original Message -------- > Subject: > Re: [core] RawPublicKeys > Date: > Thu, 17 Nov 2011 10:50:40 -0500 > From: > Rene Struik > To: > Alper Yegin > CC: > core WG >=20 >=20 > Dear colleagues: >=20 > Alper's question definitely has merit. I have another one, though: >=20 > Having public-key derived identities printed on a device presumes that = a device's public key will never change over its lifecycle. Moreover, it = assumes that the public key is available prior to printing the bar code.=20= >=20 > Could you please explain how this would work from a lifecycle = perspective? (chip production, module manuacturing, public key = "registration", "certification", "revocation", etc.)=20 > [Note - even if public keys are not certified by a CA using a = certificate, one should still consider = registration/certification/revocation, aspects] >=20 > These devices are assumed to have no trusted platform on board. What = if someone else clones a device, produces a million copies, and pollutes = the market place this way (one of the scenarios described in = draft-garcia-core-security-03 (Section 3.1)). It seems that one is just = out of luck then. >=20 > =46rom the text in Appendix D.1 it seems one just hashes bare public = keys, without any policy oriented info or time validity period. How does = this relate to security policies? What are those policies? >=20 > Rene >=20 >=20 >=20 > =20 > =20 > On Nov 18, 2011, at 3:21 AM, Alper Yegin wrote: > =20 > Hi Carsten, > =20 > On Nov 17, 2011, at 7:15 PM, Carsten Bormann wrote: > =20 > On Nov 17, 2011, at 23:22, Alper Yegin wrote: > =20 > The above text explains how the network node authenticates/authorizes = the device. > But, how does the device authenticate/authorize the network node? For = that, the "identity" of the network node's public key needs to be known = to the device. But how? > =20 > Hi Alper, > =20 > what is a "network node" in the context of CoAP? > (I read "device" to include both the client and server roles, so from = the point of CoAP, there is nothing else. But maybe I'm missing = something here.) > =20 > =20 > =20 > In the context of a "home deployment" for example, the network node is = the home gateway that one needs to configure when bringing in a new = device to home. ACL on the home gateway needs to be updated with the = device ID for access control. But this is just one side of the story. = The other side is, how does the new device identify the network (the = home gateway)? > =20 > =20 > =20 > Gr=FC=DFe, Carsten > =20 > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 >=20 >=20 > --=20 > email: rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 --Apple-Mail=_30D67620-D4CF-4FEC-B4E1-1D856967ECE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Hannes,

The issue I'm raising is = that, there story has two sides. We gotta be talking about not only how = the network authorizes the device, but also how the device authorizes = the network. What you describe above is the former, latter one is = missing.
With = the work on TLS raw public key and the cached information extension I = was actually more focusing on the communication between two applications = rather than security for network access = authentication.

Alper> Note: Same credential is likely = to be used for both network access and app auth, but we can ignore that = aspect for this = discussion.



But your issue is also valid for an = application scenario and the answer depends a bit on the device = capabilities itself and the expected = behavior.
For = example, with a picture frame you have a UI and with a temperature = sensor you probably don=92t have one. With an Internet radio you have a = small UI and actually, for more elaborate configuration, you can also = connect to the device via a Web browser. Some devices have certain = parameters pre-configured (like my Internet radio fetches a list of = available Internet radio stations from a pre-configured = URL).
So, = there is no single answer. =
=

Alper> I thought we were trying to = solve the problem of "dealing with interface-less = devices". 
Alper> Maybe we shall re-state the problem = statement, if that's not it.


It really varies a lot = but maybe you can cluster the different scenarios in some form to offer = a meaningful description.  
It's not like = the device will/shall be OK to talk to anyone who wants to talk to = itself. Device needs to authenticate and authorize the other end as = well, using ACLs etc. 
It depends. When I look at Jari=92s draft then I = believe his model is more than the device just blasts the info out into = the network using a multicast address. That may not be desirable for = every scenario but could be OK for his use = case.
How do we introduce the = ACL into such devices? There's gotta be an interface for = that.
There = are quite likely these cases:
=B7 No ACL needed (Jari=92s = case)
=

Alper> Is that the case where device is just a = sensor (not controlled), and whatever it senses/delivers is not = confidential? Only in that case we are OK with the one-sided = authentication/authorization.



=B7 ACL based on pre-configuation (device talks only to = some servers in the service provider=92s = network)
=B7 Configurable ACLs using a user interface (via a = display)
=B7 Indirect configuration via some protocols (think of = software update mechanisms, device = configuration)
Note that this is an issue for = asymmetric-crypto. With the symmetric crypto, device can assume whoever = holds the same PSK is already authorized hence I don't also need to = maintain an ACL. Symmetric crypto has other issues though (e.g., how did = you get the PSK here and there?)
 
Well. Even with asymmetric crypto = (like the raw public keys) you could, if you want to, treat them like = symmetric keys.



Alper




For = other scenarios this may not be good enough. If you have additional = requirements then you those will lead to more complexity, more code, and = additional performance requirements. There is no free lunch.
 
When it comes to documenting some of these aspects I = doubt that there is a desire to develop a one-size-fits-all solution. = Leaving everything open may not be useful either.
 
So, what could you do?
 I = believe it makes sense to
=B7 Develop some building blocks, as we are already = doing. For those it will be difficult to specify a = mandatory-to-implement security solution.
=B7 Document at least one architectural description to = see how the different building blocks actually work together and that = there are no gaps. Jari had made one attempt with
 
 
This issue and what Rene brought up =
appear to be still open=85
Any thoughts, =
folks?
Subject:
Date:
Thu, 17 Nov 2011 = 10:50:40 -0500
From:


Dear = colleagues:

Alper's question definitely has merit. I have another = one, though:

Having public-key derived identities printed on a = device presumes that a device's public key will never change over its = lifecycle. Moreover, it assumes that the public key is available prior = to printing the bar code. 

Could you please = explain how this would work from a lifecycle perspective? (chip = production, module manuacturing, public key "registration", = "certification", "revocation", etc.) 
[Note - even if public = keys are not certified by a CA using a certificate, one should still = consider registration/certification/revocation, aspects]

These = devices are assumed to have no trusted platform on board. What if = someone else clones a device, produces a million copies, and pollutes = the market place this way (one of the scenarios described in = draft-garcia-core-security-03 (Section 3.1)). It seems that one is just = out of luck then.

=46rom the text in Appendix D.1 it seems one = just hashes bare public keys, without any policy oriented info or time = validity period. How does this relate to security policies? What are = those = policies?

Rene



 
 
On Nov 18, 2011, at 3:21 AM, Alper =
Yegin wrote:
Hi =
Carsten,
On =
Nov 17, 2011, at 7:15 PM, Carsten Bormann =
wrote:
On Nov 17, 2011, at =
23:22, Alper Yegin wrote:
 
The above =
text explains how the network node authenticates/authorizes the =
device.
But, =
how does the device authenticate/authorize the network node? For that, =
the "identity" of the network node's public key needs to be known to the =
device. But how?
 
Hi Alper,
 
what is a "network node" in the context =
of CoAP?
(I =
read "device" to include both the client and server roles, so from the =
point of CoAP, there is nothing else.  But maybe I'm missing =
something here.)
 
In =
the context of a "home deployment" for example, the network node is the =
home gateway that one needs to configure when bringing in a new device =
to home. ACL on the home gateway needs to be updated with the device ID =
for access control. But this is just one side of the story. The other =
side is, how does the new device identify the network (the home =
gateway)?
Gr=FC=DFe, =
Carsten
 
core mailing =
list
core@ietf.org
core mailing =
list
core@ietf.org
-- 
Skype: =
rstruik
cell: =
+1 (647) 867-5658
USA =
Google voice: +1 (415) =
690-7363

List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 09:50:16 -0000 With the updated version of the draft there is an open issue you guys may have input to offer. -------- Original Message -------- Subject: TLS Cached Information Extension - version 11 Date: Mon, 26 Dec 2011 11:46:58 +0200 From: Hannes Tschofenig To: tls@ietf.org CC: hannes.tschofenig@gmx.net Hi all, Nikos provided review comments (see http://www.ietf.org/mail-archive/web/tls/current/msg08338.html) and I have incorporated them in version 11 of the draft: http://www.ietf.org/internet-drafts/draft-ietf-tls-cached-info-11.txt As you can see, there are a number of smaller changes here and there. I hope that readability has improved. There is an open issue: algorithm negotiation Currently, the draft defines a registry for hash algorithms that are used to produce the hashes of cached information. The client can tell the server that it has already cached, for example, the certificate chain. The server then has to only send the fingerprint of it (rather than the complete certificate chain). The other information (besides certificate chains) that can be "fingerprinted" is the list of trusted CAs. Does this cover all use cases? A few algorithms are defined, namely SHA-1, SHA-224, SHA-256, SHA-384, SHA-512. Is this a good list to start with? The draft does not define a way for the client to tell the server that it only supports a certain hash algorithm. Should we allow the client to indicate what algorithm it supports? Ciao Hannes From rene.hummen@informatik.rwth-aachen.de Sat Dec 31 09:04:21 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 C952021F8483; Sat, 31 Dec 2011 09:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBBF6DseIaBA; Sat, 31 Dec 2011 09:04:21 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id AB2B121F8482; Sat, 31 Dec 2011 09:04:19 -0800 (PST) MIME-version: 1.0 Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LX200I5HVF6TJ70@mta-1.ms.rz.RWTH-Aachen.de>; Sat, 31 Dec 2011 18:04:18 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.71,437,1320620400"; d="p7s'?scan'208";a="73704190" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Sat, 31 Dec 2011 18:04:19 +0100 Received: from [10.0.2.2] ([unknown] [2.192.237.31]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LX200K3QVF4WF70@relay-auth-1.ms.rz.rwth-aachen.de>; Sat, 31 Dec 2011 18:04:18 +0100 (CET) Content-type: multipart/signed; boundary=Apple-Mail-133--848491416; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ren=E9_Hummen?= In-reply-to: <4EEF5D92.5020503@gmail.com> Date: Sat, 31 Dec 2011 18:04:19 +0100 Message-id: <02E1CC7E-A9A4-4051-A0FA-7D12E9EF371C@cs.rwth-aachen.de> References: <04D43087-E2BF-464F-BE5E-D57FC3FFA746@cs.rwth-aachen.de> <4EC15495.3000700@gmail.com> <4EC5B600.1040700@gmail.com> <4EEF5D92.5020503@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.1084) Cc: hipsec@ietf.org, core Subject: Re: [core] [hiprg] Research topics discussion - meeting suggestion: Wednesday 7:30pm 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, 31 Dec 2011 17:04:21 -0000 --Apple-Mail-133--848491416 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Ren=E9, this email contains a few references to papers regarding the security = properties and embedding of HIP in today's network environments. First of all, HIP is a SIGMA-compliant key exchange protocol [1]. To be = exact, it is a derivate of the basic protocol described in Section 5.1, = as the HIP BEX is triggered by a separate (empty) message that is not = included in the SIGMA protocol family. This allows HIP to perform DoS = protection against exhaustive public key-based operations by the = responder by means of cryptographic puzzles. Furthermore, the public key = (A) of the responder is already sent in the first response message. = However, this does not impact the security properties, but rather the = anonymity of the responder. Regarding the usage of HIP, there is a rather comprehensive journal = article [2] that describes the architecture as well as the operation = system and infrastructure requirements of HIP. It also provides some = pointers to further papers that may be worth reading for you. = Additionally, Samu Varjonen recently published a paper on the "Secure = Resolution of End-Host Identifiers for Mobile Clients" [3]. However, it = seems to be inaccessible at the moment. Still, you may want to refer to = it at later point in time, as it describes an approach to resolve HITs = to IP addresses. I hope that this small selection is helping you in understanding the = properties of HIP. I would also like to invite other people to = contribute to this discussion, e.g., by providing further references = relevant for the CoRE WG. Regards, Ren=E9 [1] Krawczyk, H.; SIGMA: The =91SIGn-and-MAc=92 Approach to = Authenticated Diffie-Hellman and Its Use in the IKE Protocols, ADVANCES = IN CRYPTOLOGY - CRYPTO 2003 Lecture Notes in Computer Science, 2003 [2] Nikander, P.; Gurtov, A.; Henderson, T.R.; Host Identity = Protocol (HIP): Connectivity, Mobility, Multi-Homing, Security, and = Privacy over IPv4 and IPv6 Networks, Communications Surveys & Tutorials, = IEEE, 2010 [3] Varjonen, S.; Heer, T.; Rimey, K.; and Gurtov, A.; Secure Resolution = of End-Host Identifiers for Mobile Clients, IEEE GLOBECOM, 2011 On 19.12.2011, at 16:51, Rene Struik wrote: > Perhaps, worth some thoughts under the Christmas tree and then getting = back on this one after New Year. >=20 > On 17/11/2011 8:33 PM, Rene Struik wrote: >> Hi fellow-Rene: >>=20 >> If you have some papers, I would appreciate. Distributing those would = also help removing hurdles to more wide-scale use of HIP (I saw the = slides on lack of adoption of HIP). >>=20 >> Best regards, Rene >>=20 >>=20 >> On 14/11/2011 12:49 PM, Rene Struik wrote: >>> Hi fellow-Rene: >>>=20 >>> Just curious: is there any research paper outside IETF/IRTF realm = that delves into HIP-related matter? On a tangent: same question, but = now re cryptographically generated addresses? This may help people to = appreciate this effort better, without having to delve into hundreds of = pages of specification text that sometimes seems to obscure seeing the = forest for the trees (if I translate this properly). I, for one, would = love to see 2-3 academic papers that make this subject matter clearer, = including security properties, ease-of-use considerations. >>>=20 >>> Best regards, Rene >>>=20 >>> On 14/11/2011 12:38 PM, Ren=E9 Hummen wrote: >>>> Hello everyone, >>>>=20 >>>> we already had a few discussions on this list about new topics and = research directions that would foster collaboration within the context = of the hiprg. Hierarchical HITs, IoT-related protocol variants, and = middlebox awareness have been mentioned there among others. In my = opinion, an informal meeting before the hiprg meeting on Thursdays would = be a great opportunity to further discuss about these topics. = Furthermore, such a meeting would enable us see who is interested in = which field and which are the pros and cons of the different topics as = perceived by people in a more comfortable and less hurried way than in = an RG meeting. >>>>=20 >>>> As most of us will probably be at the social event tomorrow = evening, I suggest to meet for dinner/a drink on Wednesday evening at = 7:30pm in order to get some discussion going. Due to the lack of = knowledge about a better place, let's meet up at the entrance of the = convention center (TICC). Please email me if you are interested. >>>>=20 >>>> BR >>>> Ren=E9 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Dipl.-Inform. Rene Hummen, Ph.D. Student >>>> Chair of Communication and Distributed Systems >>>> RWTH Aachen University, Germany >>>> tel: +49 241 80 20772 >>>> web:=20 >>>> http://www.comsys.rwth-aachen.de/team/rene-hummen/ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> hiprg mailing list >>>>=20 >>>> hiprg@irtf.org >>>> https://www.irtf.org/mailman/listinfo/hiprg >>>=20 >>>=20 >>> --=20 >>> email:=20 >>> rstruik.ext@gmail.com >>>=20 >>> Skype: rstruik >>> cell: +1 (647) 867-5658 >>> USA Google voice: +1 (415) 690-7363 >>>=20 >>=20 >>=20 >> --=20 >> email:=20 >> rstruik.ext@gmail.com >>=20 >> Skype: rstruik >> cell: +1 (647) 867-5658 >> USA Google voice: +1 (415) 690-7363 >>=20 >=20 >=20 > --=20 > email:=20 > rstruik.ext@gmail.com >=20 > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 >=20 -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 20772 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ --Apple-Mail-133--848491416 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7zCCBCEw ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0 c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5 MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIE2jCCA8KgAwIBAgIEDuQh4zANBgkqhkiG 9w0BAQUFADBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJX VEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3RoLWFhY2hlbi5kZTAeFw0wOTEwMDEx MjQ1MDdaFw0xMjA5MzAxMjQ1MDdaMDkxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtSV1RIIEFhY2hl bjEUMBIGA1UEAxMLUmVuZSBIdW1tZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCw KpV77WtQa3ZIx+dWRTgR8wxSUsQoSEY2Do5wNPJ/m3hO3P7e8FfVKSaTimKHvRPiRvCX+HW2ldMA f33GWtJTrN6hbSHzQTpq84uQOp/R8ad094wdKbenITaOWISEAjymgA0gS1RpvxaOv5r9uw1Th2ci kjWEOA3tIXCFwFwfMzA/QllikzSkbmm8a6RryOUyQCqCpt9GGS0i1KC+NIa/GP883S4W4En9PxA+ VJ4hJFwjnIt0E+wUigPBQvLHxRqBT/sXSJxsSZO/uNR99dxKeQmdd4Uob5olMA94uZX/rbeZdgDu 49qSIlx/bEFzJTQzH7yDATed6nXGDojAVHeBAgMBAAGjggHDMIIBvzAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYDVR0O BBYEFN+tg8k5s/o7Bjed1LmJouNUa4NUMB8GA1UdIwQYMBaAFG7VPsAcL3HJPL9JTu9qVUjs0fI4 MCgGA1UdEQQhMB+BHXJlbmUuaHVtbWVuQGNzLnJ3dGgtYWFjaGVuLmRlMHkGA1UdHwRyMHAwNqA0 oDKGMGh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvcnd0aC1jYS9wdWIvY3JsL2NhY3JsLmNybDA2oDSg MoYwaHR0cDovL2NkcDIucGNhLmRmbi5kZS9yd3RoLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGUBggr BgEFBQcBAQSBhzCBhDBABggrBgEFBQcwAoY0aHR0cDovL2NkcDEucGNhLmRmbi5kZS9yd3RoLWNh L3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBABggrBgEFBQcwAoY0aHR0cDovL2NkcDIucGNhLmRmbi5k ZS9yd3RoLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAmXPLNSHW Ze3V4Rq3P2pcaBIlY4Z/nJ1jH3u6yBD3gGZrthpu1o0g45hOWbcvkkcQwvEXKlnWeiVXJsQ2XElz ydNFQprK9GFRZvuOJUkMdR87uupqLESpoue7kmTVCFcqg8c/Q9D5KTbTTtrGDydcqKy+MWbrbtGb lg0R8ZJmnIlb+8RLCqa4MbYq2M2kiImYzDrczlPWvy3SHiPASNFf31XDLFP26QlO3USacm/E+CfM sgQFudf9BqE6yW8qoqx0x1xyMdo5tWyT1MUKsDA/cGADc+r2orBNBsZ7AjdPi85fJS3NE2PGhMEZ BCsvt/EC/yIQK7O3DwELk0VlVaE/uDCCBOgwggPQoAMCAQICBAnydOAwDQYJKoZIhvcNAQEFBQAw WjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAi BgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0wNzAyMTQxMTQ5MzhaFw0xOTAy MTMwMDAwMDBaMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtSV1RIIEFhY2hlbjEXMBUGA1UEAxMO UldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3dGgtYWFjaGVuLmRlMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuDAIZOPI3HpS3zVCOZLzL/gheeMSZy+Mf3CUJzdjSHeg id36rNLIjtnsSAAn83Y8TlKUOmRTp+aXU704u7LZ5PFgGj/3fSxXfJPRm8Y4e8Ydy/tGt2nPv7Ry XF+euJ7VMRrVRjLkoRKFGmVE+X8Pe0y9+lCfDqly66qXQCnBSmifqYEadoEy4+DDVDD4wOBpbLaY 6C50/vqhZu7f2UvdvxNzqjSVMBx+gt+b0q6FbHJoPmu18U+lOCTvfTGMTXEyDM4T0vWLaft9NsO4 udXWgY69IRRjytJy0leoL++8wUhSewFRiScQUlMw59MZAy2L2cKmnmJI/JAwdqEnkcnxowIDAQAB o4IBsDCCAawwDwYDVR0TAQH/BAUwAwEB/zALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFG7VPsAcL3HJ PL9JTu9qVUjs0fI4MB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOB EWNhQHJ3dGgtYWFjaGVuLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRm bi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEE gZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRl L2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEA F4d+xiwLHCB61akGKxuT/3WFC8QLHlOsblyp0qVU5zFlRX9U7Tf6dg/vF0yrZfwOFpWGvZ6fjjW5 VnEtZybLmH+zfcKzuMwhHFQTSyABwmN2VxviKDR8IF6kmKlx86wEGY5Eia9UX2xROJ41MtJzYbQu dR19KJ4Fn6jg3Os+2hfcHttOteTIfCpPLqMeF4Iyy1f1Iz1ZcEQJ7mCHhdMMnL0Oo8/zyTLjq10o aano6WokV6isfKD1wJQnJ6KkS5UHNS9IsEBwZ9BJurQ5jB3GoW3/UgTlomfPjtGr+JcvAkPeaJM/ YbaPVBK11CMzXmtgEFwbZSMiyyoFbmD3+ItyMjGCAt4wggLaAgEBMGYwXjELMAkGA1UEBhMCREUx FDASBgNVBAoTC1JXVEggQWFjaGVuMRcwFQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4GCSqGSIb3 DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUCBA7kIeMwCQYFKw4DAhoFAKCCAU0wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMjMxMTcwNDE5WjAjBgkqhkiG9w0BCQQx FgQUDKdeQlKdWWzNosCoDw1ZnME7XsAwdQYJKwYBBAGCNxAEMWgwZjBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIEDuQh4zB3BgsqhkiG9w0BCRACCzFooGYwXjELMAkGA1UE BhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcwFQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4G CSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUCBA7kIeMwDQYJKoZIhvcNAQEBBQAEggEAVBS0 3vXN6D2j2NMMRhrF9V8BA/VxBmiNYu9ptr2Uk1PDeY/bJuFlkFytpDMW83/iApcVZ4VV7M5+f8lg k+cnn9N/dAU5dcSuUxxjvxY9ERKISLu2t/551ZP94LpzOUmd8mPjsa2zTXzbf57EFx/c9Bw2mNE8 4Nwe+WRqwO4nIS0YorcyGEtyZnLjD42H5k34Mbm2aQlrdhjqUkAe5DzYuTmvbOmlZgBWnoe8BOuq D4ibPCieqJlVQ16wVYB84m94YBT2YU7FZunr7uF0tJcv5dZvqrMgSl/jMBSTXgniQvKKX8Y9Qlhc 27wF+uRouie+ssfp8h4//1YsV3bVsIT9HAAAAAAAAA== --Apple-Mail-133--848491416--