From kovatsch@inf.ethz.ch Wed Feb 1 07:52:27 2012 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 AB55E21F863D for ; Wed, 1 Feb 2012 07:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 N-rdcliH5vnA for ; Wed, 1 Feb 2012 07:52:24 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id D433321F88E8 for ; Wed, 1 Feb 2012 07:52:22 -0800 (PST) Received: from CAS22.d.ethz.ch (172.31.51.112) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 1 Feb 2012 16:52:14 +0100 Received: from MBX10.d.ethz.ch ([169.254.1.192]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.01.0355.002; Wed, 1 Feb 2012 16:52:16 +0100 From: "Kovatsch Matthias" To: Zach Shelby , "core@ietf.org WG" Thread-Topic: [core] Fwd: New Version Notification for draft-shelby-core-interfaces-01.txt Thread-Index: AQHM4CFU27lwTok0mkyu3PXRBXVHGpYoMogw Date: Wed, 1 Feb 2012 15:52:15 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B5138EAE6D@MBX10.d.ethz.ch> References: <20120131140034.16113.99044.idtracker@ietfa.amsl.com> <45E3F318-0B61-406F-AC41-4A8ACAC830B6@sensinode.com> In-Reply-To: <45E3F318-0B61-406F-AC41-4A8ACAC830B6@sensinode.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-interfaces-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 15:52:28 -0000 Dear Zach, dear list A great advantage of the RESTful interfaces of the Web is that they are, in= most cases, human-readable. It makes APIs easy to understand, thus they ar= e learned quickly and system integration becomes cheap. In CoAP, we can have the same benefits thanks to the textual identifiers li= ke URIs and the link format. Especially in this draft (but also others), ho= wever, I see that mostly cryptic letters are used as identifiers to "save s= ome bytes." I think, this combines the disadvantages of both worlds: It is = unreadable like binary protocols, but still requires more bits to represent= the information. Another aspect: if a letter is already taken, a confusing= substitute has to be found and the benefits become even smaller. In my opinion, we should spend additional bytes for readability wherever po= ssible. The link-format, for instance, must be transferred block-wise anywa= y. Maybe a compressed SensorML with readable keys is also preferable over a= n cryptic JSON bastard. I just fear that CoAP could lose its advantage over= other (probably binary) protocols if we drop the advantages that made the = Web successful. What is your opinion on that? Best regards Matthias > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Zach Shelby > Sent: Dienstag, 31. Januar 2012 15:05 > To: core@ietf.org WG > Subject: [core] Fwd: New Version Notification for draft-shelby-core- > interfaces-01.txt >=20 > A new version of the CoRE Interfaces draft is available: >=20 > http://www.ietf.org/id/draft-shelby-core-interfaces-01.txt >=20 > New features added to this version, thanks to Cedric, Daniel and others w= ho > have given improvement ideas: >=20 > - Read-only Parameters > - Toggle feature on Actuators using POST > - Defined use of Observation and new period/step query string parameters >=20 > Zach >=20 > Begin forwarded message: >=20 > > From: internet-drafts@ietf.org > > Date: January 31, 2012 4:00:34 PM GMT+02:00 > > To: zach@sensinode.com > > Cc: zach@sensinode.com > > Subject: New Version Notification for draft-shelby-core-interfaces-01.t= xt > > > > A new version of I-D, draft-shelby-core-interfaces-01.txt has been > successfully submitted by Zach Shelby and posted to the IETF repository. > > > > Filename: draft-shelby-core-interfaces > > Revision: 01 > > Title: CoRE Interfaces > > Creation date: 2012-01-31 > > WG ID: Individual Submission > > Number of pages: 13 > > > > Abstract: > > This document defines well-known REST interface descriptions for > > Batch, Sensor, Parameter and Actuator types for use in contrained web > > servers using the CoRE Link Format. A short reference is provided > > for each type that can be efficiently included in the interface > > description attribute of the CoRE Link Format. These descriptions > > are intended to be for general use in resource designs or for > > inclusion in more specific interface profiles. > > > > > > > > > > The IETF Secretariat >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Fri Feb 3 06:34:23 2012 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 6A1A821F8535 for ; Fri, 3 Feb 2012 06:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 LcWgRnoh7cna for ; Fri, 3 Feb 2012 06:34: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 3585421F851E for ; Fri, 3 Feb 2012 06:34:21 -0800 (PST) Received: from [192.168.1.103] (188-67-134-255.bb.dnainternet.fi [188.67.134.255]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q13EYHCC022713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 3 Feb 2012 16:34:18 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Feb 2012 16:34:16 +0200 Message-Id: To: "core@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] ETSI/IPSO Plugtest 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, 03 Feb 2012 14:34:23 -0000 http://www.etsi.org/plugtests/coap/coap.htm Registration is open for the upcoming CoAP Plugtest event organized by = ETSI and the IPSO Alliance, which will be held together with the = upcoming IETF in Paris. Participation is free of charge for IETF = attendees, ETSI members and IPSO members. Anyone with a CoAP client = and/or server implementation is welcome to participate. Already over 10 = participants have registered, we hope to see you there.=20 Feel free to be in contact with me or plugtests@etsi.org if you have any = questions. 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 From alper.yegin@yegin.org Mon Feb 6 01:44:20 2012 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 A95F421F8542 for ; Mon, 6 Feb 2012 01:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 VHNQI2bvOXJJ for ; Mon, 6 Feb 2012 01:44:20 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id E615421F85CE for ; Mon, 6 Feb 2012 01:44:19 -0800 (PST) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LlUml-1SRTwJ0pqZ-00bGiV; Mon, 06 Feb 2012 04:44:00 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <3615F3CCD55F054395A882F51C6E5FDA1824457B@szxeml513-mbs.china.huawei.com> Date: Mon, 6 Feb 2012 11:43:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <674287D1-C99A-45EE-9969-D0B35160056B@yegin.org> <7D669CE5-0F33-4163-A43B-E05589BE9892@tzi.org> <3615F3CCD55F054395A882F51C6E5FDA1824457B@szxeml513-mbs.china.huawei.com> To: TianLinyi X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:3fFl0jHOT4O8MtGsu8knh0AK3M4+dh8vhqHfb62CkW7 y+64xaMameoSWgK0bAIgR1dGvPOfducif1eEEid/X34VPs64KK utz6AjPtE8nQsBef9eEcL+1l0/2mpF6Fk83PCUWrySykLYRaJ1 EheU3ihP+BoU9sdr6eW9olhsaJW7StRnbnQTcc05r2Rr7rkubm 4fhDef9OGQFSN0fJZa20Xf/juYFxjz5leBXKPGqtbp9fvZdXcy Ihue76iZ+bdoYG3REITGP8aXcZUXDRNaUL4iHN1RlUeWG3Nin3 NJWqnB3uDvb+5qFlgBKaRdLzd5cjkYJU5w2aw7Y6MZq18RqQcp LqzvDZ+28ezmarVQxdd0vpVRUR7Ch+LOw9544/tEY5TJqo5TUE BEE1qTefXzNFg== Cc: core WG Subject: Re: [core] Vendor-specific options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 09:44:20 -0000 On Jan 19, 2012, at 6:10 PM, TianLinyi wrote: >> Are there other people who want to do something in this space? >=20 > Not very much. They can do it in CoAP payload anyway. The vendor = option can't convey enough info and may also be complex. >=20 I didn't understand this response from Tian. I think there is a = misunderstanding about the proposal here.=20 Without a well-defined vendor-specific option support, there is no way = for a vendor (or a user, etc.) to be defining new options for its own = use.=20 I don't understand how "doing it in CoAP payload" as stated above can = work. Alper >=20 >> Creating a new registry for CoAP option vendor-IDs would be possible, = but I'm not convinced yet we want to set this up. >> Among other considerations, most companies in this space already need = an enterprise number, so it is much more stealthy to use this instead of = applying for a number out of a focused registry... > This would cause too much effort for not very important thing. (again = it can be done in CoAP payload) >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Mon Feb 6 04:05:07 2012 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 49D6121F85C3 for ; Mon, 6 Feb 2012 04:05:07 -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 WtBJgcmolBV0 for ; Mon, 6 Feb 2012 04:05:06 -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 E9B4D21F8611 for ; Mon, 6 Feb 2012 04:05:00 -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 q16C4i8V008766; Mon, 6 Feb 2012 13:04:44 +0100 (CET) Received: from [192.168.217.105] (p5489AA78.dip.t-dialin.net [84.137.170.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9E908C3E; Mon, 6 Feb 2012 13:04:44 +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: Mon, 6 Feb 2012 13:04:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0B4B352D-3D32-4305-872F-853F26F5EDF8@tzi.org> References: <674287D1-C99A-45EE-9969-D0B35160056B@yegin.org> <7D669CE5-0F33-4163-A43B-E05589BE9892@tzi.org> <3615F3CCD55F054395A882F51C6E5FDA1824457B@szxeml513-mbs.china.huawei.com> To: Alper Yegin X-Mailer: Apple Mail (2.1251.1) Cc: core WG Subject: Re: [core] Vendor-specific options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 12:05:07 -0000 On Feb 6, 2012, at 10:43, Alper Yegin wrote: > I don't understand how "doing it in CoAP payload" as stated above can = work. I'll let Linyi speak for himself, but I think there is one important = observation here. In protocols like DHCP, RADIUS etc. (and PANA!), if you want to do = something new, you need a new option/attribute/AVP/whatever. There is one main extension point, and all evolution has to go through = it. In HTTP and CoAP, most evolution is going on in the URIs and the = payloads. When you need new semantics for a transfer, often building the right = URIs into the server, and, possibly, defining a new media type, is all = you need. CoAP is just a transfer protocol, and this is the way to define new = semantics *of* the transfer. Only if you need new semantics *governing* a transfer, this is where you = need new options. So this is how I read "do it in the payload". Gr=FC=DFe, Carsten From tianlinyi@huawei.com Mon Feb 6 19:44:34 2012 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 28F5211E80BE for ; Mon, 6 Feb 2012 19:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.141 X-Spam-Level: X-Spam-Status: No, score=-5.141 tagged_above=-999 required=5 tests=[AWL=1.458, 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 p2SymdI7d7ms for ; Mon, 6 Feb 2012 19:44:33 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 82FF011E80D7 for ; Mon, 6 Feb 2012 19:44:33 -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 <0LZ000IWP7MBM4@szxga03-in.huawei.com> for core@ietf.org; Tue, 07 Feb 2012 11:42:11 +0800 (CST) Received: from szxrg01-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 <0LZ0007E47MBM2@szxga03-in.huawei.com> for core@ietf.org; Tue, 07 Feb 2012 11:42:11 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGS17094; Tue, 07 Feb 2012 11:42:10 +0800 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 07 Feb 2012 11:41:40 +0800 Received: from SZXEML513-MBS.china.huawei.com ([169.254.6.148]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Tue, 07 Feb 2012 11:42:45 +0800 Date: Tue, 07 Feb 2012 03:42:01 +0000 From: TianLinyi In-reply-to: <0B4B352D-3D32-4305-872F-853F26F5EDF8@tzi.org> X-Originating-IP: [10.70.109.51] To: Carsten Bormann , Alper Yegin Message-id: <3615F3CCD55F054395A882F51C6E5FDA18248DD9@szxeml513-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] Vendor-specific options Thread-index: AQHM1gaKGb+ebHmKeEWELKxIIY9l7pYSuQIAgABEAQCAAAvsAIAAzwVJgBtdgICAACd0gIABi7Dw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <674287D1-C99A-45EE-9969-D0B35160056B@yegin.org> <7D669CE5-0F33-4163-A43B-E05589BE9892@tzi.org> <3615F3CCD55F054395A882F51C6E5FDA1824457B@szxeml513-mbs.china.huawei.com> <0B4B352D-3D32-4305-872F-853F26F5EDF8@tzi.org> Cc: core WG Subject: Re: [core] Vendor-specific options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 03:44:34 -0000 Hi, All That's it. I agree with Carsten. Define a new media type is what I mean for= doing it in payload. Cheers, Linyi -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Monday, February 06, 2012 8:05 PM To: Alper Yegin Cc: TianLinyi; core WG Subject: Re: [core] Vendor-specific options On Feb 6, 2012, at 10:43, Alper Yegin wrote: > I don't understand how "doing it in CoAP payload" as stated above can wor= k. I'll let Linyi speak for himself, but I think there is one important observ= ation here. In protocols like DHCP, RADIUS etc. (and PANA!), if you want to do somethin= g new, you need a new option/attribute/AVP/whatever. There is one main extension point, and all evolution has to go through it. In HTTP and CoAP, most evolution is going on in the URIs and the payloads. When you need new semantics for a transfer, often building the right URIs i= nto the server, and, possibly, defining a new media type, is all you need. CoAP is just a transfer protocol, and this is the way to define new semanti= cs *of* the transfer. Only if you need new semantics *governing* a transfer, this is where you ne= ed new options. So this is how I read "do it in the payload". Gr=FC=DFe, Carsten From alper.yegin@yegin.org Wed Feb 8 02:25:14 2012 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 D746F21F8619 for ; Wed, 8 Feb 2012 02:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.483 X-Spam-Level: X-Spam-Status: No, score=-101.483 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_20=-0.74, 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 wB-2dbkkMwyd for ; Wed, 8 Feb 2012 02:25:14 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id D5D1321F861D for ; Wed, 8 Feb 2012 02:25:13 -0800 (PST) Received: from [192.168.2.3] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MLveu-1Rtyly1fMi-008HdZ; Wed, 08 Feb 2012 05:25:02 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <3615F3CCD55F054395A882F51C6E5FDA18248DD9@szxeml513-mbs.china.huawei.com> Date: Wed, 8 Feb 2012 12:24:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <674287D1-C99A-45EE-9969-D0B35160056B@yegin.org> <7D669CE5-0F33-4163-A43B-E05589BE9892@tzi.org> <3615F3CCD55F054395A882F51C6E5FDA1824457B@szxeml513-mbs.china.huawei.com> <0B4B352D-3D32-4305-872F-853F26F5EDF8@tzi.org> <3615F3CCD55F054395A882F51C6E5FDA18248DD9@szxeml513-mbs.china.huawei.com> To: TianLinyi , Carsten Bormann X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:DcRpnqAXlWvR2Nui/xgffjDpEchMSLGbnT3cDPQ7Lyv bai2AfL8PGEyckMaAHLMInCb6fPg/whDb/0aMyVLBx4f1CIl4h /fYks4D/B2KyU5itlc01dSSbrP7Mi6boAV9nRQA80Clgpbebox TNyvcVOwPnRl3UFUJtLWacBCDbBdYizlE4kLunqvef6a2EQzzi cqJf9hvFYpWc5lxMWzOILFcu46fYTH537uRTwTyUWwDyt7XLym KgrCSACEGtl2l1gtcbhU3QLQGBhV4RQRdOtE7D0vKUP6ghR2Za FFlyPk1SGT++9EzDHBl5gac7/ALt84zq8ST8Skl5qtM1qX1uWS B4F25HebG1HhcBz1MngoN7eGtaWw8z7+SBimjfDwMXTnBOYpYq ZTayduoAWnv9A== Cc: core WG Subject: Re: [core] Vendor-specific options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 10:25:15 -0000 Thank you Carsten, now I understand what Linyi meant. I see the extensibility in the URI/media type direction, but I still = think we need some leg room in the Options direction too.=20 My 0.02 cents. Alper On Feb 7, 2012, at 5:42 AM, TianLinyi wrote: > Hi, All >=20 > That's it. I agree with Carsten. Define a new media type is what I = mean for doing it in payload. >=20 > Cheers, > Linyi >=20 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org]=20 > Sent: Monday, February 06, 2012 8:05 PM > To: Alper Yegin > Cc: TianLinyi; core WG > Subject: Re: [core] Vendor-specific options >=20 > On Feb 6, 2012, at 10:43, Alper Yegin wrote: >=20 >> I don't understand how "doing it in CoAP payload" as stated above can = work. >=20 > I'll let Linyi speak for himself, but I think there is one important = observation here. >=20 > In protocols like DHCP, RADIUS etc. (and PANA!), if you want to do = something new, you need a new option/attribute/AVP/whatever. > There is one main extension point, and all evolution has to go through = it. >=20 > In HTTP and CoAP, most evolution is going on in the URIs and the = payloads. > When you need new semantics for a transfer, often building the right = URIs into the server, and, possibly, defining a new media type, is all = you need. > CoAP is just a transfer protocol, and this is the way to define new = semantics *of* the transfer. > Only if you need new semantics *governing* a transfer, this is where = you need new options. >=20 > So this is how I read "do it in the payload". >=20 > Gr=FC=DFe, Carsten >=20 From zach@sensinode.com Wed Feb 8 02:44:32 2012 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 8E41821F85F1 for ; Wed, 8 Feb 2012 02:44:32 -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 uGwCrQRciiy5 for ; Wed, 8 Feb 2012 02:44:31 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id DE48721F8623 for ; Wed, 8 Feb 2012 02:44:28 -0800 (PST) Received: from [192.168.0.81] (82-128-196-163.bb.dnainternet.fi [82.128.196.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q18AiJGW018101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Feb 2012 12:44:19 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: Date: Wed, 8 Feb 2012 12:44:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <674287D1-C99A-45EE-9969-D0B35160056B@yegin.org> <7D669CE5-0F33-4163-A43B-E05589BE9892@tzi.org> <3615F3CCD55F054395A882F51C6E5FDA1824457B@szxeml513-mbs.china.huawei.com> <0B4B352D-3D32-4305-872F-853F26F5EDF8@tzi.org> <3615F3CCD55F054395A882F51C6E5FDA18248DD9@szxeml513-mbs.china.huawei.com> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] Vendor-specific options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 10:44:32 -0000 I agree with Alper that there will be custom additions to CoAP needed in = the future that fit best in an extensible option (related to the CoAP = message or req/res level rather than the application). For application = related extensions then URIs and media types are fine. Should something like that be added to the base spec, I am not sure. If = we are not in a hurry for it, then a separate specification in the = future is fine. Zach On Feb 8, 2012, at 12:24 PM, Alper Yegin wrote: >=20 > Thank you Carsten, now I understand what Linyi meant. >=20 > I see the extensibility in the URI/media type direction, but I still = think we need some leg room in the Options direction too.=20 >=20 > My 0.02 cents. >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Feb 7, 2012, at 5:42 AM, TianLinyi wrote: >=20 >> Hi, All >>=20 >> That's it. I agree with Carsten. Define a new media type is what I = mean for doing it in payload. >>=20 >> Cheers, >> Linyi >>=20 >> -----Original Message----- >> From: Carsten Bormann [mailto:cabo@tzi.org]=20 >> Sent: Monday, February 06, 2012 8:05 PM >> To: Alper Yegin >> Cc: TianLinyi; core WG >> Subject: Re: [core] Vendor-specific options >>=20 >> On Feb 6, 2012, at 10:43, Alper Yegin wrote: >>=20 >>> I don't understand how "doing it in CoAP payload" as stated above = can work. >>=20 >> I'll let Linyi speak for himself, but I think there is one important = observation here. >>=20 >> In protocols like DHCP, RADIUS etc. (and PANA!), if you want to do = something new, you need a new option/attribute/AVP/whatever. >> There is one main extension point, and all evolution has to go = through it. >>=20 >> In HTTP and CoAP, most evolution is going on in the URIs and the = payloads. >> When you need new semantics for a transfer, often building the right = URIs into the server, and, possibly, defining a new media type, is all = you need. >> CoAP is just a transfer protocol, and this is the way to define new = semantics *of* the transfer. >> Only if you need new semantics *governing* a transfer, this is where = you need new options. >>=20 >> So this is how I read "do it in the payload". >>=20 >> Gr=FC=DFe, Carsten >>=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From cabo@tzi.org Wed Feb 8 03:51:11 2012 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 716D221F8606 for ; Wed, 8 Feb 2012 03:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.358 X-Spam-Level: X-Spam-Status: No, score=-106.358 tagged_above=-999 required=5 tests=[AWL=-0.109, 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 AEv5H6dQ4Kxm for ; Wed, 8 Feb 2012 03:51: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 E355321F85C3 for ; Wed, 8 Feb 2012 03:51:08 -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 q18BjPa1017337; Wed, 8 Feb 2012 12:45:25 +0100 (CET) Received: from [192.168.217.103] (p5489B3F1.dip.t-dialin.net [84.137.179.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3BC7AA52; Wed, 8 Feb 2012 12:45:25 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 8 Feb 2012 12:45:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4994B756-515A-4B50-8445-F4DBDBBE00EE@tzi.org> References: <674287D1-C99A-45EE-9969-D0B35160056B@yegin.org> <7D669CE5-0F33-4163-A43B-E05589BE9892@tzi.org> <3615F3CCD55F054395A882F51C6E5FDA1824457B@szxeml513-mbs.china.huawei.com> <0B4B352D-3D32-4305-872F-853F26F5EDF8@tzi.org> <3615F3CCD55F054395A882F51C6E5FDA18248DD9@szxeml513-mbs.china.huawei.com> To: Zach Shelby X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] Vendor-specific options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 11:51:11 -0000 On Feb 8, 2012, at 11:44, Zach Shelby wrote: > Should something like that be added to the base spec, I am not sure. = If we are not in a hurry for it, then a separate specification in the = future is fine. I think the interesting question is when are people going to need these, = and what is the danger that they will they go ahead and ship something = in a widely deployed product that will create a backwards compatibility = headache for us. Defining the vendor-specific option in the base spec would enable us to = make very clear that squatting is not the way to go (by demonstrating = the right way to go). Keeping the option definition in coap-misc works = for me, but has two disadvantages: 1) the details may not be vetted as well, possibly creating another = headache later, 2) people might not find it, and/or may think what is in the personal = draft is not relevant for "conformance". In any case, we need to agree on and reserve the option number (is 14 = it?), so we might as well standardize the option. So far, the only thing I know that might need some more thought here is = my "SDNV of enterprise ID" tagging proposal. Putting option 14 into the = base spec might get us some more input on that :-) Gr=FC=DFe, Carsten From tho@koanlogic.com Mon Feb 13 02:36:18 2012 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 B0B5721F8721 for ; Mon, 13 Feb 2012 02:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.919 X-Spam-Level: *** X-Spam-Status: No, score=3.919 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 R2-fvsvFFPbC for ; Mon, 13 Feb 2012 02:36:18 -0800 (PST) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 310EA21F8595 for ; Mon, 13 Feb 2012 02:36:17 -0800 (PST) Received: from host196-51-dynamic.47-79-r.retail.telecomitalia.it ([79.47.51.196]:61779 helo=t.homenet.telecomitalia.it) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RwtGI-0002uC-E9 for core@ietf.org; Mon, 13 Feb 2012 05:36:16 -0500 From: Thomas Fossati Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Feb 2012 11:35:24 +0100 Message-Id: To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.51.196 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] explicit observe de-registration X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 10:36:18 -0000 Wouldn't it be cleaner to have an explicit Observe de-registration = request from the observer to the subject ? It'd work with both CON and NON observations (instead of being CON-only = [*]) and would be more efficient with sleepy observers, avoiding all the = useless retransmission implied by an unreachable node that has entered = the sleep state. Thomas. [*] apropos, section 4.3 of coap-08 seems to imply that RST can be sent = in reply to a NON message, but then 4.4.4 associates RST to CON only = (consistently with the usage in current Observe I-D.). To add some more = entropy, the changelog says that 05->06 transition included an "Allowed = RST message in reply to a NON message with unexpected token", but I = can't see it anywhere in -08. =20 This all leaves some degree of ambiguity about whether RST is a valid = response to a NON message or not.= From tho@koanlogic.com Mon Feb 13 03:11:19 2012 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 3960821F867E for ; Mon, 13 Feb 2012 03:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.642 X-Spam-Level: *** X-Spam-Status: No, score=3.642 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_20=-0.74, 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 YpuvuWOYh1DL for ; Mon, 13 Feb 2012 03:11:18 -0800 (PST) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 99B4221F8647 for ; Mon, 13 Feb 2012 03:11:18 -0800 (PST) Received: from host196-51-dynamic.47-79-r.retail.telecomitalia.it ([79.47.51.196]:61998 helo=t.homenet.telecomitalia.it) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RwtoC-0002wG-Vw for core@ietf.org; Mon, 13 Feb 2012 06:11:17 -0500 From: Thomas Fossati Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Feb 2012 12:10:24 +0100 Message-Id: <51C939F8-1093-46B9-8955-1BB321733F09@koanlogic.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.51.196 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] Observe + ETag clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 11:11:19 -0000 Observe-03 I-D, last paragraph of section 3.3 says: "When the observed resource changes its state to a representation = identified by one of the ETag Options, the server can send a 2.03 = (Valid) notification instead of a 2.05 (Content) notification." I don't get the use case for this: how is the client expected to guess = in advance the ETag matching a future representation of the resource ? I'm probably reading this the wrong way :-)= From hartketzi@googlemail.com Mon Feb 13 11:15:51 2012 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 3124E21F86D8 for ; Mon, 13 Feb 2012 11:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjHUAadtb6g4 for ; Mon, 13 Feb 2012 11:15:50 -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 72DC521F8729 for ; Mon, 13 Feb 2012 11:15:50 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so5057455pbc.31 for ; Mon, 13 Feb 2012 11:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+akhrV+mO4yCUa2FBITgPhKqU0Ims0SnZ8o+Co1p314=; b=I37HA9iGcf689zWK9LUydQzfKtqLz1xPO44aSsxckcLnOfEzbqFgIMTodOqO6e1y2k YqxB3eXmjQUHwcrpKLGwv1VVEbKIRw1v7Kv8WPN23T9Pn9AwPRDd4zuN6PxJuBBPRB5B eiemJsE67GyBnDQ+jfcLBSvb8JR5g9CKmEJuY= MIME-Version: 1.0 Received: by 10.68.241.170 with SMTP id wj10mr49978665pbc.42.1329160550238; Mon, 13 Feb 2012 11:15:50 -0800 (PST) Sender: hartketzi@googlemail.com Received: by 10.68.213.7 with HTTP; Mon, 13 Feb 2012 11:15:50 -0800 (PST) In-Reply-To: <51C939F8-1093-46B9-8955-1BB321733F09@koanlogic.com> References: <51C939F8-1093-46B9-8955-1BB321733F09@koanlogic.com> Date: Mon, 13 Feb 2012 20:15:50 +0100 X-Google-Sender-Auth: Rl5gJrO69UnBNmzbCl8GCAcR9tA Message-ID: From: Klaus Hartke To: Thomas Fossati Content-Type: text/plain; charset=ISO-8859-1 Cc: core WG Subject: Re: [core] Observe + ETag clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:15:51 -0000 Thomas Fossati wrote: > Observe-03 I-D, last paragraph of section 3.3 says: > > "When the observed resource changes its state to a representation identified by one of the ETag Options, the server can send a 2.03 (Valid) notification instead of a 2.05 (Content) notification." > > I don't get the use case for this: how is the client expected to guess in advance the ETag matching a future representation of the resource ? A client can not guess future representations. But when it's observing a resource, it receives representations from the server and can keep a small set of them in its cache according to some cache algorithm (MRU, LFU, ...). It can submit the entity-tags of these representations to the server. Should the resource then change to one of these representations, the server can simply select it from the client's cache instead of sending a full response. Does that make sense to you? If you have any suggestion how to improve the text in section 3.3, please make it :-) Klaus From hartketzi@googlemail.com Mon Feb 13 11:23:00 2012 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 D903821F84E7 for ; Mon, 13 Feb 2012 11:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hHdpMoCB14i for ; Mon, 13 Feb 2012 11:22:57 -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 4ABC721F84F1 for ; Mon, 13 Feb 2012 11:22:55 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so5062976pbc.31 for ; Mon, 13 Feb 2012 11:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Uj7MOuDauKgb6/lvIqs6rvuFQQBZv3DQLWZZyzTrMBw=; b=sfW0Xollmam+W2aMYgpLUguTquJr7gHmApiJ9toQi9sc9Dr0HNyZZgczP2y/LsE3Ea NFHZ6KNxMNy/HcSY3qYDgdGmca8VjmAU94uNljLSqn/q8Qe2R0gvkF97SgVQ1oNoBd3t DN34T72BWRQ2L7Dno5iiCP3T0rBSm7mNBtobM= MIME-Version: 1.0 Received: by 10.68.218.167 with SMTP id ph7mr49942133pbc.110.1329160972134; Mon, 13 Feb 2012 11:22:52 -0800 (PST) Sender: hartketzi@googlemail.com Received: by 10.68.213.7 with HTTP; Mon, 13 Feb 2012 11:22:52 -0800 (PST) In-Reply-To: References: Date: Mon, 13 Feb 2012 20:22:52 +0100 X-Google-Sender-Auth: L4yopTdSI8jLXnZlU5MyraAHbrk Message-ID: From: Klaus Hartke To: Thomas Fossati Content-Type: text/plain; charset=ISO-8859-1 Cc: core WG Subject: Re: [core] explicit observe de-registration X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:23:01 -0000 Thomas Fossati wrote: > Wouldn't it be cleaner to have an explicit Observe de-registration request from the observer to the subject ? A client can send a GET request without Observe Option to get it removed from the list of observers; see section 4.1. Maybe some matching text should be added to section 3? Klaus From cabo@tzi.org Mon Feb 13 11:41:36 2012 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 793FF21E8018 for ; Mon, 13 Feb 2012 11:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.348 X-Spam-Level: X-Spam-Status: No, score=-106.348 tagged_above=-999 required=5 tests=[AWL=-0.099, 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 tIgTc+rWLGGt for ; Mon, 13 Feb 2012 11:41:36 -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 4247821E8010 for ; Mon, 13 Feb 2012 11:41: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 q1DJfQ6e001869; Mon, 13 Feb 2012 20:41:26 +0100 (CET) Received: from [192.168.217.103] (p5489BCF5.dip.t-dialin.net [84.137.188.245]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6DD7D3B7; Mon, 13 Feb 2012 20:41:26 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <51C939F8-1093-46B9-8955-1BB321733F09@koanlogic.com> Date: Mon, 13 Feb 2012 20:41:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0C13EDDE-4A87-4E9B-BE08-1FCC17E99B09@tzi.org> References: <51C939F8-1093-46B9-8955-1BB321733F09@koanlogic.com> To: Thomas Fossati X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] Observe + ETag clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:41:36 -0000 On Feb 13, 2012, at 12:10, Thomas Fossati wrote: > use case Adding to Klaus' explanation: Imaging observing the resource description (/.well-known/core) of a = device that actually loses and later again wins resources based on some = state (e.g., whether some part of it has been manually switched on or = off). If the client observes (English sense) that toggling, it might = offer both ETags, and the server will only need to 2.03 the right one. Yes, maybe a bit esoteric, but it comes for free with the caching model, = and you don't have to use it if it would create complexity in your = implementation. (Maybe this should be pointed out with an explicit = MAY, but then this already follows from the rest of the spec, so it is = not anything new.) Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Mon Feb 13 11:45:13 2012 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 2CB5121F85DD for ; Mon, 13 Feb 2012 11:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 150yJWMx4kcq for ; Mon, 13 Feb 2012 11:45:12 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB4121F855E for ; Mon, 13 Feb 2012 11:45:12 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rx1pW-0000yL-AA; Mon, 13 Feb 2012 14:44:54 -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: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 13 Feb 2012 19:44:54 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/183 Message-ID: <051.d737d9d709bad431585042b142a583f4@trac.tools.ietf.org> X-Trac-Ticket-ID: 183 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, 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 Resent-To: Resent-Message-Id: <20120213194512.9DB4121F855E@ietfa.amsl.com> Resent-Date: Mon, 13 Feb 2012 11:45:12 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #183: Check consistency of statements about RST on NON 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, 13 Feb 2012 19:45:13 -0000 #183: Check consistency of statements about RST on NON Thomas Fossati notes: apropos, section 4.3 of coap-08 seems to imply that RST can be sent in reply to a NON message, but then 4.4.4 associates RST to CON only (consistently with the usage in current Observe I-D.). To add some more entropy, the changelog says that 05->06 transition included an "Allowed RST message in reply to a NON message with unexpected token", but I can't see it anywhere in -08. This all leaves some degree of ambiguity about whether RST is a valid response to a NON message or not. _______________________________________________ -- --------------------------------+------------------------------------ Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: editorial | Status: new Priority: major | Milestone: Component: coap | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------ Ticket URL: core From hartketzi@googlemail.com Mon Feb 13 11:50:46 2012 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 812A821F8687 for ; Mon, 13 Feb 2012 11:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9V6NL8stBIDU for ; Mon, 13 Feb 2012 11:50:45 -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 C051621F8680 for ; Mon, 13 Feb 2012 11:50:44 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so5083504pbc.31 for ; Mon, 13 Feb 2012 11:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=fwRoNy/FN/ovLgROuyYOcucqgVbxyUc/YtW2cEUnknQ=; b=MexdjYj/LVvFJSFWkrBnk7rqDa8D8yFYP2+0A5ifNNCSCBNMLV5BMr6GKl/Pb4WmRF inzjR91MiHb50RwiRloBzE3cQRaW0/5olScZRZZPwNLv8s/pjADWqFN8CCFTP8vi/t0s w/Ln4coKSZnwB/6CHCfQFr93/aA86bW5Xnejw= MIME-Version: 1.0 Received: by 10.68.134.198 with SMTP id pm6mr50433258pbb.8.1329162644479; Mon, 13 Feb 2012 11:50:44 -0800 (PST) Sender: hartketzi@googlemail.com Received: by 10.68.213.7 with HTTP; Mon, 13 Feb 2012 11:50:44 -0800 (PST) In-Reply-To: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> References: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> Date: Mon, 13 Feb 2012 20:50:44 +0100 X-Google-Sender-Auth: bDD6bkgmg8wO7ki3IM_rfkLkGj0 Message-ID: From: Klaus Hartke To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] Moving Observe forward X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:50:46 -0000 Zach Shelby wrote: > Observe otherwise is in really good shape, and the WG seemed to think in Taipei that it would be ready for WGLC if this Max-OFE problem would be taken care of. Max-OFE was the wrong solution to the problem and needs to be disposed of. The question is: Is there is a problem that needs to be taken care of or not? If there is a problem, I believe the solution outlined by Carsten in ticket #174 is the right one. I'll submit a new revision of -observe soon with Max-OFE removed. Maybe we can gather some deployment experience in Paris that helps us answer the question. Klaus From cabo@tzi.org Mon Feb 13 11:58:51 2012 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 0BF6721F865B for ; Mon, 13 Feb 2012 11:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.344 X-Spam-Level: X-Spam-Status: No, score=-106.344 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 LOCxd8W4NfZs for ; Mon, 13 Feb 2012 11:58:50 -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 0410921F84C5 for ; Mon, 13 Feb 2012 11:58:49 -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 q1DJwhmL007785 for ; Mon, 13 Feb 2012 20:58:43 +0100 (CET) Received: from [192.168.217.103] (p5489BCF5.dip.t-dialin.net [84.137.188.245]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CEA023C7; Mon, 13 Feb 2012 20:58:42 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Mon, 13 Feb 2012 20:58:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <714C9080-16CA-46ED-9FCA-61280F7B9E97@tzi.org> References: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> To: Klaus Hartke X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org WG" Subject: Re: [core] Moving Observe forward X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:58:51 -0000 On Feb 13, 2012, at 20:50, Klaus Hartke wrote: > Zach Shelby wrote: >> Observe otherwise is in really good shape, and the WG seemed to think = in Taipei that it would be ready for WGLC if this Max-OFE problem would = be taken care of. >=20 > Max-OFE was the wrong solution to the problem and needs to be disposed > of. The question is: Is there is a problem that needs to be taken care > of or not? That question is easy to answer: Of course there is. The more interesting question is whether that problem and it solutions = are well-understood enough to build a solution in the base spec. Observe works fine for many applications without such a solution, and an = elective option that provides more efficiency for additional cases can = be added later. > If there is a problem, I believe the solution outlined by Carsten in > ticket #174 is the right one. I think so, too :-) > I'll submit a new revision of -observe soon with Max-OFE removed. I completely agree that this is the right way forward. > Maybe we can gather some deployment experience in Paris that helps us > answer the question. I could add #174 to coap-misc, so people who want to try it have some = spec to work from. Gr=FC=DFe, Carsten From stpeter@stpeter.im Mon Feb 13 12:04:36 2012 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 81EAE21F8693 for ; Mon, 13 Feb 2012 12:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 rMWOR26Rvcc1 for ; Mon, 13 Feb 2012 12:04:34 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 84C7B21F8686 for ; Mon, 13 Feb 2012 12:04:32 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 51BB940058; Mon, 13 Feb 2012 13:15:18 -0700 (MST) Message-ID: <4F396CCE.2060509@stpeter.im> Date: Mon, 13 Feb 2012 13:04:30 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Carsten Bormann References: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> <714C9080-16CA-46ED-9FCA-61280F7B9E97@tzi.org> In-Reply-To: <714C9080-16CA-46ED-9FCA-61280F7B9E97@tzi.org> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "core@ietf.org WG" , Klaus Hartke Subject: Re: [core] Moving Observe forward X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:04:37 -0000 On 2/13/12 12:58 PM, Carsten Bormann wrote: > On Feb 13, 2012, at 20:50, Klaus Hartke wrote: > >> Zach Shelby wrote: >>> Observe otherwise is in really good shape, and the WG seemed to think in Taipei that it would be ready for WGLC if this Max-OFE problem would be taken care of. >> >> Max-OFE was the wrong solution to the problem and needs to be disposed >> of. The question is: Is there is a problem that needs to be taken care >> of or not? > > That question is easy to answer: Of course there is. > The more interesting question is whether that problem and it solutions are well-understood enough to build a solution in the base spec. > Observe works fine for many applications without such a solution, and an elective option that provides more efficiency for additional cases can be added later. > >> If there is a problem, I believe the solution outlined by Carsten in >> ticket #174 is the right one. > > I think so, too :-) > >> I'll submit a new revision of -observe soon with Max-OFE removed. > > I completely agree that this is the right way forward. > >> Maybe we can gather some deployment experience in Paris that helps us >> answer the question. > > I could add #174 to coap-misc, so people who want to try it have some spec to work from. I agree that removing it from the base spec is the right path forward. Putting a proposed solution in coap-misc or a standalone spec seems like a good approach. Peter -- Peter Saint-Andre https://stpeter.im/ From tho@koanlogic.com Mon Feb 13 12:24:31 2012 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 B3F1D21F8778 for ; Mon, 13 Feb 2012 12:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.217 X-Spam-Level: ** X-Spam-Status: No, score=2.217 tagged_above=-999 required=5 tests=[AWL=0.712, 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 pntm7R01HDfx for ; Mon, 13 Feb 2012 12:24:31 -0800 (PST) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 40B5321F8776 for ; Mon, 13 Feb 2012 12:24:31 -0800 (PST) Received: from host196-51-dynamic.47-79-r.retail.telecomitalia.it ([79.47.51.196]:63619 helo=t.homenet.telecomitalia.it) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1Rx2Rj-0004PW-MU; Mon, 13 Feb 2012 15:24:30 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Mon, 13 Feb 2012 21:23:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <586F98C3-A96F-46A6-A29D-5B2B74B44A98@koanlogic.com> References: <51C939F8-1093-46B9-8955-1BB321733F09@koanlogic.com> To: Klaus Hartke X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.51.196 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 WG Subject: Re: [core] Observe + ETag clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:24:31 -0000 On Feb 13, 2012, at 8:15 PM, Klaus Hartke wrote: > Does that make sense to you? Well, it really depends on the nature of the representations' set = produced by the CoAP server for the observed resource: i.e. reps must be = fat enough, and cardinality of the set must be very low to really take = advantage of this mechanism. > If you have any suggestion how to improve > the text in section 3.3, please make it :-) A concrete use case -- something like the one cited by Carsten in this = same thread -- would perhaps aid the reader who lacks a bit of = imagination :-)= From tho@koanlogic.com Mon Feb 13 12:27:06 2012 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 2207921E801F for ; Mon, 13 Feb 2012 12:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.039 X-Spam-Level: ** X-Spam-Status: No, score=2.039 tagged_above=-999 required=5 tests=[AWL=0.534, 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 DXkoGWHifmYA for ; Mon, 13 Feb 2012 12:27:05 -0800 (PST) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id AB7C221E801A for ; Mon, 13 Feb 2012 12:27:05 -0800 (PST) Received: from host196-51-dynamic.47-79-r.retail.telecomitalia.it ([79.47.51.196]:63621 helo=t.homenet.telecomitalia.it) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1Rx2UC-0004QL-5J; Mon, 13 Feb 2012 15:27:02 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Mon, 13 Feb 2012 21:26:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <38963877-EDBC-4DC0-B1EE-8EB1F3569DD9@koanlogic.com> References: To: Klaus Hartke X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.51.196 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 WG Subject: Re: [core] explicit observe de-registration X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:27:06 -0000 On Feb 13, 2012, at 8:22 PM, Klaus Hartke wrote: > Thomas Fossati wrote: >> Wouldn't it be cleaner to have an explicit Observe de-registration = request from the observer to the subject ? >=20 > A client can send a GET request without Observe Option to get it > removed from the list of observers; see section 4.1. Great, you're right. > Maybe some matching text should be added to section 3? Thanks, that would help.= From hartketzi@googlemail.com Mon Feb 13 12:39:15 2012 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 6391921E801B for ; Mon, 13 Feb 2012 12:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 2f+GVjORs7PB for ; Mon, 13 Feb 2012 12:39:14 -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 6453C21E802E for ; Mon, 13 Feb 2012 12:39:14 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so5120433pbc.31 for ; Mon, 13 Feb 2012 12:39:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1clWkbq1XiwjjCIttfzCMw66U14S7hGS/+Z6xRIvO2M=; b=QxCk7sGRNMO0kw1wM72aeU9rEQG3LKgu4sOhDUyaPQ8m9MqlsE0tvTxkm2WjKpHdmr 0ofh/pqsmCdcTzBAM8ZZuCbDZNWJTlMj0eZuyOe/D7bv0rBn1N46Qx/u2RbvJJffUGz3 RdoUMCU/6UqvhpfLbZ+DLQkveDkmz9BPRyCl8= MIME-Version: 1.0 Received: by 10.68.191.165 with SMTP id gz5mr39876372pbc.59.1329165553179; Mon, 13 Feb 2012 12:39:13 -0800 (PST) Sender: hartketzi@googlemail.com Received: by 10.68.213.7 with HTTP; Mon, 13 Feb 2012 12:39:13 -0800 (PST) In-Reply-To: <38963877-EDBC-4DC0-B1EE-8EB1F3569DD9@koanlogic.com> References: <38963877-EDBC-4DC0-B1EE-8EB1F3569DD9@koanlogic.com> Date: Mon, 13 Feb 2012 21:39:13 +0100 X-Google-Sender-Auth: 9icjizags2mMfKTdhR6VH6ORKCM Message-ID: From: Klaus Hartke To: Thomas Fossati Content-Type: text/plain; charset=ISO-8859-1 Cc: core WG Subject: Re: [core] explicit observe de-registration X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:39:15 -0000 Thomas Fossati wrote: >> Maybe some matching text should be added to section 3? > > Thanks, that would help. Something like this? 3.5. Cancellation When a client rejects a notification (confirmable or non-confirmable) with a RST message or when it performs a GET request without an Observe Option for a resource, the server will remove the client from the list of observers. The client MAY use either action at any time to indicate that it's no longer interested in receiving notifications about the resource. Klaus From zach@sensinode.com Mon Feb 13 12:40:38 2012 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 BB98321E802A for ; Mon, 13 Feb 2012 12:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.604, 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 fl8S7eqtbic0 for ; Mon, 13 Feb 2012 12:40:38 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id C13FD21E801B for ; Mon, 13 Feb 2012 12:40:37 -0800 (PST) Received: from [192.168.1.103] (188-67-147-48.bb.dnainternet.fi [188.67.147.48]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q1DKeVw7032420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Feb 2012 22:40:33 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4F396CCE.2060509@stpeter.im> Date: Mon, 13 Feb 2012 22:40:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9317B1B1-275A-4FC5-9B61-16DDF238366D@sensinode.com> References: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> <714C9080-16CA-46ED-9FCA-61280F7B9E97@tzi.org> <4F396CCE.2060509@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) Cc: Klaus Hartke , "core@ietf.org WG" Subject: Re: [core] Moving Observe forward X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:40:38 -0000 On Feb 13, 2012, at 10:04 PM, Peter Saint-Andre wrote: >>> Maybe we can gather some deployment experience in Paris that helps = us >>> answer the question. >>=20 >> I could add #174 to coap-misc, so people who want to try it have some = spec to work from. >=20 > I agree that removing it from the base spec is the right path forward. > Putting a proposed solution in coap-misc or a standalone spec seems = like > a good approach. +1 --=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 tho@koanlogic.com Mon Feb 13 13:23:30 2012 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 5D3AD21E8038 for ; Mon, 13 Feb 2012 13:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.932 X-Spam-Level: * X-Spam-Status: No, score=1.932 tagged_above=-999 required=5 tests=[AWL=0.427, 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 5rOQHvvIPNgz for ; Mon, 13 Feb 2012 13:23:30 -0800 (PST) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id EAE5521E802A for ; Mon, 13 Feb 2012 13:23:29 -0800 (PST) Received: from host196-51-dynamic.47-79-r.retail.telecomitalia.it ([79.47.51.196]:63996 helo=t.homenet.telecomitalia.it) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1Rx3Mo-0004br-Sz; Mon, 13 Feb 2012 16:23:29 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Mon, 13 Feb 2012 22:22:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <38963877-EDBC-4DC0-B1EE-8EB1F3569DD9@koanlogic.com> To: Klaus Hartke X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.51.196 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 WG Subject: Re: [core] explicit observe de-registration X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 21:23:30 -0000 On Feb 13, 2012, at 9:39 PM, Klaus Hartke wrote: > Something like this? >=20 > 3.5. Cancellation >=20 > When a client rejects a notification (confirmable or = non-confirmable) > with a RST message or when it performs a GET request without an > Observe Option for a resource, the server will remove the client = from > the list of observers. The client MAY use either action at any time > to indicate that it's no longer interested in receiving = notifications > about the resource. >=20 I like the explicit subsection. One tiny adjustment: "[...] performs a GET request without an Observe Option to a currently = observed resource, the server will remove the client from the list of = observers for that resource. [...]" Admittedly an awful abuse of the "observ-" stem, but one that should = leave no residual ambiguity -- hopefully :-) Thank you very much.= From likepeng@huawei.com Mon Feb 13 16:54:08 2012 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 B20F421E8022 for ; Mon, 13 Feb 2012 16:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.309 X-Spam-Level: X-Spam-Status: No, score=-3.309 tagged_above=-999 required=5 tests=[AWL=-1.252, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 wZxKXGOZukmk for ; Mon, 13 Feb 2012 16:54:08 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id DD5D821E8010 for ; Mon, 13 Feb 2012 16:54:07 -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 <0LZC00HA2YI0PN@szxga05-in.huawei.com> for core@ietf.org; Tue, 14 Feb 2012 08:54:00 +0800 (CST) Received: from szxrg01-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 <0LZC001NAYI04B@szxga05-in.huawei.com> for core@ietf.org; Tue, 14 Feb 2012 08:54:00 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGU67121; Tue, 14 Feb 2012 08:53:59 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Feb 2012 08:53:53 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.127]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 14 Feb 2012 08:53:57 +0800 Date: Tue, 14 Feb 2012 00:53:57 +0000 From: Likepeng In-reply-to: <4F396CCE.2060509@stpeter.im> X-Originating-IP: [10.70.109.68] To: Peter Saint-Andre , Carsten Bormann Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2017F6DEC@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [core] Moving Observe forward Thread-index: AQHM6ojOgnqHjYz36kG9m6TtoCdB/JY6uJcAgAABnwCAANazcA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> <714C9080-16CA-46ED-9FCA-61280F7B9E97@tzi.org> <4F396CCE.2060509@stpeter.im> Cc: Klaus Hartke , "core@ietf.org WG" Subject: Re: [core] Moving Observe forward 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, 14 Feb 2012 00:54:08 -0000 SGksDQoNCj4gUHV0dGluZyBhIHByb3Bvc2VkIHNvbHV0aW9uIGluIGNvYXAtbWlzYyBvciBhIHN0 YW5kYWxvbmUgc3BlYyBzZWVtcyBsaWtlIGEgZ29vZCBhcHByb2FjaC4NCg0KQSBzZXBhcmF0ZSBk cmFmdCB3aWxsIGJlIHN1Ym1pdHRlZCBzb29uIChhIGZldyBkYXlzKS4NCg0KU2FsdmF0b3JlLCBF c2tvIGFuZCBtZSBhcmUgd29ya2luZyBvbiBhIFBhdGllbmNlIG9wdGlvbiBkcmFmdC4gDQoNCkl0 IGNvdmVycyB0aGlzIGlzc3VlICh0aWNrZXQgMTc0KS4NCg0KVGhhbmtzLA0KS2luZCBSZWdhcmRz DQpLZXBlbmcNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBjb3JlLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUGV0ZXIgU2FpbnQtQW5kcmUN Creiy83KsbzkOiAyMDEyxOoy1MIxNMjVIDQ6MDUNCsrVvP7IyzogQ2Fyc3RlbiBCb3JtYW5uDQqz rcvNOiBjb3JlQGlldGYub3JnIFdHOyBLbGF1cyBIYXJ0a2UNCtb3zOI6IFJlOiBbY29yZV0gTW92 aW5nIE9ic2VydmUgZm9yd2FyZA0KDQo8aGF0IHR5cGU9J2luZGl2aWR1YWwnLz4NCg0KSSBhZ3Jl ZSB0aGF0IHJlbW92aW5nIGl0IGZyb20gdGhlIGJhc2Ugc3BlYyBpcyB0aGUgcmlnaHQgcGF0aCBm b3J3YXJkLg0KUHV0dGluZyBhIHByb3Bvc2VkIHNvbHV0aW9uIGluIGNvYXAtbWlzYyBvciBhIHN0 YW5kYWxvbmUgc3BlYyBzZWVtcyBsaWtlDQphIGdvb2QgYXBwcm9hY2guDQoNClBldGVyDQoNCi0t IA0KUGV0ZXIgU2FpbnQtQW5kcmUNCmh0dHBzOi8vc3RwZXRlci5pbS8NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpj b3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUN Cg== From gilger@umic.rwth-aachen.de Tue Feb 14 03:49:03 2012 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 6FF6221F8639 for ; Tue, 14 Feb 2012 03:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_REPLY_C=2.012, FUZZY_VLIUM=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 UIQsE3B0LsCg for ; Tue, 14 Feb 2012 03:49:02 -0800 (PST) Received: from avalon.gnuzifer.de (avalon.gnuzifer.de [IPv6:2a01:4f8:121:43c1::a2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 7634C21F85E5 for ; Tue, 14 Feb 2012 03:49:02 -0800 (PST) Received: from [137.226.161.159] (port=49355 helo=localhost) by avalon.gnuzifer.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1RxGsW-0003tw-JW for core@ietf.org; Tue, 14 Feb 2012 12:49:00 +0100 Date: Tue, 14 Feb 2012 12:49:04 +0100 From: Johannes Gilger To: "core@ietf.org WG" Message-ID: <20120214114904.GA8794@blackbox> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <999913AB42CC9341B05A99BBF358718DE7C529@FIESEXC035.nsn-intra.net> <06384DD1-323F-49A4-8D83-2D88F91D666A@yegin.org> <999913AB42CC9341B05A99BBF358718DE7C0AA@FIESEXC035.nsn-intra.net> <0E08042A-74F3-452A-B255-E5B654C01283@yegin.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 137.226.161.159 X-SA-Exim-Mail-From: gilger@umic.rwth-aachen.de 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, 14 Feb 2012 11:49:03 -0000 Hi everyone, I'm fairly new to this list, so bear with me if I miss the more subtle points of IoT security provisioning or topics you might have discussed outside the mailinglist. On 17/11/11 17: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? In my understanding of the functionality of an interface-constrained IoT device, there is no need for the node to identify the network. In fact, there is no meaning behind any identity as far as the node is concerned. The only thing that matters is that the network can identify the node (as has been discussed) and that the network can ensure that it is the only one able to command the node. This goes beyond what has been discussed here, and I may be outside the topic, but it all boils down to the Resurrecting Duckling model [1]. On 20/12/11 12:33, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > 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. [...] > 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. [...] > 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. That is one large problem, if we assume to have no trusted platform on board. A lot of the things I came up with when looking at IoT security bootstrapping rely on having a secure chip, at least when interface-constrained (no display) publicly accessible devices are concerned. If we have *no* trusted platform, we can not really generate the key in advance and print/etch it on the box, as anyone could clone our keypair. Keep in mind that the printing / reading is an out-of-band channel. So now we have to generate our own keypair, which has to happen on the node itself, since we do not have any interfaces. After the key has been generated, the node has to transfer the public key to us, using the wireless link. If we consider devices completely void of any other interface, there simply is no secure channel to communicate the device's public key to us. I think that if we want to be on the safe side, there are two options: - A trusted platform with an ECC-keypair which is used as a CGA and printed on the case of the device or etched on the chip. - Some kind of tamper-evident out-of-band channel, even if its just an LED. It just needs integrity, not confidentiality. Of course, with the first option, the manufacturer has to get the freshly generated ECC pubkey from the device as well, just like the user. This is where I trust that it's easier for a large company to build an actual Faraday cage to ensure no interference than it is for people employing the technology. I could go on and talk about how one might need the printed CGA to be tamper-evident as well, but its obvious that there are many attack scenarios and possible mitigations. On 21/12/11 11:29, Alper Yegin wrote: > 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. Why not? Looking at the Resurrecting Duckling again, the device will talk to anyone when its in the "imprintable" state. After it has been imprinted by an authority (hopefully the right one, or you'll have to reset the device and try again), it will identify the network as the party which holds the newly agreed symmetric key. > How do we introduce the ACL into such devices? There's gotta be an > interface for that. The ACL is this: - The symmetric key agreed with the first party to start imprinting has all the authority. - The authority can add and modify the ACL (using in-band messages). > 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?) See above. After asymmetric crypto was used to establish a symmetric key (using DTLS with ECDHE_ECDSA), the symmetric key will be used and the asymmetric key will only be needed again if the device is reset. On 22/12/11 10:02, Alper Yegin wrote: > 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. I think this is what we should be talking about, in this or another thread. These are my thoughts, would like to hear what you guys think, Jojo [1] - http://www.cl.cam.ac.uk/~fms27/duckling/ -- Dipl.-Inform. Johannes Gilger Research Group IT-Security UMIC Research Centre RWTH Aachen University Mies-van-der-Rohe-Straße 15 52074 Aachen Office: 211 Phone: +49 241 80 20781 Fax: +49 241 80 22731 http://itsec.rwth-aachen.de From rstruik.ext@gmail.com Tue Feb 14 06:38:09 2012 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 8268721F8691 for ; Tue, 14 Feb 2012 06:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[AWL=0.448, 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 NhqFQY8dMVoD for ; Tue, 14 Feb 2012 06:38:05 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 85C5C21F855D for ; Tue, 14 Feb 2012 06:38:05 -0800 (PST) Received: by obbwd15 with SMTP id wd15so22602obb.31 for ; Tue, 14 Feb 2012 06:38:05 -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:x-forwarded-message-id:content-type :content-transfer-encoding; bh=uZgkvUBNcKW99Z8kTexlmaJK/EwblbYeL6fQ7Hfl7+Y=; b=TiV9RRkJfO8HiftniM33Wh/goc+tRnSGqxkXlS2H+TRmK/HqzrDeKEhrlWvcNM/wb+ KgVt7gtPOCaj0xvsonXF5DC69b3/20yEOPxupyhC3ajEjeseMAno49Tt/2ACZvqKrVp/ tQAFk8JoLjh0Hmly+IE0dXKPwDT2kyCPq9fnY= Received: by 10.50.161.231 with SMTP id xv7mr20080081igb.0.1329230285062; Tue, 14 Feb 2012 06:38:05 -0800 (PST) Received: from [192.168.1.101] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [173.34.96.176]) by mx.google.com with ESMTPS id 5sm35069226ibe.8.2012.02.14.06.38.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Feb 2012 06:38:04 -0800 (PST) Message-ID: <4F3A71C8.6020104@gmail.com> Date: Tue, 14 Feb 2012 09:38:00 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: core References: <4F3A716D.8000003@gmail.com> In-Reply-To: <4F3A716D.8000003@gmail.com> X-Enigmail-Version: 1.3.5 X-Forwarded-Message-Id: <4F3A716D.8000003@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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, 14 Feb 2012 14:38:09 -0000 Hi Johannes: There are some deployment scenarios on some (very) old slides of mine, from IETF-77, March 2010, that may be of interest: http://www.ietf.org/proceedings/77/slides/core-1.pdf Those example deployment scenarios have been harvested from users in the process control, HVAC, etc. communities. Some comments below. Best regards, Rene On 14/02/2012 6:49 AM, Johannes Gilger wrote: > Hi everyone, > > I'm fairly new to this list, so bear with me if I miss the more subtle > points of IoT security provisioning or topics you might have discussed > outside the mailinglist. > > On 17/11/11 17: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? > In my understanding of the functionality of an interface-constrained IoT > device, there is no need for the node to identify the network. In fact, > there is no meaning behind any identity as far as the node is concerned. > > The only thing that matters is that the network can identify the node > (as has been discussed) and that the network can ensure that it is the > only one able to command the node. This goes beyond what has been > discussed here, and I may be outside the topic, but it all boils down to > the Resurrecting Duckling model [1]. RS>> This is correct in the more limited model of the resurrecting duckling policy framework by Ross Anderson et al. However, this disregards that a device may be in a sequence of networks, where it remembers state transitioning from one to the next. As an example, one may have the following: a) device is "bare", without knowledge of the world; b) device gets imprinted by whatever first device communicates with it (resurrecting duckling). This results in the Id of the "imprinting"/configuring device to be stored with the device and, from now on, that device being the only one allowed to change its state; c) device gets some other parms from configuring device, including Id of network device (the one it is supposed to synch-up with). This would result in it having an arbitration mechanism to identify the network itself. d) configuration device may now imprint other parms, hand-over control to other configuration device (new mother duck, so to speak), etc. e) device joins network and has sufficient parms to not only authenticate another device, but also filter according to policies (since it has been set up with policies as part of configuration). [...] < > On 20/12/11 12:33, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> 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. > [...] >> 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. > [...] >> 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. > That is one large problem, if we assume to have no trusted platform on > board. A lot of the things I came up with when looking at IoT security > bootstrapping rely on having a secure chip, at least when > interface-constrained (no display) publicly accessible devices are > concerned. > > If we have *no* trusted platform, we can not really generate the key in > advance and print/etch it on the box, as anyone could clone our keypair. > Keep in mind that the printing / reading is an out-of-band channel. RS>> Longer term, one cannot assume every device to have a trusted platform on board. The best one can hope for is tamper evidencing mechanisms, either on the device itself (e.g., PUF technology) or by exploiting network-based polling techniques (I could elaborate on the latter more separately). < So now we have to generate our own keypair, which has to happen on the > node itself, since we do not have any interfaces. After the key has been > generated, the node has to transfer the public key to us, using the > wireless link. If we consider devices completely void of any other > interface, there simply is no secure channel to communicate the device's > public key to us. > > I think that if we want to be on the safe side, there are two options: > > - A trusted platform with an ECC-keypair which is used as a CGA and > printed on the case of the device or etched on the chip. > - Some kind of tamper-evident out-of-band channel, even if its just an > LED. It just needs integrity, not confidentiality. > > Of course, with the first option, the manufacturer has to get the > freshly generated ECC pubkey from the device as well, just like the > user. This is where I trust that it's easier for a large company to > build an actual Faraday cage to ensure no interference than it is for > people employing the technology. RS>> If public-key based, this is RA (Registration Authority) functionality and does not require a Faraday cage, just authenticity. < I could go on and talk about how one might need the printed CGA to be > tamper-evident as well, but its obvious that there are many attack > scenarios and possible mitigations. > > On 21/12/11 11:29, Alper Yegin wrote: >> 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. > Why not? Looking at the Resurrecting Duckling again, the device will > talk to anyone when its in the "imprintable" state. After it has been > imprinted by an authority (hopefully the right one, or you'll have to > reset the device and try again), it will identify the network as the > party which holds the newly agreed symmetric key. RS>> Once again, fine if one only has "one configuration stage", but discards multiple (re)configuration processes along the device's lifetime. <> How do we introduce the ACL into such devices? There's gotta be an >> interface for that. > The ACL is this: > - The symmetric key agreed with the first party to start imprinting has > all the authority. > - The authority can add and modify the ACL (using in-band messages). RS>> Or some other authority designated via policy configuration could do this... <> 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?) > See above. After asymmetric crypto was used to establish a symmetric key > (using DTLS with ECDHE_ECDSA), the symmetric key will be used and the > asymmetric key will only be needed again if the device is reset. RS>> Main missing part in lots of discussion is not the crypto part, but the policy part (authorization vs. authentication, etc.). Just sprinkling in ephemeral Diffie-Hellman with ECDSA (expensive btw - there are far more efficient solutions) is not sufficient, since it only addresses authentication, not authorization issues. < On 22/12/11 10:02, Alper Yegin wrote: >> 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. RS>> One interface that is not used sufficiently yet is the in-band one, by just using the communication channel itself to communicate policy management messages. Of course, this does require language constructs, frame structures, state machines, and the-like. Using this in-band channel and a time-based trigger by itself together go a long way. < I think this is what we should be talking about, in this or another > thread. > > These are my thoughts, > would like to hear what you guys think, > Jojo > > > [1] - http://www.cl.cam.ac.uk/~fms27/duckling/ > > -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From hannes.tschofenig@gmx.net Tue Feb 14 07:49:23 2012 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 D3DE621F8729 for ; Tue, 14 Feb 2012 07:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 no+vUeOax9A3 for ; Tue, 14 Feb 2012 07:49:19 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4390521F872B for ; Tue, 14 Feb 2012 07:49:19 -0800 (PST) Received: (qmail invoked by alias); 14 Feb 2012 15:49:17 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp040) with SMTP; 14 Feb 2012 16:49:17 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18/0pkVQDY/2kUxqafrflouRaKgRnJ0sdKVig3tt4 tucmFcl/K/Yi7I Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: <20120214114904.GA8794@blackbox> Date: Tue, 14 Feb 2012 17:49:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <923FF538-3D68-4317-9832-D0B2454B3C82@gmx.net> References: <20120214114904.GA8794@blackbox> To: Johannes Gilger X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "core@ietf.org 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, 14 Feb 2012 15:49:24 -0000 Hi Johannes,=20 thanks for you thoughtful comments; a few remarks inline.=20 On Feb 14, 2012, at 1:49 PM, Johannes Gilger wrote: > Hi everyone, >=20 > I'm fairly new to this list, so bear with me if I miss the more subtle > points of IoT security provisioning or topics you might have discussed > outside the mailinglist. >=20 > On 17/11/11 17: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? >=20 > In my understanding of the functionality of an interface-constrained = IoT What do you mean by "interface-constrained"?=20 > device, there is no need for the node to identify the network. In = fact, > there is no meaning behind any identity as far as the node is = concerned. It depends on your threat model.=20 Think about an application where you want to make sure that your video = surveillance recording goes to the right server.=20 >=20 > The only thing that matters is that the network can identify the node > (as has been discussed) It again depends what your threat scenario is.=20 If your network is access controlled (like many enterprise networks) or = the operator of the network charges you for using the network then they = definitely want to authenticate someone (typically the subscriber of the = service).=20 In some other cases this may not be a concern at all. There may be no = need for network access authentication. We don't authenticate to many = WiFi networks because they are wide open.=20 > and that the network can ensure that it is the > only one able to command the node. This goes beyond what has been > discussed here, and I may be outside the topic, but it all boils down = to > the Resurrecting Duckling model [1]. >=20 >=20 > On 20/12/11 12:33, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> 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 >> 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 >> 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 There are certainly different threat scenarios that get raised here. In = the previous discussion there seems to be a worry that devices get = cloned (including their key). As a result, you may end up with two = temperature sensors in your home who both use the same public/private = key pair, which may be confusing.=20 Then, there is the possibility that sensors get tampered with (after = they have been put in service). =20 In both cases you typically need physical access to the device.=20 So, depending on your assumptions and your usage scenario some of the = solutions work or do not work.=20 > That is one large problem, if we assume to have no trusted platform on > board. A lot of the things I came up with when looking at IoT security > bootstrapping rely on having a secure chip, at least when > interface-constrained (no display) publicly accessible devices are > concerned. >=20 > If we have *no* trusted platform, we can not really generate the key = in > advance and print/etch it on the box, as anyone could clone our = keypair. > Keep in mind that the printing / reading is an out-of-band channel.=20 >=20 > So now we have to generate our own keypair, which has to happen on the > node itself, since we do not have any interfaces. After the key has = been > generated, the node has to transfer the public key to us, using the > wireless link. If we consider devices completely void of any other > interface, there simply is no secure channel to communicate the = device's > public key to us. >=20 > I think that if we want to be on the safe side, there are two options: >=20 > - A trusted platform with an ECC-keypair which is used as a CGA and > printed on the case of the device or etched on the chip. > - Some kind of tamper-evident out-of-band channel, even if its just an > LED. It just needs integrity, not confidentiality. >=20 > Of course, with the first option, the manufacturer has to get the > freshly generated ECC pubkey from the device as well, just like the > user. This is where I trust that it's easier for a large company to > build an actual Faraday cage to ensure no interference than it is for > people employing the technology. >=20 > I could go on and talk about how one might need the printed CGA to be > tamper-evident as well, but its obvious that there are many attack > scenarios and possible mitigations. >=20 > On 21/12/11 11:29, Alper Yegin wrote: >> 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 >> 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 >=20 > Why not? Looking at the Resurrecting Duckling again, the device will > talk to anyone when its in the "imprintable" state. After it has been > imprinted by an authority (hopefully the right one, or you'll have to > reset the device and try again), it will identify the network as the > party which holds the newly agreed symmetric key. >=20 >> How do we introduce the ACL into such devices? There's gotta be an >> interface for that. >=20 > The ACL is this: > - The symmetric key agreed with the first party to start imprinting = has > all the authority. > - The authority can add and modify the ACL (using in-band messages). For many devices this may be a perfectly fine approach and it is used in = today's appliances.=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 > See above. After asymmetric crypto was used to establish a symmetric = key > (using DTLS with ECDHE_ECDSA), the symmetric key will be used and the > asymmetric key will only be needed again if the device is reset. I also see no problem with using symmetric keys in some scenarios.=20 >=20 > On 22/12/11 10:02, Alper Yegin wrote: >> 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. >=20 > I think this is what we should be talking about, in this or another > thread. >=20 > These are my thoughts, > would like to hear what you guys think, > Jojo >=20 >=20 Ciao Hannes > [1] - http://www.cl.cam.ac.uk/~fms27/duckling/ >=20 >=20 > --=20 > Dipl.-Inform. Johannes Gilger > Research Group IT-Security > UMIC Research Centre > RWTH Aachen University > Mies-van-der-Rohe-Stra=DFe 15 > 52074 Aachen >=20 > Office: 211 > Phone: +49 241 80 20781 > Fax: +49 241 80 22731 >=20 > http://itsec.rwth-aachen.de > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From trac+core@trac.tools.ietf.org Tue Feb 14 10:58:00 2012 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 9E0A021F852E for ; Tue, 14 Feb 2012 10:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 CfRctIT2zTMr for ; Tue, 14 Feb 2012 10:58:00 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 202A521F84F2 for ; Tue, 14 Feb 2012 10:57:59 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RxNZc-0001MQ-Vw; Tue, 14 Feb 2012 13:57:57 -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: Tue, 14 Feb 2012 18:57:56 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/97#comment:1 Message-ID: <072.83f6eefacdac27148ba6c25300b11699@trac.tools.ietf.org> References: <057.bd6d30b6b3a5322781daa75dcc03ba9c@trac.tools.ietf.org> X-Trac-Ticket-ID: 97 In-Reply-To: <057.bd6d30b6b3a5322781daa75dcc03ba9c@trac.tools.ietf.org> 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: Re: [core] #97: IANA related review mails to be sent 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: Tue, 14 Feb 2012 18:58:00 -0000 #97: IANA related review mails to be sent Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done. -- -------------------------+--------------------- Reporter: zach@… | Owner: zach@… Type: task | Status: closed Priority: minor | Milestone: Component: link-format | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+--------------------- Ticket URL: core From cabo@tzi.org Tue Feb 14 11:44:15 2012 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 A2DF621F84E2 for ; Tue, 14 Feb 2012 11:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.111 X-Spam-Level: X-Spam-Status: No, score=-105.111 tagged_above=-999 required=5 tests=[AWL=-1.312, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_CHARSET_FARAWAY=2.45, 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 1H6voFyh2Pjr for ; Tue, 14 Feb 2012 11:44: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 D59C121F84D7 for ; Tue, 14 Feb 2012 11:44: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 q1EJhVNm022169; Tue, 14 Feb 2012 20:43:31 +0100 (CET) Received: from [192.168.217.105] (p5489B56B.dip.t-dialin.net [84.137.181.107]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C7C2FA82; Tue, 14 Feb 2012 20:43:30 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=gb18030 From: Carsten Bormann In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F2017F6DEC@szxeml525-mbs.china.huawei.com> Date: Tue, 14 Feb 2012 20:43:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3AB8F20C-ACC3-42ED-8118-83A06BAF98CF@tzi.org> References: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> <714C9080-16CA-46ED-9FCA-61280F7B9E97@tzi.org> <4F396CCE.2060509@stpeter.im> <34966E97BE8AD64EAE9D3D6E4DEE36F2017F6DEC@szxeml525-mbs.china.huawei.com> To: Likepeng X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org WG" , Klaus Hartke Subject: Re: [core] Moving Observe forward 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, 14 Feb 2012 19:44:15 -0000 On Feb 14, 2012, at 01:53, Likepeng wrote: >> Putting a proposed solution in coap-misc or a standalone spec seems = like a good approach. >=20 > A separate draft will be submitted soon (a few days). >=20 > Salvatore, Esko and me are working on a Patience option draft.=20 >=20 > It covers this issue (ticket 174). Great! While we are waiting for that, section 6 of draft-ietf-coap-misc-11 = contains a more detailed write-up of my own simplistic view of the = interaction timings: 6. Patience, Leisure, and Pledge I'm optimistic it can be made as simple as that, but I'm looking forward = to your more detailed considerations. Gr=A8=B9=810=898e, Carsten From internet-drafts@ietf.org Tue Feb 14 11:56:06 2012 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 1F97921E80B9; Tue, 14 Feb 2012 11:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 Rxi8B3BAOZhC; Tue, 14 Feb 2012 11:56:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F079721F85F0; Tue, 14 Feb 2012 11:56:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120214195601.1075.39709.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2012 11:56:01 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-observe-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 19:56:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Work= ing Group of the IETF. Title : Observing Resources in CoAP Author(s) : Klaus Hartke Filename : draft-ietf-core-observe-04.txt Pages : 25 Date : 2012-02-14 CoAP is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that gives clients the ability to observe such changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-observe-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-observe-04.txt From cabo@tzi.org Tue Feb 14 12:20:47 2012 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 58A6A21E8106 for ; Tue, 14 Feb 2012 12:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.286 X-Spam-Level: X-Spam-Status: No, score=-106.286 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 pUN4XJKg8vNC for ; Tue, 14 Feb 2012 12:20: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 C687721E807A for ; Tue, 14 Feb 2012 12:20:42 -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 q1EKKYdL011511 for ; Tue, 14 Feb 2012 21:20:34 +0100 (CET) Received: from [192.168.217.105] (p5489B56B.dip.t-dialin.net [84.137.181.107]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0FE4DA91; Tue, 14 Feb 2012 21:20:33 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Feb 2012 21:20:32 +0100 To: "core@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [core] link-format submitted to IESG 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, 14 Feb 2012 20:20:47 -0000 link-format passed WGLC a while ago and has had its last nits resolved = on January 30. I have today submitted link-format for publication as a Proposed = Standard to the IESG. Please observe (pun intended) = http://datatracker.ietf.org/doc/draft-ietf-core-link-format/history/ if you are interested in the process. (I'm afraid we don't have feed = links on these pages yet.) This could become our first RFC, with more = soon to follow. Gr=FC=DFe, Carsten PS.: with chair hat taken off: While we are waiting for this to progress, you might want to keep = yourself amused with http://tools.ietf.org/html/draft-bormann-core-links-json From iesg-secretary@ietf.org Tue Feb 14 12:30:04 2012 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 37F0521E80C0; Tue, 14 Feb 2012 12:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 z9rdGZ9Ae367; Tue, 14 Feb 2012 12:30:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F84221E80C6; Tue, 14 Feb 2012 12:30:02 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120214203002.12230.28473.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2012 12:30:02 -0800 Cc: core@ietf.org Subject: [core] Last Call: (CoRE Link Format) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@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: Tue, 14 Feb 2012 20:30:04 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'CoRE Link Format' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes and other relationships between links. Based on the HTTP Link Header format defined in RFC5988, the CoRE Link Format is carried as a payload and is assigned an Internet media type. A well- known URI is defined as a default entry-point for requesting the links hosted by a server. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-core-link-format/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-core-link-format/ No IPR declarations have been submitted directly on this I-D. From salvatore.loreto@ericsson.com Wed Feb 15 00:13:33 2012 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 ABAD521F855F for ; Wed, 15 Feb 2012 00:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.234 X-Spam-Level: X-Spam-Status: No, score=-109.234 tagged_above=-999 required=5 tests=[AWL=1.365, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Q9Vgd2q7M+gf for ; Wed, 15 Feb 2012 00:13:32 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E797621F8573 for ; Wed, 15 Feb 2012 00:13:30 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-62-4f3b69291ded Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DA.ED.27041.9296B3F4; Wed, 15 Feb 2012 09:13:29 +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.213.0; Wed, 15 Feb 2012 09:13:28 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 27C7A22EF for ; Wed, 15 Feb 2012 10:13:28 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 161095212E for ; Wed, 15 Feb 2012 10:13:28 +0200 (EET) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C6B8352109 for ; Wed, 15 Feb 2012 10:13:27 +0200 (EET) Message-ID: <4F3B6927.1060908@ericsson.com> Date: Wed, 15 Feb 2012 10:13:27 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: core@ietf.org References: <3668B6BA-3364-4496-B001-9A172EDE05B7@sensinode.com> <714C9080-16CA-46ED-9FCA-61280F7B9E97@tzi.org> <4F396CCE.2060509@stpeter.im> <9317B1B1-275A-4FC5-9B61-16DDF238366D@sensinode.com> In-Reply-To: <9317B1B1-275A-4FC5-9B61-16DDF238366D@sensinode.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] Moving Observe forward X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 08:13:33 -0000 On 2/13/12 10:40 PM, Zach Shelby wrote: > On Feb 13, 2012, at 10:04 PM, Peter Saint-Andre wrote: > >>>> Maybe we can gather some deployment experience in Paris that helps us >>>> answer the question. >>> I could add #174 to coap-misc, so people who want to try it have some spec to work from. >> I agree that removing it from the base spec is the right path forward. >> Putting a proposed solution in coap-misc or a standalone spec seems like >> a good approach. > +1 > +1 on removing Max-OFE from the Observe draft From salvatore.loreto@ericsson.com Wed Feb 15 00:27:01 2012 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 362C021F8584 for ; Wed, 15 Feb 2012 00:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.298 X-Spam-Level: X-Spam-Status: No, score=-109.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 FGi0RzIrSJHc for ; Wed, 15 Feb 2012 00:27:00 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id F113121F853B for ; Wed, 15 Feb 2012 00:26:59 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-54-4f3b6c52963e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 28.41.27041.25C6B3F4; Wed, 15 Feb 2012 09:26:59 +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.213.0; Wed, 15 Feb 2012 09:26:59 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A483022EF for ; Wed, 15 Feb 2012 10:26:58 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 92A2D5212E for ; Wed, 15 Feb 2012 10:26:58 +0200 (EET) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 50BE852109 for ; Wed, 15 Feb 2012 10:26:58 +0200 (EET) Message-ID: <4F3B6C52.2080505@ericsson.com> Date: Wed, 15 Feb 2012 10:26:58 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: core@ietf.org References: <38963877-EDBC-4DC0-B1EE-8EB1F3569DD9@koanlogic.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090409060501040406010001" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] explicit observe de-registration X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 08:27:01 -0000 --------------090409060501040406010001 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 2/13/12 10:39 PM, Klaus Hartke wrote: > Thomas Fossati wrote: >>> Maybe some matching text should be added to section 3? >> Thanks, that would help. > Something like this? > > 3.5. Cancellation > > When a client rejects a notification (confirmable or non-confirmable) > with a RST message or when it performs a GET request without an > Observe Option for a resource, the server will remove the client from > the list of observers. The client MAY use either action at any time > to indicate that it's no longer interested in receiving notifications > about the resource. > > Klaus > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core Hi there, I like the proposal, however I think that we should really clarify if RTS works also non-confirmable msg or not. The MUST in Section 4.4.4 of core-coap draft seems not to allow it: 4.4.4. Reset (RST) A Reset message indicates that a specific confirmable message was received, but some context is missing to properly process it. This condition is usually caused when the receiving node has rebooted and has forgotten some state that would be required to interpret the message. A reset message MUST echo the Message ID of the confirmable message, and MUST be empty. /Sal -- Salvatore Loreto www.sloreto.com --------------090409060501040406010001 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 2/13/12 10:39 PM, Klaus Hartke wrote: 
Thomas Fossati wrote:

Maybe some matching text should be added to section 3?

Thanks, that would help.

Something like this?

3.5.  Cancellation

   When a client rejects a notification (confirmable or non-confirmable)
   with a RST message or when it performs a GET request without an
   Observe Option for a resource, the server will remove the client from
   the list of observers.  The client MAY use either action at any time
   to indicate that it's no longer interested in receiving notifications
   about the resource.

Klaus
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
Hi there,

I like the proposal, however I think that we should really clarify if RTS works also
non-confirmable msg or not.

The MUST in Section 4.4.4 of core-coap draft seems not to allow it:

4.4.4.  Reset (RST)

   A Reset message indicates that a specific confirmable message was
   received, but some context is missing to properly process it.  This
   condition is usually caused when the receiving node has rebooted and
   has forgotten some state that would be required to interpret the
   message.

   A reset message MUST echo the Message ID of the confirmable message,
   and MUST be empty.
 
/Sal
-- 
Salvatore Loreto
www.sloreto.com
--------------090409060501040406010001-- From salvatore.loreto@ericsson.com Wed Feb 15 00:34:49 2012 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 6D8EB21F85E1 for ; Wed, 15 Feb 2012 00:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.357 X-Spam-Level: X-Spam-Status: No, score=-109.357 tagged_above=-999 required=5 tests=[AWL=1.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 kt3vZMyb2mJH for ; Wed, 15 Feb 2012 00:34:48 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2E321F85CE for ; Wed, 15 Feb 2012 00:34:47 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-7e-4f3b6e267282 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A8.36.01970.62E6B3F4; Wed, 15 Feb 2012 09:34:47 +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.213.0; Wed, 15 Feb 2012 09:34:46 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 90B8A22EF for ; Wed, 15 Feb 2012 10:34:46 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7D4B85212E for ; Wed, 15 Feb 2012 10:34:46 +0200 (EET) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 385FF520E4 for ; Wed, 15 Feb 2012 10:34:46 +0200 (EET) Message-ID: <4F3B6E25.8000104@ericsson.com> Date: Wed, 15 Feb 2012 10:34:45 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: core@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000303090007010109080901" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [core] RST and NON (was Re: explicit observe de-registration) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 08:34:49 -0000 --------------000303090007010109080901 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi there, from on the Thomas mail (see below) and the thread discussion related on how to cancel an observation it seems that the core-coap 08 draft needs some text to clarify how the RST message works and when it is possible to use it. sections seems to imply that RST MUST be used only with confirmable messages 4.4.4. Reset (RST) A Reset message indicates that a specific confirmable message was received, but some context is missing to properly process it. This condition is usually caused when the receiving node has rebooted and has forgotten some state that would be required to interpret the message. A reset message MUST echo the Message ID of the confirmable message, and MUST be empty. however, section 4.2 states that it MAY be used also with an Unreliable Message 4.2. Unreliable Messages As a more lightweight alternative, a message can be transmitted less reliably by marking the message as "non-confirmable". A non- confirmable message MUST NOT be acknowledged by the recipient. If a recipient lacks context to process the message properly, it MAY reject the message with a reset message or otherwise MUST silently ignore it. -- Salvatore Loreto www.sloreto.com On 2/13/12 12:35 PM, Thomas Fossati wrote: > Wouldn't it be cleaner to have an explicit Observe de-registration request from the observer to the subject ? > > It'd work with both CON and NON observations (instead of being CON-only [*]) and would be more efficient with sleepy observers, avoiding all the useless retransmission implied by an unreachable node that has entered the sleep state. > > Thomas. > > > [*] apropos, section 4.3 of coap-08 seems to imply that RST can be sent in reply to a NON message, but then 4.4.4 associates RST to CON only (consistently with the usage in current Observe I-D.). To add some more entropy, the changelog says that 05->06 transition included an "Allowed RST message in reply to a NON message with unexpected token", but I can't see it anywhere in -08. > This all leaves some degree of ambiguity about whether RST is a valid response to a NON message or not. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------000303090007010109080901 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi there,

from on the Thomas mail (see below) and the thread discussion related on how to cancel an observation
it seems that the core-coap 08 draft needs some text to clarify how the RST message works and when it is possible to use it.


sections seems to imply that RST MUST be used only with confirmable messages
4.4.4.  Reset (RST)

   A Reset message indicates that a specific confirmable message was
   received, but some context is missing to properly process it.  This
   condition is usually caused when the receiving node has rebooted and
   has forgotten some state that would be required to interpret the
   message.

   A reset message MUST echo the Message ID of the confirmable message,
   and MUST be empty.

however, section 4.2 states that it MAY be used also with an Unreliable Message

4.2.  Unreliable Messages

   As a more lightweight alternative, a message can be transmitted less
   reliably by marking the message as "non-confirmable".  A non-
   confirmable message MUST NOT be acknowledged by the recipient.  If a
   recipient lacks context to process the message properly, it MAY
   reject the message with a reset message or otherwise MUST silently
   ignore it.


-- 
Salvatore Loreto
www.sloreto.com







On 2/13/12 12:35 PM, Thomas Fossati wrote: 
Wouldn't it be cleaner to have an explicit Observe de-registration request from the observer to the subject ?

It'd work with both CON and NON observations (instead of being CON-only [*]) and would be more efficient with sleepy observers, avoiding all the useless retransmission implied by an unreachable node that has entered the sleep state.

Thomas.


[*] apropos, section 4.3 of coap-08 seems to imply that RST can be sent in reply to a NON message, but then 4.4.4 associates RST to CON only (consistently with the usage in current Observe I-D.).  To add some more entropy, the changelog says that 05->06 transition included an "Allowed RST message in reply to a NON message with unexpected token", but I can't see it anywhere in -08.  
This all leaves some degree of ambiguity about whether RST is a valid response to a NON message or not.
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

--------------000303090007010109080901-- From trac+core@trac.tools.ietf.org Wed Feb 15 01:06:52 2012 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 4153821F8790 for ; Wed, 15 Feb 2012 01:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 yayb1emT0ITR for ; Wed, 15 Feb 2012 01:06:48 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id F3D0A21F878A for ; Wed, 15 Feb 2012 01:06:47 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rxaok-0001Ra-Jx; Wed, 15 Feb 2012 04:06:26 -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: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Wed, 15 Feb 2012 09:06:25 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/183#comment:1 Message-ID: <066.43aca47f0505db8077dd7ad23acb769b@trac.tools.ietf.org> References: <051.d737d9d709bad431585042b142a583f4@trac.tools.ietf.org> X-Trac-Ticket-ID: 183 In-Reply-To: <051.d737d9d709bad431585042b142a583f4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, 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 Resent-To: Resent-Message-Id: <20120215090647.F3D0A21F878A@ietfa.amsl.com> Resent-Date: Wed, 15 Feb 2012 01:06:47 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #183: Check consistency of statements about RST on NON X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 09:06:52 -0000 #183: Check consistency of statements about RST on NON Comment (by cabo@…): Salvatore also notes: sections seems to imply that RST MUST be used only with confirmable messages 4.4.4. Reset (RST) A Reset message indicates that a specific confirmable message was received, but some context is missing to properly process it. This condition is usually caused when the receiving node has rebooted and has forgotten some state that would be required to interpret the message. A reset message MUST echo the Message ID of the confirmable message, and MUST be empty. however, section 4.2 states that it MAY be used also with an Unreliable Message 4.2. Unreliable Messages As a more lightweight alternative, a message can be transmitted less reliably by marking the message as "non-confirmable". A non- confirmable message MUST NOT be acknowledged by the recipient. If a recipient lacks context to process the message properly, it MAY reject the message with a reset message or otherwise MUST silently ignore it. -- --------------------------------+------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: editorial | Status: new Priority: major | Milestone: Component: coap | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------------------- Ticket URL: core From cabo@tzi.org Wed Feb 15 07:23:35 2012 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 6370421F8715 for ; Wed, 15 Feb 2012 07:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.505 X-Spam-Level: X-Spam-Status: No, score=-105.505 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 bmHP0x+noL3o for ; Wed, 15 Feb 2012 07:23:34 -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 6F76321F869A for ; Wed, 15 Feb 2012 07:23:34 -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 q1FFNOlQ014088 for ; Wed, 15 Feb 2012 16:23:24 +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 8D99CFE5; Wed, 15 Feb 2012 16:23:24 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Feb 2012 16:23:23 +0100 To: "core@ietf.org WG" Message-Id: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [core] Resolution to tickets #176, #177, #181 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 15:23:35 -0000 Klaus and I sat together today and rearranged coap-misc, moving stuff = that isn't ready for standardization to the appendices and finishing = other stuff. As a result, we are proposing the body of coap-misc as the resolution = for tickets #176, #177 (and indirectly for #174), and #181, as well as = the vendor-defined option that was discussed. If these solutions are acceptable, this leaves us with #166 and #183 = (#182 already has proposed text and just needs to be applied) on = core-coap. I also have to generate a proposal for #171 (block), and we = need to decide whether #170 really needs any work. I am optimistic we can finish all this in the next couple of days, so we = have a set of documents that the authors believe is ready for WGLC. Gr=FC=DFe, Carsten From cabo@tzi.org Wed Feb 15 07:44:21 2012 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 2299121F8623 for ; Wed, 15 Feb 2012 07:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.9 X-Spam-Level: X-Spam-Status: No, score=-104.9 tagged_above=-999 required=5 tests=[AWL=-1.101, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_CHARSET_FARAWAY=2.45, 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 fZX+FqySvD+G for ; Wed, 15 Feb 2012 07:44:20 -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 AC91B21F862A for ; Wed, 15 Feb 2012 07:44:17 -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 q1FFhrf4023203; Wed, 15 Feb 2012 16:43:53 +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 5C5FA1A; Wed, 15 Feb 2012 16:43:53 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=gb18030 From: Carsten Bormann In-Reply-To: Date: Wed, 15 Feb 2012 16:43:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <48CBD068-E56D-461F-806E-173A145AD496@tzi.org> References: <34966E97BE8AD64EAE9D3D6E4DEE36F2280F85@SZXEML506-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F22828B7@SZXEML506-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2283E66@SZXEML506-MBS.china.huawei.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org" Subject: Re: [core] Combined 4.13 response with Block 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, 15 Feb 2012 15:44:21 -0000 On Apr 20, 2011, at 13:20, Dijk, Esko wrote: > If a server receiving a (first) block finds that the message in its = receive buffer is truncated (truncation case I took from coap-05), the = problem is it can=A1=AFt acknowledge the block because part of the data = is missing. Hence, it cannot send a Block Option to indicate a smaller = block size is necessary. It can only respond with error 4.13 in this = case?=20 Hmm, it might send a 4.13 with a Block1 to indicate the desired size. Would that solve #170? I'm about to add this text to the penultimate paragraph of Section 2 in = -block, to solve #170: (Note that a 4.13 response to a request that does not employ Block1 is a hint for the client to try sending Block1, and a 4.13 response with a smaller SZX in the Block1 than requested is a hint to try a smaller = SZX.) Gr=A8=B9=810=898e, Carsten From esko.dijk@philips.com Wed Feb 15 08:51:01 2012 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 80B0C21F867E for ; Wed, 15 Feb 2012 08:51:01 -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 v+WD2BHD5zvi for ; Wed, 15 Feb 2012 08:51:00 -0800 (PST) Received: from AM1EHSOBE004.bigfish.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 6EABB21E8019 for ; Wed, 15 Feb 2012 08:51:00 -0800 (PST) Received: from mail98-am1-R.bigfish.com (10.3.201.243) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 15 Feb 2012 16:51:00 +0000 Received: from mail98-am1 (localhost [127.0.0.1]) by mail98-am1-R.bigfish.com (Postfix) with ESMTP id 9FB7480254; Wed, 15 Feb 2012 16:50:59 +0000 (UTC) X-SpamScore: -47 X-BigFish: VPS-47(zz217bL15d6O9251Jc89bh179dN542M98dKzz1202hzz1033IL8275dhz2dh2a8h668h839h) 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 mail98-am1 (localhost.localdomain [127.0.0.1]) by mail98-am1 (MessageSwitch) id 1329324647860424_29020; Wed, 15 Feb 2012 16:50:47 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.237]) by mail98-am1.bigfish.com (Postfix) with ESMTP id 5A089601CE; Wed, 15 Feb 2012 16:50:47 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 15 Feb 2012 16:50:45 +0000 Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.28]) by 011-DB3MMR1-011.MGDPHG.emi.philips.com ([10.128.28.50]) with mapi id 14.01.0355.003; Wed, 15 Feb 2012 16:52:22 +0000 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] Combined 4.13 response with Block Option? Thread-Index: AQHL/nSETKqXGLwIEEuujEVzqYzXI5Rl6xEAgdoJZ8aAABH0YA== Date: Wed, 15 Feb 2012 16:52:21 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618063B65@011-DB3MPN1-012.MGDPHG.emi.philips.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F2280F85@SZXEML506-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F22828B7@SZXEML506-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2283E66@SZXEML506-MBS.china.huawei.com> <48CBD068-E56D-461F-806E-173A145AD496@tzi.org> In-Reply-To: <48CBD068-E56D-461F-806E-173A145AD496@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.33.229.113] 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] Combined 4.13 response with Block 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, 15 Feb 2012 16:51:01 -0000 Yes, that would solve #170 I believe. Also my preferred solution. thanks, Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Wednesday 15 February 2012 16:44 To: Dijk, Esko Cc: Likepeng; core@ietf.org Subject: Re: [core] Combined 4.13 response with Block Option? On Apr 20, 2011, at 13:20, Dijk, Esko wrote: > If a server receiving a (first) block finds that the message in its recei= ve buffer is truncated (truncation case I took from coap-05), the problem i= s it can't acknowledge the block because part of the data is missing. Hence= , it cannot send a Block Option to indicate a smaller block size is necessa= ry. It can only respond with error 4.13 in this case? Hmm, it might send a 4.13 with a Block1 to indicate the desired size. Would that solve #170? I'm about to add this text to the penultimate paragraph of Section 2 in -bl= ock, to solve #170: (Note that a 4.13 response to a request that does not employ Block1 is a hint for the client to try sending Block1, and a 4.13 response with a smaller SZX in the Block1 than requested is a hint to try a smaller SZX.) 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 trac+core@trac.tools.ietf.org Wed Feb 15 08:58:57 2012 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 E319621E8048 for ; Wed, 15 Feb 2012 08:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 tAgNbv-cmFVw for ; Wed, 15 Feb 2012 08:58:53 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id C420921E8040 for ; Wed, 15 Feb 2012 08:58:52 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RxiBv-0008Rp-UV; Wed, 15 Feb 2012 11:58:52 -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: cabo@tzi.org X-Trac-Project: core Date: Wed, 15 Feb 2012 16:58:51 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/170#comment:1 Message-ID: <072.990b3633f6bfc21891f8fc0f5f29c3c0@trac.tools.ietf.org> References: <057.d70b3a61b803ae9326fd0fb0622040f6@trac.tools.ietf.org> X-Trac-Ticket-ID: 170 In-Reply-To: <057.d70b3a61b803ae9326fd0fb0622040f6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, 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: Re: [core] #170: Request Entity Too Large X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 16:58:58 -0000 #170: Request Entity Too Large Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: Fixed in [501]: Fix #170 (4.13 confusion), #171 (Size option). -- -----------------------------+--------------------- Reporter: zach@… | Owner: cabo@… Type: protocol defect | Status: closed Priority: minor | Milestone: Component: block | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------+--------------------- Ticket URL: core From internet-drafts@ietf.org Wed Feb 15 09:02:08 2012 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 9803E21F8576; Wed, 15 Feb 2012 09:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 bgAI6mCOAbcN; Wed, 15 Feb 2012 09:02:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0392A21F854B; Wed, 15 Feb 2012 09:02:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120215170207.13281.84489.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2012 09:02:07 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-block-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 17:02:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Work= ing Group of the IETF. Title : Blockwise transfers in CoAP Author(s) : Carsten Bormann Zach Shelby Filename : draft-ietf-core-block-08.txt Pages : 30 Date : 2012-02-15 CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-block-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-block-08.txt From trac+core@trac.tools.ietf.org Wed Feb 15 09:03:24 2012 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 A36D221E8067 for ; Wed, 15 Feb 2012 09:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 djFjJ8HHd4A1 for ; Wed, 15 Feb 2012 09:03:20 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 78D5C21E8040 for ; Wed, 15 Feb 2012 09:03:20 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RxiG8-0008P2-3p; Wed, 15 Feb 2012 12:03:12 -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: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Wed, 15 Feb 2012 17:03:12 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/171#comment:2 Message-ID: <072.ef197b41c3d234cf65261745da770ab9@trac.tools.ietf.org> References: <057.e138be52af7e75e86559cc5a5dfa0423@trac.tools.ietf.org> X-Trac-Ticket-ID: 171 In-Reply-To: <057.e138be52af7e75e86559cc5a5dfa0423@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, 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: Re: [core] #171: Merging of Size into Block X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 17:03:24 -0000 #171: Merging of Size into Block Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: Fixed by the new section 4 in -block-08. The next in the current size option draft turned out to be a less convincing fit than I thought, so I wrote new text for that section and simplified things considerably in the process. -- ----------------------------------+--------------------- Reporter: zach@… | Owner: cabo@… Type: protocol enhancement | Status: closed Priority: major | Milestone: Component: block | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+--------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Feb 15 09:10:22 2012 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 5E74421F85D4 for ; Wed, 15 Feb 2012 09:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 A64vkT1tL1LK for ; Wed, 15 Feb 2012 09:10:18 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4A121F8526 for ; Wed, 15 Feb 2012 09:10:17 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RxiMz-0001Cy-79; Wed, 15 Feb 2012 12:10:17 -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: hartke@tzi.org, cabo@tzi.org X-Trac-Project: core Date: Wed, 15 Feb 2012 17:10:16 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/174#comment:3 Message-ID: <068.c5ba6a17150bcf99aa1e187e9ddca2d4@trac.tools.ietf.org> References: <053.70316ef76a2aab1204bc99bad86807ea@trac.tools.ietf.org> X-Trac-Ticket-ID: 174 In-Reply-To: <053.70316ef76a2aab1204bc99bad86807ea@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, cabo@tzi.org, 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: Re: [core] #174: Robust observation relationships X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 17:10:22 -0000 #174: Robust observation relationships Comment (by cabo@…): A proposal for a solution is in coap-misc-12 ("Pledge"). There may be no need to put this in the base -observe spec. Do we need to keep this ticket open (i.e., to indeed make the addition in the base -observe?) -- -----------------------------------+----------------------- Reporter: hartke@… | Owner: hartke@… Type: protocol defect | Status: reopened Priority: major | Milestone: Component: observe | Version: Severity: Submitted WG Document | Resolution: Keywords: | -----------------------------------+----------------------- Ticket URL: core From stpeter@stpeter.im Thu Feb 16 13:51:37 2012 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 A714821E8043 for ; Thu, 16 Feb 2012 13:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 d2EJVU-PQZu0 for ; Thu, 16 Feb 2012 13:51:33 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D6F2521E8051 for ; Thu, 16 Feb 2012 13:51:29 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D84C040058; Thu, 16 Feb 2012 15:02:25 -0700 (MST) Message-ID: <4F3D7A60.5050305@stpeter.im> Date: Thu, 16 Feb 2012 14:51:28 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Carsten Bormann References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> In-Reply-To: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> X-Enigmail-Version: 1.3.5 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] Resolution to tickets #176, #177, #181 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 21:51:37 -0000 On 2/15/12 8:23 AM, Carsten Bormann wrote: > As a result, we are proposing the body of coap-misc as the resolution > for tickets #176, #177 (and indirectly for #174), and #181, as well > as the vendor-defined option that was discussed. Regarding #181, would the proposed change obviate the need for the +exi prefix as discussed on the apps-discuss list (since CoAP entities could handle content-encoding)? Peter -- Peter Saint-Andre https://stpeter.im/ From cabo@tzi.org Thu Feb 16 14:10:37 2012 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 71EFB21F87AF for ; Thu, 16 Feb 2012 14:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.843 X-Spam-Level: X-Spam-Status: No, score=-103.843 tagged_above=-999 required=5 tests=[AWL=-1.844, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 B-9Y2OpwVwcJ for ; Thu, 16 Feb 2012 14:10: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 3068C21F87AD for ; Thu, 16 Feb 2012 14:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q1GMA87V006358; Thu, 16 Feb 2012 23:10:10 +0100 (CET) Message-Id: From: Carsten Bormann To: Peter Saint-Andre In-Reply-To: <4F3D7A60.5050305@stpeter.im> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 16 Feb 2012 23:10:08 +0100 References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> <4F3D7A60.5050305@stpeter.im> X-Mailer: Apple Mail (2.936) Cc: "core@ietf.org WG" Subject: Re: [core] Resolution to tickets #176, #177, #181 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 22:10:37 -0000 On Feb 16 2012, at 22:51, Peter Saint-Andre wrote: > > > On 2/15/12 8:23 AM, Carsten Bormann wrote: > >> As a result, we are proposing the body of coap-misc as the resolution >> for tickets #176, #177 (and indirectly for #174), and #181, as well >> as the vendor-defined option that was discussed. > > Regarding #181, would the proposed change obviate the need for the > +exi > prefix as discussed on the apps-discuss list (since CoAP entities > could > handle content-encoding)? I think that discussion is slightly confused (I haven't tried to intervene, as I'm not an EXI person). application/foo+exi could be a media type for a schema-informed EXI encoding of foo+xml. Content-Encoding is meant to be futzed with in proxies (all the 214 verbage notwithstanding), so from my point of view needs to be schemaless. But there are a lot of angels and pinheads in the interpretation of these attributes and concepts, so I think we need to be able to cope with both outcomes. The Content-Encoding column is mainly an insurance against people claiming we need a Content-Encoding Option in CoAP because we can't have encoded media types. HTTP wants media type and Content-Encoding to be orthogonal and freely combinable. Since constrained devices are unlikely to have that level of orthogonality, I'd rather make it obvious that both media type and Content-Encoding are tied together in your decision of what to ship over the wireless. If the "you can't have +exi but must encode that aspect of the representation format in Content-Encoding" faction wins, there will be zero change for us, except in the documents where we replace "+exi --" with "+xml exi" in some tables. Protocol design 101: Design so you win with either possible outcome of a tussle. Gruesse, Carsten From lishitao@huawei.com Thu Feb 16 17:16:43 2012 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 91B9821E808F for ; Thu, 16 Feb 2012 17:16:43 -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=[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 kYaEZ89W50iV for ; Thu, 16 Feb 2012 17:16:39 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5879221E805C for ; Thu, 16 Feb 2012 17:16:39 -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 <0LZI000Y8JJLC5@szxga05-in.huawei.com> for core@ietf.org; Fri, 17 Feb 2012 09:16:33 +0800 (CST) Received: from szxrg01-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 <0LZI00AIIJJLTF@szxga05-in.huawei.com> for core@ietf.org; Fri, 17 Feb 2012 09:16:33 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGX00689; Fri, 17 Feb 2012 09:15:33 +0800 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 09:15:24 +0800 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.222]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Fri, 17 Feb 2012 09:15:32 +0800 Date: Fri, 17 Feb 2012 01:16:49 +0000 From: Li Shitao In-reply-to: X-Originating-IP: [10.138.73.34] To: "core@ietf.org WG" Message-id: 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: New Version Notification for draft-li-core-conditional-observe-00.txt Thread-index: AQHM7RGkr55IczEuc0qzE9wilGcfJQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> <4F3D7A60.5050305@stpeter.im> Subject: [core] New Version Notification for draft-li-core-conditional-observe-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 01:16:43 -0000 Hi all I have submit a new draft about condition observe in CoAP, the main idea is using a new option called "condition" to carry the condition required by the observer. In this draft, it has defined three condition type, the minimum response time, step and range. The detail usage has defined in this draft, if you are interested with this draft you can find it at http://datatracker.ietf.org/doc/draft-li-core-conditional-observe/ . Hope to receive more comments! regards shitao From cabo@tzi.org Thu Feb 16 22:57:36 2012 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 F157C21F8617 for ; Thu, 16 Feb 2012 22:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.094 X-Spam-Level: X-Spam-Status: No, score=-106.094 tagged_above=-999 required=5 tests=[AWL=0.155, 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 x+S+jmDS+fkJ for ; Thu, 16 Feb 2012 22:57: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 D1A6521F85EF for ; Thu, 16 Feb 2012 22:57:29 -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 q1H6vBpU010095; Fri, 17 Feb 2012 07:57:11 +0100 (CET) Received: from [192.168.217.105] (p5B3E6073.dip.t-dialin.net [91.62.96.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BF8CD937; Fri, 17 Feb 2012 07:57:10 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 17 Feb 2012 07:57:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> <4F3D7A60.5050305@stpeter.im> To: Li Shitao X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org WG" Subject: Re: [core] New Version Notification for draft-li-core-conditional-observe-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 06:57:37 -0000 On Feb 17, 2012, at 02:16, Li Shitao wrote: > In this draft, it has defined three condition type, the minimum = response time, step and range. The detail usage has defined in this = draft, if you are interested with this=20 >=20 > draft you can find it at = http://datatracker.ietf.org/doc/draft-li-core-conditional-observe/ . I think that most applications will want to carry conditions like these = in the URI, because ultimately there will be applications semantics that = will trigger when a new resource state needs to be indicated. Yes, it would be nice to separate the trigger condition from the = resource identification (e.g., to improve caching), but it is hard to = get such an architecture right. Imagine a proxy that starts observation = relationships with two clients, with different trigger conditions -- = what trigger condition does it relay upstream to the origin server? = Ultimately, the proxy would need to understand enough of the application = to combine the trigger conditions. Proxies having to understand = applications is a big no-no in our architecture. Gr=FC=DFe, Carsten From lishitao@huawei.com Thu Feb 16 23:29:09 2012 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 EEA5321F85F6 for ; Thu, 16 Feb 2012 23:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 Q2T7715zmfXM for ; Thu, 16 Feb 2012 23:29:05 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCA521F85F2 for ; Thu, 16 Feb 2012 23:29:05 -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 <0LZJ005FH0S66B@szxga03-in.huawei.com> for core@ietf.org; Fri, 17 Feb 2012 15:28:54 +0800 (CST) Received: from szxrg01-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 <0LZJ00IYR0S674@szxga03-in.huawei.com> for core@ietf.org; Fri, 17 Feb 2012 15:28:54 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGX30853; Fri, 17 Feb 2012 15:28:08 +0800 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 15:27:57 +0800 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.222]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Fri, 17 Feb 2012 15:28:03 +0800 Date: Fri, 17 Feb 2012 07:29:28 +0000 From: Li Shitao In-reply-to: X-Originating-IP: [10.138.73.34] To: Carsten Bormann Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [core] New Version Notification for draft-li-core-conditional-observe-00.txt Thread-index: AQHM7RGkr55IczEuc0qzE9wilGcfJZZAInyAgACN/EA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> <4F3D7A60.5050305@stpeter.im> Cc: "core@ietf.org WG" Subject: [core] =?utf-8?b?562U5aSNOiAgTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv?= =?utf-8?q?r_draft-li-core-conditional-observe-00=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 07:29:10 -0000 SGkgQ2Fyc3Rlbg0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkhDQoNCkJ1dCwgSSBhbSBub3QgcXVp dGUgdW5kZXJzdGFuZGluZyBhYm91dCB0aGUgcHJveHkgdGhpbmcgeW91IG1lbnRpb24gaGVyZSwg YXMgeW91IHNhaWQgdGhlIHByb3h5IHN0YXJ0cyBvYnNlcnZhdGlvbiByZWxhdGlvbnNoaXBzIHdp dGggdHdvIGNsaWVudHMsIHNvIHRoZXkgYXJlIHR3byBzZXBhcmF0ZSBvYnNlcnZhdGlvbiByZWxh dGlvbnNoaXBzLCByaWdodD8gSWYgdGhleSBhcmUsIGl0IGNhbiBiZSBkaXN0aW5ndWlzaGVkIGJ5 IHRoZSBtZXNzYWdlIElELCB0aGUgcHJveHkgY2FuIHRyZWF0IHRoZW0gYXMgRGlmZmVyZW50IHJl cXVlc3QuIEkgZGlkIG5vdCBzZWUgdGhlIHByb2JsZW0gaGVyZS4NCg0KcmVnYXJkcw0KU2hpdGFv DQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogQ2Fyc3RlbiBCb3JtYW5uIFtt YWlsdG86Y2Fib0B0emkub3JnXSANCuWPkemAgeaXtumXtDogMjAxMuW5tDLmnIgxN+aXpSAxNDo1 Nw0K5pS25Lu25Lq6OiBMaSBTaGl0YW8NCuaKhOmAgTogY29yZUBpZXRmLm9yZyBXRw0K5Li76aKY OiBSZTogW2NvcmVdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktY29yZS1j b25kaXRpb25hbC1vYnNlcnZlLTAwLnR4dA0KDQpPbiBGZWIgMTcsIDIwMTIsIGF0IDAyOjE2LCBM aSBTaGl0YW8gd3JvdGU6DQoNCj4gSW4gdGhpcyBkcmFmdCwgaXQgaGFzIGRlZmluZWQgdGhyZWUg Y29uZGl0aW9uIHR5cGUsIHRoZSBtaW5pbXVtIHJlc3BvbnNlIHRpbWUsIHN0ZXAgYW5kIHJhbmdl LiBUaGUgZGV0YWlsIHVzYWdlIGhhcyBkZWZpbmVkIGluIHRoaXMgZHJhZnQsIGlmIHlvdSBhcmUg aW50ZXJlc3RlZCB3aXRoIHRoaXMgDQo+IA0KPiBkcmFmdCB5b3UgY2FuIGZpbmQgaXQgYXQgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saS1jb3JlLWNvbmRpdGlvbmFsLW9i c2VydmUvIC4NCg0KSSB0aGluayB0aGF0IG1vc3QgYXBwbGljYXRpb25zIHdpbGwgd2FudCB0byBj YXJyeSBjb25kaXRpb25zIGxpa2UgdGhlc2UgaW4gdGhlIFVSSSwgYmVjYXVzZSB1bHRpbWF0ZWx5 IHRoZXJlIHdpbGwgYmUgYXBwbGljYXRpb25zIHNlbWFudGljcyB0aGF0IHdpbGwgdHJpZ2dlciB3 aGVuIGEgbmV3IHJlc291cmNlIHN0YXRlIG5lZWRzIHRvIGJlIGluZGljYXRlZC4NCg0KWWVzLCBp dCB3b3VsZCBiZSBuaWNlIHRvIHNlcGFyYXRlIHRoZSB0cmlnZ2VyIGNvbmRpdGlvbiBmcm9tIHRo ZSByZXNvdXJjZSBpZGVudGlmaWNhdGlvbiAoZS5nLiwgdG8gaW1wcm92ZSBjYWNoaW5nKSwgYnV0 IGl0IGlzIGhhcmQgdG8gZ2V0IHN1Y2ggYW4gYXJjaGl0ZWN0dXJlIHJpZ2h0LiAgSW1hZ2luZSBh IHByb3h5IHRoYXQgc3RhcnRzIG9ic2VydmF0aW9uIHJlbGF0aW9uc2hpcHMgd2l0aCB0d28gY2xp ZW50cywgd2l0aCBkaWZmZXJlbnQgdHJpZ2dlciBjb25kaXRpb25zIC0tIHdoYXQgdHJpZ2dlciBj b25kaXRpb24gZG9lcyBpdCByZWxheSB1cHN0cmVhbSB0byB0aGUgb3JpZ2luIHNlcnZlcj8gIFVs dGltYXRlbHksIHRoZSBwcm94eSB3b3VsZCBuZWVkIHRvIHVuZGVyc3RhbmQgZW5vdWdoIG9mIHRo ZSBhcHBsaWNhdGlvbiB0byBjb21iaW5lIHRoZSB0cmlnZ2VyIGNvbmRpdGlvbnMuICBQcm94aWVz IGhhdmluZyB0byB1bmRlcnN0YW5kIGFwcGxpY2F0aW9ucyBpcyBhIGJpZyBuby1ubyBpbiBvdXIg YXJjaGl0ZWN0dXJlLg0KDQpHcsO8w59lLCBDYXJzdGVuDQoNCg== From cabo@tzi.org Thu Feb 16 23:38:00 2012 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 CE2F121F8659 for ; Thu, 16 Feb 2012 23:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.104 X-Spam-Level: X-Spam-Status: No, score=-106.104 tagged_above=-999 required=5 tests=[AWL=0.145, 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 YGWt0vVeOOzE for ; Thu, 16 Feb 2012 23:38:00 -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 0B40921F85CF for ; Thu, 16 Feb 2012 23:37:59 -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 q1H7bm0F024458; Fri, 17 Feb 2012 08:37:48 +0100 (CET) Received: from [192.168.217.105] (p5B3E6073.dip.t-dialin.net [91.62.96.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5EE5396E; Fri, 17 Feb 2012 08:37:48 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 17 Feb 2012 08:37:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> <4F3D7A60.5050305@stpeter.im> To: Li Shitao X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org WG" Subject: Re: [core] New Version Notification for draft-li-core-conditional-observe-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 07:38:00 -0000 On Feb 17, 2012, at 08:29, Li Shitao wrote: > Hi Carsten >=20 > Thanks for your reply! >=20 > But, I am not quite understanding about the proxy thing you mention = here, as you said the proxy starts observation relationships with two = clients, so they are two separate observation relationships, right? If = they are, it can be distinguished by the message ID, the proxy can treat = them as Different request. I did not see the problem here. Right. The problem is in the upstream observation relationship. What trigger = conditions does the proxy relay to the origin server? If the triggers cannot be combined. there is no benefit the proxy can = realize from both observation relationships using the same URI (i.e., no = benefit from any separation of URI and trigger condition). This is all theoretical, of course -- today's systems would model the = trigger in the URI (most likely the query part), so there is nothing a = proxy can do to combine multiple downstream observation relationships = into one upstream. BTW, I'd expect formats such as SenML to come up with conventions for = how to specify such triggers. JSON pointer comes to mind as a possible = component. Gr=FC=DFe, Carsten From zach@sensinode.com Fri Feb 17 00:18:10 2012 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 7CD5C21F8750 for ; Fri, 17 Feb 2012 00:18:10 -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 B4r2tI5V+9Mb for ; Fri, 17 Feb 2012 00:18:08 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id BCB3921F874A for ; Fri, 17 Feb 2012 00:18:07 -0800 (PST) Received: from [172.20.10.2] (84-231-228-2.elisa-mobile.fi [84.231.228.2]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q1H8HNeC025431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Feb 2012 10:17:26 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Fri, 17 Feb 2012 10:17:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> <4F3D7A60.5050305@stpeter.im> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" Subject: Re: [core] New Version Notification for draft-li-core-conditional-observe-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 08:18:11 -0000 On Feb 17, 2012, at 8:57 AM, Carsten Bormann wrote: > I think that most applications will want to carry conditions like = these in the URI, because ultimately there will be applications = semantics that will trigger when a new resource state needs to be = indicated. I agree. The newest version of the CoRE Interfaces draft includes such a = URI based condition mechanism.=20 http://tools.ietf.org/id/draft-shelby-core-interfaces-01.txt Shitao, I am happy to hear your input if you think the conditions need = some more improvement. These are meant to be simple conditions that can = be used with any of the interface descriptions described in that draft. = I do expect more complex conditions to be defined for specific market = segments. 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 From lishitao@huawei.com Fri Feb 17 01:35:33 2012 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 8ED5821F88A3 for ; Fri, 17 Feb 2012 01:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.26 X-Spam-Level: X-Spam-Status: No, score=-6.26 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 uT06LJjJWBpv for ; Fri, 17 Feb 2012 01:35:32 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id D195121F8894 for ; Fri, 17 Feb 2012 01:35:31 -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 <0LZJ00HI26JADJ@szxga03-in.huawei.com> for core@ietf.org; Fri, 17 Feb 2012 17:33:10 +0800 (CST) Received: from szxrg01-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 <0LZJ005CL6JAJ1@szxga03-in.huawei.com> for core@ietf.org; Fri, 17 Feb 2012 17:33:10 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGX47639; Fri, 17 Feb 2012 17:33:09 +0800 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Feb 2012 17:33:14 +0800 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.222]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Fri, 17 Feb 2012 17:33:06 +0800 Date: Fri, 17 Feb 2012 09:34:33 +0000 From: Li Shitao In-reply-to: X-Originating-IP: [10.138.73.34] To: Carsten Bormann Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_qToSDL3jK7IEUUEHngK06w)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [core] New Version Notification for draft-li-core-conditional-observe-00.txt Thread-index: AQHM7RGkr55IczEuc0qzE9wilGcfJZZAInyAgACN/ED//31egIAAn9tw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> <4F3D7A60.5050305@stpeter.im> Cc: "core@ietf.org WG" Subject: [core] =?utf-8?b?562U5aSNOiAgTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv?= =?utf-8?q?r_draft-li-core-conditional-observe-00=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 09:35:33 -0000 --Boundary_(ID_qToSDL3jK7IEUUEHngK06w) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 UmVsYXRlZCB0byB0aGUgcHJveHkgY29tYmluZS4gSSBnb3QgYSBxdWVzdGlvbiBoZXJlLCBpZiB0 aGUgcHJveHkgcmVjZWl2ZSB0d28gcmVxdWVzdCBib3RoIHRvIHRoZSBzYW1lIFVSSSwgYnV0IG9u ZSB3aXRoIHRoZSBvYnNlcnZlIG9wdGlvbiwgYW5vdGhlciBub3QsIGlmIHRoZSBwcm94eSBqdXN0 IGRvIHRoZSBVUkkgY2hlY2sgYnV0IG5vIG90aGVyIG9wdGlvbiBjaGVjaywNCg0KV2hlbiB0aGUg cHJveHkgY29tYmluZSB0aG9zZSB0d28gcmVxdWVzdCB0b2dldGhlciwgd2hhdCB3aWxsIGJlIG5l eHQ/IEZvcndhcmQgd2hpY2ggcmVxdWVzdCB0byB0aGUgc2VydmVyPw0KDQoNCg0KU28gdG8gbXkg dW5kZXJzdGFuZGluZywgdGhlIHByb3h5IGF0IGxlYXN0IG5lZWQgdG8gYW5hbHl6ZSB0aGUgb2Jz ZXJ2ZSBvcHRpb24sIHJpZ2h0PyBDb25kaXRpb24gb3B0aW9uIGFzIGluIG15IGRyYWZ0LCBzaG91 bGQgdXNlZCB0b2dldGhlciB3aXRoIHRoZSBvYnNlcnZlIG9wdGlvbiwgaWYgdGhlIHByb3h5IGNh biBjaGVjayB0aGUgb2JzZXJ2ZSBvcHRpb24sIGl0IGlzIG5vdCBoYXJkIHRvIGRvIG9uZSBjaGVj ayBhYm91dCB0aGUgY29uZGl0aW9uIG9wdGlvbiBjaGVjay4NCg0KDQoNClRoZSBtYWluIHJlYXNv biwgSSBmb3VuZCBVUkktcXVlcnkgaXMgbm90IHNvIGdvb2QgaXMsIHdlIHVzZSB1cmktcXVlcnkg Zm9yIG1hbnkgcHVycG9zZXMsIGFuZCBtb3N0IHRpbWUgd2UgcXVlcnkgc29tZSBjb25kaXRpb25z IHRoYXQgYXJlIG5vdCByZWxhdGVkIHRvIG9ic2VydmUsICBmb3IgYSBzZXJ2ZXIsIGl0cyBsb2dp YyBuZWVkcyB0byBiZSBxdWl0ZSBjb21wbGljYXRlZC4gQnV0IHVzaW5nIGEgc2VwYXJhdGUgb3B0 aW9uIHRvIGRvIHRoaXMsIGNhbg0KDQoNCg0Kc2ltcGxpZnkgdGhlIGxvZ2ljIG9mIHRoZSBDb0FQ IHNlcnZlciwgaXQgZG9lcyBub3Qgb2NjdXB5IG1vcmUgYml0cywgYnV0IGl0IHNhdmUgbW9yZSBy ZXNvdXJjZSBvbiB0aGUgc2VydmVyLg0KDQoNCg0KDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0N Cg0K5Y+R5Lu25Lq6OiBDYXJzdGVuIEJvcm1hbm4gW21haWx0bzpjYWJvQHR6aS5vcmddDQoNCuWP kemAgeaXtumXtDogMjAxMuW5tDLmnIgxN+aXpSAxNTozOA0KDQrmlLbku7bkuro6IExpIFNoaXRh bw0KDQrmioTpgIE6IGNvcmVAaWV0Zi5vcmcgV0cNCg0K5Li76aKYOiBSZTogW2NvcmVdIE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktY29yZS1jb25kaXRpb25hbC1vYnNlcnZl LTAwLnR4dA0KDQoNCg0KDQoNCk9uIEZlYiAxNywgMjAxMiwgYXQgMDg6MjksIExpIFNoaXRhbyB3 cm90ZToNCg0KDQoNCj4gSGkgQ2Fyc3Rlbg0KDQo+DQoNCj4gVGhhbmtzIGZvciB5b3VyIHJlcGx5 IQ0KDQo+DQoNCj4gQnV0LCBJIGFtIG5vdCBxdWl0ZSB1bmRlcnN0YW5kaW5nIGFib3V0IHRoZSBw cm94eSB0aGluZyB5b3UgbWVudGlvbiBoZXJlLCBhcyB5b3Ugc2FpZCB0aGUgcHJveHkgc3RhcnRz IG9ic2VydmF0aW9uIHJlbGF0aW9uc2hpcHMgd2l0aCB0d28gY2xpZW50cywgc28gdGhleSBhcmUg dHdvIHNlcGFyYXRlIG9ic2VydmF0aW9uIHJlbGF0aW9uc2hpcHMsIHJpZ2h0PyBJZiB0aGV5IGFy ZSwgaXQgY2FuIGJlIGRpc3Rpbmd1aXNoZWQgYnkgdGhlIG1lc3NhZ2UgSUQsIHRoZSBwcm94eSBj YW4gdHJlYXQgdGhlbSBhcyBEaWZmZXJlbnQgcmVxdWVzdC4gSSBkaWQgbm90IHNlZSB0aGUgcHJv YmxlbSBoZXJlLg0KDQoNCg0KUmlnaHQuDQoNCg0KDQpUaGUgcHJvYmxlbSBpcyBpbiB0aGUgdXBz dHJlYW0gb2JzZXJ2YXRpb24gcmVsYXRpb25zaGlwLiAgV2hhdCB0cmlnZ2VyIGNvbmRpdGlvbnMg ZG9lcyB0aGUgcHJveHkgcmVsYXkgdG8gdGhlIG9yaWdpbiBzZXJ2ZXI/DQoNCklmIHRoZSB0cmln Z2VycyBjYW5ub3QgYmUgY29tYmluZWQuIHRoZXJlIGlzIG5vIGJlbmVmaXQgdGhlIHByb3h5IGNh biByZWFsaXplIGZyb20gYm90aCBvYnNlcnZhdGlvbiByZWxhdGlvbnNoaXBzIHVzaW5nIHRoZSBz YW1lIFVSSSAoaS5lLiwgbm8gYmVuZWZpdCBmcm9tIGFueSBzZXBhcmF0aW9uIG9mIFVSSSBhbmQg dHJpZ2dlciBjb25kaXRpb24pLg0KDQoNCg0KVGhpcyBpcyBhbGwgdGhlb3JldGljYWwsIG9mIGNv dXJzZSAtLSB0b2RheSdzIHN5c3RlbXMgd291bGQgbW9kZWwgdGhlIHRyaWdnZXIgaW4gdGhlIFVS SSAobW9zdCBsaWtlbHkgdGhlIHF1ZXJ5IHBhcnQpLCBzbyB0aGVyZSBpcyBub3RoaW5nIGEgcHJv eHkgY2FuIGRvIHRvIGNvbWJpbmUgbXVsdGlwbGUgZG93bnN0cmVhbSBvYnNlcnZhdGlvbiByZWxh dGlvbnNoaXBzIGludG8gb25lIHVwc3RyZWFtLg0KDQoNCg0KQlRXLCBJJ2QgZXhwZWN0IGZvcm1h dHMgc3VjaCBhcyBTZW5NTCB0byBjb21lIHVwIHdpdGggY29udmVudGlvbnMgZm9yIGhvdyB0byBz cGVjaWZ5IHN1Y2ggdHJpZ2dlcnMuICBKU09OIHBvaW50ZXIgY29tZXMgdG8gbWluZCBhcyBhIHBv c3NpYmxlIGNvbXBvbmVudC4NCg0KDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KDQo= --Boundary_(ID_qToSDL3jK7IEUUEHngK06w) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0 aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6Iue6r+aWh+acrCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5DaGFyDQoJe21z by1zdHlsZS1uYW1lOiLnuq/mlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOue6r+aWh+acrDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30N Ci8qIFBhZ2UgRGVmaW5pdGlvbnMgKi8NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ0ZXh0LWp1c3RpZnkt dHJpbTpwdW5jdHVhdGlvbiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlbGF0ZWQgdG8gdGhlIHByb3h5IGNv bWJpbmUuIEkgZ290IGEgcXVlc3Rpb24gaGVyZSwgaWYgdGhlIHByb3h5IHJlY2VpdmUgdHdvIHJl cXVlc3QgYm90aCB0byB0aGUgc2FtZSBVUkksIGJ1dCBvbmUgd2l0aCB0aGUgb2JzZXJ2ZSBvcHRp b24sIGFub3RoZXIgbm90LCBpZiB0aGUgcHJveHkganVzdCBkbyB0aGUgVVJJIGNoZWNrIGJ1dCBu byBvdGhlciBvcHRpb24gY2hlY2ssDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+V2hlbiB0aGUgcHJveHkgY29tYmluZSB0 aG9zZSB0d28gcmVxdWVzdCB0b2dldGhlciwgd2hhdCB3aWxsIGJlIG5leHQ/IEZvcndhcmQgd2hp Y2ggcmVxdWVzdCB0byB0aGUgc2VydmVyPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5TbyB0 byBteSB1bmRlcnN0YW5kaW5nLCB0aGUgcHJveHkgYXQgbGVhc3QgbmVlZCB0byBhbmFseXplIHRo ZSBvYnNlcnZlIG9wdGlvbiwgcmlnaHQ/IENvbmRpdGlvbiBvcHRpb24gYXMgaW4gbXkgZHJhZnQs IHNob3VsZCB1c2VkIHRvZ2V0aGVyIHdpdGggdGhlIG9ic2VydmUgb3B0aW9uLCBpZiB0aGUgcHJv eHkgY2FuIGNoZWNrIHRoZSBvYnNlcnZlIG9wdGlvbiwgaXQgaXMNCiBub3QgaGFyZCB0byBkbyBv bmUgY2hlY2sgYWJvdXQgdGhlIGNvbmRpdGlvbiBvcHRpb24gY2hlY2suPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGUgbWFpbiByZWFzb24sIEkgZm91bmQgVVJJLXF1ZXJ5IGlzIG5vdCBzbyBn b29kIGlzLCB3ZSB1c2UgdXJpLXF1ZXJ5IGZvciBtYW55IHB1cnBvc2VzLCBhbmQgbW9zdCB0aW1l IHdlIHF1ZXJ5IHNvbWUgY29uZGl0aW9ucyB0aGF0IGFyZSBub3QgcmVsYXRlZCB0byBvYnNlcnZl LCAmbmJzcDtmb3IgYSBzZXJ2ZXIsIGl0cyBsb2dpYyBuZWVkcyB0byBiZSBxdWl0ZSBjb21wbGlj YXRlZC4NCiBCdXQgdXNpbmcgYSBzZXBhcmF0ZSBvcHRpb24gdG8gZG8gdGhpcywgY2FuIDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+c2ltcGxpZnkgdGhlIGxvZ2ljIG9mIHRoZSBDb0FQIHNlcnZl ciwgaXQgZG9lcyBub3Qgb2NjdXB5IG1vcmUgYml0cywgYnV0IGl0IHNhdmUgbW9yZSByZXNvdXJj ZSBvbiB0aGUgc2VydmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi Pi0tLS0tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZMiPumCruS7tuWOn+S7 tjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj7l j5Hku7bkuro8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjogQ2Fyc3RlbiBCb3JtYW5uIFttYWls dG86Y2Fib0B0emkub3JnXQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+5Y+R6YCB5pe26Ze0PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj46IDIwMTI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OuWui+S9kyI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4yPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTrlrovkvZMiPuaciDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+MTc8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+5pelPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj4NCiAxNTozODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZMiPuaUtuS7tuS6ujwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+OiBMaSBTaGl0YW88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj7m ioTpgIE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjogY29yZUBpZXRmLm9yZyBXRzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTrlrovkvZMiPuS4u+mimDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+OiBSZTogW2Nv cmVdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktY29yZS1jb25kaXRpb25h bC1vYnNlcnZlLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi Pk9uIEZlYiAxNywgMjAxMiwgYXQgMDg6MjksIExpIFNoaXRhbyB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDsgSGkgQ2Fyc3RlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7 IFRoYW5rcyBmb3IgeW91ciByZXBseSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBCdXQs IEkgYW0gbm90IHF1aXRlIHVuZGVyc3RhbmRpbmcgYWJvdXQgdGhlIHByb3h5IHRoaW5nIHlvdSBt ZW50aW9uIGhlcmUsIGFzIHlvdSBzYWlkIHRoZSBwcm94eSBzdGFydHMgb2JzZXJ2YXRpb24gcmVs YXRpb25zaGlwcyB3aXRoIHR3byBjbGllbnRzLCBzbyB0aGV5IGFyZSB0d28gc2VwYXJhdGUgb2Jz ZXJ2YXRpb24gcmVsYXRpb25zaGlwcywgcmlnaHQ/IElmIHRoZXkNCiBhcmUsIGl0IGNhbiBiZSBk aXN0aW5ndWlzaGVkIGJ5IHRoZSBtZXNzYWdlIElELCB0aGUgcHJveHkgY2FuIHRyZWF0IHRoZW0g YXMgRGlmZmVyZW50IHJlcXVlc3QuIEkgZGlkIG5vdCBzZWUgdGhlIHByb2JsZW0gaGVyZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJpZ2h0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhl IHByb2JsZW0gaXMgaW4gdGhlIHVwc3RyZWFtIG9ic2VydmF0aW9uIHJlbGF0aW9uc2hpcC4mbmJz cDsgV2hhdCB0cmlnZ2VyIGNvbmRpdGlvbnMgZG9lcyB0aGUgcHJveHkgcmVsYXkgdG8gdGhlIG9y aWdpbiBzZXJ2ZXI/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHRoZSB0cmlnZ2VycyBjYW5ub3QgYmUgY29tYmluZWQu IHRoZXJlIGlzIG5vIGJlbmVmaXQgdGhlIHByb3h5IGNhbiByZWFsaXplIGZyb20gYm90aCBvYnNl cnZhdGlvbiByZWxhdGlvbnNoaXBzIHVzaW5nIHRoZSBzYW1lIFVSSSAoaS5lLiwgbm8gYmVuZWZp dCBmcm9tIGFueSBzZXBhcmF0aW9uIG9mIFVSSSBhbmQgdHJpZ2dlciBjb25kaXRpb24pLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBpcyBhbGwgdGhlb3JldGljYWwsIG9mIGNvdXJzZSAt LSB0b2RheSdzIHN5c3RlbXMgd291bGQgbW9kZWwgdGhlIHRyaWdnZXIgaW4gdGhlIFVSSSAobW9z dCBsaWtlbHkgdGhlIHF1ZXJ5IHBhcnQpLCBzbyB0aGVyZSBpcyBub3RoaW5nIGEgcHJveHkgY2Fu IGRvIHRvIGNvbWJpbmUgbXVsdGlwbGUgZG93bnN0cmVhbSBvYnNlcnZhdGlvbiByZWxhdGlvbnNo aXBzIGludG8NCiBvbmUgdXBzdHJlYW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5CVFcsIEkn ZCBleHBlY3QgZm9ybWF0cyBzdWNoIGFzIFNlbk1MIHRvIGNvbWUgdXAgd2l0aCBjb252ZW50aW9u cyBmb3IgaG93IHRvIHNwZWNpZnkgc3VjaCB0cmlnZ2Vycy4mbmJzcDsgSlNPTiBwb2ludGVyIGNv bWVzIHRvIG1pbmQgYXMgYSBwb3NzaWJsZSBjb21wb25lbnQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj5Hcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij7DvMOfPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5lLCBDYXJz dGVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --Boundary_(ID_qToSDL3jK7IEUUEHngK06w)-- From jeroen.hoebeke@intec.ugent.be Fri Feb 17 02:37:08 2012 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 DE5D521F878E for ; Fri, 17 Feb 2012 02:37:08 -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=[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 rWc4Xr8zzVNo for ; Fri, 17 Feb 2012 02:37:07 -0800 (PST) Received: from smtp1.UGent.be (smtp1.ugent.be [157.193.71.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA8C21F8605 for ; Fri, 17 Feb 2012 02:37:07 -0800 (PST) Received: from localhost (mcheck5.ugent.be [157.193.49.247]) by smtp1.UGent.be (Postfix) with ESMTP id 12FBD3F6BEA; Fri, 17 Feb 2012 11:37:06 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp1.UGent.be ([157.193.71.182]) by localhost (mcheck5.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id ItxxjIWkh9zK; Fri, 17 Feb 2012 11:37:01 +0100 (CET) Received: from koeck.intec.ugent.be (koeck.intec.ugent.be [157.193.214.150]) (Authenticated sender: jjhoebek) by smtp1.UGent.be (Postfix) with ESMTPSA id 505423F6A5F; Fri, 17 Feb 2012 11:37:01 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Jeroen Hoebeke In-Reply-To: Date: Fri, 17 Feb 2012 11:37:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1A219ABD-874C-47FF-9C7B-2AAF334A12F6@intec.ugent.be> References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> <4F3D7A60.5050305@stpeter.im> To: Li Shitao X-Mailer: Apple Mail (2.1257) X-Miltered: at mcheck5 with ID 4F3E2DCD.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 4F3E2DCD.000 from koeck.intec.ugent.be/koeck.intec.ugent.be/157.193.214.150/koeck.intec.ugent.be/ X-j-chkmail-Score: MSGID : 4F3E2DCD.000 on smtp1.UGent.be : j-chkmail score : . : R=. U=. O=# B=0.000 -> S=0.083 X-j-chkmail-Status: Ham Cc: "core@ietf.org WG" Subject: Re: [core] New Version Notification for draft-li-core-conditional-observe-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 10:37:09 -0000 On 17 Feb 2012, at 02:16, Li Shitao wrote: > Hi all >=20 > I have submit a new draft about condition observe in CoAP, the main = idea is using a new option called "condition" to carry the condition = required by the observer. >=20 > In this draft, it has defined three condition type, the minimum = response time, step and range. The detail usage has defined in this = draft, if you are interested with this=20 >=20 > draft you can find it at = http://datatracker.ietf.org/doc/draft-li-core-conditional-observe/ . Dear Li, all We are also looking into the possibility of using conditional = observations. Based on earlier discussions on the list and the = capabilities of the CoAP protocol, we saw three approaches for realizing = conditional observations: 1) as a new option (in line with your proposal): compact bit-coding of = frequently used conditional observations, the same coding can be used by = a resource to announce how it can be observed (e.g. as part of = .well-known/core) -> we are currently implementing such a solution in = order to do some experiments. So we are definitely interested in your = draft. 2) as part of the URI (as in CoRE Interfaces draft): here you could = choose to use human-readable descriptions of the conditions or = abbreviations in order to save bytes. Using this approach, it is not = completely clear how a resource will describe its observation = capabilities (assuming not all resources will implement the same = conditional observations). You could for example retrieve the = capabilities by making a request using a specific URI query. This = approach is very flexible, but maybe too flexibly if a good agreed set = of conditional observations is absent. 3) through the use of additional resources where you could both retrieve = the possible conditional observations and establish the relationship: = here the description could use semantics=20 One can define many possible conditional observations, but we feel one = will always have frequently occurring conditional observations (such as = thresholds, frequency, variability=85). Having an agreed specification = for such a set could be very useful: e.g. to enable resources to = announce how they can be observed, to achieve intelligent/automated = processing of conditional observations, code reuse for implementing this = on embedded devices... =20 Jeroen --=20 Jeroen Hoebeke Senior Researcher IBBT - IBCN/UGent http://www.ibbt.be http://www.ibcn.intec.UGent.be From salvatore.loreto@ericsson.com Fri Feb 17 03:31:12 2012 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 53D1D21F874A for ; Fri, 17 Feb 2012 03:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.185 X-Spam-Level: X-Spam-Status: No, score=-109.185 tagged_above=-999 required=5 tests=[AWL=0.961, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152, 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 JeLoskZMOxg6 for ; Fri, 17 Feb 2012 03:31:11 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A7EE321F873E for ; Fri, 17 Feb 2012 03:31:10 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-b0-4f3e3a7de8fa Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 14.C7.01970.D7A3E3F4; Fri, 17 Feb 2012 12:31:09 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Fri, 17 Feb 2012 12:31:09 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2E5112323 for ; Fri, 17 Feb 2012 13:31:09 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2260B51B94 for ; Fri, 17 Feb 2012 13:31:09 +0200 (EET) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C882B517EC for ; Fri, 17 Feb 2012 13:31:08 +0200 (EET) Message-ID: <4F3E3A7C.3070508@ericsson.com> Date: Fri, 17 Feb 2012 13:31:08 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: core@ietf.org References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> <4F3D7A60.5050305@stpeter.im> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030401090804050605090104" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] =?utf-8?b?562U5aSNOiAgTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv?= =?utf-8?q?r_draft-li-core-conditional-observe-00=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 11:31:12 -0000 --------------030401090804050605090104 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit On 2/17/12 11:34 AM, Li Shitao wrote: > > Related to the proxy combine. I got a question here, if the proxy > receive two request both to the same URI, but one with the observe > option, another not, if the proxy just do the URI check but no other > option check, > > When the proxy combine those two request together, what will be next? > Forward which request to the server? > > So to my understanding, the proxy at least need to analyze the observe > option, right? Condition option as in my draft, should used together > with the observe option, if the proxy can check the observe option, it > is not hard to do one check about the condition option check. > Hi Li and Carsten I don't understand the issue with the proxy, the draft try to minimize the traffic on the client side so if a proxy starts observation relationships with two or more clients, each with different trigger condition it can just a plain observation relationship with the upstream (the origin) server. It is not necessary (and I do not thing I would like) for the proxy to combine or do any strange or complicate operation before sending it to the origin server. Of course I would expect the proxy filtering the observation to the downstream client based on the right Condition. Having said that, I am not sure I am convinced of the opportunity of having a Condition Option: in a clean Restful architecture everything should be done in a Restful way (i.e. uri-query for the specific scenario); however we have already deviated from the Restful clean architecture several time and actually the Observe scenario is one of them, so if there is really the need for that (a Condition Option) ... why not, but at moment I don't see it -- Salvatore Loreto www.sloreto.com > The main reason, I found URI-query is not so good is, we use uri-query > for many purposes, and most time we query some conditions that are not > related to observe, for a server, its logic needs to be quite > complicated. But using a separate option to do this, can > > simplify the logic of the CoAP server, it does not occupy more bits, > but it save more resource on the server. > > --------------030401090804050605090104 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit On 2/17/12 11:34 AM, Li Shitao wrote:

Related to the proxy combine. I got a question here, if the proxy receive two request both to the same URI, but one with the observe option, another not, if the proxy just do the URI check but no other option check,

When the proxy combine those two request together, what will be next? Forward which request to the server?

 

So to my understanding, the proxy at least need to analyze the observe option, right? Condition option as in my draft, should used together with the observe option, if the proxy can check the observe option, it is not hard to do one check about the condition option check.

Hi Li and Carsten

I don't understand the issue with the proxy,
the draft try to minimize the traffic on the client side so if a proxy starts observation relationships with two or more clients, each with different trigger condition
it can just a plain observation relationship with the upstream (the origin) server. It is not necessary (and I do not thing I would like) for the proxy to combine or
do any strange or complicate operation before sending it to the origin server.
Of course I would expect the proxy filtering the observation to the downstream client based on the right Condition.


Having said that,
I am not sure I am convinced of the opportunity of having a Condition Option:
in a clean Restful architecture everything should be done in a Restful way (i.e. uri-query for the specific scenario);
however we have already deviated from the Restful clean architecture several time and actually the Observe scenario is one of them,
so if there is really the need for that (a Condition Option) ... why not,
but at moment I don't see it

-- 
Salvatore Loreto
www.sloreto.com

 

The main reason, I found URI-query is not so good is, we use uri-query for many purposes, and most time we query some conditions that are not related to observe,  for a server, its logic needs to be quite complicated. But using a separate option to do this, can

 

simplify the logic of the CoAP server, it does not occupy more bits, but it save more resource on the server.

 


--------------030401090804050605090104-- From prvs=73944DF72C=guido.moritz@uni-rostock.de Fri Feb 17 04:43:41 2012 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 7B7A021F875A for ; Fri, 17 Feb 2012 04:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, MANGLED_LOAN=2.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 cMorF5tug5s9 for ; Fri, 17 Feb 2012 04:43:40 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6541921F8759 for ; Fri, 17 Feb 2012 04:43:40 -0800 (PST) From: Guido Moritz To: 'Carsten Bormann' , 'Peter Saint-Andre' Date: Fri, 17 Feb 2012 13:43:39 +0100 Message-ID: <001b01cced71$c60c8b60$5225a220$@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: AcztbonHxOBL8lzGT3G6ZjwWiIuYjQ== Content-Language: de X-Originating-IP: [139.30.201.226] Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 12:43:41 -0000 I have to point out that I got lost somewhere in this discussion about = the EXI content type and encoding. But because I am working with EXI and implementing it for Contiki+TelosB, maybe I could clarify a bit.=20 (Please take care of the used wordings: serialization, encoding and representing) >From a more general data representation perspective, EXI and Unicode XML (e.g. utf-8) are different encodings, which are both capable of = representing the same serialized structured data objects. Native Unicode XML can have different encodings like e.g. utf-8 and utf-16. The EXI Format is a completely different encoding format.=20 EXI has much more options, leading to very different meanings about what = a single bit or byte on a wire stands for. EXI e.g. differentiates between schema-informed, schema-less, strict, non-strict, bit-aligned, = byte-aligned and compressed modes and their combination (just to name few of the = relevant buzz words). Hence, the EXI format has its very own mechanisms within an = EXI stream to indicate the encoding mode and options to be used to parse = each single stream. Summing up my suggestion would be: 1) EXI is a very important format for constrained environments and must = be considered 2) Keep application/exi media type as it is 3) Do not add any further content encoding options for the EXI format, = as such indication mechanism are already part of the EXI format itself. Defining such additional options for e.g. CoAP or HTTP is out of scope = for the CoRE WG. If required, it MUST be part of the EXI standardization = process within the W3C to define the option values and their semantics in the context of the EXI format. Sorry if I did not got the point of the discussion,=20 Guido > -----Urspr=FCngliche Nachricht----- > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von > Carsten Bormann > Gesendet: Donnerstag, 16. Februar 2012 23:10 > An: Peter Saint-Andre > Cc: core@ietf.org WG > Betreff: Re: [core] Resolution to tickets #176, #177, #181 >=20 > On Feb 16 2012, at 22:51, Peter Saint-Andre wrote: >=20 > > > > > > On 2/15/12 8:23 AM, Carsten Bormann wrote: > > > >> As a result, we are proposing the body of coap-misc as the = resolution > >> for tickets #176, #177 (and indirectly for #174), and #181, as well > >> as the vendor-defined option that was discussed. > > > > Regarding #181, would the proposed change obviate the need for the > > +exi > > prefix as discussed on the apps-discuss list (since CoAP entities > > could > > handle content-encoding)? >=20 > I think that discussion is slightly confused (I haven't tried to > intervene, as I'm not an EXI person). >=20 > application/foo+exi could be a media type for a schema-informed EXI > encoding of foo+xml. > Content-Encoding is meant to be futzed with in proxies (all the 214 > verbage notwithstanding), so from my point of view needs to be > schemaless. >=20 > But there are a lot of angels and pinheads in the interpretation of > these attributes and concepts, so I think we need to be able to cope > with both outcomes. >=20 > The Content-Encoding column is mainly an insurance against people > claiming we need a Content-Encoding Option in CoAP because we can't > have encoded media types. > HTTP wants media type and Content-Encoding to be orthogonal and freely > combinable. > Since constrained devices are unlikely to have that level of > orthogonality, I'd rather make it obvious that both media type and > Content-Encoding are tied together in your decision of what to ship > over the wireless. >=20 > If the "you can't have +exi but must encode that aspect of the > representation format in Content-Encoding" faction wins, there will be > zero change for us, except in the documents where we replace "+exi --" > with "+xml exi" in some tables. >=20 > Protocol design 101: Design so you win with either possible outcome of > a tussle. >=20 > Gruesse, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From trac+core@trac.tools.ietf.org Fri Feb 17 04:53:33 2012 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 65B8821F86DA for ; Fri, 17 Feb 2012 04:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 3oUkBgMvy9eV for ; Fri, 17 Feb 2012 04:53:32 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 302AB21F86D9 for ; Fri, 17 Feb 2012 04:53:31 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RyNJY-0004TJ-VH; Fri, 17 Feb 2012 07:53:29 -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: hartke@tzi.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 17 Feb 2012 12:53:28 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/174#comment:4 Message-ID: <068.975701694dbd00cbebaf4eb30985064d@trac.tools.ietf.org> References: <053.70316ef76a2aab1204bc99bad86807ea@trac.tools.ietf.org> X-Trac-Ticket-ID: 174 In-Reply-To: <053.70316ef76a2aab1204bc99bad86807ea@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, cabo@tzi.org, 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: Re: [core] #174: Robust observation relationships 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: Fri, 17 Feb 2012 12:53:33 -0000 #174: Robust observation relationships Comment (by cabo@…): If Pledge or something similar is the medium-term solution, maybe there is one last thing that could be added to base -observe now: An implementation note with a short discussion of the inaccuracy of clocks and the influence of propagation delays — a naive implementation might have the re-subscribe of the client and new notification after max-age cross over each other. -- -----------------------------------+----------------------- Reporter: hartke@… | Owner: hartke@… Type: protocol defect | Status: reopened Priority: major | Milestone: Component: observe | Version: Severity: Submitted WG Document | Resolution: Keywords: | -----------------------------------+----------------------- Ticket URL: core From cabo@tzi.org Fri Feb 17 05:11:29 2012 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 7DEEB21F8693 for ; Fri, 17 Feb 2012 05:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.737 X-Spam-Level: X-Spam-Status: No, score=-105.737 tagged_above=-999 required=5 tests=[AWL=0.512, 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 CH7-VUf5OoMr for ; Fri, 17 Feb 2012 05:11:29 -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 E9D2921F87D6 for ; Fri, 17 Feb 2012 05:11:20 -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 q1HDBDcJ002182; Fri, 17 Feb 2012 14:11:13 +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 8703DBB4; Fri, 17 Feb 2012 14:11:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> Date: Fri, 17 Feb 2012 14:11:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 13:11:29 -0000 On Feb 17, 2012, at 13:43, Guido Moritz wrote: > 2) Keep application/exi media type as it is That is the point where the discussion begins: application/exi tells you about the basic syntax, but not about the = interpretation of the data. There are about three base syntaxes of interest right now: (character) = XML, EXI, and JSON. But we also need higher level format definitions such as senml, which in = turn can use (character) XML, EXI, JSON. So how do we encode the combination? SenML says: 6. JSON Representation (application/senml+json) . . . . . . . . . 7 7. XML Representation (application/senml+xml) . . . . . . . . . . 11 8. EXI Representation (application/senml+exi) . . . . . . . . . . 12 Works for me. But then there are purists that think EXI is a Content-Encoding of XML = (while character XML is "unencoded" XML). So in HTTP you would have: Content-Type: application/senml+xml Content-Encoding: exi While the other two would be: Content-Type: application/senml+json and Content-Type: application/senml+xml To isolate us from this discussion, I propose to combine the media type = and the Content-Encoding in our numeric Content-Type option. Gr=FC=DFe, Carsten From prvs=839495AD90=guido.moritz@uni-rostock.de Fri Feb 17 05:34:24 2012 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 B425B21F8769 for ; Fri, 17 Feb 2012 05:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=1.329, 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 J7FKFsSF0Cs7 for ; Fri, 17 Feb 2012 05:34:24 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id E1D3B21F84D3 for ; Fri, 17 Feb 2012 05:34:23 -0800 (PST) From: Guido Moritz To: 'Carsten Bormann' References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> In-Reply-To: <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> Date: Fri, 17 Feb 2012 14:34:30 +0100 Message-ID: <001e01cced78$e09dd400$a1d97c00$@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: AQJDql7zU4g+F/NRwedVXTOjNtAGiwLaQyC+lTzH7AA= Content-Language: de X-Originating-IP: [139.30.201.226] Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 13:34:24 -0000 > > 2) Keep application/exi media type as it is > > That is the point where the discussion begins: > application/exi tells you about the basic syntax, but not about the interpretation > of the data. > There are about three base syntaxes of interest right now: (character) XML, > EXI, and JSON. > But we also need higher level format definitions such as senml, which in turn > can use (character) XML, EXI, JSON. > So how do we encode the combination? > > SenML says: > > 6. JSON Representation (application/senml+json) . . . . . . . . . 7 > 7. XML Representation (application/senml+xml) . . . . . . . . . . 11 > 8. EXI Representation (application/senml+exi) . . . . . . . . . . 12 > > Works for me. Works this way also for HTTP as far as I know and also for other applications specific formats (e.g. SOAP ;). application/soap+xml application/soap+exi > But then there are purists that think EXI is a Content-Encoding of XML (while > character XML is "unencoded" XML). Wrong! As stated in my last mail, EXI and Unicode (you say character) XML are different encodings for one and the same serialized data objects. JSON and Fast Infoset are the next two candidates. All these formats are not generated from the Unicode (character) XML, but instead in parallel to Unicode (character) XML. The purists should keep in mind that 'XML' is a quite verbose standards family and not only the single encoding format they have in mind. > To isolate us from this discussion, I propose to combine the media type and the > Content-Encoding in our numeric Content-Type option. +1. Maybe still requires careful attention for each dedicated format. Guido From cabo@tzi.org Fri Feb 17 06:24:57 2012 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 9826F21F8603 for ; Fri, 17 Feb 2012 06:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.794 X-Spam-Level: X-Spam-Status: No, score=-105.794 tagged_above=-999 required=5 tests=[AWL=0.455, 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 nINoXy42f+Pb for ; Fri, 17 Feb 2012 06:24:56 -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 8A4DD21F8595 for ; Fri, 17 Feb 2012 06:24:56 -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 q1HEOlw5003754; Fri, 17 Feb 2012 15:24:47 +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 F2B4EC2D; Fri, 17 Feb 2012 15:24:46 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> Date: Fri, 17 Feb 2012 15:24:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 14:24:57 -0000 On Feb 17, 2012, at 14:34, Guido Moritz wrote: > application/soap+xml > application/soap+exi Yeah, except that the first one exists and the other one doesn't: http://www.iana.org/assignments/media-types/application/index.html >=20 >> But then there are purists that think EXI is a Content-Encoding of = XML > (while >> character XML is "unencoded" XML). >=20 > Wrong! You and I agree on that=85 But there is still considerable confusion in the wider community. > As stated in my last mail, EXI and Unicode (you say character) XML > are different encodings for one and the same serialized data objects. = JSON > and Fast Infoset Yep: application/soap+fastinfoset [ITU-T ASN.1 Rapporteur] > are the next two candidates. (Except that JSON has a different abstract syntax, too.) > All these formats are not > generated from the Unicode (character) XML, but instead in parallel to > Unicode (character) XML. The purists should keep in mind that 'XML' is = a > quite verbose standards family and not only the single encoding format = they > have in mind. (In SGML, we called that a "concrete syntax". ASN.1 has encoding rules. = Etc.) >> To isolate us from this discussion, I propose to combine the media = type > and the >> Content-Encoding in our numeric Content-Type option. >=20 > +1. Maybe still requires careful attention for each dedicated format.=20= I think the two of us agree that viewing EXI as a Content-Encoding of = (character) XML is problematic. Gr=FC=DFe, Carsten From stpeter@stpeter.im Fri Feb 17 08:06:23 2012 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 158BA21F8678 for ; Fri, 17 Feb 2012 08:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 6q1kz5PcC+dn for ; Fri, 17 Feb 2012 08:06:22 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6186621F8870 for ; Fri, 17 Feb 2012 08:06:22 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7A03240058; Fri, 17 Feb 2012 09:17:20 -0700 (MST) Message-ID: <4F3E758B.8020007@stpeter.im> Date: Fri, 17 Feb 2012 08:43:07 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Carsten Bormann References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> In-Reply-To: <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:06:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/17/12 7:24 AM, Carsten Bormann wrote: > On Feb 17, 2012, at 14:34, Guido Moritz wrote: > >> application/soap+xml application/soap+exi > > Yeah, except that the first one exists and the other one doesn't: > > http://www.iana.org/assignments/media-types/application/index.html I am not an EXI expert, but my understanding from a conversation with Zach in Taipei (and afterward on the apps-discuss list) is that one could see EXI as either (1) a content-encoding of XML or (2) a new and different content-type. The matter isn't settled, but it would be good to settle it. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8+dYsACgkQNL8k5A2w/vz7BACbBfWt68yfJRrKPxiqKWbKvJJo YLwAn1F3Y/m1nFGbBO+OAAOtLSZyDCRI =uzzL -----END PGP SIGNATURE----- From zach@sensinode.com Fri Feb 17 08:25:36 2012 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 A204A21F8866 for ; Fri, 17 Feb 2012 08:25:36 -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 HOuH-r7msTmi for ; Fri, 17 Feb 2012 08:25:35 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 509CD21F8786 for ; Fri, 17 Feb 2012 08:25:34 -0800 (PST) Received: from [192.168.1.103] (87-93-48-9.bb.dnainternet.fi [87.93.48.9]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q1HGPU9l015658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Feb 2012 18:25:31 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4F3E758B.8020007@stpeter.im> Date: Fri, 17 Feb 2012 18:25:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5AAD1595-F8EC-443F-B085-71759FE21DC2@sensinode.com> References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> <4F3E758B.8020007@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:25:36 -0000 On Feb 17, 2012, at 5:43 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > >=20 > On 2/17/12 7:24 AM, Carsten Bormann wrote: >> On Feb 17, 2012, at 14:34, Guido Moritz wrote: >>=20 >>> application/soap+xml application/soap+exi >>=20 >> Yeah, except that the first one exists and the other one doesn't: >>=20 >> http://www.iana.org/assignments/media-types/application/index.html >=20 > I am not an EXI expert, but my understanding from a conversation with > Zach in Taipei (and afterward on the apps-discuss list) is that one > could see EXI as either (1) a content-encoding of XML or (2) a new and > different content-type. The matter isn't settled, but it would be good > to settle it. :) And regarding the +exi registration requirements I have an AP to write = up a -00 draft on that. Will forward that also to this WG. 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 From prvs=63945112D4=guido.moritz@uni-rostock.de Fri Feb 17 12:14:44 2012 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 7DC2621F8685 for ; Fri, 17 Feb 2012 12:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[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 5Ln2zFmIrs12 for ; Fri, 17 Feb 2012 12:14:43 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 29E8621F8686 for ; Fri, 17 Feb 2012 12:14:42 -0800 (PST) From: Guido Moritz To: 'Peter Saint-Andre' , 'Carsten Bormann' References: <001b01cced71$c60c8b60$5225a220$@uni-rostock.de> <07CC0900-8116-4242-AB96-D74879E247D8@tzi.org> <001e01cced78$e09dd400$a1d97c00$@uni-rostock.de> <73456E11-9651-4FB8-82E3-1CBC490C55DF@tzi.org> <4F3E758B.8020007@stpeter.im> In-Reply-To: <4F3E758B.8020007@stpeter.im> Date: Fri, 17 Feb 2012 21:14:48 +0100 Message-ID: <000f01ccedb0$cd0fe620$672fb260$@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: AQJDql7zU4g+F/NRwedVXTOjNtAGiwLaQyC+AQgANPwBs7Xr8wLC71iMlRFALKA= Content-Language: de X-Originating-IP: [78.54.34.94] Cc: core@ietf.org Subject: Re: [core] EXI content type and encoding (was: Resolution to tickets #176, #177, #181) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 20:14:44 -0000 > I am not an EXI expert, but my understanding from a conversation with > Zach in Taipei (and afterward on the apps-discuss list) is that one > could see EXI as either (1) a content-encoding of XML or (2) a new and > different content-type. The matter isn't settled, but it would be good > to settle it. :) I also had to think about this issue for a while, because I have to = explain the differences and perspectives as part of my Phd thesis...keep = fingers cross to have finished it before Paris ;). Overall I concluded = in (2) and describe EXI as a completely new and different = 'content-type', i.e. 'on wire encoding' of XML-Infoset serialized object = structures. I think how and why people favor one of the two options is how they use = it. There are applications/implementations that are already using XML = and to save bandwidth now the data stream is changed for several = parts/communications into the EXI format. In this use case, EXI can even = be a compressor, i.e. compression is the process changing the data = representation to a more efficient one. But because their = applications/implementations are still parsing and processing native = Unicode XML, EXI is just another encoding for the existing XML = structures. From this perspective absolutely feasibly to favor (1).=20 But EXI is, in contrast to e.g. gzip, also capable to be a standalone = representation that can be parsed and processed directly by the = implementations. This is how the EXI format was designed by the W3C, as = a complete replacement for Unicode XML if required. In this case there = is no need to change EXI to XML to process it. In this case (2) is more = feasible. And this is also the way we are using EXI within our = 6LoWPAN-related implementations.=20 My 2 cents, Maybe we can discuss it in Paris while having a nice wine,=20 Guido From cabo@tzi.org Sat Feb 18 01:29:32 2012 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 BAEB521F859B for ; Sat, 18 Feb 2012 01:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.889 X-Spam-Level: X-Spam-Status: No, score=-103.889 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, 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 B7jNLO8kWkY4 for ; Sat, 18 Feb 2012 01:29: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 B021021F859A for ; Sat, 18 Feb 2012 01:29:31 -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 q1I9TLh2004884; Sat, 18 Feb 2012 10:29:21 +0100 (CET) Received: from [192.168.2.3] (ip-2-202-182-191.web.vodafone.de [2.202.182.191]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 88C45DC7; Sat, 18 Feb 2012 10:29:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F3E3A7C.3070508@ericsson.com> Date: Sat, 18 Feb 2012 10:29:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> <4F3D7A60.5050305@stpeter.im> <4F3E3A7C.3070508@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] =?utf-8?b?562U5aSNOiAgTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv?= =?utf-8?q?r_draft-li-core-conditional-observe-00=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 09:29:32 -0000 On Feb 17, 2012, at 12:31, Salvatore Loreto wrote: > I don't understand the issue with the proxy, I apologize for not making myself clear. There is no issue. Let's try again: 1) If you want to do trigger specifications now, you can put them in the URI. So I don't personally see a need for urgent action. 1a) Trigger specs are by necessity somewhat application specific. If you are interested in more standardization in this space, it is probably most productive to work within the framework of the application data formats of interest, such as SenML. 2) If we do not just want to standardize elements of a URI-based way of doing this, but want to pull down some of this functionality to the level of the CoAP protocol (e.g., in the form of a new CoAP Option), we should have a reason for that. 2a) One reason might be that we want to integrate better into the CoAP caching/proxying model. 2b) Problem statement: Putting trigger specs in the URI means that a proxy that makes one resource upstream available to two clients downstream cannot make out this fact if the trigger specs are different. E.g., a temp sensor that can provide data in regular intervals, one client that want a new temperature every minute and one that wants one every two minutes -- all the proxy sees are two different URIs; it therefore cannot combine its two downstream observation relationships into a single upstream one (here: once every minute). 2c) Again, a solution will need to tie in with application semantics, so doing 1a first will help us with doing 2 right. So what I was arguing for was to put some energy first into looking into trigger specs in the context of SenML or your favorite application data format. Gr=FC=DFe, Carsten From salvatore.loreto@ericsson.com Sat Feb 18 05:36:45 2012 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 018BB21F8514 for ; Sat, 18 Feb 2012 05:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.451 X-Spam-Level: X-Spam-Status: No, score=-109.451 tagged_above=-999 required=5 tests=[AWL=1.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 cJA+amhDZN4b for ; Sat, 18 Feb 2012 05:36:43 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1C48121F850F for ; Sat, 18 Feb 2012 05:36:42 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-6d-4f3fa969c1e0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D0.04.01970.969AF3F4; Sat, 18 Feb 2012 14:36:41 +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.213.0; Sat, 18 Feb 2012 14:36:41 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2C4D52320 for ; Sat, 18 Feb 2012 15:36:41 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F2E7751E54 for ; Sat, 18 Feb 2012 15:36:40 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AF5BC51DD1 for ; Sat, 18 Feb 2012 15:36:40 +0200 (EET) Message-ID: <4F3FA968.10802@ericsson.com> Date: Sat, 18 Feb 2012 15:36:40 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: core@ietf.org References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> In-Reply-To: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> Content-Type: multipart/alternative; boundary="------------060908070509080109080009" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [core] Patience ( was Re: Resolution to tickets #176, #177, #181) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 13:36:45 -0000 --------------060908070509080109080009 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit as pointed out by Kepeng in http://www.ietf.org/mail-archive/web/core/current/msg02644.html we are working together to propose a solution for 174 that somehow overload the Patience Option to clearly and cleanly solve all the three different different case (Section 4.1 Patience, 4.2 Leisure, 4.3 Pledge you have at moment in coap-misc ) I don't see the need to define three different Options, but lets discuss it on the mailing list once the draft will be released and eventually in one of the CoRe sessions in Paris. The first version of the draft is almost ready and Li Kepeng will submit the draft in the next few days.. regards Sal -- Salvatore Loreto www.sloreto.com On 2/15/12 5:23 PM, Carsten Bormann wrote: > Klaus and I sat together today and rearranged coap-misc, moving stuff that isn't ready for standardization to the appendices and finishing other stuff. > > As a result, we are proposing the body of coap-misc as the resolution for tickets #176, #177 (and indirectly for #174), and #181, as well as the vendor-defined option that was discussed. > > If these solutions are acceptable, this leaves us with #166 and #183 (#182 already has proposed text and just needs to be applied) on core-coap. I also have to generate a proposal for #171 (block), and we need to decide whether #170 really needs any work. > > I am optimistic we can finish all this in the next couple of days, so we have a set of documents that the authors believe is ready for WGLC. > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------060908070509080109080009 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit as pointed out by Kepeng in
http://www.ietf.org/mail-archive/web/core/current/msg02644.html

we are working together to propose a solution for 174
that somehow overload the Patience Option
to clearly and cleanly solve  all the three different different case (Section 4.1 Patience, 4.2 Leisure, 4.3 Pledge you have at moment in coap-misc )

I don't see the need to define three different Options, but lets discuss it on the mailing list once the draft will be released
and eventually in one of the CoRe sessions in Paris.

The first version of the draft is almost ready and Li Kepeng will submit the draft in the next few days..

regards
Sal
-- 
Salvatore Loreto
www.sloreto.com



On 2/15/12 5:23 PM, Carsten Bormann wrote: 
Klaus and I sat together today and rearranged coap-misc, moving stuff that isn't ready for standardization to the appendices and finishing other stuff.

As a result, we are proposing the body of coap-misc as the resolution for tickets #176, #177 (and indirectly for #174), and #181, as well as the vendor-defined option that was discussed.

If these solutions are acceptable, this leaves us with #166 and #183 (#182 already has proposed text and just needs to be applied) on core-coap.  I also have to generate a proposal for #171 (block), and we need to decide whether #170 really needs any work.

I am optimistic we can finish all this in the next couple of days, so we have a set of documents that the authors believe is ready for WGLC.

Grüße, Carsten

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

--------------060908070509080109080009-- From salvatore.loreto@ericsson.com Sat Feb 18 09:52:50 2012 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 7D60121F8577 for ; Sat, 18 Feb 2012 09:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.272 X-Spam-Level: X-Spam-Status: No, score=-109.272 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152, 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 FGwT8NOSqLxp for ; Sat, 18 Feb 2012 09:52:49 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF9F21F857F for ; Sat, 18 Feb 2012 09:52:48 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-eb-4f3fe56f7e90 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 4D.BD.01970.F65EF3F4; Sat, 18 Feb 2012 18:52:48 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Sat, 18 Feb 2012 18:52:47 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4B8802320; Sat, 18 Feb 2012 19:52:47 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 25E1251E54; Sat, 18 Feb 2012 19:52:47 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C618551DD1; Sat, 18 Feb 2012 19:52:46 +0200 (EET) Message-ID: <4F3FE56E.7010608@ericsson.com> Date: Sat, 18 Feb 2012 19:52:46 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Carsten Bormann References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> <4F3D7A60.5050305@stpeter.im> <4F3E3A7C.3070508@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: "core@ietf.org" Subject: Re: [core] =?utf-8?b?562U5aSNOiAgTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv?= =?utf-8?q?r_draft-li-core-conditional-observe-00=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 17:52:50 -0000 in line On 2/18/12 11:29 AM, Carsten Bormann wrote: > On Feb 17, 2012, at 12:31, Salvatore Loreto wrote: > >> I don't understand the issue with the proxy, > I apologize for not making myself clear. > There is no issue. > Let's try again: > > 1) If you want to do trigger specifications now, you can put them in > the URI. So I don't personally see a need for urgent action. and I fully agree with you here! > > 1a) Trigger specs are by necessity somewhat application specific. If > you are interested in more standardization in this space, it is > probably most productive to work within the framework of the > application data formats of interest, such as SenML. > > 2) If we do not just want to standardize elements of a URI-based way > of doing this, "*to standardize* elements of a URI-based way"??? what do you mean, here? > but want to pull down some of this functionality to > the level of the CoAP protocol (e.g., in the form of a new CoAP > Option), we should have a reason for that. agreed with you that at moment there are no clear use cases for this! > > 2a) One reason might be that we want to integrate better into the CoAP > caching/proxying model. > > 2b) Problem statement: Putting trigger specs in the URI means that a > proxy that makes one resource upstream available to two clients > downstream cannot make out this fact if the trigger specs are > different. E.g., a temp sensor that can provide data in regular > intervals, one client that want a new temperature every minute and > one that wants one every two minutes -- all the proxy sees are two > different URIs; it therefore cannot combine its two downstream > observation relationships into a single upstream one (here: once > every minute). maybe here, was my turn to not be able to explain myself clearly for the use case you described in 2b I think that a possible and simple solution would be for the proxy to simply do a single plain (or full if you prefer) relationship upstream and then apply the filtering stuff locally (in the proxy/cache)... However this imply quite a lot of intelligence in the proxy, and I am not sure I like it. > > 2c) Again, a solution will need to tie in with application semantics, > so doing 1a first will help us with doing 2 right. > > So what I was arguing for was to put some energy first into looking > into trigger specs in the context of SenML or your favorite > application data format. agree that more investigation are necessary cheers Salvatore -- Salvatore Loreto www.sloreto.com From therbst@silverspringnet.com Sat Feb 18 10:27:53 2012 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 9ABFA21F85D5 for ; Sat, 18 Feb 2012 10:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 jxQtITyWod54 for ; Sat, 18 Feb 2012 10:27:53 -0800 (PST) Received: from it-ipdr-01.silverspringnet.com (it-ipdr-01.silverspringnet.com [74.121.22.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1C60121F857F for ; Sat, 18 Feb 2012 10:27:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAHPsP08KOQxz/2dsb2JhbABEsyyBejo/EgEVKUImAQQOwRqMEBgGBQoMBQkKCwEQA4cxBIhOkmiNDw X-IronPort-AV: E=Sophos;i="4.73,443,1325491200"; d="scan'208";a="1170229" Received: from unknown (HELO SFO-EXCA-02.silverspringnet.com) ([10.57.12.115]) by it-ipdr-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 18 Feb 2012 10:27:52 -0800 Received: from IT-EXCA-01.silverspringnet.com (10.200.1.60) by SFO-EXCA-02.silverspringnet.com (10.57.12.101) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 18 Feb 2012 10:27:52 -0800 Received: from IT-RESTORE-01.silverspringnet.com ([::1]) by IT-EXCA-01.silverspringnet.com ([::1]) with mapi; Sat, 18 Feb 2012 10:27:52 -0800 From: Thomas Herbst To: "core@ietf.org" Date: Sat, 18 Feb 2012 10:27:50 -0800 Thread-Topic: Protocol Constants section of coap-08 Thread-Index: AczuawWXS7LfDBeoRDWXveCk1PsMyQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [core] Protocol Constants section of coap-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 18:27:53 -0000 Trying to come up with a better way to deal with the protocol constants section. Obvious first edit is that all three values - Timeout, random factor and max retransmits should be configurable. Next step might be to state that these are configurable, but the configuration is out of scope of this document. Deployment guidance could be that the numbers should be constant for any given network, though I can think of several cases where I might have different constants for different node types, but that is me playing with my own rope. On the specific numbers, 2 seconds is way too short of a default for our networks, but I understand having everyone use our constants for their smaller networks may make the smaller networks slower than necessary. Someone putting an unconfigured device on a network should work. Best case would be the unconfigured device would work efficiently. Tom ------------------------------------------ 9. Protocol Constants This section defines the relevant protocol constants defined in this document: RESPONSE_TIMEOUT 2 seconds RESPONSE_RANDOM_FACTOR 1.5 MAX_RETRANSMIT 4 Future specifications are expected that will allow implementations to use other sources for initializing RESPONSE_TIMEOUT. The RESPONSE_TIMEOUT variable MAY be configured with a different value for special environments that exhibit very short or very long RTTs. From jmh@joelhalpern.com Sat Feb 18 11:25:14 2012 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 69A7021F8573; Sat, 18 Feb 2012 11:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 y1bKk0LDdgQn; Sat, 18 Feb 2012 11:25:14 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id EBA6E21F856D; Sat, 18 Feb 2012 11:25:13 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id C736ECD0F3; Sat, 18 Feb 2012 11:25:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 42E221BC907D; Sat, 18 Feb 2012 11:25:13 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 082801BC9079; Sat, 18 Feb 2012 11:25:13 -0800 (PST) Message-ID: <4F3FFB16.6030502@joelhalpern.com> Date: Sat, 18 Feb 2012 14:25:10 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: gen-art@ietf.org References: <4F3D931C.1000101@nostrum.com> In-Reply-To: <4F3D931C.1000101@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 18 Feb 2012 13:01:10 -0800 Cc: cabo@tsi.org, "A. Jean Mahoney" , core@ietf.org Subject: [core] [Gen-art] Review: draft-ietf-core-link-format-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 19:25:14 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-core-link-format-11 CoRE Link Format Reviewer: Joel M. Halpern Review Date: 18-Feb 2012 IETF LC End Date: 28-Feb-2012 IESG Telechat date: N/A Summary: This document is almost ready for publication as a proposed standard. Major issues: What is the registration / collision avoidance strategy for resource type (rt) and interface description (if) values? They are both defined as opaque strings which can happen to be URIs. So there seems to be potential for collision. Minor issues: Would it be sensible, in the introduction, when the well-known URI is first introduced, to refer to it as a "well-known relative URI"? Should this document register a resource type (rt) and interface description (if) for the server resource manager itself? The text refers to using multicast to find resources, with filtering based on rt and if. (This would, I think, be defined in section 4, and registered in the IANA considerations section?) Presumably all devices would support the interface, which is why a resource type for the master server would seem useful. Nits/editorial comments: From zach@sensinode.com Sun Feb 19 05:21:52 2012 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 9638021F8566 for ; Sun, 19 Feb 2012 05:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 DRe6wh09wq8s for ; Sun, 19 Feb 2012 05:21:51 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6E921F84F2 for ; Sun, 19 Feb 2012 05:21:50 -0800 (PST) Received: from [192.168.1.105] (188-67-143-124.bb.dnainternet.fi [188.67.143.124]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q1JDLjd3027436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 19 Feb 2012 15:21:47 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Sun, 19 Feb 2012 15:21:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <87779E67-8B28-4BA5-B39A-2C816F107264@sensinode.com> References: To: Thomas Herbst X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" Subject: Re: [core] Protocol Constants section of coap-08 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, 19 Feb 2012 13:21:52 -0000 Tom, Agreeing with you on all points. The intention has been that those = constants are configurable. Could you propose some new text? Regarding RESPONSE_TIMEOUT, I would like to find a default value that = works for the majority of LoWPANs at least. Don't see a problem in = increasing that somewhat, for example to 3-4 seconds. With a longer = starting timeout, it may make sense to reduce MAX_RETRANSMIT to 3. Zach On Feb 18, 2012, at 8:27 PM, Thomas Herbst wrote: > Trying to come up with a better way to deal with the protocol = constants > section. >=20 > Obvious first edit is that all three values - Timeout, random factor = and > max retransmits should be configurable. >=20 > Next step might be to state that these are configurable, but the > configuration is out of scope of this document. >=20 > Deployment guidance could be that the numbers should be constant for = any > given network, though I can think of several cases where I might have > different constants for different node types, but that is me playing = with > my own rope. >=20 > On the specific numbers, 2 seconds is way too short of a default for = our > networks, but I understand having everyone use our constants for their > smaller networks may make the smaller networks slower than necessary. >=20 > Someone putting an unconfigured device on a network should work. Best > case would be the unconfigured device would work efficiently. >=20 >=20 >=20 > Tom > ------------------------------------------ >=20 > 9. Protocol Constants > This section defines the relevant protocol constants defined in this > document: > RESPONSE_TIMEOUT 2 seconds > RESPONSE_RANDOM_FACTOR 1.5 > MAX_RETRANSMIT 4 > Future specifications are expected that will allow implementations to = use > other sources for initializing RESPONSE_TIMEOUT. The RESPONSE_TIMEOUT > variable MAY be configured with a different value for special = environments > that exhibit very short or very long RTTs. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From lishitao@huawei.com Sun Feb 19 22:40:15 2012 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 D002921F868C for ; Sun, 19 Feb 2012 22:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 C8J5pACtHDxn for ; Sun, 19 Feb 2012 22:40:15 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC4221F868A for ; Sun, 19 Feb 2012 22:40:14 -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 <0LZO006F9IIQ8M@szxga03-in.huawei.com> for core@ietf.org; Mon, 20 Feb 2012 14:40:03 +0800 (CST) Received: from szxrg01-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 <0LZO00MC7IIQ2F@szxga03-in.huawei.com> for core@ietf.org; Mon, 20 Feb 2012 14:40:02 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGY31819; Mon, 20 Feb 2012 14:40:01 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 20 Feb 2012 14:39:45 +0800 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.222]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 20 Feb 2012 14:39:57 +0800 Date: Mon, 20 Feb 2012 06:40:52 +0000 From: Li Shitao In-reply-to: X-Originating-IP: [10.138.73.34] To: Carsten Bormann , Salvatore Loreto Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: =?utf-8?B?W2NvcmVdIOetlOWkjTogIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig?= =?utf-8?Q?draft-li-core-conditional-observe-00.txt?= Thread-index: AQHM7WetNrxlcXR2oUyqvEhzM6WKzJZB3qiAgANxlnA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> <4F3D7A60.5050305@stpeter.im> <4F3E3A7C.3070508@ericsson.com> Cc: "core@ietf.org" Subject: [core] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgTmV3IFZlcnNpb24gTm90aWZp?= =?utf-8?q?cation_for_draft-li-core-conditional-observe-00=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 06:40:15 -0000 aGkgQ2Fyc3RlbiBhbmQgYWxsDQoNCnBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lLg0KDQpT aGl0YW8NCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBjb3JlLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBDYXJzdGVuIEJv cm1hbm4NCuWPkemAgeaXtumXtDogMjAxMuW5tDLmnIgxOOaXpSAxNzoyOQ0K5pS25Lu25Lq6OiBT YWx2YXRvcmUgTG9yZXRvDQrmioTpgIE6IGNvcmVAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtjb3Jl XSDnrZTlpI06IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktY29yZS1jb25k aXRpb25hbC1vYnNlcnZlLTAwLnR4dA0KDQpPbiBGZWIgMTcsIDIwMTIsIGF0IDEyOjMxLCBTYWx2 YXRvcmUgTG9yZXRvIHdyb3RlOg0KDQo+IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgaXNzdWUgd2l0 aCB0aGUgcHJveHksDQoNCkkgYXBvbG9naXplIGZvciBub3QgbWFraW5nIG15c2VsZiBjbGVhci4N ClRoZXJlIGlzIG5vIGlzc3VlLg0KTGV0J3MgdHJ5IGFnYWluOg0KDQoxKSBJZiB5b3Ugd2FudCB0 byBkbyB0cmlnZ2VyIHNwZWNpZmljYXRpb25zIG5vdywgeW91IGNhbiBwdXQgdGhlbSBpbg0KICAg dGhlIFVSSS4gIFNvIEkgZG9uJ3QgcGVyc29uYWxseSBzZWUgYSBuZWVkIGZvciB1cmdlbnQgYWN0 aW9uLg0KDQoxYSkgVHJpZ2dlciBzcGVjcyBhcmUgYnkgbmVjZXNzaXR5IHNvbWV3aGF0IGFwcGxp Y2F0aW9uIHNwZWNpZmljLiAgSWYNCiAgIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBtb3JlIHN0YW5k YXJkaXphdGlvbiBpbiB0aGlzIHNwYWNlLCBpdCBpcw0KICAgcHJvYmFibHkgbW9zdCBwcm9kdWN0 aXZlIHRvIHdvcmsgd2l0aGluIHRoZSBmcmFtZXdvcmsgb2YgdGhlDQogICBhcHBsaWNhdGlvbiBk YXRhIGZvcm1hdHMgb2YgaW50ZXJlc3QsIHN1Y2ggYXMgU2VuTUwuDQoNCltzaGl0YW9dIEkgYWdy ZWUsIHdlIGNhbiB1c2UgU2VuTUwgdG8gZGVpZm5lIHNvbWUgbW9yZSBpbnRlcmVzdGVkIGRhdGEg Zm9ybWF0cyBmb3IgYXBwbGljYXRpb24gdXNhZ2UuDQoNCjIpIElmIHdlIGRvIG5vdCBqdXN0IHdh bnQgdG8gc3RhbmRhcmRpemUgZWxlbWVudHMgb2YgYSBVUkktYmFzZWQgd2F5DQogICBvZiBkb2lu ZyB0aGlzLCBidXQgd2FudCB0byBwdWxsIGRvd24gc29tZSBvZiB0aGlzIGZ1bmN0aW9uYWxpdHkg dG8NCiAgIHRoZSBsZXZlbCBvZiB0aGUgQ29BUCBwcm90b2NvbCAoZS5nLiwgaW4gdGhlIGZvcm0g b2YgYSBuZXcgQ29BUA0KICAgT3B0aW9uKSwgd2Ugc2hvdWxkIGhhdmUgYSByZWFzb24gZm9yIHRo YXQuDQoNCltzaGl0YW9deWVzLCBzbyB3ZSBjYW4gZmlyc3QgZGVmaW5lIG91ciBpbnRlcmVzdGlu ZyB0cmlnZ2VycyAoY29uZGl0aW9ucyksIHRoZW4gd2UgY2FuIHNlZSBpZiBhIG5ldyBvcHRpb24g aXMgbmVlZGVkIG9yIG5vdC4NCg0KMmEpIE9uZSByZWFzb24gbWlnaHQgYmUgdGhhdCB3ZSB3YW50 IHRvIGludGVncmF0ZSBiZXR0ZXIgaW50byB0aGUgQ29BUA0KICAgY2FjaGluZy9wcm94eWluZyBt b2RlbC4NCg0KMmIpIFByb2JsZW0gc3RhdGVtZW50OiAgUHV0dGluZyB0cmlnZ2VyIHNwZWNzIGlu IHRoZSBVUkkgbWVhbnMgdGhhdCBhDQogICBwcm94eSB0aGF0IG1ha2VzIG9uZSByZXNvdXJjZSB1 cHN0cmVhbSBhdmFpbGFibGUgdG8gdHdvIGNsaWVudHMNCiAgIGRvd25zdHJlYW0gY2Fubm90IG1h a2Ugb3V0IHRoaXMgZmFjdCBpZiB0aGUgdHJpZ2dlciBzcGVjcyBhcmUNCiAgIGRpZmZlcmVudC4g IEUuZy4sIGEgdGVtcCBzZW5zb3IgdGhhdCBjYW4gcHJvdmlkZSBkYXRhIGluIHJlZ3VsYXINCiAg IGludGVydmFscywgb25lIGNsaWVudCB0aGF0IHdhbnQgYSBuZXcgdGVtcGVyYXR1cmUgZXZlcnkg bWludXRlIGFuZA0KICAgb25lIHRoYXQgd2FudHMgb25lIGV2ZXJ5IHR3byBtaW51dGVzIC0tIGFs bCB0aGUgcHJveHkgc2VlcyBhcmUgdHdvDQogICBkaWZmZXJlbnQgVVJJczsgaXQgdGhlcmVmb3Jl IGNhbm5vdCBjb21iaW5lIGl0cyB0d28gZG93bnN0cmVhbQ0KICAgb2JzZXJ2YXRpb24gcmVsYXRp b25zaGlwcyBpbnRvIGEgc2luZ2xlIHVwc3RyZWFtIG9uZSAoaGVyZTogb25jZQ0KICAgZXZlcnkg bWludXRlKS4NCg0KW3NoaXRhb11BcyBJIHJlc3BvbmRlZCBpbiBhIHByZXZpb3VzIGVtYWlsLCBl dmVuIHdlIGRvIHByb3h5aW5nLCB0aGUgcHJveHkgbmVlZHMgdG8gDQpLbm93IHRoZSBvYnNlcnZl IG9wdGlvbiwgaXQgbmVlZHMgdG8gZGlzdGluZ3Vpc2ggYSBub3JtYWwgR0VUIHJlcXVlc3Qgd2l0 aCBhIHJlcXVlc3Qgd2l0aA0KT2JzZXJ2ZS4gDQpBbmQgSSBnb3QgYSBxdWVzdGlvbiBoZXJlLCBp biB0aGUgY29hcC0wOCBzcGVjLCBlaXRoZXIgaW4gY2FjaGluZyBub3IgcHJveHlpbmcgc2VjdGlv biwgDQpJIGRpZCBub3QgZmluZCB0aGUgcmVsYXRlZCBzZW50ZW5jZSBhYm91dCB0aGUgY29tYmlu aW5nIHByb2NlZHVyZSB5b3UgZGVzY3JpYmVkLiBEaWQgSSBtaXNzZWQgc29tZXdoZXJlLCANCklm IHNvLCBjYW4geW91IHByb3ZpZGUgbWUgc29tZSB1c2VmdWxseSBpbmZvcm1hdGlvbiBhYm91dCB0 aGlzLg0KDQoyYykgQWdhaW4sIGEgc29sdXRpb24gd2lsbCBuZWVkIHRvIHRpZSBpbiB3aXRoIGFw cGxpY2F0aW9uIHNlbWFudGljcywNCiAgIHNvIGRvaW5nIDFhIGZpcnN0IHdpbGwgaGVscCB1cyB3 aXRoIGRvaW5nIDIgcmlnaHQuDQoNClNvIHdoYXQgSSB3YXMgYXJndWluZyBmb3Igd2FzIHRvIHB1 dCBzb21lIGVuZXJneSBmaXJzdCBpbnRvIGxvb2tpbmcNCmludG8gdHJpZ2dlciBzcGVjcyBpbiB0 aGUgY29udGV4dCBvZiBTZW5NTCBvciB5b3VyIGZhdm9yaXRlDQphcHBsaWNhdGlvbiBkYXRhIGZv cm1hdC4NCg0KW3NoaXRhb11JIGZ1bGx5IGFncmVlIHdpdGggeW91IGhlcmUuDQoNCkdyw7zDn2Us IENhcnN0ZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== From abetzler426@gmail.com Mon Feb 20 06:08:18 2012 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 344E221F8759 for ; Mon, 20 Feb 2012 06:08:18 -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 AwMhQh8p3BYH for ; Mon, 20 Feb 2012 06:08:13 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4E4321F85F7 for ; Mon, 20 Feb 2012 06:08:12 -0800 (PST) Received: by wibhm9 with SMTP id hm9so3704973wib.31 for ; Mon, 20 Feb 2012 06:08:12 -0800 (PST) Received-SPF: pass (google.com: domain of abetzler426@gmail.com designates 10.180.92.165 as permitted sender) client-ip=10.180.92.165; Authentication-Results: mr.google.com; spf=pass (google.com: domain of abetzler426@gmail.com designates 10.180.92.165 as permitted sender) smtp.mail=abetzler426@gmail.com; dkim=pass header.i=abetzler426@gmail.com Received: from mr.google.com ([10.180.92.165]) by 10.180.92.165 with SMTP id cn5mr18776777wib.2.1329746892015 (num_hops = 1); Mon, 20 Feb 2012 06:08:12 -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=epkhAxmEP4SvRd4gtkx/SqaBYyk3TtK1dMOSFzlS0Fk=; b=nEo+Tu3amK6G5t1Rr1YQ84w8SyAc+aADaSZwkOup7VdqEIUoPnNwXcDr4HCBHT4HeW JdpCYJEc6aNwQQDPjbxSczwqP2sKEY2ortI0/l+tUByBVufk+uWPUzN48Ywe0ZgY9she oXShdj4BymucxC83OePN4K4997rrCsxt3jRY8= MIME-Version: 1.0 Received: by 10.180.92.165 with SMTP id cn5mr15627751wib.2.1329746891959; Mon, 20 Feb 2012 06:08:11 -0800 (PST) Received: by 10.216.157.213 with HTTP; Mon, 20 Feb 2012 06:08:11 -0800 (PST) Date: Mon, 20 Feb 2012 15:08:11 +0100 Message-ID: From: August Betzler To: zach@sensinode.com Content-Type: multipart/alternative; boundary=f46d043c092622ef0604b965d3c8 Cc: core@ietf.org Subject: Re: [core] Protocol Constants section of coap-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:13:59 -0000 --f46d043c092622ef0604b965d3c8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I understand that small initial backoffs may lead to problems in your networks. Could you give us a short statement, about why you are experiencing "large" delays? What I'm actually interested in is the size and composition of your networks or maybe even the average number of hops for data transmissions. Is the large delay/RTT you observe a consequence of large internal processing times or maybe due to congestion? I'm asking, because we are also interested in finding an adequate inital RESPONSE_TIMEOUT for our (currently rather small) networks. We are not quite shure, if using a fix interval as initial backoff is a good solution though. As it has already been stated, the "optimal" value depends on the network size, it's architecture and the operations that are carried out, so I think it will be difficult to find a initial timeout that fits most of the networks and applications. Also, with the currently proposed values, the margins of the backoff interval get quite large after a few retries (3 or 4, it does not matter). This may result in long periods of time, during which message buffers are reserved and therefore not available to other transmissions. Especially for constrained devices with low memory capacity this may represent a problem, in particular, when several CoAP operations have to be executed in short periods of time over lossy or strongly congestioned paths (so packets may actually get lost or suffer from large delays). Capping the number of retries may be one solution to avoid exaggerated timeouts, even though this could reduce the probabilities for a successful transmission. August > Tom, > > Agreeing with you on all points. The intention has been that those consta= nts are configurable. Could you propose some new text? > > Regarding RESPONSE_TIMEOUT, I would like to find a default value that wor= ks for the majority of LoWPANs at least. Don't see a problem in increasing = that somewhat, for example to 3-4 seconds. With a longer starting timeout, = it may make sense to reduce MAX_RETRANSMIT to 3. > > Zach > > On Feb 18, 2012, at 8:27 PM, Thomas Herbst wrote: > > > Trying to come up with a better way to deal with the protocol constants > > section. > > > > Obvious first edit is that all three values - Timeout, random factor an= d > > max retransmits should be configurable. > > > > Next step might be to state that these are configurable, but the > > configuration is out of scope of this document. > > > > Deployment guidance could be that the numbers should be constant for an= y > > given network, though I can think of several cases where I might have > > different constants for different node types, but that is me playing wi= th > > my own rope. > > > > On the specific numbers, 2 seconds is way too short of a default for ou= r > > networks, but I understand having everyone use our constants for their > > smaller networks may make the smaller networks slower than necessary. > > > > Someone putting an unconfigured device on a network should work. Best > > case would be the unconfigured device would work efficiently. > > > > > > > > Tom > > ------------------------------------------ > > > > 9. Protocol Constants > > This section defines the relevant protocol constants defined in this > > document: > > RESPONSE_TIMEOUT 2 seconds > > RESPONSE_RANDOM_FACTOR 1.5 > > MAX_RETRANSMIT 4 > > Future specifications are expected that will allow implementations to u= se > > other sources for initializing RESPONSE_TIMEOUT. The RESPONSE_TIMEOUT > > variable MAY be configured with a different value for special environme= nts > > that exhibit very short or very long RTTs. > > > > _______________________________________________ > > core mailing list > > core at ietf.org > > https://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd.http://www.sensinode.comhttp://zac= hshelby.org - My blog "On the Internet of Things"http://6lowpan.net - My b= ook "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > --f46d043c092622ef0604b965d3c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I understand that small initial backoffs may lead to=20 problems in your networks. Could you give us a short statement, about=20 why you are experiencing "large" delays? What I'm actually in= terested in is the size and composition of your networks or maybe even the average=20 number of hops for data transmissions. Is the large delay/RTT you=20 observe a consequence of large internal processing times or maybe due to congestion? I'm asking, because we are also interested in finding an= =20 adequate inital RESPONSE_TIMEOUT for our (currently rather small)=20 networks. We are not quite shure, if using a fix interval as initial=20 backoff is a good solution though. As it has already been stated, the=20 "optimal" value depends on the=20 network size, it's architecture and the operations that are carried out= , so I think it will be difficult to find a initial timeout that fits=20 most of the networks and applications.

Also, with the currently pro= posed values,=20 the margins of the backoff interval get quite large after a few retries=20 (3 or 4, it does not matter). This may result in long periods of time,=20 during which message buffers are reserved and therefore not available=20 to other transmissions. Especially for constrained devices with low=20 memory capacity this may represent a problem, in particular, when=20 several CoAP operations have to be executed in short periods of time=20 over lossy or strongly congestioned paths (so packets may actually get=20 lost or suffer from large delays). Capping the number of retries may be=20 one solution to avoid exaggerated timeouts, even though this could=20 reduce the probabilities for a successful transmission.

August=A0 
Tom,

Agreeing with you on all points. The intention has been that those constant=
s are configurable. Could you propose some new text?

Regarding RESPONSE_TIMEOUT, I would like to find a default value that works=
 for the majority of LoWPANs at least. Don't see a problem in increasin=
g that somewhat, for example to 3-4 seconds. With a longer starting timeout=
, it may make sense to reduce MAX_RETRANSMIT to 3.

Zach

On Feb 18, 2012, at 8:27 PM, Thomas Herbst wrote:

> Trying to come up with a better way to deal with the protocol constant=
s
> section.
>=20
> Obvious first edit is that all three values - Timeout, random factor a=
nd
> max retransmits should be configurable.
>=20
> Next step might be to state that these are configurable, but the
> configuration is out of scope of this document.
>=20
> Deployment guidance could be that the numbers should be constant for a=
ny
> given network, though I can think of several cases where I might have
> different constants for different node types, but that is me playing w=
ith
> my own rope.
>=20
> On the specific numbers, 2 seconds is way too short of a default for o=
ur
> networks, but I understand having everyone use our constants for their
> smaller networks may make the smaller networks slower than necessary.
>=20
> Someone putting an unconfigured device on a network should work.  Best
> case would be the unconfigured device would work efficiently.
>=20
>=20
>=20
> Tom
> ------------------------------------------
>=20
> 9. Protocol Constants
> This section defines the relevant protocol constants defined in this
> document:
> RESPONSE_TIMEOUT 2 seconds
> RESPONSE_RANDOM_FACTOR 1.5
> MAX_RETRANSMIT 4
> Future specifications are expected that will allow implementations to =
use
> other sources for initializing RESPONSE_TIMEOUT. The RESPONSE_TIMEOUT
> variable MAY be configured with a different value for special environm=
ents
> that exhibit very short or very long RTTs.
>=20
> _______________________________________________
> core mailing list
> core at ietf.org
> https://www.ietf.org/mailman/listinfo/core

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
ht=
tp://www.sensinode.com
http:=
//zachshelby.org  - My blog "On the Internet of Things"
http://6=
lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"=
;
Mobile: +358 40 7796297
--f46d043c092622ef0604b965d3c8-- From cabo@tzi.org Mon Feb 20 07:18:25 2012 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 75EAD21F879A for ; Mon, 20 Feb 2012 07:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.284 X-Spam-Level: X-Spam-Status: No, score=-106.284 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 v5keZ4FGX566 for ; Mon, 20 Feb 2012 07:18:24 -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 70D4721F8548 for ; Mon, 20 Feb 2012 07:18:24 -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 q1KFIBOR010694; Mon, 20 Feb 2012 16:18:11 +0100 (CET) Received: from [192.168.217.103] (p54899FE4.dip.t-dialin.net [84.137.159.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BC5B64E9; Mon, 20 Feb 2012 16:18:10 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Mon, 20 Feb 2012 16:18:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: August Betzler X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] Protocol Constants section of coap-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 15:18:25 -0000 On Feb 20, 2012, at 15:08, August Betzler wrote: > Capping the number of retries may be one solution to avoid exaggerated = timeouts, even though this could reduce the probabilities for a = successful transmission. Indeed. One way of increasing the minimum wait time without increasing the = maximum is clamping up the wait. So, right now we have 2 4 8 16 32 If we naively increase this to 3, we get 3 6 12 24 48 Instead, we could go to a min of 3 this way: 3 4 8 16 32 or (increasing the min to 5): 5 5 8 16 32 (You could also clamp while keeping the total, as in 3 3 8 16 32 and 5 5 5 15 32 and 10 10 10 10 22 and so on. Algorithms are left as an exercise for the reader :-) Beyond this little tweak, I agree that the protocol constants are = tunables. Going significantly below the values that are equivalent to those = characteristic of TCP behavior will jeopardize TCP-friendliness, though. Also, you just may not know how well the network at the other end of the = conversation is working, so tuning for your local network may not help = you very much. If you have the space, keep state from previous conversations with the = same place, and use something like EWMA to evolve that state. Gr=FC=DFe, Carsten From prvs=7398B6719E=guido.moritz@uni-rostock.de Tue Feb 21 01:55:31 2012 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 A970921F85B4 for ; Tue, 21 Feb 2012 01:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.763 X-Spam-Level: X-Spam-Status: No, score=-0.763 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_21=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 Ya0ONiGp+5pc for ; Tue, 21 Feb 2012 01:55:27 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9AABB21F85AE for ; Tue, 21 Feb 2012 01:55:18 -0800 (PST) From: Guido Moritz To: 'core' Date: Tue, 21 Feb 2012 10:55:17 +0100 Message-ID: <000901ccf07e$ea1545f0$be3fd1d0$@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: AczwfZe2THLJkXKMR3KHCnPzmObLGw== Content-Language: de X-Originating-IP: [139.30.201.226] Subject: [core] Open Source CoAP Proxy X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 09:55:31 -0000 Dear WG, there is a new (maybe the first?) open source CoAP/HTTP proxy available through the WS4D folk, which might be interesting for this community. Further contributions to the project are welcome! See: http://ws4d.e-technik.uni-rostock.de/2012/announcing-the-coaphttp-proxy-for- jcoap/ Regards, Guido From trac+core@trac.tools.ietf.org Wed Feb 22 07:16:51 2012 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 A287121F87A3 for ; Wed, 22 Feb 2012 07:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 el76UhDjJ0+o for ; Wed, 22 Feb 2012 07:16:47 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA0E21F8790 for ; Wed, 22 Feb 2012 07:16:47 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S0DvB-0006pL-E6; Wed, 22 Feb 2012 10:15:57 -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: draft-ietf-core-observe@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Wed, 22 Feb 2012 15:15:57 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/core/trac/ticket/184 Message-ID: <051.1d985a98083f5d7102ae3d8bf240deb7@trac.tools.ietf.org> X-Trac-Ticket-ID: 184 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, cabo@tzi.org, 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 Resent-To: Resent-Message-Id: <20120222151647.7EA0E21F8790@ietfa.amsl.com> Resent-Date: Wed, 22 Feb 2012 07:16:47 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #184: Add implementation note to 3.5 about careless GETs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 15:16:51 -0000 #184: Add implementation note to 3.5 about careless GETs When an implementation is careless, it might tear down an observation relationship carelessly by carelessly sending a GET without Observe on the same transport address on which it has the observation relationship. This does not occur in client that implement caching with complete mediation, as any industrial-strength implementation is likely to do. It might occur in more careless environments, such as shell scripts. So maybe we should add some editorial explanation that clients that (1) want to keep up observation relationships and (2) still send GETs carelessly to the same resource for implementation expediency should (3) not do the latter from the same source address/port their observation relationships run on. While it could be argued the same kind of implementation note would need to be added about other state attached to a transport address pair, such as MID or Token use, these can be partitioned off in a more obvious way (e.g., use odd MIDs and Tokens for careless requests). -- --------------------------------+--------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-observe@… Type: editorial | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: Active WG Document | Keywords: --------------------------------+--------------------------------------- Ticket URL: core From therbst@silverspringnet.com Wed Feb 22 09:44:57 2012 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 A446321F86F3 for ; Wed, 22 Feb 2012 09:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 Ou+8796A7rcZ for ; Wed, 22 Feb 2012 09:44:52 -0800 (PST) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5300221F86AF for ; Wed, 22 Feb 2012 09:44:31 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4EADspRU8KOQxz/2dsb2JhbABDgk2icYQZAYl0gXMBAQEDAQEBAWQHCwUNAQgHBgEDAQIBAgEnKAYLFAMGCAEBBAENBRuHZgm4Ioh/g0kBDgEBAQQCDA5QBAGEdRgbQgwGBwEHAQoEBwSDLQSIT5JohRiHdw X-IronPort-AV: E=Sophos;i="4.73,465,1325491200"; d="scan'208,217";a="9530553" Received: from unknown (HELO SFO-EXCA-02.silverspringnet.com) ([10.57.12.115]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 22 Feb 2012 09:44:13 -0800 Received: from IT-EXCA-01.silverspringnet.com (10.200.1.60) by SFO-EXCA-02.silverspringnet.com (10.57.12.101) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 22 Feb 2012 09:44:12 -0800 Received: from IT-RESTORE-01.silverspringnet.com ([::1]) by IT-EXCA-01.silverspringnet.com ([::1]) with mapi; Wed, 22 Feb 2012 09:44:12 -0800 From: Thomas Herbst To: August Betzler , "zach@sensinode.com" Date: Wed, 22 Feb 2012 09:44:10 -0800 Thread-Topic: [core] Protocol Constants section of coap-08 Thread-Index: AczxiZZhPlqN4qFQQIyqTMg6l2OHBQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB6A666F2396Etherbstsilverspringnetcom_" MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] Protocol Constants section of coap-08 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, 22 Feb 2012 17:44:57 -0000 --_000_CB6A666F2396Etherbstsilverspringnetcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Our largest network has over 5 million devices deployed, with several thous= ands aggregated into each access point. The average number of hops is fairl= y low, but geography (going around a hill or other obstruction) can result = a longer tail. We need to design to those edge cases. After thinking about this some more, perhaps the most expedient way forward= to just to specific that all three parameters are configurable and offer a= reasonable default. We are okay with that default being fairly short and = devices connecting to our network changing from the defaults. Some adaptiv= e, negotiated or full defined configuration method would be unneeded compl= exity in the base spec. Existing Text : > Future specifications are expected that will allow implementations to use= > other sources for initializing RESPONSE_TIMEOUT. The RESPONSE_TIMEOUT > variable MAY be configured with a different value for special environment= s > that exhibit very short or very long RTTs. Suggested Text : The values for RESPONSE_TIMEOUT, RESPONSE_RANDOM_FACTOR, and MAX_RETRANSM= IT may be configured to network specific values, but the configuration meth= od is out of scope of this document. It is recommended that a network use c= onsistent values for these parameters. tom From: August Betzler > Date: Mon, 20 Feb 2012 06:08:11 -0800 To: "zach@sensinode.com" > Cc: "core@ietf.org" > Subject: Re: [core] Protocol Constants section of coap-08 Hi, I understand that small initial backoffs may lead to problems in your netwo= rks. Could you give us a short statement, about why you are experiencing "l= arge" delays? What I'm actually interested in is the size and composition o= f your networks or maybe even the average number of hops for data transmiss= ions. Is the large delay/RTT you observe a consequence of large internal pr= ocessing times or maybe due to congestion? I'm asking, because we are also = interested in finding an adequate inital RESPONSE_TIMEOUT for our (currentl= y rather small) networks. We are not quite shure, if using a fix interval a= s initial backoff is a good solution though. As it has already been stated,= the "optimal" value depends on the network size, it's architecture and the= operations that are carried out, so I think it will be difficult to find a= initial timeout that fits most of the networks and applications. Also, with the currently proposed values, the margins of the backoff interv= al get quite large after a few retries (3 or 4, it does not matter). This m= ay result in long periods of time, during which message buffers are reserve= d and therefore not available to other transmissions. Especially for constr= ained devices with low memory capacity this may represent a problem, in par= ticular, when several CoAP operations have to be executed in short periods = of time over lossy or strongly congestioned paths (so packets may actually = get lost or suffer from large delays). Capping the number of retries may be= one solution to avoid exaggerated timeouts, even though this could reduce = the probabilities for a successful transmission. August Tom, Agreeing with you on all points. The intention has been that those constant= s are configurable. Could you propose some new text? Regarding RESPONSE_TIMEOUT, I would like to find a default value that works= for the majority of LoWPANs at least. Don't see a problem in increasing th= at somewhat, for example to 3-4 seconds. With a longer starting timeout, it= may make sense to reduce MAX_RETRANSMIT to 3. Zach On Feb 18, 2012, at 8:27 PM, Thomas Herbst wrote: > Trying to come up with a better way to deal with the protocol constants > section. > > Obvious first edit is that all three values - Timeout, random factor and > max retransmits should be configurable. > > Next step might be to state that these are configurable, but the > configuration is out of scope of this document. > > Deployment guidance could be that the numbers should be constant for any > given network, though I can think of several cases where I might have > different constants for different node types, but that is me playing with > my own rope. > > On the specific numbers, 2 seconds is way too short of a default for our > networks, but I understand having everyone use our constants for their> s= maller networks may make the smaller networks slower than necessary. > > Someone putting an unconfigured device on a network should work. Best> c= ase would be the unconfigured device would work efficiently. > > > > Tom > ------------------------------------------ > > 9. Protocol Constants > This section defines the relevant protocol constants defined in this > document: > RESPONSE_TIMEOUT 2 seconds > RESPONSE_RANDOM_FACTOR 1.5 > MAX_RETRANSMIT 4 > Future specifications are expected that will allow implementations to use > other sources for initializing RESPONSE_TIMEOUT. The RESPONSE_TIMEOUT > variable MAY be configured with a different value for special environment= s > that exhibit very short or very long RTTs. > > _______________________________________________ > core mailing list > core at ietf.org > https://www.ietf.org/mailman/listinfo/core -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.comhttp://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Em= bedded Internet" Mobile: +358 40 7796297 --_000_CB6A666F2396Etherbstsilverspringnetcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Our largest network has = over 5 million devices deployed, with several thousands aggregated into eac= h access point. The average number of hops is fairly low, but geography (go= ing around a hill or other obstruction) can result a longer tail.  We = need to design to those edge cases.

After thinking= about this some more, perhaps the most expedient way forward to just to sp= ecific that all three parameters are configurable and offer a reasonable de= fault.  We are okay with that default being fairly short and devices c= onnecting to our network changing from the defaults.  Some adaptive, &= nbsp;negotiated or full defined configuration method would be unneeded comp= lexity in the base spec. 

Existing Text =
:
> Future specifications are expected that will allow impleme=
ntations to use> other sources for initializing RESPONSE_TIMEOUT. The RE=
SPONSE_TIMEOUT
> variable MAY be configured with a different value for special environm=
ents
> that exhibit very short or very long RTTs.


Suggested Text :
The values  = ;for RESPONSE_TIMEOUT,  RESPONSE_RANDOM_FACTOR, and = MAX_RETRANSMIT may be configured to network specific values, but= the configuration method is out of scope of this document. It is recommen= ded that a network use consistent values for these parameters.

tom


From: August Betzler <abetzler426@gmail.com>
Date: Mon, 20 Feb 2012 06:08:11 -0800
To: "za= ch@sensinode.com" <zach@sensin= ode.com>
Cc: "core@ietf.org" <core@ietf.org>
Subject: Re: [core] Protocol Constants section of coap-08

Hi,

I understand that small initial backoffs may lead to=20 problems in your networks. Could you give us a short statement, about=20 why you are experiencing "large" delays? What I'm actually interested in is the size and composition of your networks or maybe even the average=20 number of hops for data transmissions. Is the large delay/RTT you=20 observe a consequence of large internal processing times or maybe due to congestion? I'm asking, because we are also interested in finding an=20 adequate inital RESPONSE_TIMEOUT for our (currently rather small)=20 networks. We are not quite shure, if using a fix interval as initial=20 backoff is a good solution though. As it has already been stated, the=20 "optimal" value depends on the=20 network size, it's architecture and the operations that are carried out, so I think it will be difficult to find a initial timeout that fits=20 most of the networks and applications.

Also, with the currently pro= posed values,=20 the margins of the backoff interval get quite large after a few retries=20 (3 or 4, it does not matter). This may result in long periods of time,=20 during which message buffers are reserved and therefore not available=20 to other transmissions. Especially for constrained devices with low=20 memory capacity this may represent a problem, in particular, when=20 several CoAP operations have to be executed in short periods of time=20 over lossy or strongly congestioned paths (so packets may actually get=20 lost or suffer from large delays). Capping the number of retries may be=20 one solution to avoid exaggerated timeouts, even though this could=20 reduce the probabilities for a successful transmission.

August  
Tom,

Agreeing with you on all points. The intention has been that those constant=
s are configurable. Could you propose some new text?

Regarding RESPONSE_TIMEOUT, I would like to find a default value that works=
 for the majority of LoWPANs at least. Don't see a problem in increasing th=
at somewhat, for example to 3-4 seconds. With a longer starting timeout, it=
 may make sense to reduce MAX_RETRANSMIT to 3.

Zach

On Feb 18, 2012, at 8:27 PM, Thomas Herbst wrote:

> Trying to come up with a better way to deal with the protocol constant=
s
> section.
>=20
> Obvious first edit is that all three values - Timeout, random factor a=
nd
> max retransmits should be configurable.
>=20
> Next step might be to state that these are configurable, but the
> configuration is out of scope of this document.
>=20
> Deployment guidance could be that the numbers should be constant for a=
ny
> given network, though I can think of several cases where I might have
> different constants for different node types, but that is me playing w=
ith
> my own rope.
>=20
> On the specific numbers, 2 seconds is way too short of a default for o=
ur
> networks, but I understand having everyone use our constants for their=
> smaller networks may make the smaller networks slower than necessary.
>=20
> Someone putting an unconfigured device on a network should work.  Best=
> case would be the unconfigured device would work efficiently.
>=20
>=20
>=20
> Tom
> ------------------------------------------
>=20
> 9. Protocol Constants
> This section defines the relevant protocol constants defined in this
> document:
> RESPONSE_TIMEOUT 2 seconds
> RESPONSE_RANDOM_FACTOR 1.5
> MAX_RETRANSMIT 4
> Future specifications are expected that will allow implementations to =
use
> other sources for initializing RESPONSE_TIMEOUT. The RESPONSE_TIMEOUT
> variable MAY be configured with a different value for special environm=
ents
> that exhibit very short or very long RTTs.
>=20
> _______________________________________________
> core mailing list
> core at ietf.org
> https://www.ietf.org/mailman/listinfo/core

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
ht=
tp://www.sensinode.comhttp://zachshelby.org  - My blog "On the Internet =
of Things"
http://6=
lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297
--_000_CB6A666F2396Etherbstsilverspringnetcom_-- From cabo@tzi.org Wed Feb 22 09:54:09 2012 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 4350521F852A for ; Wed, 22 Feb 2012 09:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.113 X-Spam-Level: X-Spam-Status: No, score=-106.113 tagged_above=-999 required=5 tests=[AWL=0.136, 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 xBIvBMYGRZQi for ; Wed, 22 Feb 2012 09:54:04 -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 B415D21F8833 for ; Wed, 22 Feb 2012 09:54:03 -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 q1MHrpaV014169; Wed, 22 Feb 2012 18:53:51 +0100 (CET) Received: from [192.168.217.103] (p5B3E717D.dip.t-dialin.net [91.62.113.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 456AB1DB; Wed, 22 Feb 2012 18:53:51 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Wed, 22 Feb 2012 18:53:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9922C3A0-6AE1-4782-938E-3B968EB34CB2@tzi.org> References: To: Thomas Herbst X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org" Subject: Re: [core] Protocol Constants section of coap-08 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, 22 Feb 2012 17:54:09 -0000 On Feb 22, 2012, at 18:44, Thomas Herbst wrote: > Suggested Text : > The values for RESPONSE_TIMEOUT, RESPONSE_RANDOM_FACTOR, and = MAX_RETRANSMIT may be configured to network specific values, but the = configuration method is out of scope of this document. It is = recommended that a network use consistent values for these parameters. =20= Thanks! We probably want to replace "network" by something more general, as the = network characteristics are not the only factor in choosing good values = -- one also has to look at application requirements for timeliness and = delivery probabilities etc. E.g., some applications' networks will "the = Internet", and there won't be a single set of values right for those = applications... maybe: =85 to values specific on the application environment =85 =85 that an application environment employ consistent =85 In the long run, I expect many implementations will be able to employ = adaptive schemes for configuring the values. But, as you said, this is = out of scope for this document. Thanks again for bringing this up; it is important we get this right. Gr=FC=DFe, Carsten From esko.dijk@philips.com Thu Feb 23 06:55:42 2012 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 1E95F21F87D4 for ; Thu, 23 Feb 2012 06:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.474 X-Spam-Level: X-Spam-Status: No, score=-5.474 tagged_above=-999 required=5 tests=[AWL=1.125, 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 mK37XKpHDOx7 for ; Thu, 23 Feb 2012 06:55:41 -0800 (PST) Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 62C0121F872F for ; Thu, 23 Feb 2012 06:55:41 -0800 (PST) Received: from mail67-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 23 Feb 2012 14:55:40 +0000 Received: from mail67-tx2 (localhost [127.0.0.1]) by mail67-tx2-R.bigfish.com (Postfix) with ESMTP id 7FFDF401B2; Thu, 23 Feb 2012 14:55:40 +0000 (UTC) X-SpamScore: -38 X-BigFish: VPS-38(zz217bL15d6O9251Jc89bh542Mzz1202hzz1033IL8275dhz2dh2a8h668h839h) 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-tx2 (localhost.localdomain [127.0.0.1]) by mail67-tx2 (MessageSwitch) id 1330008938204541_16559; Thu, 23 Feb 2012 14:55:38 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.236]) by mail67-tx2.bigfish.com (Postfix) with ESMTP id 2221620049; Thu, 23 Feb 2012 14:55:38 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 23 Feb 2012 14:55:35 +0000 Received: from 011-DB3MPN1-014.MGDPHG.emi.philips.com ([169.254.4.162]) by 011-DB3MMR1-004.MGDPHG.emi.philips.com ([10.128.28.54]) with mapi id 14.01.0355.003; Thu, 23 Feb 2012 14:55:33 +0000 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] Resolution to tickets #176, #177, #181 Thread-Index: AQHM6/XL9v2hz3KLp0iWB1g4NxtpyJZKkdgA Date: Thu, 23 Feb 2012 14:55:33 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61806C223@011-DB3MPN1-014.MGDPHG.emi.philips.com> References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> In-Reply-To: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.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 WG" Subject: Re: [core] Resolution to tickets #176, #177, #181 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:55:42 -0000 Hello Carsten, Klaus, some discussion about the Patience and Leisure concepts would be good I thi= nk. "To avoid response implosion, responses to multicast requests SHOULD be dithered within a Leisure period chosen by the server to fall between these two bounds." I have some questions about the proposed bounds: 1- if no Patience option is present, or if a server does not recognize it, = there is no de facto upper bound. Would be good to indicate what to do in s= uch cases? 2- the upper bound can be calculated lower than the lower bound (e.g. lower= bound 10 seconds, and patience option specifies 5 seconds value). Will the= leisure range now become a single value i.e. 10 seconds? 3- Suppose a group of 20 devices all receives a CoAP multicast request at a= bout the same time. Now each device waits at least the "lower bound" time b= efore sending any response, e.g. 10 seconds. Why would all these devices fi= rst collectively wait for 10 seconds (while nothing happens in the network.= ..) before being able to respond? I.e. why a lower bound at all. 4- To make the situation worse, take the previous case combined with a Pati= ence Option value of 10 seconds or lower in the request which sets the uppe= r bound. Will the entire group of devices now respond at about the same tim= e t=3D10 sec. ? regards, Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Wednesday 15 February 2012 16:23 To: core@ietf.org WG Subject: [core] Resolution to tickets #176, #177, #181 Klaus and I sat together today and rearranged coap-misc, moving stuff that = isn't ready for standardization to the appendices and finishing other stuff= . As a result, we are proposing the body of coap-misc as the resolution for t= ickets #176, #177 (and indirectly for #174), and #181, as well as the vendo= r-defined option that was discussed. If these solutions are acceptable, this leaves us with #166 and #183 (#182 = already has proposed text and just needs to be applied) on core-coap. I al= so have to generate a proposal for #171 (block), and we need to decide whet= her #170 really needs any work. I am optimistic we can finish all this in the next couple of days, so we ha= ve a set of documents that the authors believe is ready for WGLC. 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 cabo@tzi.org Thu Feb 23 07:15:28 2012 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 40B5A21F872D for ; Thu, 23 Feb 2012 07:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.84 X-Spam-Level: X-Spam-Status: No, score=-105.84 tagged_above=-999 required=5 tests=[AWL=0.409, 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 GOqvM1-hB0Qq for ; Thu, 23 Feb 2012 07:15:27 -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 3105421F84F1 for ; Thu, 23 Feb 2012 07:15:26 -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 q1NFFIMR027271; Thu, 23 Feb 2012 16:15:18 +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 9F5AD661; Thu, 23 Feb 2012 16:15:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED61806C223@011-DB3MPN1-014.MGDPHG.emi.philips.com> Date: Thu, 23 Feb 2012 16:15:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> <031DD135F9160444ABBE3B0C36CED61806C223@011-DB3MPN1-014.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org WG" Subject: Re: [core] Resolution to tickets #176, #177, #181 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:15:28 -0000 Hi Esko, these are good questions, and I don't pretend to have final answers to = all of them. But let's try DTSTTCPW to obtain a starting position. > 1- if no Patience option is present, or if a server does not recognize = it, there is no de facto upper bound. Would be good to indicate what to = do in such cases? Well, there is no upper bound for anything in this case, as with HTTP or = many other TCP-based protocols. Traditionally, clients have had timeouts chosen on a scale that is based = on human patience, e.g. 60 to 180 seconds. Another approach is not to have timeouts at all but to consider the = incoming responses a stream of additional data, to each of which you = react separately. E.g., in an interactive discovery application, a new response would = cause a new icon to come up on the screen, independent of timeouts. Being somewhat reasonable with respect to Leisure in a server becomes a = quality of implementation issue then. > 2- the upper bound can be calculated lower than the lower bound (e.g. = lower bound 10 seconds, and patience option specifies 5 seconds value). = Will the leisure range now become a single value i.e. 10 seconds? Well, if the CC-based bound does not allow everyone to respond within = the patience interval without overloading a channel, then not everyone = should respond. I think that makes the answer to your question a Yes. This allows the system to slide into a multi-anycast situation when the = request is unrealistic. > 3- Suppose a group of 20 devices all receives a CoAP multicast request = at about the same time. Now each device waits at least the "lower bound" = time before sending any response, e.g. 10 seconds. Why would all these = devices first collectively wait for 10 seconds (while nothing happens in = the network...) before being able to respond? I.e. why a lower bound at = all. Oh, the lower bound is a lower bound for the choice of the value of = Leisure, not the minimum time a response may take. Devices dither their response delay within [0..Leisure]. (I need to fix the text to be clear that Leisure is a single number = representing a duration, not a specific interval in time.) Note that the distribution of responses within [0..Leisure] will be = skewed a bit by the actual processing time in some cases; I was assuming = this effect could simply be ignored for most multicast requests. > 4- To make the situation worse, take the previous case combined with a = Patience Option value of 10 seconds or lower in the request which sets = the upper bound. Will the entire group of devices now respond at about = the same time t=3D10 sec. ? No, see 3 above. Gr=FC=DFe, Carsten From esko.dijk@philips.com Thu Feb 23 08:03:42 2012 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 686D921F87E3 for ; Thu, 23 Feb 2012 08:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.061 X-Spam-Level: X-Spam-Status: No, score=-4.061 tagged_above=-999 required=5 tests=[AWL=-0.462, 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 QIfW4nvnoXv0 for ; Thu, 23 Feb 2012 08:03:40 -0800 (PST) Received: from AM1EHSOBE002.bigfish.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id EC30E21F87E0 for ; Thu, 23 Feb 2012 08:03:13 -0800 (PST) Received: from mail80-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 23 Feb 2012 16:03:12 +0000 Received: from mail80-am1 (localhost [127.0.0.1]) by mail80-am1-R.bigfish.com (Postfix) with ESMTP id 154A9404A1; Thu, 23 Feb 2012 16:03:12 +0000 (UTC) X-SpamScore: -43 X-BigFish: VPS-43(zz217bL15d6O9251Jc89bh542M1418Mzz1202hzz1033IL8275dhz2dh2a8h668h839h) 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 mail80-am1 (localhost.localdomain [127.0.0.1]) by mail80-am1 (MessageSwitch) id 133001298961806_26727; Thu, 23 Feb 2012 16:03:09 +0000 (UTC) Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.245]) by mail80-am1.bigfish.com (Postfix) with ESMTP id 08E4F2004A; Thu, 23 Feb 2012 16:03:09 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 23 Feb 2012 16:03:05 +0000 Received: from 011-DB3MPN1-014.MGDPHG.emi.philips.com ([169.254.4.162]) by 011-DB3MMR1-010.MGDPHG.emi.philips.com ([10.128.28.49]) with mapi id 14.01.0355.003; Thu, 23 Feb 2012 16:04:49 +0000 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] Resolution to tickets #176, #177, #181 Thread-Index: AQHM6/XL9v2hz3KLp0iWB1g4NxtpyJZKkdgAgAASIoCAAAQVAA== Date: Thu, 23 Feb 2012 16:03:02 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61806E2A3@011-DB3MPN1-014.MGDPHG.emi.philips.com> References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> <031DD135F9160444ABBE3B0C36CED61806C223@011-DB3MPN1-014.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 WG" Subject: Re: [core] Resolution to tickets #176, #177, #181 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 16:03:42 -0000 Hi Carsten, some comments below: 1- I understand your reply that the client may have some predefined timeout/pa= tience. Ok for me. I was wondering more about a server and the "SHOULD be d= ithered" recommendation. I can read it in two ways for a server: 1) if ther= e's no upper bound I can ignore the SHOULD with good reason (i.e. no bound = known!), or 2) the SHOULD still applies but I need to use a default/predefi= ned upper bound. Or maybe an upper bound is not relevant anymore, because t= he server will anyway always apply dithering in the interval [0,lower-bound= ] ? Or maybe the upper bound is still there and the server chooses Leisure= between up/low bound depending on e.g. network traffic conditions. 2- Given your answer to #3, this makes sense. So a server will dither in the i= nterval [0,lower-bound] if ( upper-bound < lower-bound ). 3- OK, clear, maybe text is then to be adapted: "...value that we will call Le= isure, which indicates the period of time that will be used for responding = to a request." -> wrongly sounds like it will always take a time period "L= eisure" before responding. thanks Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Thursday 23 February 2012 16:15 To: Dijk, Esko Cc: core@ietf.org WG Subject: Re: [core] Resolution to tickets #176, #177, #181 Hi Esko, these are good questions, and I don't pretend to have final answers to all = of them. But let's try DTSTTCPW to obtain a starting position. > 1- if no Patience option is present, or if a server does not recognize it= , there is no de facto upper bound. Would be good to indicate what to do in= such cases? Well, there is no upper bound for anything in this case, as with HTTP or ma= ny other TCP-based protocols. Traditionally, clients have had timeouts chosen on a scale that is based on= human patience, e.g. 60 to 180 seconds. Another approach is not to have timeouts at all but to consider the incomin= g responses a stream of additional data, to each of which you react separat= ely. E.g., in an interactive discovery application, a new response would cause a= new icon to come up on the screen, independent of timeouts. Being somewhat reasonable with respect to Leisure in a server becomes a qua= lity of implementation issue then. > 2- the upper bound can be calculated lower than the lower bound (e.g. low= er bound 10 seconds, and patience option specifies 5 seconds value). Will t= he leisure range now become a single value i.e. 10 seconds? Well, if the CC-based bound does not allow everyone to respond within the p= atience interval without overloading a channel, then not everyone should re= spond. I think that makes the answer to your question a Yes. This allows the system to slide into a multi-anycast situation when the req= uest is unrealistic. > 3- Suppose a group of 20 devices all receives a CoAP multicast request at= about the same time. Now each device waits at least the "lower bound" time= before sending any response, e.g. 10 seconds. Why would all these devices = first collectively wait for 10 seconds (while nothing happens in the networ= k...) before being able to respond? I.e. why a lower bound at all. Oh, the lower bound is a lower bound for the choice of the value of Leisure= , not the minimum time a response may take. Devices dither their response delay within [0..Leisure]. (I need to fix the text to be clear that Leisure is a single number represe= nting a duration, not a specific interval in time.) Note that the distribution of responses within [0..Leisure] will be skewed = a bit by the actual processing time in some cases; I was assuming this effe= ct could simply be ignored for most multicast requests. > 4- To make the situation worse, take the previous case combined with a Pa= tience Option value of 10 seconds or lower in the request which sets the up= per bound. Will the entire group of devices now respond at about the same t= ime t=3D10 sec. ? No, see 3 above. 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 cabo@tzi.org Fri Feb 24 00:26:02 2012 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 CD50221F85E7; Fri, 24 Feb 2012 00:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.821 X-Spam-Level: X-Spam-Status: No, score=-105.821 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=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 SrlwqWPvFQqq; Fri, 24 Feb 2012 00:26:02 -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 ED5E721F85E5; Fri, 24 Feb 2012 00:26:01 -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 q1O8PrP2018457; Fri, 24 Feb 2012 09:25:53 +0100 (CET) Received: from [192.168.217.105] (p5B3E6044.dip.t-dialin.net [91.62.96.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0B95A872; Fri, 24 Feb 2012 09:25:52 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Feb 2012 09:25:53 +0100 To: 6lowpan@ietf.org, "core@ietf.org WG" , roll@ietf.org, lwip@ietf.org Message-Id: <1B2B5C1F-AF12-44CB-BCF1-C5DD2978FBEB@tzi.org> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [core] Constrained Node/Network Cluster @ IETF83 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 08:26:02 -0000 Here is my usual compilation of the draft agenda for IETF83. Note that this agenda is subject to change, so please don't plan travel = around it. This time, we are nicely spread out over the week, so a lot of things = will happen between the meeting slots. Gr=FC=DFe, Carsten ***DRAFT*** Agenda for Constrained Node/Network related events during IETF 83 in Paris ***Subject to change*** -- don't plan travel around this * FRIDAY, March 23, 2012 IAB Workshop on Smart Object Security * SATURDAY, March 24, 2012; SUNDAY, March 25, 2012 ETSI CoAP plugfest * MONDAY, March 26, 2012 0900-1130 Maillot OPS v6ops IPv6 Operations WG * TUESDAY, March 27, 2012 0900-1130 243 APP *core* Constrained RESTful Environments WG Maillot INT homenet Home Networking WG 1300-1500 241 OPS eman Energy Management WG * WEDNESDAY, March 28, 2012 0900-1130 242AB INT 6man IPv6 Maintenance WG 1300-1500 241 RTG *roll* Routing Over Low power and Lossy networks WG * THURSDAY, March 29, 2012 1300-1500 Maillot INT intarea Internet Area Working Group WG 1520-1720 252B INT *lwig* Light-Weight Implementation Guidance WG Maillot OPS v6ops IPv6 Operations WG * FRIDAY, March 30, 2012 0900-1100 253 APP *core* Constrained RESTful Environments WG From tho@koanlogic.com Fri Feb 24 01:08:03 2012 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 1702521F88F5 for ; Fri, 24 Feb 2012 01:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.642 X-Spam-Level: X-Spam-Status: No, score=0.642 tagged_above=-999 required=5 tests=[AWL=1.575, BAYES_00=-2.599, 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 f9J918EZCco7 for ; Fri, 24 Feb 2012 01:08:02 -0800 (PST) Received: from relay1.serverpronto.com (srv1023-mia.serverpronto.com [38.117.1.254]) by ietfa.amsl.com (Postfix) with ESMTP id 0F76621F88F1 for ; Fri, 24 Feb 2012 01:07:43 -0800 (PST) Received: from gonzo.koanlogic.com (166-118-60-69.serverpronto.com [69.60.118.166] (may be forged)) by relay1.serverpronto.com (8.13.8/8.13.8) with ESMTP id q1O97gk5006715; Fri, 24 Feb 2012 04:07:43 -0500 Received: from host196-51-dynamic.47-79-r.retail.telecomitalia.it ([79.47.51.196]:65015 helo=t.homenet.telecomitalia.it) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1S0r7e-0004Bw-UH; Fri, 24 Feb 2012 04:07:42 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <1B2B5C1F-AF12-44CB-BCF1-C5DD2978FBEB@tzi.org> Date: Fri, 24 Feb 2012 10:07:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1B2B5C1F-AF12-44CB-BCF1-C5DD2978FBEB@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.51.196 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 WG Subject: Re: [core] Constrained Node/Network Cluster @ IETF83 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 09:08:03 -0000 On Feb 24, 2012, at 9:25 AM, Carsten Bormann wrote: > Here is my usual compilation of the draft agenda for IETF83. > Note that this agenda is subject to change, so please don't plan = travel around it. > This time, we are nicely spread out over the week, so a lot of things = will happen between the meeting slots. Too bad that the CoRE and HOMENET sessions have been superposed (on = tuesday). I tend to regard these two WGs as very much related. Am I the only one = ?= From ycma610103@gmail.com Fri Feb 24 01:21:17 2012 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 47E2921F88CD for ; Fri, 24 Feb 2012 01:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, 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 A8WSk5LuQprf for ; Fri, 24 Feb 2012 01:21:16 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 45E4B21F87DC for ; Fri, 24 Feb 2012 01:21:15 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2975950obb.31 for ; Fri, 24 Feb 2012 01:21:15 -0800 (PST) Received-SPF: pass (google.com: domain of ycma610103@gmail.com designates 10.182.216.41 as permitted sender) client-ip=10.182.216.41; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ycma610103@gmail.com designates 10.182.216.41 as permitted sender) smtp.mail=ycma610103@gmail.com; dkim=pass header.i=ycma610103@gmail.com Received: from mr.google.com ([10.182.216.41]) by 10.182.216.41 with SMTP id on9mr599574obc.18.1330075275013 (num_hops = 1); Fri, 24 Feb 2012 01:21:15 -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:content-transfer-encoding; bh=COG3FSJ9M0HTeUhoI+ZMIBjx4aTwEZXUK/GlTDzyLqY=; b=DO91mLquzUEwlW8Omr844FbeX6jeCKL6LCan6OB/QNhjVyjhJjKTwL7gjcDeiETueL r2zYoTdENhOp3az7CMDKl2uSoQEXF47kfcXMEy9Bq//lU6OM8u/PL3xQUnfbwF/jMEjW pI6DIcu0BI0Idz8duIQ3ydSi2+Kzyj2qiiOV0= MIME-Version: 1.0 Received: by 10.182.216.41 with SMTP id on9mr520814obc.18.1330075274948; Fri, 24 Feb 2012 01:21:14 -0800 (PST) Received: by 10.60.6.2 with HTTP; Fri, 24 Feb 2012 01:21:14 -0800 (PST) In-Reply-To: References: <1B2B5C1F-AF12-44CB-BCF1-C5DD2978FBEB@tzi.org> Date: Fri, 24 Feb 2012 17:21:14 +0800 Message-ID: From: ma yc To: Thomas Fossati Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: core WG Subject: Re: [core] Constrained Node/Network Cluster @ IETF83 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 09:21:17 -0000 +1 =D4=DA 2012=C4=EA2=D4=C224=C8=D5 =CF=C2=CE=E75:07=A3=ACThomas Fossati =D0=B4=B5=C0=A3=BA > On Feb 24, 2012, at 9:25 AM, Carsten Bormann wrote: >> Here is my usual compilation of the draft agenda for IETF83. >> Note that this agenda is subject to change, so please don't plan travel = around it. >> This time, we are nicely spread out over the week, so a lot of things wi= ll happen between the meeting slots. > > Too bad that the CoRE and HOMENET sessions have been superposed (on tuesd= ay). > > I tend to regard these two WGs as very much related. Am I the only one ? > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From salvatore.loreto@ericsson.com Fri Feb 24 01:31:08 2012 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 7DF1F21F88CA for ; Fri, 24 Feb 2012 01:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.507 X-Spam-Level: X-Spam-Status: No, score=-108.507 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, 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 r3t4EGnlAgZF for ; Fri, 24 Feb 2012 01:31:07 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC4C21F88C9 for ; Fri, 24 Feb 2012 01:31:07 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-e5-4f4758dace6a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 39.E8.27041.AD8574F4; Fri, 24 Feb 2012 10:31:06 +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.213.0; Fri, 24 Feb 2012 10:31:06 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 751DA2319 for ; Fri, 24 Feb 2012 11:31:05 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6A1275228E for ; Fri, 24 Feb 2012 11:31:05 +0200 (EET) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2606B5228D for ; Fri, 24 Feb 2012 11:31:05 +0200 (EET) Message-ID: <4F4758D8.4090007@ericsson.com> Date: Fri, 24 Feb 2012 11:31:04 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: core@ietf.org References: <1B2B5C1F-AF12-44CB-BCF1-C5DD2978FBEB@tzi.org> In-Reply-To: Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] Constrained Node/Network Cluster @ IETF83 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 09:31:08 -0000 I concur -- Salvatore Loreto www.sloreto.com On 2/24/12 11:21 AM, ma yc wrote: > +1 > > ÔÚ 2012Äê2ÔÂ24ÈÕ ÏÂÎç5:07£¬Thomas Fossati дµÀ£º >> On Feb 24, 2012, at 9:25 AM, Carsten Bormann wrote: >>> Here is my usual compilation of the draft agenda for IETF83. >>> Note that this agenda is subject to change, so please don't plan travel around it. >>> This time, we are nicely spread out over the week, so a lot of things will happen between the meeting slots. >> Too bad that the CoRE and HOMENET sessions have been superposed (on tuesday). >> >> I tend to regard these two WGs as very much related. Am I the only one ? >> _______________________________________________ >> 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 jaime.j.jimenez@ericsson.com Fri Feb 24 02:58:58 2012 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 8D9BA21F8927 for ; Fri, 24 Feb 2012 02:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 uqn0INvDU-sr for ; Fri, 24 Feb 2012 02:58:58 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 89CC321F8926 for ; Fri, 24 Feb 2012 02:58:57 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-94-4f476d70e30c Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 97.6A.27041.07D674F4; Fri, 24 Feb 2012 11:58:56 +0100 (CET) Received: from ESESSCMS0358.eemea.ericsson.se ([169.254.1.235]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 24 Feb 2012 11:58:55 +0100 From: =?iso-8859-1?Q?Jaime_Jim=E9nez_J?= To: "core@ietf.org" Date: Fri, 24 Feb 2012 11:58:51 +0100 Thread-Topic: draft-jimenez-p2psip-coap-reload-00 Thread-Index: Aczy40y0Zjlp8TlfSd+gB2GqdcIf1g== Message-ID: <9CB1CA12-3EA5-499E-9716-026635365D2A@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_CC2F7FD4-BF40-4C5E-86CB-58AC9B5CF1A9"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [core] draft-jimenez-p2psip-coap-reload-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 10:58:58 -0000 --Apple-Mail=_CC2F7FD4-BF40-4C5E-86CB-58AC9B5CF1A9 Content-Type: multipart/alternative; boundary="Apple-Mail=_7144FE32-4E85-45B4-A92E-5C15D104BB91" --Apple-Mail=_7144FE32-4E85-45B4-A92E-5C15D104BB91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, we just submitted a draft to the p2psip WG, it is also related with core = since we use CoAP. The draft proposes a CoAP Usage for RELOAD.=20 The CoAP Usage provides the functionality to federate Wireless Sensor = Networks (WSN) in a peer-to-peer fashion. =20 It also provides a rendezvous service for CoAP Nodes and caching of = sensor information in a DHT (Chord in particular) overlay .=20 http://tools.ietf.org/id/draft-jimenez-p2psip-coap-reload-00.txt=20 Best Regards, -- Jaime --Apple-Mail=_7144FE32-4E85-45B4-A92E-5C15D104BB91 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The CoAP Usage provides = the functionality to federate Wireless Sensor Networks (WSN) in a = peer-to-peer fashion.  
It also = provides a rendezvous service for CoAP Nodes and caching of = sensor information in a DHT (Chord in particular) overlay . =


Best Regards,
-- = Jaime

= --Apple-Mail=_7144FE32-4E85-45B4-A92E-5C15D104BB91-- --Apple-Mail=_CC2F7FD4-BF40-4C5E-86CB-58AC9B5CF1A9 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICEQCaObzOR9uy6LZk9ciUsJXTMA0GCSqGSIb3DQEBBQUAMDkxETAPBgNVBAoMCEVy aWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwHhcNMTExMDA3MDgy NDA3WhcNMTQxMDA3MDgyNDA1WjBqMREwDwYDVQQKDAhFcmljc3NvbjEWMBQGA1UEAwwNSmFpbWUg SmltZW5lejEQMA4GA1UEBRMHZWphamltbjErMCkGCSqGSIb3DQEJARYcamFpbWUuai5qaW1lbmV6 QGVyaWNzc29uLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzS0HqaJg8DzcIQIMn3U7 MMfhgUlP8eETQflo8p6+CtB6QePChaU+7igtsK28NwE3keNwGXAWulJlg4ScqvTHuhQkaCHpq1eZ X18exYkpzI2dw6LIVcJwVauWSIR7TEeuIHzD71ekDDdQGSFYMnhbKc+mTfWCpZ3zT9NH2IGok4kC AwEAAaOCAYgwggGEMIHABgNVHR8EgbgwgbUwgbKgga+ggayGN2h0dHA6Ly9jcmwudHJ1c3QudGVs aWEuY29tL0VyaWNzc29uTkxJbmRpdmlkdWFsQ0EwMS5jcmyGcWxkYXA6Ly9sZGFwLnRydXN0LnRl bGlhLmNvbS9jbj1Fcmljc3NvbiUyME5MJTIwSW5kaXZpZHVhbCUyMENBMDEsbz1Fcmljc3Nvbj9j ZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlMCcGA1UdEQQgMB6BHGphaW1lLmou amltZW5lekBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFLs/X1d9fU7fNptr Jf+FMGSwhLB8MB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAlAPQI4BnKBEx2hYo3J+WU0+ZB38sRl9P39BEZXv6pFeLP1kB 0b/oe20EQshlRuzttkwMoQ2ibW70LM6+dALQ+LzYNXVxH8RUnj7ZsyLHj3kmRiT9oFi0ytayn1+O quoC1njz5q2ULAInUIw5mfKZ0Rldm0TjtmhzMTjTNGyKSHU9fi8Ra+zu6CeXg/wEVSVy6XX9Chqc sL3WkTRea2juYj+xOVnz75nybxfAp9VRdGi7OGc8dOt2rVaf18LnPbgyzNUMUJfKvETHJrT6IG7P zH0lY3o7svmyr01evx/7tFq4pBoq9vYtYCzQ2Jf31WzbJu0HEzgNZAHnAK8AMNqbjDCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICFTCCAhECAQEwTjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhEAmjm8zkfbsui2ZPXIlLCV0zAJBgUrDgMCGgUAoIIBHTAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAyMjQxMDU4NTJaMCMGCSqG SIb3DQEJBDEWBBQmYqtqMwAvO3oZLKkEzXU3hC7B+DBdBgkrBgEEAYI3EAQxUDBOMDkxETAPBgNV BAoMCEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEQCaObzO R9uy6LZk9ciUsJXTMF8GCyqGSIb3DQEJEAILMVCgTjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIG A1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxAhEAmjm8zkfbsui2ZPXIlLCV0zANBgkq hkiG9w0BAQEFAASBgD5zQ7yo2pHVeVQGwM7x+QxIq90YOVXMW2qG3bcMddj+zOz0XUvkq6jipJoA ZAKnrIBp2JKGFhhS1prEZHxjxN55Yq5FjTt/waQx8cDjtqkuolfo4NU0LzsedhuQKFQ9BVykXx8/ cFDDL5kvxQXvkL2/WXFjw5hBukDtgnAN2kF8AAAAAAAA --Apple-Mail=_CC2F7FD4-BF40-4C5E-86CB-58AC9B5CF1A9-- From kerlyn2001@gmail.com Fri Feb 24 04:20:22 2012 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 BCACB21F86BD for ; Fri, 24 Feb 2012 04:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 uNKEFGdVbZSh for ; Fri, 24 Feb 2012 04:20:22 -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 81C3921F86B8 for ; Fri, 24 Feb 2012 04:20:21 -0800 (PST) Received: by lahl5 with SMTP id l5so3229262lah.31 for ; Fri, 24 Feb 2012 04:20:20 -0800 (PST) Received-SPF: pass (google.com: domain of kerlyn2001@gmail.com designates 10.152.112.132 as permitted sender) client-ip=10.152.112.132; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kerlyn2001@gmail.com designates 10.152.112.132 as permitted sender) smtp.mail=kerlyn2001@gmail.com; dkim=pass header.i=kerlyn2001@gmail.com Received: from mr.google.com ([10.152.112.132]) by 10.152.112.132 with SMTP id iq4mr1579355lab.28.1330086020303 (num_hops = 1); Fri, 24 Feb 2012 04:20:20 -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=qJ8G2gxEe/42M9LhjMuCTg0XXSUjuaWt7l0ncByejuc=; b=x8WOp03f7yf5DmbZQcaKZsVqtbCVlwAGhd7VuZQ7OTSkifTPcFe4f6bx+q6qVO3M1d 5Z2nvQUeL8wSU5kPG1xDTzWMUpQXycBysJtEsw6TzUsH7Uns1GeSIdlUljF3AnRLI0BO YjxnPHFw/oR43MV1J+8vY0YBfFpyId4liFF50= MIME-Version: 1.0 Received: by 10.152.112.132 with SMTP id iq4mr1315392lab.28.1330086020026; Fri, 24 Feb 2012 04:20:20 -0800 (PST) Received: by 10.112.111.106 with HTTP; Fri, 24 Feb 2012 04:20:19 -0800 (PST) In-Reply-To: <4F4758D8.4090007@ericsson.com> References: <1B2B5C1F-AF12-44CB-BCF1-C5DD2978FBEB@tzi.org> <4F4758D8.4090007@ericsson.com> Date: Fri, 24 Feb 2012 07:20:19 -0500 Message-ID: From: Kerry Lynn To: Salvatore Loreto Content-Type: multipart/alternative; boundary=f46d0408d673be930c04b9b4c856 Cc: core@ietf.org Subject: Re: [core] Constrained Node/Network Cluster @ IETF83 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 12:20:22 -0000 --f46d0408d673be930c04b9b4c856 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable ++ 2012/2/24 Salvatore Loreto > I concur > > -- > Salvatore Loreto > www.sloreto.com > > > > On 2/24/12 11:21 AM, ma yc wrote: > > +1 > > > > =D4=DA 2012=C4=EA2=D4=C224=C8=D5 =CF=C2=CE=E75:07=A3=ACThomas Fossati <= tho@koanlogic.com> =D0=B4=B5=C0=A3=BA > >> On Feb 24, 2012, at 9:25 AM, Carsten Bormann wrote: > >>> Here is my usual compilation of the draft agenda for IETF83. > >>> Note that this agenda is subject to change, so please don't plan > travel around it. > >>> This time, we are nicely spread out over the week, so a lot of things > will happen between the meeting slots. > > >> Too bad that the CoRE and HOMENET sessions have been superposed (on > tuesday). > >> > >> I tend to regard these two WGs as very much related. Am I the only on= e > ? > >> _______________________________________________ > >> 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 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --f46d0408d673be930c04b9b4c856 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable ++

2012/2/24 Salvatore Loreto <salvatore.lor= eto@ericsson.com>
I concur

--
Salvatore Loreto
www.sloreto.com



On 2/24/12 11:21 AM, ma yc wrote:
> +1
>
> =D4=DA 2012=C4=EA2=D4=C224=C8=D5 =CF=C2=CE=E75:07=A3=ACThomas Fossati = <tho@koanlogic.com> =D0=B4= =B5=C0=A3=BA
>> On Feb 24, 2012, at 9:25 AM, Carsten Bormann wrote:
>>> Here is my usual compilation of the draft agenda for IETF83. >>> Note that this agenda is subject to change, so please don'= t plan travel around it.
>>> This time, we are nicely spread out over the week, so a lot of= things will happen between the meeting slots.

>> Too bad that the CoRE and HOMENET sessions have been superposed (o= n tuesday).
>>
>> I tend to regard these two WGs as very much related.  Am I th= e only one ?
>> _______________________________________________
>> 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

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

--f46d0408d673be930c04b9b4c856-- From fluffy@iii.ca Fri Feb 24 08:05:07 2012 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 2ACC021F865D for ; Fri, 24 Feb 2012 08:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[AWL=-0.201, 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 QxGzOKKHXV6J for ; Fri, 24 Feb 2012 08:05:05 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2E56221F87C5 for ; Fri, 24 Feb 2012 08:05:03 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9291722DD6D for ; Fri, 24 Feb 2012 11:05:02 -0500 (EST) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 24 Feb 2012 09:05:02 -0700 References: <20120223200500.32458.2768.idtracker@ietfa.amsl.com> To: core WG Message-Id: <59DA5163-0875-48F4-9F8C-0502128B7967@iii.ca> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Fwd: core - Requested sessions have been scheduled for IETF 83 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:05:07 -0000 FYI on meeting time at IETF 83 - note this is *draft* and may change. Begin forwarded message: > core Session 1 (2 hours) > Tuesday, Morning Session I 0930-1130 > Room Name: 243 > --------------------------------------------- > core Session 2 (2 hours) > Friday, Morning Session I 0900-1100 > Room Name: 253 > --------------------------------------------- From stpeter@stpeter.im Fri Feb 24 08:09:28 2012 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 E10D821F8621 for ; Fri, 24 Feb 2012 08:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.684 X-Spam-Level: X-Spam-Status: No, score=-102.684 tagged_above=-999 required=5 tests=[AWL=-0.085, 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 7KLTQgZAfLIw for ; Fri, 24 Feb 2012 08:09:27 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 921EE21F8622 for ; Fri, 24 Feb 2012 08:09:27 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 101CF40058 for ; Fri, 24 Feb 2012 09:20:47 -0700 (MST) Message-ID: <4F47B635.8090103@stpeter.im> Date: Fri, 24 Feb 2012 09:09:25 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: core@ietf.org References: <1B2B5C1F-AF12-44CB-BCF1-C5DD2978FBEB@tzi.org> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [core] Constrained Node/Network Cluster @ IETF83 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:09:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/24/12 2:07 AM, Thomas Fossati wrote: > On Feb 24, 2012, at 9:25 AM, Carsten Bormann wrote: >> Here is my usual compilation of the draft agenda for IETF83. Note >> that this agenda is subject to change, so please don't plan >> travel around it. This time, we are nicely spread out over the >> week, so a lot of things will happen between the meeting slots. > > Too bad that the CoRE and HOMENET sessions have been superposed (on > tuesday). > > I tend to regard these two WGs as very much related. Am I the only > one ? As you have no doubt noticed, the schedule for IETF 83 is *very* full. It was extremely difficult to get every requested session onto the schedule. If the CORE and HOMENET chairs think this is a bad conflict that needs to be fixed, then please contact your friendly ADs. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9HtjMACgkQNL8k5A2w/vwnkwCgrxG/xZA3OKcHR7YkHMgNQyZn 9U8AniTSH97GvT8GHXoO3AsoI/XTVFlS =x4IV -----END PGP SIGNATURE----- From likepeng@huawei.com Mon Feb 27 00:36:00 2012 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 DC08921F8478 for ; Mon, 27 Feb 2012 00:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[AWL=1.197, BAYES_00=-2.599, HTML_MESSAGE=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 OGqz9U4GKUmr for ; Mon, 27 Feb 2012 00:36:00 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 10EDD21F8471 for ; Mon, 27 Feb 2012 00:35:59 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0100ED5MJ6PE@szxga04-in.huawei.com> for core@ietf.org; Mon, 27 Feb 2012 16:35:31 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M010061JMI2ZG@szxga04-in.huawei.com> for core@ietf.org; Mon, 27 Feb 2012 16:35:30 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHK89467; Mon, 27 Feb 2012 16:35:30 +0800 Received: from SZXEML432-HUB.china.huawei.com (10.72.61.60) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 27 Feb 2012 16:34:59 +0800 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.201]) by SZXEML432-HUB.china.huawei.com ([10.72.61.60]) with mapi id 14.01.0323.003; Mon, 27 Feb 2012 16:35:25 +0800 Date: Mon, 27 Feb 2012 08:35:25 +0000 From: Likepeng In-reply-to: <4F3FA968.10802@ericsson.com> X-Originating-IP: [10.70.109.64] To: "core@ietf.org" Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F20181C560@szxeml525-mbx.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Qf90136ePXVwYD29HToKjA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [core] Patience Thread-index: AQHM7kJn2IsvNVdbGUi0isi19HO7ZZZQeFDw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <67192BEA-8E33-4FB6-ADC4-FE62A35D658B@tzi.org> <4F3FA968.10802@ericsson.com> Subject: [core] Patience X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 08:36:01 -0000 --Boundary_(ID_Qf90136ePXVwYD29HToKjA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SGVsbG8gYWxsLA0KDQpIZXJlIGlzIHRoZSB1cGxvYWRlZCBwYXRpZW5jZSBkcmFmdDoNCmh0dHA6 Ly93d3cuaWV0Zi5vcmcvc3RhZ2luZy9kcmFmdC1saS1jb3JlLWNvYXAtcGF0aWVuY2Utb3B0aW9u LTAwLnR4dA0KDQpXZWxjb21lIHlvdXIgY29tbWVudHMgYW5kIGZlZWRiYWNrcy4NCg0KVGhhbmtz LA0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCuWPkeS7tuS6ujogY29yZS1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSDku6PooaggU2FsdmF0b3JlIExvcmV0bw0K 5Y+R6YCB5pe26Ze0OiAyMDEy5bm0MuaciDE45pelIDIxOjM3DQrmlLbku7bkuro6IGNvcmVAaWV0 Zi5vcmcNCuS4u+mimDogW2NvcmVdIFBhdGllbmNlICggd2FzIFJlOiBSZXNvbHV0aW9uIHRvIHRp Y2tldHMgIzE3NiwgIzE3NywgIzE4MSkNCg0KYXMgcG9pbnRlZCBvdXQgYnkgS2VwZW5nIGluDQpo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY29yZS9jdXJyZW50L21zZzAyNjQ0 Lmh0bWwNCg0Kd2UgYXJlIHdvcmtpbmcgdG9nZXRoZXIgdG8gcHJvcG9zZSBhIHNvbHV0aW9uIGZv ciAxNzQNCnRoYXQgc29tZWhvdyBvdmVybG9hZCB0aGUgUGF0aWVuY2UgT3B0aW9uDQp0byBjbGVh cmx5IGFuZCBjbGVhbmx5IHNvbHZlICBhbGwgdGhlIHRocmVlIGRpZmZlcmVudCBkaWZmZXJlbnQg Y2FzZSAoU2VjdGlvbiA0LjEgUGF0aWVuY2UsIDQuMiBMZWlzdXJlLCA0LjMgUGxlZGdlIHlvdSBo YXZlIGF0IG1vbWVudCBpbiBjb2FwLW1pc2MgKQ0KDQpJIGRvbid0IHNlZSB0aGUgbmVlZCB0byBk ZWZpbmUgdGhyZWUgZGlmZmVyZW50IE9wdGlvbnMsIGJ1dCBsZXRzIGRpc2N1c3MgaXQgb24gdGhl IG1haWxpbmcgbGlzdCBvbmNlIHRoZSBkcmFmdCB3aWxsIGJlIHJlbGVhc2VkDQphbmQgZXZlbnR1 YWxseSBpbiBvbmUgb2YgdGhlIENvUmUgc2Vzc2lvbnMgaW4gUGFyaXMuDQoNClRoZSBmaXJzdCB2 ZXJzaW9uIG9mIHRoZSBkcmFmdCBpcyBhbG1vc3QgcmVhZHkgYW5kIExpIEtlcGVuZyB3aWxsIHN1 Ym1pdCB0aGUgZHJhZnQgaW4gdGhlIG5leHQgZmV3IGRheXMuLg0KDQpyZWdhcmRzDQpTYWwNCg0K DQotLQ0KDQpTYWx2YXRvcmUgTG9yZXRvDQoNCnd3dy5zbG9yZXRvLmNvbTxodHRwOi8vd3d3LnNs b3JldG8uY29tPg0KDQoNCg0KT24gMi8xNS8xMiA1OjIzIFBNLCBDYXJzdGVuIEJvcm1hbm4gd3Jv dGU6DQoNCktsYXVzIGFuZCBJIHNhdCB0b2dldGhlciB0b2RheSBhbmQgcmVhcnJhbmdlZCBjb2Fw LW1pc2MsIG1vdmluZyBzdHVmZiB0aGF0IGlzbid0IHJlYWR5IGZvciBzdGFuZGFyZGl6YXRpb24g dG8gdGhlIGFwcGVuZGljZXMgYW5kIGZpbmlzaGluZyBvdGhlciBzdHVmZi4NCg0KDQoNCkFzIGEg cmVzdWx0LCB3ZSBhcmUgcHJvcG9zaW5nIHRoZSBib2R5IG9mIGNvYXAtbWlzYyBhcyB0aGUgcmVz b2x1dGlvbiBmb3IgdGlja2V0cyAjMTc2LCAjMTc3IChhbmQgaW5kaXJlY3RseSBmb3IgIzE3NCks IGFuZCAjMTgxLCBhcyB3ZWxsIGFzIHRoZSB2ZW5kb3ItZGVmaW5lZCBvcHRpb24gdGhhdCB3YXMg ZGlzY3Vzc2VkLg0KDQoNCg0KSWYgdGhlc2Ugc29sdXRpb25zIGFyZSBhY2NlcHRhYmxlLCB0aGlz IGxlYXZlcyB1cyB3aXRoICMxNjYgYW5kICMxODMgKCMxODIgYWxyZWFkeSBoYXMgcHJvcG9zZWQg dGV4dCBhbmQganVzdCBuZWVkcyB0byBiZSBhcHBsaWVkKSBvbiBjb3JlLWNvYXAuICBJIGFsc28g aGF2ZSB0byBnZW5lcmF0ZSBhIHByb3Bvc2FsIGZvciAjMTcxIChibG9jayksIGFuZCB3ZSBuZWVk IHRvIGRlY2lkZSB3aGV0aGVyICMxNzAgcmVhbGx5IG5lZWRzIGFueSB3b3JrLg0KDQoNCg0KSSBh bSBvcHRpbWlzdGljIHdlIGNhbiBmaW5pc2ggYWxsIHRoaXMgaW4gdGhlIG5leHQgY291cGxlIG9m IGRheXMsIHNvIHdlIGhhdmUgYSBzZXQgb2YgZG9jdW1lbnRzIHRoYXQgdGhlIGF1dGhvcnMgYmVs aWV2ZSBpcyByZWFkeSBmb3IgV0dMQy4NCg0KDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCmNvcmUgbWFp bGluZyBsaXN0DQoNCmNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQoNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQo= --Boundary_(ID_Qf90136ePXVwYD29HToKjA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0K CXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEg NiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFw5ODg0XDhCQkVcNjgzQ1w1RjBGIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJIVE1MIFw5ODg0XDhCQkVcNjgzQ1w1RjBGIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBcOTg4NFw4QkJFXDY4M0NcNUYwRiI7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIu MHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5IZWxsbyBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhl cmUgaXMgdGhlIHVwbG9hZGVkIHBhdGllbmNlIGRyYWZ0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9zdGFnaW5n L2RyYWZ0LWxpLWNvcmUtY29hcC1wYXRpZW5jZS1vcHRpb24tMDAudHh0Ij5odHRwOi8vd3d3Lmll dGYub3JnL3N0YWdpbmcvZHJhZnQtbGktY29yZS1jb2FwLXBhdGllbmNlLW9wdGlvbi0wMC50eHQ8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlbGNvbWUgeW91ciBjb21t ZW50cyBhbmQgZmVlZGJhY2tzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5LaW5kIFJl Z2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPktlcGVuZzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpTaW1TdW47Y29sb3I6d2luZG93dGV4dCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4t VVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOndpbmRvd3RleHQiPiBjb3JlLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOndpbmRv d3RleHQiPuS7o+ihqCA8L3NwYW4+DQo8L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjp3aW5kb3d0ZXh0Ij5TYWx2YXRv cmUgTG9yZXRvPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OlNpbVN1bjtjb2xvcjp3aW5kb3d0ZXh0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5n PSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6d2luZG93dGV4dCI+IDIwMTI8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2Nv bG9yOndpbmRvd3RleHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4yPC9zcGFuPuaciDxzcGFuIGxh bmc9IkVOLVVTIj4xODwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMjE6Mzc8YnI+DQo8 L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gY29yZUBpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5n PSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBbY29yZV0gUGF0aWVuY2Ug KCB3YXMgUmU6IFJlc29sdXRpb24gdG8gdGlja2V0cyAjMTc2LCAjMTc3LCAjMTgxKTxvOnA+PC9v OnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5hcyBwb2ludGVkIG91dCBieSBLZXBl bmcgaW48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv Y29yZS9jdXJyZW50L21zZzAyNjQ0Lmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9jb3JlL2N1cnJlbnQvbXNnMDI2NDQuaHRtbDwvYT48YnI+DQo8YnI+DQp3ZSBhcmUg d29ya2luZyB0b2dldGhlciB0byBwcm9wb3NlIGEgc29sdXRpb24gZm9yIDE3NCA8YnI+DQp0aGF0 IHNvbWVob3cgb3ZlcmxvYWQgdGhlIFBhdGllbmNlIE9wdGlvbjxicj4NCnRvIGNsZWFybHkgYW5k IGNsZWFubHkgc29sdmUmbmJzcDsgYWxsIHRoZSB0aHJlZSBkaWZmZXJlbnQgZGlmZmVyZW50IGNh c2UgKFNlY3Rpb24gNC4xIFBhdGllbmNlLCA0LjIgTGVpc3VyZSwgNC4zIFBsZWRnZSB5b3UgaGF2 ZSBhdCBtb21lbnQgaW4gY29hcC1taXNjICk8YnI+DQo8YnI+DQpJIGRvbid0IHNlZSB0aGUgbmVl ZCB0byBkZWZpbmUgdGhyZWUgZGlmZmVyZW50IE9wdGlvbnMsIGJ1dCBsZXRzIGRpc2N1c3MgaXQg b24gdGhlIG1haWxpbmcgbGlzdCBvbmNlIHRoZSBkcmFmdCB3aWxsIGJlIHJlbGVhc2VkPGJyPg0K YW5kIGV2ZW50dWFsbHkgaW4gb25lIG9mIHRoZSBDb1JlIHNlc3Npb25zIGluIFBhcmlzLjxicj4N Cjxicj4NClRoZSBmaXJzdCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBpcyBhbG1vc3QgcmVhZHkgYW5k IExpIEtlcGVuZyB3aWxsIHN1Ym1pdCB0aGUgZHJhZnQgaW4gdGhlIG5leHQgZmV3IGRheXMuLjxi cj4NCjxicj4NCnJlZ2FyZHM8YnI+DQpTYWw8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlNhbHZhdG9yZSBMb3JldG88bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHA6Ly93d3cuc2xv cmV0by5jb20iPnd3dy5zbG9yZXRvLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8YnI+DQpP biAyLzE1LzEyIDU6MjMgUE0sIENhcnN0ZW4gQm9ybWFubiB3cm90ZTogPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+S2xhdXMgYW5kIEkgc2F0IHRvZ2V0aGVy IHRvZGF5IGFuZCByZWFycmFuZ2VkIGNvYXAtbWlzYywgbW92aW5nIHN0dWZmIHRoYXQgaXNuJ3Qg cmVhZHkgZm9yIHN0YW5kYXJkaXphdGlvbiB0byB0aGUgYXBwZW5kaWNlcyBhbmQgZmluaXNoaW5n IG90aGVyIHN0dWZmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj5BcyBhIHJlc3VsdCwgd2UgYXJlIHByb3Bvc2luZyB0aGUgYm9keSBvZiBjb2FwLW1pc2Mg YXMgdGhlIHJlc29sdXRpb24gZm9yIHRpY2tldHMgIzE3NiwgIzE3NyAoYW5kIGluZGlyZWN0bHkg Zm9yICMxNzQpLCBhbmQgIzE4MSwgYXMgd2VsbCBhcyB0aGUgdmVuZG9yLWRlZmluZWQgb3B0aW9u IHRoYXQgd2FzIGRpc2N1c3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+SWYgdGhlc2Ugc29sdXRpb25zIGFyZSBhY2NlcHRhYmxlLCB0aGlzIGxlYXZl cyB1cyB3aXRoICMxNjYgYW5kICMxODMgKCMxODIgYWxyZWFkeSBoYXMgcHJvcG9zZWQgdGV4dCBh bmQganVzdCBuZWVkcyB0byBiZSBhcHBsaWVkKSBvbiBjb3JlLWNvYXAuJm5ic3A7IEkgYWxzbyBo YXZlIHRvIGdlbmVyYXRlIGEgcHJvcG9zYWwgZm9yICMxNzEgKGJsb2NrKSwgYW5kIHdlIG5lZWQg dG8gZGVjaWRlIHdoZXRoZXIgIzE3MCByZWFsbHkgbmVlZHMgYW55IHdvcmsuPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYW0gb3B0aW1pc3RpYyB3ZSBj YW4gZmluaXNoIGFsbCB0aGlzIGluIHRoZSBuZXh0IGNvdXBsZSBvZiBkYXlzLCBzbyB3ZSBoYXZl IGEgc2V0IG9mIGRvY3VtZW50cyB0aGF0IHRoZSBhdXRob3JzIGJlbGlldmUgaXMgcmVhZHkgZm9y IFdHTEMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkdy w7zDn2UsIENhcnN0ZW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmNvcmUgbWFpbGlu ZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48 YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jb3JlPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --Boundary_(ID_Qf90136ePXVwYD29HToKjA)-- From trac+core@trac.tools.ietf.org Mon Feb 27 03:19:15 2012 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 A281C21F86C9 for ; Mon, 27 Feb 2012 03:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 tdG7f939fyH8 for ; Mon, 27 Feb 2012 03:19:15 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5CB21F86C7 for ; Mon, 27 Feb 2012 03:19:14 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S1ybf-0002mV-0j; Mon, 27 Feb 2012 06:19:03 -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: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 27 Feb 2012 11:19:02 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/185 Message-ID: <060.aed390b8a1237d4f971337af6cfc7d37@trac.tools.ietf.org> X-Trac-Ticket-ID: 185 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.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 Resent-To: Resent-Message-Id: <20120227111915.1B5CB21F86C7@ietfa.amsl.com> Resent-Date: Mon, 27 Feb 2012 03:19:14 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #185: Add key use cases including discovery 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, 27 Feb 2012 11:19:15 -0000 #185: Add key use cases including discovery As requested during the IETF 82 CoRE meeting. -- -----------------------------+----------------------------------------- Reporter: esko.dijk@… | Owner: draft-ietf-core-groupcomm@… Type: protocol defect | Status: new Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -----------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Feb 27 03:24:08 2012 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 1789A21F86D7 for ; Mon, 27 Feb 2012 03:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 JZfX1aBptU9H for ; Mon, 27 Feb 2012 03:24:07 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A4E7521F86C6 for ; Mon, 27 Feb 2012 03:24:06 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S1ygS-0004I5-Jt; Mon, 27 Feb 2012 06:24:00 -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: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 27 Feb 2012 11:24:00 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/186 Message-ID: <060.eb5c7fd492cee5e575b774073d7222ad@trac.tools.ietf.org> X-Trac-Ticket-ID: 186 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.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 Resent-To: Resent-Message-Id: <20120227112407.A4E7521F86C6@ietfa.amsl.com> Resent-Date: Mon, 27 Feb 2012 03:24:06 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #186: Clearer guidance on group operations (PUT/POST/GET) 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, 27 Feb 2012 11:24:08 -0000 #186: Clearer guidance on group operations (PUT/POST/GET) Have clearer guidance on the group operations and in what cases which can be used. If possible/useful, improve the definition of group in terms of group of end-points with shared resource name(s). -- -------------------------+----------------------------------------- Reporter: esko.dijk@… | Owner: draft-ietf-core-groupcomm@… Type: task | Status: new Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Feb 27 03:25:52 2012 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 E5C1121F86B7 for ; Mon, 27 Feb 2012 03:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 WJvIIL87QKSr for ; Mon, 27 Feb 2012 03:25:52 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7966021F86B2 for ; Mon, 27 Feb 2012 03:25:52 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S1yi7-0000ua-H2; Mon, 27 Feb 2012 06:25:43 -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: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 27 Feb 2012 11:25:43 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/187 Message-ID: <060.5ebafee4b484555221fd2bac521f9baa@trac.tools.ietf.org> X-Trac-Ticket-ID: 187 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.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 Resent-To: Resent-Message-Id: <20120227112552.7966021F86B2@ietfa.amsl.com> Resent-Date: Mon, 27 Feb 2012 03:25:52 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #187: Identify deployment scenarios where IP multicast may NOT work well 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, 27 Feb 2012 11:25:53 -0000 #187: Identify deployment scenarios where IP multicast may NOT work well Identify any deployment scenarios where IP multicast may NOT work well. Consider the alternative group communication methods in these caes. As requested in IETF 82 CoRE meeting. -- -------------------------+----------------------------------------- Reporter: esko.dijk@… | Owner: draft-ietf-core-groupcomm@… Type: task | Status: new Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Feb 27 03:29:17 2012 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 0420021F86B7 for ; Mon, 27 Feb 2012 03:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 u1pgl0ytSYSa for ; Mon, 27 Feb 2012 03:29:16 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 67D2B21F86B5 for ; Mon, 27 Feb 2012 03:29:15 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S1ylQ-0006tl-VW; Mon, 27 Feb 2012 06:29:09 -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: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 27 Feb 2012 11:29:08 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/188 Message-ID: <060.6fe395be06f6b58e5701326691e6bff7@trac.tools.ietf.org> X-Trac-Ticket-ID: 188 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.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 Resent-To: Resent-Message-Id: <20120227112916.67D2B21F86B5@ietfa.amsl.com> Resent-Date: Mon, 27 Feb 2012 03:29:15 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #188: Update congestion control with recent "Patience" contributions 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, 27 Feb 2012 11:29:17 -0000 #188: Update congestion control with recent "Patience" contributions Update congestion control section with recent "Patience" contributions from draft-bormann-coap-misc-12, draft-li-core-coap-patience-option-00 and CoRE WG list discussions on these. -- -------------------------+----------------------------------------- Reporter: esko.dijk@… | Owner: draft-ietf-core-groupcomm@… Type: task | Status: new Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Feb 27 06:23:20 2012 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 7038021F85F6 for ; Mon, 27 Feb 2012 06:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 t-zcxk8MjJfq for ; Mon, 27 Feb 2012 06:23:19 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 85DF821F85D7 for ; Mon, 27 Feb 2012 06:23:18 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S21Tq-0000dh-Tl; Mon, 27 Feb 2012 09:23:10 -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: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 27 Feb 2012 14:23:10 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/185#comment:1 Message-ID: <075.ce2d56e1c5c7a0c9b2dea106980306b0@trac.tools.ietf.org> References: <060.aed390b8a1237d4f971337af6cfc7d37@trac.tools.ietf.org> X-Trac-Ticket-ID: 185 In-Reply-To: <060.aed390b8a1237d4f971337af6cfc7d37@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.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 Resent-To: Resent-Message-Id: <20120227142319.85DF821F85D7@ietfa.amsl.com> Resent-Date: Mon, 27 Feb 2012 06:23:18 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #185: Add key use cases including discovery 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, 27 Feb 2012 14:23:20 -0000 #185: Add key use cases including discovery Changes (by esko.dijk@…): * type: protocol defect => task -- -------------------------+------------------------------------------ Reporter: esko.dijk@… | Owner: draft-ietf-core-groupcomm@… Type: task | Status: new Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------ Ticket URL: core From julian.reschke@gmx.de Tue Feb 28 11:49:43 2012 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 AC51121F853A for ; Tue, 28 Feb 2012 11:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.918 X-Spam-Level: X-Spam-Status: No, score=-103.918 tagged_above=-999 required=5 tests=[AWL=-2.519, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, 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 CQtrZ4rda-T9 for ; Tue, 28 Feb 2012 11:49:41 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4B57721F850F for ; Tue, 28 Feb 2012 11:49:41 -0800 (PST) Received: (qmail invoked by alias); 28 Feb 2012 19:49:39 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp035) with SMTP; 28 Feb 2012 20:49:39 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+8PRsKDuy8QX1alOSuZDU8XOQHK/Q//C8986zzSw OFhIOaSwGhWh8y Message-ID: <4F4D2FCB.8030805@gmx.de> Date: Tue, 28 Feb 2012 20:49:31 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: IETF Apps Discuss , draft-ietf-core-link-format@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Tue, 28 Feb 2012 11:51:00 -0800 Cc: The IESG , core@ietf.org Subject: [core] APPSDIR review of draft-ietf-core-link-format-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 19:49:43 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-core-link-format-11 Title: CoRE Link Format Reviewer: Julian Reschke Review Date: 2012-02-28 IETF Last Call Date: 2012-02-14 IESG Telechat Date: ? Summary: This draft is almost ready for publication as an Standards Track RFC but has a few issues that should be fixed before publication (I tried to categorize into Major/Minor/Nits but sometimes left Nits in context so that they appear under Major/Minor) Major Issues: 2.2. Link relations Since links in the CoRE Link Format are typically used to describe resources hosted by a server, and thus in the absence of the relation parameter the new relation type "hosts" is assumed (see Section 7.2). It took me a moment to realize that "hosts" isn't the plural of "host" here. Maybe a different relation name would make things clearer (although I currently have no better proposal :-). The "hosts" relation type indicates that the target URI is a resource hosted by the server given by the base URI, or, if present, the anchor parameter. So the rule for determining the context URI is different for this link relation? I believe this needs to change. To express other relations, links can make use of any registered relation by including the relation parameter. To simplify the constrained implementations, the value of a "rel" parameter in this link format SHOULD NOT contain more than one relation type. There That's a SHOULD NOT that doesn't help anybody. Are recipients supposed to understand multiple relation types or not? If yes, then the constraint isn't needed. If no, it's a MUST NOT. may be cases where multiple relation types cannot be avoided, for example when storing a RFC5988 Link header in this link format. The context of a relation can be defined using the anchor parameter. In this way, relations between resources hosted on a server, or between hosted resources and external resources can be expressed. This seems to repeat information from earlier on... 3. CoRE link extensions The following CoRE specific target attributes are defined in addition to the ABNF rules in Section 5 of [RFC5988]. These attributes describe information useful in accessing the target link of the relation, and in some cases may be URIs. These URIs MUST be treated s/may be/can use the syntactical form of a/ as non resolvable identifiers (they are not meant to be retrieved). Not sure about the "MUST". Maybe replace with an explanation that they can indeed by dereferenced (for instance to obtain a description of the link relation), but that this is not part of the protocol and MUST NOT be done automatically on link evaluation. When attributes are compared, they MUST be compared as strings. Attribute values? Relationships to resources that are meant to be retrieved should be expressed as separate links using the anchor attribute and the appropriate relation type. It's not clear to me what this means. Could you elaborate? link-extension = link-extension =/ ( "rt=" quoted-string ) link-extension =/ ( "if=" quoted-string ) link-extension =/ ( "sz=" cardinal ) cardinal = "0" / %x31-39 *DIGIT In here, you copied the ABNF style from RFC 5988. I think that style is something we should avoid, though, because it encourages parsers to special case certain attributes. I would recommend to allow both token and quoted-string for all new parameters. (and yes, I'll raise an erratum against RFC 5988 once we have done the base work in HTTPbis) 3.1. Resource type 'rt' attribute The resource type "rt" attribute is an opaque string used to assign a semantically important type to a resource. One can think of this as a noun describing the resource. In the case of a temperature resource this could be e.g. an application-specific semantic type like "OutdoorTemperature", a Universal Resource Name (URN) like "urn:temperature:outdoor" or a URI referencing a specific concept in an ontology like "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature". Multiple resource type attributes MAY appear in a link. Please avoid that. In general, the format that you're borrowing from doesn't allow multiple parameters with the same name. Either make it multiple links, or allow a white-space separated list of values in the attribute value. The resource type attribute is not meant to used to assign a human readable name to a resource. The "title" attribute defined in [RFC5988] is meant for that purpose. Did you consider using the type attribute that already is defined in RFC 5988? 5. Examples A few examples of typical link descriptions in this format follows. Multiple resource descriptions in a representation are separated by commas. Linefeeds never occur in the actual format, but are shown in these examples for readability. Although the following examples use CoAP response codes, the examples are applicable to HTTP as well (the corresponding response code would be 200 OK). Actually, RFC 5988 allows CR LF between parameters as it uses the RFC 2616 list production allowing implied LWS. If you want to rule this out, you probably need to specify your own ABNF. This example arranges link descriptions hierarchically, with the entry point including a link to a sub-resource containing links about the sensors. REQ: GET /.well-known/core RES: 2.05 "Content" ;rt="index" REQ: GET /sensors RES: 2.05 "Content" ;rt="TemperatureC";if="sensor", ;rt="LightLux";if="sensor" rt="index" is mentioned for the first time here. Is this something recipients need to understand, so is it predefined? Also, isn't this a use case for rel=index? Minor Issues: The main function of such a discovery mechanism is to provide Universal Resource Identifiers (URIs, called links) for the resources Nope. As discussed further down below, a link requires two resources, not a single one. 2.1. Target and context URIs Each link conveys one target URI as a URI-reference inside angle brackets ("<>"). The context URI of a link (also called base URI in [RFC3986]) conveyed in the CoRE Link Format is by default built from the scheme and authority parts of the target URI. In the absence of OK, so ; rel=bar represents the link http://example.com --bar--> http://example.com/foo ? Sounds a bit counter-intuitive to me; maybe you should explain that in examples. this information in the target URI, the context URI is built from the scheme and authority that was used for referencing the resource returning the set of links, replacing the path with an empty path. Thus by default links can be thought of as describing a target resource hosted by the server. Other relations can be expressed by including an anchor parameter (which defines the context URI) along with an explicit relation parameter. This is an important difference to the way the HTTP Link Header format is used, as it is included in the header of an HTTP response for some URI (this URI is by default the context URI). Thus the HTTP Link Header is by default relating the target URI to the URI that was requested. In comparison, the CoRE link format includes one or more links, each describing a resource hosted by a server by default. Other relations can be expressed by using the anchor parameter. See Section 5 of [RFC3986] for a description of how URIs are constructed from URI references. Alternative explanation: The context URI specified by a) the anchor parameter, when specified, or b) protocol + authority of the target URI, when specified c) protocol + authority of the link format document's base URI. It would be nice if the reason why only protocol + authority are used. (you may also want to use the term "Origin" (RFC 6454) for protocol + authority) 2.3. Use of anchors As per Section 5.2 of [RFC5988] a link description MAY include an "anchor" attribute, in which case the context is the URI included in that attribute. This is used to describe a relationship between two resources. 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. Right. Maybe make clear that recipients MUST either process anchor correctly, or ignore the whole link relation (not only the anchor parameter). 7.2. New 'hosts' relation type This memo registers the new "hosts" Web Linking relation type as per [RFC5988]. Relation Name: hosts Description: Refers to a resource hosted by the server indicated by the link context. Does that indicate more than "is one the same server"? In which case I believe no link relation is needed. Nits: Abstract This document defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes and other relationships between links. Based on the HTTP Link Header format defined in RFC5988, the CoRE Link Format is Please s/header/header field/ throughout. Resource Discovery can be performed either unicast or multicast. When a server's IP address is already known, either a priori or resolved via the Domain Name System (DNS) [RFC1034][RFC1035], unicast discovery is performed in order to locate the entry point to the resource of interest. This is performed using a GET to /.well-known/ core on the server, which returns a payload in the CoRE Link Format. A client would then match the appropriate Resource Type, Interface Description and possible Content-Type [RFC2045] for its application. "Media type, as specified in the type attribute"? CoRE Link Format A particular serialization of typed links based the HTTP Link Header serialization defined in Section 5 of RFC5988, but carried as a resource representation with a MIME type. s/MIME type/Internet Media Type/ Attribute Properly called "Target Attribute" in RFC5988. A set of key/value pairs that describe the link or its target. One attribute is a *single* key/value pair... 3.2. Interface description 'if' attribute The Interface Description "if" attribute is an opaque string used to provide a name, URI or URN indicating a specific interface definition URNs are a subset of URIs... used to interact with the target resource. One can think of this as describing verbs usable on a resource. The Interface Description attribute is meant to describe the generic REST interface to interact with a resource or a set of resources. It is expected that an Interface Description will be re-used by different resource types. For example the resource types "OutdoorTemperature", "DewPoint" and "RelHumidity" could all be accessible using the Interface Description "http://www.example.org/myapp.wadl#sensor". The Interface Description could be for example the URI of a Web Application Description Language (WADL) [WADL] definition of the target resource "http://www.example.org/myapp.wadl#sensor", a URN indicating the type of interface to the resource "urn:myapp:sensor", or an application-specific name "Sensor". Multiple Interface Description attributes MAY appear in a link. (see above) 3.3. Maximum size estimate 'sz' attribute The maximum size estimate attribute "sz" gives an indication of the maximum size of the resource indicated by the target URI. This Checking: is "size of the resource" sufficiently defined in Core? In HTTP it would need a somewhat more complex definition ("payload returned upon GET..."). 4.1. Query Filtering A server implementing this document MAY recognize the query part of a resource discovery URI as a filter on the resources to be returned. The query part should conform to the following syntax (parmname is as defined in [RFC5988], pct-encoded and unreserved are defined in [RFC3986]). Note that this only defines querying for a single parameter at a time. I note that hardwiring URI query parameters into the protocol is *not* Restful. Also, you probably need to state how to present non-ASCII parameter characters in the parameter (UTF8-encode-then-percent-escape...) filter-query = resource-param "=" query-pattern resource-param = "uri" / parmname query-pattern = search-token [ "*" ] search-token = *search-char search-char = unreserved / pct-encoded / ":" / "@" ; from pchar / "/" / "?" ; from query / "!" / "$" / "'" / "(" / ")" / "+" / "," / ";" / "=" ; from sub-delims The resource-param "uri" refers to the URI-reference between the "<" and ">" characters of a link. Other resource-param values refer to the link attribute they name. Filtering is performed by comparing the query-pattern against the value of the attribute identified by the resource-param for each link-value in the collection of resources identified by the URI path. Which makes it impossible to use "uri" as link attribute. Maybe this should be noted. Alternatively maybe use a format that doesn't require overloading the name. This example shows the use of an anchor attribute to relate the temperature sensor resource to an external description and to an alternative URL. s/URL/URI/ From cabo@tzi.org Tue Feb 28 12:14:39 2012 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 042BB21E8053; Tue, 28 Feb 2012 12:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.426 X-Spam-Level: X-Spam-Status: No, score=-106.426 tagged_above=-999 required=5 tests=[AWL=-0.177, 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 teaZbTYL7s67; Tue, 28 Feb 2012 12:14: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 C0F2721E8018; Tue, 28 Feb 2012 12:14: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 q1SKDoRv007727; Tue, 28 Feb 2012 21:13:50 +0100 (CET) Received: from [192.168.217.103] (p5489AA88.dip.t-dialin.net [84.137.170.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A78E4A04; Tue, 28 Feb 2012 21:13:49 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F4D2FCB.8030805@gmx.de> Date: Tue, 28 Feb 2012 21:13:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1154EF26-CC2F-49DC-87F0-04AD88F1C7FD@tzi.org> References: <4F4D2FCB.8030805@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org, draft-ietf-core-link-format@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [core] [apps-discuss] APPSDIR review of draft-ietf-core-link-format-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 20:14:39 -0000 On Feb 28, 2012, at 20:49, Julian Reschke wrote: A really good, = comprehensive review. Let me grab my implementer hat and pick three of the items. > I would recommend to allow both token and quoted-string for all new = parameters. I whole-heartedly agree. I'd really like to lose the code commencing: MUSTBEQUOTED =3D map_to_true(%w{anchor title rt if}) (The same issue appears to be apply to =BBanchor=AB and =BBtitle=AB in = RFC 5988. And I probably even missed some others that another = implementer will take for granted, likely to cause some immediate = interop issues. Please raise that erratum now...) > [...] Which makes it impossible to use "uri" as link attribute. Maybe = this should be noted. Alternatively maybe use a format that doesn't = require overloading the name. We could use href as the ersatz attribute name, or something weird that = is not allowed by the =BBparmname=AB production. Please also see = draft-bormann-core-links-json-00.txt, where I had to solve the same = problem (and tried to solve it in a way that it causes the same damage = this use in link-format already causes). > I note that hardwiring URI query parameters into the protocol is *not* = Restful. Yes, we are painfully aware of that. A better way has not emerged yet. Again, thanks for a very good review. Let's now work on making the = points actionable. Gr=FC=DFe, Carsten From julian.reschke@gmx.de Tue Feb 28 12:52:01 2012 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 A5DFF21E8064 for ; Tue, 28 Feb 2012 12:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.31 X-Spam-Level: X-Spam-Status: No, score=-104.31 tagged_above=-999 required=5 tests=[AWL=-1.711, 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 EhyvSoloqGEb for ; Tue, 28 Feb 2012 12:51:55 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 734B921E8056 for ; Tue, 28 Feb 2012 12:51:55 -0800 (PST) Received: (qmail invoked by alias); 28 Feb 2012 20:51:54 -0000 Received: from p3EE2676A.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.103.106] by mail.gmx.net (mp019) with SMTP; 28 Feb 2012 21:51:54 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX185qERO0SA57ANewsQkd/zOqA7fLl4dOgHr1UEKgn bSd4e1G7oYpvN4 Message-ID: <4F4D3E66.7060402@gmx.de> Date: Tue, 28 Feb 2012 21:51:50 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Carsten Bormann References: <4F4D2FCB.8030805@gmx.de> <1154EF26-CC2F-49DC-87F0-04AD88F1C7FD@tzi.org> In-Reply-To: <1154EF26-CC2F-49DC-87F0-04AD88F1C7FD@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss , draft-ietf-core-link-format@tools.ietf.org, The IESG , core@ietf.org Subject: Re: [core] [apps-discuss] APPSDIR review of draft-ietf-core-link-format-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 20:52:01 -0000 On 2012-02-28 21:13, Carsten Bormann wrote: > On Feb 28, 2012, at 20:49, Julian Reschke wrote: A really good, comprehensive review. > > Let me grab my implementer hat and pick three of the items. > >> I would recommend to allow both token and quoted-string for all new parameters. > > I whole-heartedly agree. > I'd really like to lose the code commencing: > > MUSTBEQUOTED = map_to_true(%w{anchor title rt if}) > > (The same issue appears to be apply to »anchor« and »title« in RFC 5988. And I probably even missed some others that another implementer will take for granted, likely to cause some immediate interop issues. Please raise that erratum now...) Good to hear I'm not alone with that complaint :-) >> [...] Which makes it impossible to use "uri" as link attribute. Maybe this should be noted. Alternatively maybe use a format that doesn't require overloading the name. > > We could use href as the ersatz attribute name, or something weird that is not allowed by the »parmname« production. Please also see draft-bormann-core-links-json-00.txt, where I had to solve the same problem (and tried to solve it in a way that it causes the same damage this use in link-format already causes). Maybe the empty name? >> I note that hardwiring URI query parameters into the protocol is *not* Restful. > > Yes, we are painfully aware of that. A better way has not emerged yet. Ack. > Again, thanks for a very good review. Let's now work on making the points actionable. Genau. Schönen Abend noch, Julian From peter.van.der.stok@philips.com Wed Feb 29 02:57:44 2012 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 5A91621F86B3 for ; Wed, 29 Feb 2012 02:57:44 -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=[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 jv42L6vcOQ6F for ; Wed, 29 Feb 2012 02:57:43 -0800 (PST) Received: from TX2EHSOBE005.bigfish.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5C19D21F88F1 for ; Wed, 29 Feb 2012 02:57:43 -0800 (PST) Received: from mail137-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Feb 2012 10:57:42 +0000 Received: from mail137-tx2 (localhost [127.0.0.1]) by mail137-tx2-R.bigfish.com (Postfix) with ESMTP id B503A400213 for ; Wed, 29 Feb 2012 10:57:42 +0000 (UTC) X-SpamScore: -36 X-BigFish: VPS-36(zz217bL15d6O9251J936eKzz1202hzz1033IL8275dhz2dh2a8h668h839h93fh) 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 mail137-tx2 (localhost.localdomain [127.0.0.1]) by mail137-tx2 (MessageSwitch) id 1330513060330380_32284; Wed, 29 Feb 2012 10:57:40 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.250]) by mail137-tx2.bigfish.com (Postfix) with ESMTP id 4B38D22071E for ; Wed, 29 Feb 2012 10:57:40 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Feb 2012 10:57:39 +0000 Received: from 011-DB3MPN1-061.MGDPHG.emi.philips.com ([169.254.1.139]) by 011-DB3MMR1-011.MGDPHG.emi.philips.com ([10.128.28.50]) with mapi id 14.01.0355.003; Wed, 29 Feb 2012 10:57:37 +0000 From: "Stok, Peter van der" To: "core@ietf.org" Thread-Topic: New Version Notification for draft-vanderstok-core-dna-00.txt Thread-Index: AQHM9tAD/e1NkDN+jECVU8zSQr0G/5ZTspoA Date: Wed, 29 Feb 2012 10:57:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.41.100.77] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] FW: New Version Notification for draft-vanderstok-core-dna-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 10:57:44 -0000 RGVhciBDb1JFIHdnLA0KDQpXZSBoYXZlIHN1Ym1pdHRlZCB0aGUgZHJhZnQgb24gZGlzY292ZXJ5 IG5hbWluZyBhbmQgYWRkcmVzc2luZywgd2hpY2ggaXMgYSBtb3JlIGZvY3VzZWQgZm9sbG93LXVw IG9mIHRoZSBidWlsZGluZyBjb250cm9sIGRyYWZ0Lg0KV2UgbG9vayBmb3J3YXJkIHRvIGRpc2N1 c3MgdGhlIGRyYWZ0IG9uIHRoZSBtYWlsaW5nIGxpc3QgYW5kIGluIFBhcmlzLg0KDQpHcmVldGlu Z3MsDQoNCnBldGVyDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXZhbmRlcnN0b2st Y29yZS1kbmEtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGV0ZXIg dmFuIGRlciBTdG9rIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5h bWU6ICAgICAgICBkcmFmdC12YW5kZXJzdG9rLWNvcmUtZG5hDQpSZXZpc2lvbjogICAgICAgIDAw DQpUaXRsZTogICAgICAgICAgIENvUkUgRGlzY292ZXJ5LCBOYW1pbmcsIGFuZCBBZGRyZXNzaW5n DQpDcmVhdGlvbiBkYXRlOiAgIDIwMTItMDItMjkNCldHIElEOiAgICAgICAgICAgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDI0DQoNCkFic3RyYWN0Og0KICAgVGhpcyBp cyBhIHdvcmtpbmcgZG9jdW1lbnQgaW50ZW5kZWQgdG8gZm9jdXMgZGlzY3Vzc2lvbiBhbmQgcmVm aW5lDQogICBkcmFmdCBsYW5ndWFnZSBmb3IgdGhlIENvQVAgcHJvdG9jb2wgc3BlY2lmaWNhdGlv biAob3Igb3RoZXIgcHJvcG9zZWQNCiAgIHN0YW5kYXJkcykgaW4gdGhlIGFyZWFzIG9mIGRpc2Nv dmVyeSwgbmFtaW5nLCBhbmQgYWRkcmVzc2luZy4NCiAgIEVuZ2luZWVyaW5nIHRyYWRlb2ZmcyBi ZWNvbWUgbW9yZSBjaGFsbGVuZ2luZyBpbiBjb25zdHJhaW5lZA0KICAgZW52aXJvbm1lbnRzOyB0 aGVyZWZvcmUgZGlzY292ZXJ5LCBuYW1pbmcsIGFuZCBhZGRyZXNzaW5nIGFyZQ0KICAgY29uc2lk ZXJlZCB3aXRoaW4gdGhlIGNvbnRleHQgb2YgYWRqYWNlbnQgdG9waWNzIHRoYXQgbWF5IGltcGFj dCBvcg0KICAgYmUgaW1wYWN0ZWQgYnkgZGVzaWduIGNob2ljZXMgaW4gdGhlIHN1YmplY3QgYXJl YXMuICBTcGVjaWFsIGVtcGhhc2lzDQogICBpcyBwbGFjZWQgb24gZ3JvdXAgZGVmaW5pdGlvbiBh bmQgZGlzY292ZXJ5LiAgRXhhbXBsZXMgc2hvdyBob3cNCiAgIGdyb3VwcyBjYW4gYmUgcmVwcmVz ZW50ZWQgaW4gQ29BUCBSZXNvdXJjZSBEaXJlY3RvcmllcyBvciBETlMtU0QuDQoNCg0KaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdmFuZGVyc3Rvay1jb3JlLWRuYS8NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVj dGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkg Zm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlz c2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBw cm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBh bmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0K From tho@koanlogic.com Wed Feb 29 13:47:40 2012 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 9ABD321E8063 for ; Wed, 29 Feb 2012 13:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.717 X-Spam-Level: X-Spam-Status: No, score=0.717 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 4zTCzUP4siZR for ; Wed, 29 Feb 2012 13:47:40 -0800 (PST) Received: from relay2.serverpronto.com (srv1021-mia.serverpronto.com [38.117.1.241]) by ietfa.amsl.com (Postfix) with ESMTP id F3CCB21E8054 for ; Wed, 29 Feb 2012 13:47:39 -0800 (PST) Received: from gonzo.koanlogic.com (166-118-60-69.serverpronto.com [69.60.118.166] (may be forged)) by relay2.serverpronto.com (8.13.8/8.13.8) with ESMTP id q1TLdvMq017896 for ; Wed, 29 Feb 2012 16:39:57 -0500 Received: from host196-51-dynamic.47-79-r.retail.telecomitalia.it ([79.47.51.196]:60608 helo=t.homenet.telecomitalia.it) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1S2rMq-0001i4-8p for core@ietf.org; Wed, 29 Feb 2012 16:47:37 -0500 From: Thomas Fossati Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Feb 2012 22:46:58 +0100 Message-Id: <9032C193-A015-4F41-B441-4D1D47594FC9@koanlogic.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.51.196 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] sleepy to sleepy communication I-Ds X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 21:47:40 -0000 Hello all, today we have submitted a couple of I-Ds proposing three new CoAP = Options that try dealing with the requirement REQ3 of = draft-shelby-core-coap-req-04 The ability to deal with sleeping nodes. Devices may be powered off at any point in time but periodically "wake up" for brief periods of time. leveraging on different techniques, i.e. store-and-forward, explicit = origin delegation, REST interface to carbon-copy an observed resource. Their URIs and respective abstracts are given in the following for = convenience: (1) "Sleepy Option for CoAP" (see = http://tools.ietf.org/html/draft-giacomin-core-sleepy-option-00) This draft defines a new CoAP elective option, Sleepy, targeted = specifically at proxies and used to signal a proxy the will to initiate = an asynchronous request/response exchange. The Sleepy option is = partitioned in 2/3 subfields indicating: the remaining time before = sleep, the expected sleep interval, and (optionally) the on-duty = interval. (2) "Publish and Monitor Options for CoAP" (see = http://tools.ietf.org/html/draft-fossati-core-publish-monitor-options-00) This draft defines two additional Options for the Constrained = Application Protocol (CoAP) especially targeted at sleepy sensors: = Publish and Monitor. The Publish Option enables opportunistic updates of a given resource = state, by temporarily delegating the authority of the Publish'ed = resource to a Proxy node. The whole process is driven by the (sleepy) = origin -- which may actually never need to listen. The Monitor Option complements the typical Observe pattern, enabling the = tracking of a resource hosted by a node sleeping most of the time, by = taking care of establishing and maintaining an Observe relationship with = the (sleepy) origin on behalf of the (sleepy) client. We look forward for receiving comments and suggestions to the proposed = solutions.