From nobody Sun Mar 2 07:05:18 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509C01A07C3 for ; Sun, 2 Mar 2014 07:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILjUorbiamU4 for ; Sun, 2 Mar 2014 07:05:16 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A539B1A0786 for ; Sun, 2 Mar 2014 07:05:15 -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.5/8.14.5) with ESMTP id s22F5B39006203 for ; Sun, 2 Mar 2014 16:05:11 +0100 (CET) Received: from dhcp-9be3.meeting.ietf.org (dhcp-9be3.meeting.ietf.org [31.133.155.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DAC3AE94; Sun, 2 Mar 2014 16:05:10 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sun, 2 Mar 2014 15:05:09 +0000 Message-Id: To: "core@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/8M1fPtSgnZCzUzdzz8u59mTVZ70 Subject: [core] CoRE @ IETF89 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 15:05:17 -0000 I have uploaded the 1.0 agenda for the CoRE meetings at IETF89. http://www.ietf.org/proceedings/89/agenda/agenda-89-core=20 If you have requested a slot (or think you should have had), please = check. I=92ll need the slides for the Tuesday slot at Monday 12:00 UTC (and for = the Friday slot at Thursday 12:00 UTC). Gr=FC=DFe, Carsten From nobody Mon Mar 3 06:04:12 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CCA1A0002 for ; Mon, 3 Mar 2014 06:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EP8klJaDMH8 for ; Mon, 3 Mar 2014 06:04:08 -0800 (PST) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8AD1A0136 for ; Mon, 3 Mar 2014 06:04:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,577,1389724200"; d="scan'208";a="508318635" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 7725ADAC12 for ; Mon, 3 Mar 2014 19:33:56 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 4C285DAC02 for ; Mon, 3 Mar 2014 19:33:56 +0530 (IST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: Abhijan Bhattacharyya To: "core@ietf.org WG" Message-ID: Date: Mon, 3 Mar 2014 19:33:54 +0530 X-Mailer: Lotus Domino Web Server Release 9.0HF507 August 20, 2013 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 03/03/2014 19:33:54, Serialize complete at 03/03/2014 19:33:54, Itemize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 03/03/2014 19:33:54, Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 03/03/2014 19:33:56, Serialize complete at 03/03/2014 19:33:56, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 03/03/2014 19:33:56 Content-Type: multipart/alternative; boundary="=_alternative 004D431865257C90_=" Archived-At: http://mailarchive.ietf.org/arch/msg/core/lsqM8NdXipBNT8LjYN-xFSqg7SQ Subject: [core] Fw: New Version Notification for draft-bhattacharyya-core-coap-lite-auth-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 14:04:11 -0000 --=_alternative 004D431865257C90_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All, We have uploaded a proposal on a lightweight application-layer mutual authe= ntication scheme for CoAP. Since this was specific to CoAP we have uploaded= in CoRE. Not sure if ACE would have been a suitable place. But, ACE is yet= come up with a concrete problem definition. So, keeping it in CoRE so that= at least the proposal could be publicly accessed if considered as a potent= ial solution to some requirements. The draft is part of a larger work in progress with some promising results.= =A0 Comments, suggestions are welcome. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----Forwarded by Abhijan Bhattacharyya/KOL/TCS on 03/03/2014 07:23PM ----- To: Soma Bandyopadhyay , "Soma Bandyopadhyay" <= soma.bandyopadhyay@tcs.com>, "Abhijan Bhattacharyya" , "Arijit Ukil" , Arijit Ukil , Arpan Pal , "Arpan Pal" , "Tu= lika Bose" , Abhijan Bhattacharyya , Tulika Bose From: internet-drafts@ietf.org Date: 03/03/2014 07:07PM Subject: New Version Notification for draft-bhattacharyya-core-coap-lite-au= th-00.txt A new version of I-D, draft-bhattacharyya-core-coap-lite-auth-00.txt has been successfully submitted by Abhijan Bhattacharyya and posted to the IETF repository. Name: draft-bhattacharyya-core-coap-lite-auth Revision: 00 Title: Lightweight mutual authentication for CoAP (WIP) Document date: 2014-03-03 Group: Individual Submission Pages: 11 URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/internet-drafts/draft-bhatt= acharyya-core-coap-lite-auth-00.txt Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/doc/draft-bhattacharyy= a-core-coap-lite-auth/ Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-bhattacharyya-core-c= oap-lite-auth-00 Abstract: =A0=A0 This draft presents a work-in-progress on a challenge-response based =A0=A0 lightweight authentication scheme to mutually authenticate CoAP =A0=A0 client and server for establishing a secure unicast communication =A0=A0 channel. The draft discusses the generic idea behind the proposed =A0=A0 authentication scheme, as well as presents its CoAP specific =A0=A0 adoption. The proposed scheme has low communication overhead and can =A0=A0 be a robust alternative against the usual DTLS based connection =A0=A0 initiation scheme with PSK. =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 004D431865257C90_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All,
We have uploaded a proposal on a lightweigh= t application-layer mutual authentication scheme for CoAP. Since this was s= pecific to CoAP we have uploaded in CoRE. Not sure if ACE would have been a= suitable place. But, ACE is yet come up with a concrete problem definition= . So, keeping it in CoRE so that at least the proposal could be publicly ac= cessed if considered as a potential solution to some requirements.

The draft is part of a larger work in progress with some p= romising results.  

Comments, suggestions are= welcome.


Regards
Abhijan Bhattacharyya
Associate Consulta= nt
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Service= s Limited
Mailto: abhij= an.bhattacharyya@tcs.com
Website: htt= p://www.tcs.com
____________________________________________
Expe= rience certainty. IT Services
Business Solutions
Consulting
= ____________________________________________


-----Forwarded by Abhijan Bhattacharyya/KOL/TCS on 03/03/2014 07:23P= M -----
To: Soma Bandyopadhyay <soma.bandyopadhyay@tcs.com>, "S= oma Bandyopadhyay" <soma.bandyopadhyay@tcs.com>, "Abhijan Bhattachary= ya" <abhijan.bhattacharyya@tcs.com>, "Arijit Ukil" <arijit.ukil@tc= s.com>, Arijit Ukil <arijit.ukil@tcs.com>, Arpan Pal <arpan.pal= @tcs.com>, "Arpan Pal" <arpan.pal@tcs.com>, "Tulika Bose" <tuli= ka.bose@tcs.com>, Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.co= m>, Tulika Bose <tulika.bose@tcs.com>
From: internet-drafts@iet= f.org
Date: 03/03/2014 07:07PM
Subject: New Version Notification for = draft-bhattacharyya-core-coap-lite-auth-00.txt

A new version of I-D, draft-bhattac= haryya-core-coap-lite-auth-00.txt
has been successfully submitted by Abh= ijan Bhattacharyya and posted to the
IETF repository.

Name: draf= t-bhattacharyya-core-coap-lite-auth
Revision: 00
Title: Lightweight = mutual authentication for CoAP (WIP)
Document date: 2014-03-03
Group:= Individual Submission
Pages: 11
URL:         &= nbsp;  http://www.ietf.org/internet-drafts/draft-b= hattacharyya-core-coap-lite-auth-00.txt
Status:      =   https://datatracker.ietf.org/doc/draft-bhattacharyya-cor= e-coap-lite-auth/
Htmlized:       http://tools= .ietf.org/html/draft-bhattacharyya-core-coap-lite-auth-00


Ab= stract:
   This draft presents a work-in-progress on a challen= ge-response based
   lightweight authentication scheme to mutu= ally authenticate CoAP
   client and server for establishing a= secure unicast communication
   channel. The draft discusses = the generic idea behind the proposed
   authentication scheme,= as well as presents its CoAP specific
   adoption. The propos= ed scheme has low communication overhead and can
   be a robus= t alternative against the usual DTLS based connection
   initi= ation scheme with PSK.

           &nbs= p;                     &n= bsp;                     =                      = ;      


Please note that it may take a couple of = minutes from the time of submission
until the htmlized version and diff = are available at tools.ietf.org.

The IETF Secretariat

=

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

--=_alternative 004D431865257C90_=-- From nobody Mon Mar 3 12:25:21 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCEF1A03C2 for ; Mon, 3 Mar 2014 12:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NszEe94sUFnz for ; Mon, 3 Mar 2014 12:25: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 005BE1A03CC for ; Mon, 3 Mar 2014 12:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s23KP5vi019010 for ; Mon, 3 Mar 2014 21:25:05 +0100 (CET) Received: from dhcp-9be3.meeting.ietf.org (dhcp-9be3.meeting.ietf.org [31.133.155.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4524B639; Mon, 3 Mar 2014 21:25:05 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Mar 2014 20:25:03 +0000 Message-Id: <3C4674CE-AB94-4E26-8A7B-2B9154522B24@tzi.org> To: "core@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/6bZHRMoVqKfg3XIWWDoTROE1CcA Subject: [core] Slides for IETF89... X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 20:25:17 -0000 =85 have been uploaded at = http://www.ietf.org/proceedings/89/slides/slides-89-core-0.pdf Speakers: Please do the usual checks whether I bungled it. Gr=FC=DFe, Carsten From nobody Mon Mar 3 14:42:13 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3251A027F for ; Mon, 3 Mar 2014 14:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQpl_-ulaSjj for ; Mon, 3 Mar 2014 14:42:09 -0800 (PST) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 791341A00DD for ; Mon, 3 Mar 2014 14:42:09 -0800 (PST) X-ASG-Debug-ID: 1393886525-06daaa24ac1b8290001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id ZiVUkJqSrBGC5Qgp for ; Mon, 03 Mar 2014 17:42:05 -0500 (EST) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Mar 2014 17:42:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CF3731.E5E3223C" Date: Mon, 3 Mar 2014 17:42:46 -0500 X-ASG-Orig-Subj: RE: [core] Slides for IETF89... Message-ID: In-Reply-To: <3C4674CE-AB94-4E26-8A7B-2B9154522B24@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Slides for IETF89... Thread-Index: Ac83HvKqErSmJWgfQLy1tbCED7trIwAEvNPT References: <3C4674CE-AB94-4E26-8A7B-2B9154522B24@tzi.org> From: "Rahman, Akbar" To: "Carsten Bormann" , X-OriginalArrivalTime: 03 Mar 2014 22:42:47.0262 (UTC) FILETIME=[E63B87E0:01CF3731] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1393886525 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145710 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/core/e3qvuYksISIX-6g5vHx5WbMQnvw Subject: Re: [core] Slides for IETF89... X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 22:42:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CF3731.E5E3223C Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2Fyc3RlbiwNCg0KDQpUaGFua3MsIGl0IGxvb2tzIGdvb2QgdG8gbWUuDQoNCg0KQWtiYXIN Cg0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDYXJzdGVuIEJv cm1hbm4gW2NhYm9AdHppLm9yZ10NClNlbnQ6IE1vbmRheSwgTWFyY2ggMDMsIDIwMTQgMDM6Mjcg UE0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQpUbzogY29yZUBpZXRmLm9yZyBXRw0KU3ViamVjdDog W2NvcmVdIFNsaWRlcyBmb3IgSUVURjg5Li4uDQoNCg0KDQrigKYgaGF2ZSBiZWVuIHVwbG9hZGVk IGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODkvc2xpZGVzL3NsaWRlcy04OS1j b3JlLTAucGRmDQoNClNwZWFrZXJzOiBQbGVhc2UgZG8gdGhlIHVzdWFsIGNoZWNrcyB3aGV0aGVy IEkgYnVuZ2xlZCBpdC4NCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQoNCg== ------_=_NextPart_001_01CF3731.E5E3223C Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0bWw+ DQo8aGVhZD4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0iSFRNTCBUaWR5IGZvciBX aW5kb3dzICh2ZXJzIDI1IE1hcmNoIDIwMDkpLCBzZWUgd3d3LnczLm9yZyI+DQo8bWV0YSBodHRw LWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+ DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1TIEV4Y2hhbmdlIFNlcnZlciB2ZXJz aW9uIDYuNS43NjU0LjEyIj4NCjx0aXRsZT5bY29yZV0gU2xpZGVzIGZvciBJRVRGODkuLi48L3Rp dGxlPg0KPC9oZWFkPg0KPGJvZHk+DQpIaSBDYXJzdGVuLDxicj4NCjxicj4NCjxicj4NClRoYW5r cywgaXQgbG9va3MgZ29vZCB0byBtZS48YnI+DQo8YnI+DQo8YnI+DQpBa2Jhcjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KPGI+RnJvbTombmJzcDs8L2I+Q2Fyc3RlbiBCb3JtYW5uIFs8YSBocmVmPSJtYWlsdG86 Y2Fib0B0emkub3JnIj5jYWJvQHR6aS5vcmc8L2E+XTxicj4NCjxiPlNlbnQ6Jm5ic3A7PC9iPk1v bmRheSwgTWFyY2ggMDMsIDIwMTQgMDM6MjcgUE0gRWFzdGVybiBTdGFuZGFyZCBUaW1lPGJyPg0K PGI+VG86Jm5ic3A7PC9iPmNvcmVAaWV0Zi5vcmcgV0c8YnI+DQo8Yj5TdWJqZWN0OiZuYnNwOzwv Yj5bY29yZV0gU2xpZGVzIGZvciBJRVRGODkuLi48YnI+DQo8YnI+DQo8IS0tIENvbnZlcnRlZCBm cm9tIHRleHQvcGxhaW4gZm9ybWF0IC0tPg0KPHA+PGZvbnQgc2l6ZT0iMiI+4oCmIGhhdmUgYmVl biB1cGxvYWRlZCBhdCA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg5 L3NsaWRlcy9zbGlkZXMtODktY29yZS0wLnBkZiI+aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVk aW5ncy84OS9zbGlkZXMvc2xpZGVzLTg5LWNvcmUtMC5wZGY8L2E+PGJyPg0KPGJyPg0KU3BlYWtl cnM6IFBsZWFzZSBkbyB0aGUgdXN1YWwgY2hlY2tzIHdoZXRoZXIgSSBidW5nbGVkIGl0Ljxicj4N Cjxicj4NCkdyw7zDn2UsIENhcnN0ZW48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmNvcmUgbWFpbGluZyBsaXN0PGJyPg0KY29y ZUBpZXRmLm9yZzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY29yZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPC9h Pjxicj48L2ZvbnQ+PC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K ------_=_NextPart_001_01CF3731.E5E3223C-- From nobody Tue Mar 4 07:21:53 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8321A1A005E for ; Tue, 4 Mar 2014 07:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.447 X-Spam-Level: X-Spam-Status: No, score=-7.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBq2sju4N4sV for ; Tue, 4 Mar 2014 07:21:46 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id E23801A0085 for ; Tue, 4 Mar 2014 07:21:45 -0800 (PST) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 4 Mar 2014 16:21:37 +0100 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.03.0174.001; Tue, 4 Mar 2014 16:21:41 +0100 From: "Kovatsch Matthias" To: "core@ietf.org" Thread-Topic: Observe Cancellation Thread-Index: Ac83r+3jwpuMU0icTxO/RDVFtTNfYg== Date: Tue, 4 Mar 2014 15:21:41 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.155.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/core/SHdaXm3KjRjJJCu9qwRnsEf8xVk Cc: "Szymon.Sasin@arm.com" , "'Klaus Hartke \(hartke@tzi.org\)'" Subject: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:21:49 -0000 RGVhciBsaXN0DQoNCkkgd2FudCB0byBzdGFydCB0aGUgZGlzY3Vzc2lvbiBhYm91dCB3aGF0IHRv IGRvIGFib3V0IE9ic2VydmUgY2FuY2VsbGF0aW9uLiBUb2RheSdzIHNlc3Npb24gc2hvd2VkIHRo YXQgd2UgaGF2ZSB0d28gb3B0aW9ucyB0byBmaW5pc2ggLW9ic2VydmU6IChpKSBmaXggc29tZXRo aW5nIGJ5IHRoZSBlbmQgb2YgdGhlIHdlZWsgYW5kIChpaSkgZWplY3QgdGhlIGNhbmNlbGxhdGlv biBtZWNoYW5pc20gYW5kIGRlYWwgd2l0aCBpdCBpbiBhIHNlcGFyYXRlIGRyYWZ0Lg0KDQpUbyBo ZWxwIGZpbmRpbmcgY29uc2Vuc3VzIGJ5IHRoZSBlbmQgb2YgdGhpcyB3ZWVrLCBJIHN0YXJ0ZWQg YSBwcm8vY29uIGxpc3QgZm9yIHRoZSBwb3NzaWJsZSBzb2x1dGlvbnMgd2UgaGF2ZS4gUGxlYXNl IGNvbW1lbnQsIGFtZW5kLCBldGMuLCBlc3BlY2lhbGx5IHdoZW4geW91IGFyZSBhbiBpbXBsZW1l bnRlciENCg0KUlNUIHdpdGggTGFzdCBOb3RpZmljYXRpb24gTUlEDQo9PT09PT09PT09PT09PT09 PT09PT09PQ0KUFJPDQorIE5vIHJlLXVzZSBvZiBhY3RpdmUgVG9rZW4NCisgTm8gcmVwcmVzZW50 YXRpb24gb24gY2FuY2VsDQpDT04NCi0gTmVlZHMgc3BlY2lhbCBydWxlIHRvIGtlZXAgTUlEcyBi ZXlvbmQgbGlmZXRpbWUNCi0tIE5vdCBhdmFpbGFibGUgb3ZlciBhbHRlcm5hdGl2ZSB0cmFuc3Bv cnRzDQoNCkkgdGhpbmsgdGhpcyBkb2VzIG5vdCB3b3JrIGJlY2F1c2Ugb2YgdGhlIGFsdGVybmF0 aXZlIHRyYW5zcG9ydHMuDQoNClBVVC9QT1NUL0RFTEVURSB3aXRoIE9ic2VydmUgT3B0aW9uDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClBSTw0KKyBJdCBpcyBub3QgYSBHRVQNCkNP Tg0KLS0gT2JzZXJ2ZSBpcyBlbGVjdGl2ZSBhbmQgdW5zYWZlIG1ldGhvZHMgbWlnaHQgY29ycnVw dCB0aGUgcmVzb3VyY2Ugc3RhdGUNCg0KSSB0aGluayBpdCBpcyBhIHJlYWxseSBiYWQgaWRlYSB0 byBvdmVybG9hZCBhbiB1bnNhZmUgbWV0aG9kIGZvciB0aGlzLg0KDQpHRVQgd2l0aG91dCBPYnNl cnZlIE9wdGlvbg0KPT09PT09PT09PT09PT09PT09PT09PQ0KUFJPDQorIE1vZHVsYXIgZGVzaWdu IGJhc2VkIG9uIEdFVA0KKyBBbHJlYWR5IHRlc3RlZA0KQ09ODQotIFRyYW5zbWlzc2lvbiBvZiBy ZXByZXNlbnRhdGlvbiBkZXNwaXRlIGRpc2ludGVyZXN0IChpbmNsdWRpbmcgY2FjaGVzKQ0KLSBS ZS11c2Ugb2YgYWN0aXZlIFRva2VuDQotIE5lZWRzIHNwZWNpYWwgcnVsZSB0byBrZWVwIHJlcXVl c3QgdGhlIHNhbWUgKHNpbWlsYXIgdG8gcmUtcmVnaXN0cmF0aW9uKQ0KDQpUaGUgR0VUIHdpdGhv dXQgT2JzZXJ2ZSBvcHRpb24gYWxsb3dzIG1hbnkgZGlmZmVyZW50IGltcGxlbWVudGF0aW9uIHN0 cmF0ZWdpZXM6IGZpcnN0IGRpdmlkaW5nIGludG8gcmVxdWVzdHMgb3IgcmVzcG9uc2VzIChmb3Ig dGhlIGh5YnJpZCBDb0FQIGNsaWVudC1hbmQtc2VydmVyIGltcGxlbWVudGF0aW9ucyBmb3IgTFdN Mk0pLCBmaXJzdCBkZWxpdmVyaW5nIGEgcmVxdWVzdCB0byBpdHMgcmVzb3VyY2UgYmVmb3JlIGZ1 cnRoZXIgaW5zcGVjdGlvbiAoT2JzZXJ2ZSBzdXBwb3J0IGNvdWxkIGJlIGFkZGVkIHdpdGhpbiBh IHJlc291cmNlIGhhbmRsZXIgaW1wbGVtZW50YXRpb24pLCBoYXZpbmcgYSBjbGVhbiBwcm9jZXNz aW5nIHBpcGVsaW5lLCAuLi4uDQoNCjcueHggQ29udHJvbCBNZXNzYWdlcw0KPT09PT09PT09PT09 PT09PT0NClBSTw0KKyBObyByZS11c2Ugb2YgYWN0aXZlIFRva2VuIChhcyByZXF1ZXN0KQ0KKyBO byByZXByZXNlbnRhdGlvbiBvbiBjYW5jZWwNCkNPTg0KLSBTdGlsbCByZS11c2Ugb2YgYWN0aXZl IFRva2VuIGZvciByZS1yZWdpc3RyYXRpb24NCi0gQ29udHJvbCBtZXNzYWdlIGNsYXNzIGJyaW5n cyB0aGUgZGFuZ2VyIG9mIG11dGF0aW9uIGludG8gYSB2ZXJ5IHVuUkVTVGZ1bCBwcm90b2NvbA0K LSBOZXcgY2xhc3MgYXQgbGF0ZSBzdGF0ZSAod2h5IGlzIENvQVAgcGluZyBub3QgYSBjb250cm9s IG1lc3NhZ2U/KQ0KLSBDb25mbGljdCB3aXRoIERUTFMgbWVzc2FnZSBkZXRlY3Rpb24gKGlmIGtl cHQgYXQgZW5kIG9mIDcueHgpDQotIE1hbmFnZW1lbnQgb2YgcmVtb3RlIFRva2VucyAoZGlmZmVy ZW50IG5hbWVzcGFjZXMuLi4pIG9yIGhvb2tzIHRoYXQgc2hvcnRjdXQgdGhlIHByb3RvY29sIGNv bnRyb2wgZmxvdw0KDQpUaGUgY29udHJvbCBtZXNzYWdlIGNhbmNlbGxhdGlvbiBpcyBhbHNvIHVz ZWZ1bCBmb3Igc2VwYXJhdGUgcmVzcG9uc2VzIGFzIHdlbGwgYXMgdGhlIGxpdmVsaW5lc3MgY2hl Y2tzIG9mIHRoZSBmdWxsIGxpdmVsaW5lc3MgZHJhZnQuIEhvd2V2ZXIsIHRoaXMgZ29lcyBiZXlv bmQgT2JzZXJ2ZS4gT2JzZXJ2ZSB3aXRob3V0IGFjdGl2ZSBjYW5jZWxsYXRpb24gc3RpbGwgd29y a3MgYW5kIExXTTJNIGNvdWxkIGluY2x1ZGUgdGhlIGxpdmVsaW5lc3MgbW9kdWxlIHRvIGhhdmUg dGhlIHJlcXVpcmVkIGFjdGl2ZSBjYW5jZWxsYXRpb24uDQoNCg0KSG9waW5nIGZvciB5b3VyIGlu cHV0DQpNYXR0aGlhcw0KDQo= From nobody Tue Mar 4 08:42:58 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8438C1A01FD for ; Tue, 4 Mar 2014 08:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fiupMNj1I2N for ; Tue, 4 Mar 2014 08:42:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C06641A01EE for ; Tue, 4 Mar 2014 08:42:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBS91144; Tue, 04 Mar 2014 16:42:45 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Mar 2014 16:42:18 +0000 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Mar 2014 16:42:44 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Wed, 5 Mar 2014 00:42:39 +0800 From: Likepeng To: "Kovatsch Matthias" , "core@ietf.org" Thread-Topic: Observe Cancellation Thread-Index: Ac83r+3jwpuMU0icTxO/RDVFtTNfYgAGEmpA Date: Tue, 4 Mar 2014 16:42:38 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252AFED55@SZXEMA501-MBS.china.huawei.com> References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.85.158] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/AMJjkU87NrFu9SkbqUSiS5z_p20 Cc: "Szymon.Sasin@arm.com" , "'Klaus Hartke \(hartke@tzi.org\)'" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 16:42:55 -0000 PkdFVCB3aXRob3V0IE9ic2VydmUgT3B0aW9uDQoNCkkgcHJlZmVyIHRoaXMgb3B0aW9uLiBXZSBp bXBsZW1lbnRlZCB0aGlzIG1lY2hhbmlzbSwgYW5kIGl0IHdvcmtzIGZpbmUuDQoNCj5Ub2RheSdz IHNlc3Npb24gc2hvd2VkIHRoYXQgd2UgaGF2ZSB0d28gb3B0aW9ucyB0byBmaW5pc2ggLW9ic2Vy dmU6IChpKSBmaXggc29tZXRoaW5nIGJ5IHRoZSBlbmQgb2YgdGhlIHdlZWsgYW5kIChpaSkgZWpl Y3QgdGhlIGNhbmNlbGxhdGlvbiBtZWNoYW5pc20gYW5kIGRlYWwgd2l0aCBpdCBpbiBhIHNlcGFy YXRlIGRyYWZ0Lg0KDQpJIHByZWZlciB0byBmaXggaXQgYnkgdGhlIGVuZCBvZiB0aGlzIHdlZWsu IEl0IGlzIGEgc21hbGwgdXBkYXRlLCBhbmQgbm90IG5lY2Vzc2FyaWx5IHRvIGJlIGEgc2VwYXJh dGUgZHJhZnQuIEFsc28gaXQgaXMgYmV0dGVyIHRvIGhhdmUgdGhlIG1lY2hhbmlzbSB0b2dldGhl ciB3aXRoIHRoZSBvYnNlcnZlIGRyYWZ0LCB0byBoYXZlIHRoZSB3aG9sZSBzb2x1dGlvbi4NCg0K S2luZCBSZWdhcmRzDQpLZXBlbmcNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IGNvcmUg W21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gS292YXRzY2ggTWF0dGhpYXMNCrei y83KsbzkOiAyMDE0xOoz1MI0yNUgMTU6MjINCsrVvP7IyzogY29yZUBpZXRmLm9yZw0Ks63LzTog U3p5bW9uLlNhc2luQGFybS5jb207ICdLbGF1cyBIYXJ0a2UgKGhhcnRrZUB0emkub3JnKScNCtb3 zOI6IFtjb3JlXSBPYnNlcnZlIENhbmNlbGxhdGlvbg0KDQpEZWFyIGxpc3QNCg0KSSB3YW50IHRv IHN0YXJ0IHRoZSBkaXNjdXNzaW9uIGFib3V0IHdoYXQgdG8gZG8gYWJvdXQgT2JzZXJ2ZSBjYW5j ZWxsYXRpb24uIFRvZGF5J3Mgc2Vzc2lvbiBzaG93ZWQgdGhhdCB3ZSBoYXZlIHR3byBvcHRpb25z IHRvIGZpbmlzaCAtb2JzZXJ2ZTogKGkpIGZpeCBzb21ldGhpbmcgYnkgdGhlIGVuZCBvZiB0aGUg d2VlayBhbmQgKGlpKSBlamVjdCB0aGUgY2FuY2VsbGF0aW9uIG1lY2hhbmlzbSBhbmQgZGVhbCB3 aXRoIGl0IGluIGEgc2VwYXJhdGUgZHJhZnQuDQoNClRvIGhlbHAgZmluZGluZyBjb25zZW5zdXMg YnkgdGhlIGVuZCBvZiB0aGlzIHdlZWssIEkgc3RhcnRlZCBhIHByby9jb24gbGlzdCBmb3IgdGhl IHBvc3NpYmxlIHNvbHV0aW9ucyB3ZSBoYXZlLiBQbGVhc2UgY29tbWVudCwgYW1lbmQsIGV0Yy4s IGVzcGVjaWFsbHkgd2hlbiB5b3UgYXJlIGFuIGltcGxlbWVudGVyIQ0KDQpSU1Qgd2l0aCBMYXN0 IE5vdGlmaWNhdGlvbiBNSUQNCj09PT09PT09PT09PT09PT09PT09PT09DQpQUk8NCisgTm8gcmUt dXNlIG9mIGFjdGl2ZSBUb2tlbg0KKyBObyByZXByZXNlbnRhdGlvbiBvbiBjYW5jZWwNCkNPTg0K LSBOZWVkcyBzcGVjaWFsIHJ1bGUgdG8ga2VlcCBNSURzIGJleW9uZCBsaWZldGltZQ0KLS0gTm90 IGF2YWlsYWJsZSBvdmVyIGFsdGVybmF0aXZlIHRyYW5zcG9ydHMNCg0KSSB0aGluayB0aGlzIGRv ZXMgbm90IHdvcmsgYmVjYXVzZSBvZiB0aGUgYWx0ZXJuYXRpdmUgdHJhbnNwb3J0cy4NCg0KUFVU L1BPU1QvREVMRVRFIHdpdGggT2JzZXJ2ZSBPcHRpb24NCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KUFJPDQorIEl0IGlzIG5vdCBhIEdFVA0KQ09ODQotLSBPYnNlcnZlIGlzIGVsZWN0 aXZlIGFuZCB1bnNhZmUgbWV0aG9kcyBtaWdodCBjb3JydXB0IHRoZSByZXNvdXJjZSBzdGF0ZQ0K DQpJIHRoaW5rIGl0IGlzIGEgcmVhbGx5IGJhZCBpZGVhIHRvIG92ZXJsb2FkIGFuIHVuc2FmZSBt ZXRob2QgZm9yIHRoaXMuDQoNCkdFVCB3aXRob3V0IE9ic2VydmUgT3B0aW9uDQo9PT09PT09PT09 PT09PT09PT09PT09DQpQUk8NCisgTW9kdWxhciBkZXNpZ24gYmFzZWQgb24gR0VUDQorIEFscmVh ZHkgdGVzdGVkDQpDT04NCi0gVHJhbnNtaXNzaW9uIG9mIHJlcHJlc2VudGF0aW9uIGRlc3BpdGUg ZGlzaW50ZXJlc3QgKGluY2x1ZGluZyBjYWNoZXMpDQotIFJlLXVzZSBvZiBhY3RpdmUgVG9rZW4N Ci0gTmVlZHMgc3BlY2lhbCBydWxlIHRvIGtlZXAgcmVxdWVzdCB0aGUgc2FtZSAoc2ltaWxhciB0 byByZS1yZWdpc3RyYXRpb24pDQoNClRoZSBHRVQgd2l0aG91dCBPYnNlcnZlIG9wdGlvbiBhbGxv d3MgbWFueSBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb24gc3RyYXRlZ2llczogZmlyc3QgZGl2aWRp bmcgaW50byByZXF1ZXN0cyBvciByZXNwb25zZXMgKGZvciB0aGUgaHlicmlkIENvQVAgY2xpZW50 LWFuZC1zZXJ2ZXIgaW1wbGVtZW50YXRpb25zIGZvciBMV00yTSksIGZpcnN0IGRlbGl2ZXJpbmcg YSByZXF1ZXN0IHRvIGl0cyByZXNvdXJjZSBiZWZvcmUgZnVydGhlciBpbnNwZWN0aW9uIChPYnNl cnZlIHN1cHBvcnQgY291bGQgYmUgYWRkZWQgd2l0aGluIGEgcmVzb3VyY2UgaGFuZGxlciBpbXBs ZW1lbnRhdGlvbiksIGhhdmluZyBhIGNsZWFuIHByb2Nlc3NpbmcgcGlwZWxpbmUsIC4uLi4NCg0K Ny54eCBDb250cm9sIE1lc3NhZ2VzDQo9PT09PT09PT09PT09PT09PQ0KUFJPDQorIE5vIHJlLXVz ZSBvZiBhY3RpdmUgVG9rZW4gKGFzIHJlcXVlc3QpIE5vIHJlcHJlc2VudGF0aW9uIG9uIGNhbmNl bA0KQ09ODQotIFN0aWxsIHJlLXVzZSBvZiBhY3RpdmUgVG9rZW4gZm9yIHJlLXJlZ2lzdHJhdGlv bg0KLSBDb250cm9sIG1lc3NhZ2UgY2xhc3MgYnJpbmdzIHRoZSBkYW5nZXIgb2YgbXV0YXRpb24g aW50byBhIHZlcnkgdW5SRVNUZnVsIHByb3RvY29sDQotIE5ldyBjbGFzcyBhdCBsYXRlIHN0YXRl ICh3aHkgaXMgQ29BUCBwaW5nIG5vdCBhIGNvbnRyb2wgbWVzc2FnZT8pDQotIENvbmZsaWN0IHdp dGggRFRMUyBtZXNzYWdlIGRldGVjdGlvbiAoaWYga2VwdCBhdCBlbmQgb2YgNy54eCkNCi0gTWFu YWdlbWVudCBvZiByZW1vdGUgVG9rZW5zIChkaWZmZXJlbnQgbmFtZXNwYWNlcy4uLikgb3IgaG9v a3MgdGhhdCBzaG9ydGN1dCB0aGUgcHJvdG9jb2wgY29udHJvbCBmbG93DQoNClRoZSBjb250cm9s IG1lc3NhZ2UgY2FuY2VsbGF0aW9uIGlzIGFsc28gdXNlZnVsIGZvciBzZXBhcmF0ZSByZXNwb25z ZXMgYXMgd2VsbCBhcyB0aGUgbGl2ZWxpbmVzcyBjaGVja3Mgb2YgdGhlIGZ1bGwgbGl2ZWxpbmVz cyBkcmFmdC4gSG93ZXZlciwgdGhpcyBnb2VzIGJleW9uZCBPYnNlcnZlLiBPYnNlcnZlIHdpdGhv dXQgYWN0aXZlIGNhbmNlbGxhdGlvbiBzdGlsbCB3b3JrcyBhbmQgTFdNMk0gY291bGQgaW5jbHVk ZSB0aGUgbGl2ZWxpbmVzcyBtb2R1bGUgdG8gaGF2ZSB0aGUgcmVxdWlyZWQgYWN0aXZlIGNhbmNl bGxhdGlvbi4NCg0KDQpIb3BpbmcgZm9yIHlvdXIgaW5wdXQNCk1hdHRoaWFzDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlz dA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j b3JlDQo= From nobody Tue Mar 4 09:54:37 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CE41A0286 for ; Tue, 4 Mar 2014 09:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQpi6wKfjoso for ; Tue, 4 Mar 2014 09:54:30 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id AEBD01A029A for ; Tue, 4 Mar 2014 09:54:29 -0800 (PST) Received: from CAS21.d.ethz.ch (172.31.51.111) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 4 Mar 2014 18:54:23 +0100 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.03.0174.001; Tue, 4 Mar 2014 18:54:25 +0100 From: "Kovatsch Matthias" To: Szymon Sasin , "core@ietf.org" Thread-Topic: Observe Cancellation Thread-Index: Ac83r+3jwpuMU0icTxO/RDVFtTNfYgAIKm6EAACMAqg= Date: Tue, 4 Mar 2014 17:54:25 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch>, <1C23526A7C42DB45BBF55B662C7C530E25D8A7AACC@BUNGLE.Emea.Arm.com> In-Reply-To: <1C23526A7C42DB45BBF55B662C7C530E25D8A7AACC@BUNGLE.Emea.Arm.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/core/c6-ErMF_mTPQ8EbFq-q9fi-L1EQ Cc: "'Klaus Hartke \(hartke@tzi.org\)'" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:54:33 -0000 MIDs have a lifetime (basically for deduplication, 247s...). To avoid imple= mentations forgetting due to a clean-up, we would need to define a longer l= ifetime for notification MID. Anyhow, there are no RSTs when used over WebSockets, TCP, or SMS and we do = not want to close the whole connection only to cancel a specific Observe re= lationship. -------- Original message -------- From: Szymon Sasin Date:2014/03/04 17:42 (GMT+00:00) To: Kovatsch Matthias ,core@ietf.org Cc: "'Klaus Hartke (hartke@tzi.org)'" Subject: RE: Observe Cancellation > RST with Last Notification MID +1 What do you mean that it needs special rule to keep MIDs beyond lifetime? -- Szymon Sasin Staff SW Engineer IoT BU ARM Ltd. ________________________________________ From: Kovatsch Matthias [kovatsch@inf.ethz.ch] Sent: Tuesday, March 04, 2014 5:21 PM To: core@ietf.org Cc: 'Klaus Hartke (hartke@tzi.org)'; Szymon Sasin Subject: Observe Cancellation Dear list I want to start the discussion about what to do about Observe cancellation.= Today's session showed that we have two options to finish -observe: (i) fi= x something by the end of the week and (ii) eject the cancellation mechanis= m and deal with it in a separate draft. To help finding consensus by the end of this week, I started a pro/con list= for the possible solutions we have. Please comment, amend, etc., especiall= y when you are an implementer! RST with Last Notification MID =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PRO + No re-use of active Token + No representation on cancel CON - Needs special rule to keep MIDs beyond lifetime -- Not available over alternative transports I think this does not work because of the alternative transports. PUT/POST/DELETE with Observe Option =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D PRO + It is not a GET CON -- Observe is elective and unsafe methods might corrupt the resource state I think it is a really bad idea to overload an unsafe method for this. GET without Observe Option =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PRO + Modular design based on GET + Already tested CON - Transmission of representation despite disinterest (including caches) - Re-use of active Token - Needs special rule to keep request the same (similar to re-registration) The GET without Observe option allows many different implementation strateg= ies: first dividing into requests or responses (for the hybrid CoAP client-= and-server implementations for LWM2M), first delivering a request to its re= source before further inspection (Observe support could be added within a r= esource handler implementation), having a clean processing pipeline, .... 7.xx Control Messages =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PRO + No re-use of active Token (as request) + No representation on cancel CON - Still re-use of active Token for re-registration - Control message class brings the danger of mutation into a very unRESTful= protocol - New class at late state (why is CoAP ping not a control message?) - Conflict with DTLS message detection (if kept at end of 7.xx) - Management of remote Tokens (different namespaces...) or hooks that short= cut the protocol control flow The control message cancellation is also useful for separate responses as w= ell as the liveliness checks of the full liveliness draft. However, this go= es beyond Observe. Observe without active cancellation still works and LWM2= M could include the liveliness module to have the required active cancellat= ion. Hoping for your input Matthias -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 From nobody Tue Mar 4 12:13:38 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104C11A02EE for ; Tue, 4 Mar 2014 12:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-rodbOtUAS9 for ; Tue, 4 Mar 2014 12:13:32 -0800 (PST) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by ietfa.amsl.com (Postfix) with ESMTP id 63BBA1A01C1 for ; Tue, 4 Mar 2014 12:13:32 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id s24KDRcI007473 for ; Tue, 4 Mar 2014 21:13:27 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id B8FA12CBD0E for ; Tue, 4 Mar 2014 21:13:26 +0100 (CET) Received: from 81.168.48.219 by webmail.entel.upc.edu with HTTP; Tue, 4 Mar 2014 21:13:27 +0100 Message-ID: <4240841922dadcd63f77cb87b6182543.squirrel@webmail.entel.upc.edu> In-Reply-To: <3C4674CE-AB94-4E26-8A7B-2B9154522B24@tzi.org> References: <3C4674CE-AB94-4E26-8A7B-2B9154522B24@tzi.org> Date: Tue, 4 Mar 2014 21:13:27 +0100 From: carlesgo@entel.upc.edu To: "core@ietf.org WG" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: ACL matched, not delayed by milter-greylist-4.4.3 (dash.upc.es [147.83.2.50]); Tue, 04 Mar 2014 21:13:27 +0100 (CET) Archived-At: http://mailarchive.ietf.org/arch/msg/core/NjjUiRXkwR3nZ3HphSPeS5mhwgc Subject: [core] Congestion control: details on the simulation setup and scenarios X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 20:13:36 -0000 Dear list, In today's slot on CoAP congestion control, I was asked to provide more details about the simulation setup used and the scenarios considered. A detailed description of almost the same setup and scenarios can be found in prior published work: A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "Congestion Control in Reliable CoAP Communication", 16th ACM International Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWIM'13), Barcelona, Spain, Nov. 2013. (Note that this paper provides results on cocoa-00 and does not include the latest results, using cocoa-01 and cocoa+, that I mentioned today.) If anyone is interested but doesn't have access to ACM, please do not hesitate to contact me for a copy of the paper. Greetings, Carles From nobody Wed Mar 5 08:11:16 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888A11A0234 for ; Wed, 5 Mar 2014 08:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JrsgdF5tTRP for ; Wed, 5 Mar 2014 08:10:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFE81A00DA for ; Wed, 5 Mar 2014 08:10:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEG59937; Wed, 05 Mar 2014 16:10:54 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Mar 2014 16:10:06 +0000 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Mar 2014 16:10:37 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.94]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Thu, 6 Mar 2014 00:10:31 +0800 From: Bert Greevenbosch To: "Kovatsch Matthias" , "core@ietf.org" Thread-Topic: Observe Cancellation Thread-Index: Ac83r+3jwpuMU0icTxO/RDVFtTNfYgA3WpJW Date: Wed, 5 Mar 2014 16:10:30 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.70.177] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/kMZHhGKTm88rqEjYW6e9ALyzulM Cc: "Szymon.Sasin@arm.com" , "'Klaus Hartke \(hartke@tzi.org\)'" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 16:11:09 -0000 Hi Matthias, I prefer "GET without Observe Option" (using the same token). Works fine, and doesn't give issues to non-supporting devices. I don't really worry about the token-reuse issue, especially since the toke= n is related to that observe transaction anyway. Best regards, Bert ________________________________________ From: core [core-bounces@ietf.org] on behalf of Kovatsch Matthias [kovatsc= h@inf.ethz.ch] Sent: 04 March 2014 23:21 To: core@ietf.org Cc: Szymon.Sasin@arm.com; 'Klaus Hartke (hartke@tzi.org)' Subject: [core] Observe Cancellation Dear list I want to start the discussion about what to do about Observe cancellation.= Today's session showed that we have two options to finish -observe: (i) fi= x something by the end of the week and (ii) eject the cancellation mechanis= m and deal with it in a separate draft. To help finding consensus by the end of this week, I started a pro/con list= for the possible solutions we have. Please comment, amend, etc., especiall= y when you are an implementer! RST with Last Notification MID =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PRO + No re-use of active Token + No representation on cancel CON - Needs special rule to keep MIDs beyond lifetime -- Not available over alternative transports I think this does not work because of the alternative transports. PUT/POST/DELETE with Observe Option =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D PRO + It is not a GET CON -- Observe is elective and unsafe methods might corrupt the resource state I think it is a really bad idea to overload an unsafe method for this. GET without Observe Option =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PRO + Modular design based on GET + Already tested CON - Transmission of representation despite disinterest (including caches) - Re-use of active Token - Needs special rule to keep request the same (similar to re-registration) The GET without Observe option allows many different implementation strateg= ies: first dividing into requests or responses (for the hybrid CoAP client-= and-server implementations for LWM2M), first delivering a request to its re= source before further inspection (Observe support could be added within a r= esource handler implementation), having a clean processing pipeline, .... 7.xx Control Messages =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PRO + No re-use of active Token (as request) + No representation on cancel CON - Still re-use of active Token for re-registration - Control message class brings the danger of mutation into a very unRESTful= protocol - New class at late state (why is CoAP ping not a control message?) - Conflict with DTLS message detection (if kept at end of 7.xx) - Management of remote Tokens (different namespaces...) or hooks that short= cut the protocol control flow The control message cancellation is also useful for separate responses as w= ell as the liveliness checks of the full liveliness draft. However, this go= es beyond Observe. Observe without active cancellation still works and LWM2= M could include the liveliness module to have the required active cancellat= ion. Hoping for your input Matthias _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core= From nobody Thu Mar 6 00:22:15 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887AF1A015F for ; Thu, 6 Mar 2014 00:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08wva3UPfHko for ; Thu, 6 Mar 2014 00:22:11 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 99D151A0020 for ; Thu, 6 Mar 2014 00:22:11 -0800 (PST) Received: from mail157-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 6 Mar 2014 08:22:07 +0000 Received: from mail157-va3 (localhost [127.0.0.1]) by mail157-va3-R.bigfish.com (Postfix) with ESMTP id 25CAA40193; Thu, 6 Mar 2014 08:22:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:206.191.242.69; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:error; EFVD:FOP X-SpamScore: -27 X-BigFish: VPS-27(z569dhz15d6O542I9251Id799h217bIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275dh1de097h186068hz2dh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25f6h2605h1155h) Received: from mail157-va3 (localhost.localdomain [127.0.0.1]) by mail157-va3 (MessageSwitch) id 1394094125259892_27397; Thu, 6 Mar 2014 08:22:05 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.238]) by mail157-va3.bigfish.com (Postfix) with ESMTP id 1699448012B; Thu, 6 Mar 2014 08:22:05 +0000 (UTC) Received: from mail.philips.com (206.191.242.69) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 6 Mar 2014 08:22:01 +0000 Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.126]) by AMSPRD9003HT003.MGDPHG.emi.philips.com ([141.251.33.80]) with mapi id 14.16.0411.000; Thu, 6 Mar 2014 08:22:00 +0000 From: "Dijk, Esko" To: Bert Greevenbosch , "core@ietf.org" Thread-Topic: Observe Cancellation Thread-Index: Ac83r+3jwpuMU0icTxO/RDVFtTNfYgA3WpJWACFj1VA= Date: Thu, 6 Mar 2014 08:22:00 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.69.205.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/core/_eMhjUKWTv4oVpLnOzNj9JDwflw Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 08:22:14 -0000 Looking at the pros and cons of the solutions the "GET without Observe Opti= on" comes out best, avoiding "--" cons and having the least number of "-" = cons. Can people confirm that the list of pros and cons is complete? (i.e. no ite= ms have been overlooked) The issue "- Control message class brings the danger of mutation into a ver= y unRESTful protocol" would also hold for the "GET without Observe" option = or not? Since we're using GET then for its side-effect and not to get the r= esource content. And besides, isn't IETF/CoRE in control of the codes alloc= ation so the amount of unRESTful-ness is under our control. The issue "- Conflict with DTLS message detection (if kept at end of 7.xx)"= seems not a problem if something else than 7.31 is chosen, or not? (Why no= t 7.01?) The issue "- Management of remote Tokens (different namespaces...) or hooks= that shortcut the protocol control flow" I don't fully understand. (Was th= at previously discussed?) Esko -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Bert Greevenbosch Sent: Wednesday, March 05, 2014 17:11 To: Kovatsch Matthias; core@ietf.org Cc: Szymon.Sasin@arm.com; 'Klaus Hartke (hartke@tzi.org)' Subject: Re: [core] Observe Cancellation Hi Matthias, I prefer "GET without Observe Option" (using the same token). Works fine, and doesn't give issues to non-supporting devices. I don't really worry about the token-reuse issue, especially since the toke= n is related to that observe transaction anyway. Best regards, Bert ________________________________________ From: core [core-bounces@ietf.org] on behalf of Kovatsch Matthias [kovatsc= h@inf.ethz.ch] Sent: 04 March 2014 23:21 To: core@ietf.org Cc: Szymon.Sasin@arm.com; 'Klaus Hartke (hartke@tzi.org)' Subject: [core] Observe Cancellation Dear list I want to start the discussion about what to do about Observe cancellation.= Today's session showed that we have two options to finish -observe: (i) fi= x something by the end of the week and (ii) eject the cancellation mechanis= m and deal with it in a separate draft. To help finding consensus by the end of this week, I started a pro/con list= for the possible solutions we have. Please comment, amend, etc., especiall= y when you are an implementer! RST with Last Notification MID =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PRO + No re-use of active Token + No representation on cancel CON - Needs special rule to keep MIDs beyond lifetime -- Not available over alternative transports I think this does not work because of the alternative transports. PUT/POST/DELETE with Observe Option =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D PRO + It is not a GET CON -- Observe is elective and unsafe methods might corrupt the resource state I think it is a really bad idea to overload an unsafe method for this. GET without Observe Option =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PRO + Modular design based on GET + Already tested CON - Transmission of representation despite disinterest (including caches) - Re-use of active Token - Needs special rule to keep request the same (similar to re-registration) The GET without Observe option allows many different implementation strateg= ies: first dividing into requests or responses (for the hybrid CoAP client-= and-server implementations for LWM2M), first delivering a request to its re= source before further inspection (Observe support could be added within a r= esource handler implementation), having a clean processing pipeline, .... 7.xx Control Messages =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PRO + No re-use of active Token (as request) No representation on cancel CON - Still re-use of active Token for re-registration - Control message class brings the danger of mutation into a very unRESTful= protocol - New class at late state (why is CoAP ping not a control message?) - Conflict with DTLS message detection (if kept at end of 7.xx) - Management of remote Tokens (different namespaces...) or hooks that short= cut the protocol control flow The control message cancellation is also useful for separate responses as w= ell as the liveliness checks of the full liveliness draft. However, this go= es beyond Observe. Observe without active cancellation still works and LWM2= M could include the liveliness module to have the required active cancellat= ion. Hoping for your input Matthias _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From nobody Thu Mar 6 00:29:28 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B631A0020 for ; Thu, 6 Mar 2014 00:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjzV-jAzDCfw for ; Thu, 6 Mar 2014 00:29:24 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) by ietfa.amsl.com (Postfix) with ESMTP id 9364C1A0121 for ; Thu, 6 Mar 2014 00:29:24 -0800 (PST) Received: from mfilter2-d.gandi.net (mfilter2-d.gandi.net [217.70.178.140]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 00539A80D7; Thu, 6 Mar 2014 09:29:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter2-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter2-d.gandi.net (mfilter2-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id CVOkbDKmHCvx; Thu, 6 Mar 2014 09:29:18 +0100 (CET) X-Originating-IP: 81.133.95.167 Received: from alma.home (host81-133-95-167.in-addr.btopenworld.com [81.133.95.167]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 5A999A80B1; Thu, 6 Mar 2014 09:29:16 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> Date: Thu, 6 Mar 2014 08:29:16 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <86216A3E-8F93-4A23-959E-5EE4E6FEFD44@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/972NSuoioWn7pioE2AFpZ_I5apQ Cc: "core@ietf.org" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 08:29:26 -0000 On 06 Mar 2014, at 08:22, Dijk, Esko wrote: > Since we're using GET then for its side-effect and not to get the = resource content.=20 I may be misreading this: You mean we should define this in such a way that the GET isn=92t = actually executed if it on the token of an existing observation = relationship? That would be ugly indeed. Gr=FC=DFe, Carsten From nobody Thu Mar 6 01:03:30 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421E21A017D for ; Thu, 6 Mar 2014 01:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hbsxfMjn8di for ; Thu, 6 Mar 2014 01:03:28 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E35411A0170 for ; Thu, 6 Mar 2014 01:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2693IbD009877; Thu, 6 Mar 2014 10:03:18 +0100 (CET) Received: from aung.tzi.org (dhcp-9b50.meeting.ietf.org [31.133.155.80]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2F67D5BD; Thu, 6 Mar 2014 10:03:18 +0100 (CET) From: Olaf Bergmann To: Carsten Bormann In-Reply-To: <86216A3E-8F93-4A23-959E-5EE4E6FEFD44@tzi.org> (Carsten Bormann's message of "Thu, 6 Mar 2014 08:29:16 +0000") Date: Thu, 06 Mar 2014 09:02:46 +0000 References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> <86216A3E-8F93-4A23-959E-5EE4E6FEFD44@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) Message-ID: <87zjl3r962.fsf@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/core/Lprk58Qx6vZD2P-iX-BiKm3t7_g Cc: "core@ietf.org" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:03:29 -0000 Carsten Bormann writes: > On 06 Mar 2014, at 08:22, Dijk, Esko wrote: > >> Since we're using GET then for its side-effect and not to get the >> resource content. > > I may be misreading this: > You mean we should define this in such a way that the GET isn=A1=AFt > actually executed if it on the token of an existing observation > relationship? That would be ugly indeed. A client could use the No-Response option to overcome this. >From my point of view, the "GET without Observe" is the most ugly to implement. For RST and 7.xx, the message can be handled automatically at the message layer while a GET must be passed on to the application.=20 The drawbacks of 7.xx are there, no question, but from an implementation perspective, this seems to be the easiest to implement as it is treated similar to RST. Gruesse Olaf From nobody Thu Mar 6 01:03:34 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308D01A0189 for ; Thu, 6 Mar 2014 01:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1K8CAG3NBVdg for ; Thu, 6 Mar 2014 01:03:30 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id DD4EE1A0170 for ; Thu, 6 Mar 2014 01:03:28 -0800 (PST) Received: from mail3-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.22; Thu, 6 Mar 2014 09:03:24 +0000 Received: from mail3-ch1 (localhost [127.0.0.1]) by mail3-ch1-R.bigfish.com (Postfix) with ESMTP id EA6562004CA; Thu, 6 Mar 2014 09:03:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:206.191.242.69; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:error; EFVD:FOP X-SpamScore: -28 X-BigFish: VPS-28(zz98dI15d6Oc89bh542I9251I217bIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275bh8275dh1de097hz2dh109h2a8h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25f6h2605h1155h) Received: from mail3-ch1 (localhost.localdomain [127.0.0.1]) by mail3-ch1 (MessageSwitch) id 1394096602443807_32213; Thu, 6 Mar 2014 09:03:22 +0000 (UTC) Received: from CH1EHSMHS039.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236]) by mail3-ch1.bigfish.com (Postfix) with ESMTP id 5DBBD1E004C; Thu, 6 Mar 2014 09:03:22 +0000 (UTC) Received: from mail.philips.com (206.191.242.69) by CH1EHSMHS039.bigfish.com (10.43.69.248) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 6 Mar 2014 09:03:21 +0000 Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.126]) by AMSPRD9003HT001.MGDPHG.emi.philips.com ([141.251.33.78]) with mapi id 14.16.0411.000; Thu, 6 Mar 2014 09:03:19 +0000 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] Observe Cancellation Thread-Index: Ac83r+3jwpuMU0icTxO/RDVFtTNfYgA3WpJWACFj1VAAANBrAAAA37Mw Date: Thu, 6 Mar 2014 09:03:18 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180D65B164@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> <86216A3E-8F93-4A23-959E-5EE4E6FEFD44@tzi.org> In-Reply-To: <86216A3E-8F93-4A23-959E-5EE4E6FEFD44@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.106] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/core/ACZ-5fM4KJ41VjK4Kz-Op8eRIxE Cc: "core@ietf.org" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:03:32 -0000 No, I just meant that in the "GET without Observe" solution we are using th= e on its own very RESTful GET request only for its side-effect: which is ca= ncelling an existing Observe relationship i.e. to delete some binding. That= sounds to me un-RESTful as well. The optimal RESTful way would be like e= .g. used in Resource Directory; first POST somewhere to create a relationsh= ip, then the server returns a new resource Location-URI like /relation/1234= which the client may DELETE at a future point in time to stop the relation= ship. But perhaps that's too heavy-weight for the purpose, and leads to the= question of where to POST to etc. In summary, also here I see some "danger of mutation into a very unRESTful = protocol" Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Thursday, March 06, 2014 09:29 To: Dijk, Esko Cc: Bert Greevenbosch; core@ietf.org Subject: Re: [core] Observe Cancellation On 06 Mar 2014, at 08:22, Dijk, Esko wrote: > Since we're using GET then for its side-effect and not to get the resourc= e content. I may be misreading this: You mean we should define this in such a way that the GET isn't actually ex= ecuted if it on the token of an existing observation relationship? That wo= uld be ugly indeed. 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 nobody Thu Mar 6 01:35:01 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4581A01BE for ; Thu, 6 Mar 2014 01:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ui2qXccGTLk8 for ; Thu, 6 Mar 2014 01:34:58 -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 B58D91A019D for ; Thu, 6 Mar 2014 01:34:57 -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.5/8.14.5) with ESMTP id s269YmU7013395 for ; Thu, 6 Mar 2014 10:34:48 +0100 (CET) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4E738613 for ; Thu, 6 Mar 2014 10:34:48 +0100 (CET) Received: by mail-vc0-f178.google.com with SMTP id ik5so2275574vcb.23 for ; Thu, 06 Mar 2014 01:34:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ucyy/4nBm/qKt29ZnSTn5sEY8FgFZBTtRIHDFq1OYwg=; b=Kf/Nn9MvtR0nzzuTpZ7NhBT7cSjw2II+gg0Macz55Sx8dww1CStUrGWBUlZ0YidHAq XF6iKVw8QTk0gh8LywhMUYg+jwZPCUjAjExNutyNAHPMyLu/NoEBYoDRhPharjO6Crzv 8fPmRvwxuRHQAgST7+d+PxW3LoErLHCL+vIf1LM72PW+9I0EhGY90pbYPmbmgp5LxP6u 8qMTfVzcx6fcAYIqC4JnteSaL9mk6e2IWs0qGrJSU7E1Ac7BvoQ4bgGRx8qw3uiRzWxw ZzHrna6Q3sIiTJefzzczV1QJdxW9Ta611NWe5K5aMeDffcLZSDIHIaa60x457M9z5m/A oNWQ== MIME-Version: 1.0 X-Received: by 10.220.92.135 with SMTP id r7mr4168476vcm.11.1394098486927; Thu, 06 Mar 2014 01:34:46 -0800 (PST) Received: by 10.52.53.227 with HTTP; Thu, 6 Mar 2014 01:34:46 -0800 (PST) In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> Date: Thu, 6 Mar 2014 10:34:46 +0100 Message-ID: From: Klaus Hartke To: "Dijk, Esko" Content-Type: multipart/alternative; boundary=047d7b66f5fb18669804f3ecd9cc Archived-At: http://mailarchive.ietf.org/arch/msg/core/yUWi1lyFNPyqd1CtdEVBFITj-RA Cc: "core@ietf.org" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:35:00 -0000 --047d7b66f5fb18669804f3ecd9cc Content-Type: text/plain; charset=ISO-8859-1 Hi Esko! Esko Dijk wrote: > Looking at the pros and cons of the solutions the "GET without Observe > Option" comes out best, avoiding "--" cons and having the least number of > "-" cons. > Can people confirm that the list of pros and cons is complete? (i.e. no > items have been overlooked) Matthias and I discussed the list before he posted it, so it's these are the issues we could come up with. The intention of the mail is to fully understand each alternative by discussing the pros and cons and finding more pros and cons, not to start a vote on picking an alternative. The issue "- Control message class brings the danger of mutation into a > very unRESTful protocol" would also hold for the "GET without Observe" > option or not? Since we're using GET then for its side-effect and not to > get the resource content. And besides, isn't IETF/CoRE in control of the > codes allocation so the amount of unRESTful-ness is under our control. Since REST is about single request/single response interactions, having interactions where a single request leads to a stream of responses makes the protocol strictly speaking unRESTful. But since resource observation otherwise blends in with REST perfectly (transfer of resource state representations, support for intermediaries and caches, etc.), it can be thought of as some kind of Extended REST. The danger is, once we have lots of unassigned control codes available, that people could want to use them for things outside the Extended REST scope ("unExtendedRESTful"). In Extended REST, there are two situations where we want a new kind of interaction besides requests (which target resources) and responses (which target requests). These interactions are new because they target ongoing observations: when the client has not received a notification for a while and wants to check whether the server is still aware of the observation; and when the client is no longer interested in the observation and wants the server to cancel the observation. The question is how to express these new interactions in our messages. There generally two possible strategies: introduce new protocol elements for them, or overloading existing protocol elements with additional semantics. For the single request/multiple response interaction, we chose to overload the GET method, because it provides representation-retrieval semantics and nicely falls back to polling if the feature is not supported. For the liveliness check, we chose to overload the GET method as well, because we didn't want to introduce a new protocol element, and the client likely wants to re-register after the check anyway. Though this gave us a headache about token reuse and request matching with some unspecified behavior now in the protocol. For cancellation, the pattern breaks down now, because cancellation is the very case where the client does not want a current representation anymore and the GET method always gives the client a current representation. The issue "- Conflict with DTLS message detection (if kept at end of 7.xx)" > seems not a problem if something else than 7.31 is chosen, or not? (Why not > 7.01?) This is not really an issue if we reserve some codes for current an future versions of DTLS (assuming that future versions still have the major version in the second byte). DTLS 1.x is code 7.30, DTLS 2.x is code 7.29, etc. We could reserve codes 7.20 to 7.30 for DTLS, which leaves codes 7.00 to 7.19 as well as 7.31 to our disposal. I do not expect any other use case than the liveliness check and cancellation, so the allocation of the entire 7.xx range could be seen as waste or lead people to look for more control codes. The issue "- Management of remote Tokens (different namespaces...) or hooks > that shortcut the protocol control flow" I don't fully understand. (Was > that previously discussed?) > The issue here is mostly that there are so many implementations already, which all assume that there are no interactions besides requests and (multiple) responses (with some small hack to support re-registrations). Whichever solution for cancellation we pick, there will always be an implementation that will require a significant rewrite. In the case of the 7.31 control code, it's Matthias' implementation :-) Best regards, Klaus --047d7b66f5fb18669804f3ecd9cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Esko!

Esko Dijk=A0wrote:
Looking at the pros and cons of the solutions the "GET without O= bserve Option" comes out =A0best, avoiding "--" cons and hav= ing the least number of "-" cons.
Can people confirm that the list of pros and cons is complete? (i.e. no ite= ms have been overlooked)

Matthias and I discusse= d the list before he posted it, so it's these are the issues we could c= ome up with. The intention of the mail is to fully understand each alternat= ive by discussing the pros and cons and finding more pros and cons, not to = start a vote on picking an alternative.

The issue "- Control message class brings the danger of mutation into = a very unRESTful protocol" would also hold for the "GET without O= bserve" option or not? Since we're using GET then for its side-eff= ect and not to get the resource content. And besides, isn't IETF/CoRE i= n control of the codes allocation so the amount of unRESTful-ness is under = our control.

Since REST is about s= ingle request/single response interactions, having interactions where a sin= gle request leads to a stream of responses makes the protocol strictly spea= king unRESTful. But since resource observation otherwise blends in with RES= T perfectly (transfer of resource state representations, support for interm= ediaries and caches, etc.), it can be thought of as some kind of Extended R= EST. The danger is, once we h= ave lots of unassigned control codes available, that people could want to u= se them for things=A0outside the Extended REST scope ("unExtendedRESTf= ul").

In Extended REST,=A0there are two situations where we want a new kind of intera= ction besides requests (which target resources)=A0and responses (which target requests).=A0The= se interactions are new because they=A0target=A0ongo= ing observations:=A0when the client has not received a notification for a while=A0and want= s to check whether the server is still aware of the observation; and when t= he client is no longer interested in the observation and wants=A0the server= to cancel the observation.=A0

The=A0question is how to express these new=A0interactions in our=A0message= s. There generally two possible strategies: introduce new protocol elements= for them, or overloading existing protocol elements with additional semant= ics. For the single request/multiple response interaction, we chose to over= load the GET method, because it provides representation-retrieval semantics= and=A0nicely falls back to polling if the feature is not supported. For th= e liveliness check, we chose to overload the GET method as well, because we= didn't want to introduce a new protocol element, and the client likely= wants to re-register after the check anyway. Though this gave us a headach= e about token reuse and request matching with some unspecified behavior now= in the protocol. For cancellation, the=A0pattern breaks down now, because = cancellation is the very case where the client does not want a current repr= esentation anymore and the GET method always gives the client=A0a current r= epresentation.

The issue "- Conflict with DTLS message detection (if kept at end of 7= .xx)" seems not a problem if something else than 7.31 is chosen, or no= t? (Why not 7.01?)

This is not really an is= sue if we reserve some codes for current an future versions of DTLS (assumi= ng that future versions still have the major version in the second byte). D= TLS 1.x is code 7.30, DTLS 2.x is code 7.29, etc. We could reserve codes 7.= 20 to 7.30 for DTLS, which leaves codes 7.00 to 7.19 as well as 7.31 to our= disposal. I do not expect any other use case than the liveliness check and= cancellation, so the allocation of the entire 7.xx range could be seen as = waste or=A0lead people to look for more control codes.

The issue "- Management of remote Tokens (different namespaces...) or = hooks that shortcut the protocol control flow" I don't fully under= stand. (Was that previously discussed?)

The issue here is mostly that there are so= many implementations already, which all assume that there are no interacti= ons besides requests and (multiple) responses (with some small hack to supp= ort re-registrations). Whichever solution for cancellation we pick, there w= ill always be an implementation that will require a significant=A0rewrite. = In=A0the=A0case of the 7.31 control code, it's Matthias' implementa= tion :-)

Best regards,
Klaus
--047d7b66f5fb18669804f3ecd9cc-- From nobody Thu Mar 6 01:54:35 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CD41A019A for ; Thu, 6 Mar 2014 01:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTy6-loQBGF4 for ; Thu, 6 Mar 2014 01:54:31 -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 862021A019D for ; Thu, 6 Mar 2014 01:54: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.5/8.14.5) with ESMTP id s269sPIn021511; Thu, 6 Mar 2014 10:54:25 +0100 (CET) Received: from aung.tzi.org (dhcp-9b50.meeting.ietf.org [31.133.155.80]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4202B659; Thu, 6 Mar 2014 10:54:25 +0100 (CET) From: Olaf Bergmann To: Klaus Hartke References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> Date: Thu, 06 Mar 2014 09:54:24 +0000 In-Reply-To: (Klaus Hartke's message of "Thu, 6 Mar 2014 10:34:46 +0100") Message-ID: <87ob1jr6sv.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/core/tZsov_9leT99IoyyuRvhsdP_W6U Cc: "core@ietf.org" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:54:32 -0000 Klaus, you may just have convinced me that the cleanest solution would be to take a huge step back and make observe soft-state again (let the observer tell the resource server how long it wants the observation relationship to persist, and the resource server answer with some value that tells the planned expiry time of that relationship, which may or may not be smaller than the requested expiry time.) I am fully aware that this has a lot of practical issues, starting with the notion of real time missing on some platforms. The benefit is that this makes the protocol much cleaner as notifications now can tell the observer how long the resource server thinks the relationship to persist. The burden would be on the client to re-establish the observation relationship, let it expire or clear it by requesting an expiration time of zero. Gruesse Olaf From nobody Thu Mar 6 02:10:49 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53121A01AF for ; Thu, 6 Mar 2014 02:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giNcOdZ-aU54 for ; Thu, 6 Mar 2014 02:10: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 7559D1A019A for ; Thu, 6 Mar 2014 02:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s26AAcZc024761 for ; Thu, 6 Mar 2014 11:10:38 +0100 (CET) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1632169A for ; Thu, 6 Mar 2014 11:10:37 +0100 (CET) Received: by mail-vc0-f172.google.com with SMTP id lf12so2341475vcb.17 for ; Thu, 06 Mar 2014 02:10:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L1jA9nzo3i2G4kytAhRrY6+pxk3yBdTk+N+380p92I8=; b=II98vjhiabs5QVlsAS/1dmlfHEV0yTAFFEambShwWFGnIbsC7LNs45Nq31utfNZMTw kUK9m/iP2evrQH1eZiAOq3sVf9v59MsuWLQqzXEftjNsAe1O547ruvgDhvqFo+YJHKga SEyot4cqI/7nAPjbqyc1q9lbrTyrd64JgtZ/2u/Ct3tLNcORBuFLAcLp9gspbJrDB7yc PytytsXeuZxsPbPIqzDXC2CreKWYuh0Aw04jt1CIvdINtC+x7n8V3YnGEqZx+/S+5A1V d0UjHFxrr3sjrhBX1rQAv3YgL2QJaAXE/t8l8cISUbfX695sRkJHCV+215H5udoDC9Np HEWw== MIME-Version: 1.0 X-Received: by 10.220.147.16 with SMTP id j16mr340840vcv.28.1394100636763; Thu, 06 Mar 2014 02:10:36 -0800 (PST) Received: by 10.52.53.227 with HTTP; Thu, 6 Mar 2014 02:10:36 -0800 (PST) In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> Date: Thu, 6 Mar 2014 11:10:36 +0100 Message-ID: From: Klaus Hartke To: Bert Greevenbosch Content-Type: multipart/alternative; boundary=047d7b3436d23c4e9404f3ed599d Archived-At: http://mailarchive.ietf.org/arch/msg/core/jHRTruTY3ZviCezu6970BshEJsw Cc: "Szymon.Sasin@arm.com" , "Klaus Hartke \(hartke@tzi.org\)" , "core@ietf.org" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 10:10:47 -0000 --047d7b3436d23c4e9404f3ed599d Content-Type: text/plain; charset=ISO-8859-1 Hi Bert! Bert Greevenbosch wrote: > I prefer "GET without Observe Option" (using the same token). > > Works fine, and doesn't give issues to non-supporting devices. > > I don't really worry about the token-reuse issue, especially since the > token is related to that observe transaction anyway. > The issue here is more that cancellation by itself is a very simple thing really: one hop tells the next hop to stop, done. However, the usage of the GET method naturally drags in the whole semantics of resource representation retrieval: in addition to simply updating some internal data structure, the next hop now must acquire a current representation of the target resource to return. This may involve just checking the local cache, but may also involve requesting the representation from the next hop, which may have to acquire it from the next hop, and so on. This may involve waiting for sleepy devices to wake up, powering up radios, establishing secure connections -- all of which are expensive operations. It seems that cancellation is a fairly frequent interaction in some scenarios, i.e., there are scenarios where observations are short-lived and predominantly ended by proactive cancellation. I don't know if the cost of a full GET request every time is acceptable here. Best regards, Klaus --047d7b3436d23c4e9404f3ed599d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Bert!

Bert Greevenbosch wrote:
I prefer "GET without Observe Option" (using the sa= me token).

Works fine, and doesn't give issues to non-supporting devices.

I don't really worry about the token-reuse issue, especially since the = token is related to that observe transaction anyway.

The issue here is more that cancellation b= y itself is a very simple thing really:=A0one hop tells the next hop to sto= p, done.=A0However, the usage of the= GET method naturally drags in the whole semantics of resource representati= on retrieval: in addition to simply updating some internal data structure, = the next hop now must acquire a current representation of the target resour= ce=A0to return. This may involve just checking the local cache, but may als= o involve requesting the representation from the next hop, which may have t= o acquire it from the next hop,=A0and so on. This may involve waiting for= =A0sleepy devices to wake up, powering up=A0radios, establishing secure con= nections -- all of which are=A0expensive operations.

It seems that cancellation is a fairly frequent interac= tion in some scenarios, i.e., there are scenarios where observations are sh= ort-lived and predominantly ended by proactive cancellation. I don't kn= ow=A0if the cost of a full=A0GET request every time=A0is acceptable here.

Best regards,
Klaus
--047d7b3436d23c4e9404f3ed599d-- From nobody Thu Mar 6 04:47:59 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD171A025E for ; Thu, 6 Mar 2014 04:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqAiRm7ocDAJ for ; Thu, 6 Mar 2014 04:47:55 -0800 (PST) Received: from p3plsmtpa07-06.prod.phx3.secureserver.net (p3plsmtpa07-06.prod.phx3.secureserver.net [173.201.192.235]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1E21A0282 for ; Thu, 6 Mar 2014 04:47:55 -0800 (PST) Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa07-06.prod.phx3.secureserver.net with id aCnp1n00C1mTNtu01Cnq0F; Thu, 06 Mar 2014 05:47:50 -0700 Message-ID: <53186E78.90102@pabigot.com> Date: Thu, 06 Mar 2014 06:47:52 -0600 From: "Peter A. Bigot" Organization: Peter Bigot Consulting, LLC User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: core@ietf.org References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> <86216A3E-8F93-4A23-959E-5EE4E6FEFD44@tzi.org> <031DD135F9160444ABBE3B0C36CED6180D65B164@AMSPRD9003MB066.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180D65B164@AMSPRD9003MB066.MGDPHG.emi.philips.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/core/q8INuV_611JYQNpQ0-NuI-XIGO0 Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 12:47:58 -0000 +1. (+100 if it were possible; what Esko proposes is exactly what I had in mind over three years ago.) I have never been comfortable with -observe, and never felt the WG was particularly interested in a RESTful approach to the underlying problem. My last attempt at working towards such a solution produced http://www.ietf.org/mail-archive/web/core/current/msg00970.html which pretty much told me I was wasting my time. Last fall I tried to implement CoAP from the specification; http://pabigot.github.io/coapy/ has the result to the point where I gave up. You can see where it started to go off the rails in the architectural analysis at http://pabigot.github.io/coapy/domain.html#operations, where I tried to formalize the notion of cancellation at the message level. Without a robust solution to that, cancellation at the transaction level becomes even more messy. Regardless of past history, transaction termination and cancellation are foundational concepts, and a solution that only works for -observe is, in my opinion, a mistake. Also regardless of where things are today, it is long past time to ship CoAP and its companion capabilities (-observe, -block, etc) so people who have not been intimately involved in its evolution can determine whether it meets their needs and work on CoAPbis can start, informed by real-world experience. Peter On 03/06/2014 03:03 AM, Dijk, Esko wrote: > No, I just meant that in the "GET without Observe" solution we are using the on its own very RESTful GET request only for its side-effect: which is cancelling an existing Observe relationship i.e. to delete some binding. That sounds to me un-RESTful as well. The optimal RESTful way would be like e.g. used in Resource Directory; first POST somewhere to create a relationship, then the server returns a new resource Location-URI like /relation/1234 which the client may DELETE at a future point in time to stop the relationship. But perhaps that's too heavy-weight for the purpose, and leads to the question of where to POST to etc. > > In summary, also here I see some "danger of mutation into a very unRESTful protocol" > > Esko > > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Thursday, March 06, 2014 09:29 > To: Dijk, Esko > Cc: Bert Greevenbosch; core@ietf.org > Subject: Re: [core] Observe Cancellation > > On 06 Mar 2014, at 08:22, Dijk, Esko wrote: > >> Since we're using GET then for its side-effect and not to get the resource content. > I may be misreading this: > You mean we should define this in such a way that the GET isn't actually executed if it on the token of an existing observation relationship? That would be ugly indeed. > > Grüße, Carsten > > > ________________________________ > The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Mar 6 05:49:24 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD131A019C for ; Thu, 6 Mar 2014 05:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.951 X-Spam-Level: X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-DdG-pqRRpI for ; Thu, 6 Mar 2014 05:49:18 -0800 (PST) Received: from smtpgw.sap-ag.de (smtpgw02.sap-ag.de [155.56.66.97]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF7A1A01FE for ; Thu, 6 Mar 2014 05:49:18 -0800 (PST) From: "Thoma, Matthias" To: "core@ietf.org" Thread-Topic: [core] Observe Cancellation Thread-Index: Ac83r+3jwpuMU0icTxO/RDVFtTNfYgA3WpJWACFj1VD///W/AIAACYMAgAA+vgD//+aIEA== Date: Thu, 6 Mar 2014 13:49:05 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> <86216A3E-8F93-4A23-959E-5EE4E6FEFD44@tzi.org> <031DD135F9160444ABBE3B0C36CED6180D65B164@AMSPRD9003MB066.MGDPHG.emi.philips.com> <53186E78.90102@pabigot.com> In-Reply-To: <53186E78.90102@pabigot.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.40.90] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/core/YwaSNhEitwveuHCAHqCZm2D_R9Y Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 13:49:22 -0000 Hi, to add one more implementator point of view:=20 What we are currently using is also the "get without observe" option, but w= ith an additional optional no-response option (like it has been proposed he= re) to save some energy (otherwise the sensor would have to gather informat= ion which might just been thrown away at the receiver side). The RST also h= ad something appealing, but as it supported by alternative transport (*) I= can understand why people think it is a no-go. Generally, I agree with Pe= ter and Esko that the current way CoAP-observe is working is not very RESTf= ul, but on the other hand, a more RESTful solution might already be too res= ource intensive for very constrained devices.=20 Furthermore, why not giving people a choice? I also see some valid points f= or the RST+MID in CoAP over UDP, when you are in a very constrained device = as the parsing complexity is way smaller and you can cancel an observer by = examining the 4-byte header only. The problem with clean but resource hungr= y or too complex solutions (which might work with every transport-layer pro= tocol) is that people might start just ignoring it, looking for less energy= /computation/memory whatever-consuming ways of doing things. I wouldn't pr= ematurely give up on nice elegant resource-saving solutions, even if they= are transport layer specific. Additionally, to a one works-for-all soluti= on, of course. (*) Looking into the websockets alternative transport, I got the feeling th= at the unlayered "mixing" of concepts (transport layer, application layer) = in CoAP is, while maybe justified from a constraintness point of view, is = very unfortunate from a general engineering point of view. After all, even= the header of the protocol changed so it is not as easy as it could be to = move from one transport layer (CoAP over UDP) to another (CoAP over websock= ets) as it could be.=20 Best, Matthias --=20 SAP (Switzerland) Inc.=20 BIT PA&TS=20 T +41 58 871 7843 | mailto: matthias.thoma@sap.com http://www.sap.com Please consider to send me encrypted mail: http://keys.sap.com -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Peter A. Bigot Sent: Donnerstag, 6. M=E4rz 2014 13:48 To: core@ietf.org Subject: Re: [core] Observe Cancellation +1. (+100 if it were possible; what Esko proposes is exactly what I had=20 in mind over three years ago.) I have never been comfortable with -observe, and never felt the WG was=20 particularly interested in a RESTful approach to the underlying=20 problem. My last attempt at working towards such a solution produced=20 http://www.ietf.org/mail-archive/web/core/current/msg00970.html which=20 pretty much told me I was wasting my time. Last fall I tried to implement CoAP from the specification;=20 http://pabigot.github.io/coapy/ has the result to the point where I gave=20 up. You can see where it started to go off the rails in the=20 architectural analysis at=20 http://pabigot.github.io/coapy/domain.html#operations, where I tried to=20 formalize the notion of cancellation at the message level. Without a=20 robust solution to that, cancellation at the transaction level becomes=20 even more messy. Regardless of past history, transaction termination and cancellation are=20 foundational concepts, and a solution that only works for -observe is,=20 in my opinion, a mistake. Also regardless of where things are today, it is long past time to ship=20 CoAP and its companion capabilities (-observe, -block, etc) so people=20 who have not been intimately involved in its evolution can determine=20 whether it meets their needs and work on CoAPbis can start, informed by=20 real-world experience. Peter On 03/06/2014 03:03 AM, Dijk, Esko wrote: > No, I just meant that in the "GET without Observe" solution we are using = the on its own very RESTful GET request only for its side-effect: which is = cancelling an existing Observe relationship i.e. to delete some binding. Th= at sounds to me un-RESTful as well. The optimal RESTful way would be like= e.g. used in Resource Directory; first POST somewhere to create a relation= ship, then the server returns a new resource Location-URI like /relation/12= 34 which the client may DELETE at a future point in time to stop the relati= onship. But perhaps that's too heavy-weight for the purpose, and leads to t= he question of where to POST to etc. > > In summary, also here I see some "danger of mutation into a very unRESTfu= l protocol" > > Esko > > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Thursday, March 06, 2014 09:29 > To: Dijk, Esko > Cc: Bert Greevenbosch; core@ietf.org > Subject: Re: [core] Observe Cancellation > > On 06 Mar 2014, at 08:22, Dijk, Esko wrote: > >> Since we're using GET then for its side-effect and not to get the resour= ce content. > I may be misreading this: > You mean we should define this in such a way that the GET isn't actually = executed if it on the token of an existing observation relationship? That = would be ugly indeed. > > Gr=FC=DFe, Carsten > > > ________________________________ > The information contained in this message may be confidential and legally= protected under applicable law. The message is intended solely for the add= ressee(s). If you are not the intended recipient, you are hereby notified t= hat any use, forwarding, dissemination, or reproduction of this message is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original message. > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Mar 6 06:06:41 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7430A1A027D for ; Thu, 6 Mar 2014 06:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.746 X-Spam-Level: X-Spam-Status: No, score=-4.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jtfy50VCB8AM for ; Thu, 6 Mar 2014 06:06:36 -0800 (PST) Received: from smtp2.ugent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id A87FE1A0156 for ; Thu, 6 Mar 2014 06:06:35 -0800 (PST) Received: from localhost (mcheck3.ugent.be [157.193.71.89]) by smtp2.ugent.be (Postfix) with ESMTP id 3147D12C38D; Thu, 6 Mar 2014 15:06:31 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp2.ugent.be ([IPv6:::ffff:157.193.49.126]) by localhost (mcheck3.UGent.be [::ffff:157.193.43.11]) (amavisd-new, port 10024) with ESMTP id zVZm-xfCpie4; Thu, 6 Mar 2014 15:06:25 +0100 (CET) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp2.ugent.be (Postfix) with ESMTP id BF27D12C364; Thu, 6 Mar 2014 15:06:25 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id B56D11F; Thu, 6 Mar 2014 15:06:25 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLZgYi6mTQIX; Thu, 6 Mar 2014 15:06:25 +0100 (CET) Received: from [157.193.135.191] (dhcp-zdpt-191.intec.ugent.be [157.193.135.191]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fvdabeele) by mail2.intec.ugent.be (Postfix) with ESMTPSA id 9F5B71E; Thu, 6 Mar 2014 15:06:25 +0100 (CET) Message-ID: <531880E1.407@intec.ugent.be> Date: Thu, 06 Mar 2014 15:06:25 +0100 From: Floris Van den Abeele User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Thoma, Matthias" , "core@ietf.org" References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> <86216A3E-8F93-4A23-959E-5EE4E6FEFD44@tzi.org> <031DD135F9160444ABBE3B0C36CED6180D65B164@AMSPRD9003MB066.MGDPHG.emi.philips.com> <53186E78.90102@pabigot.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------000200020402080206070203" X-Miltered: at jchkm3 with ID 531880E1.002 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 531880E1.002 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 531880E1.002 on smtp2.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: http://mailarchive.ietf.org/arch/msg/core/q8KeMj5WUDuo8aD9aW1j3JrCbu8 Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:06:38 -0000 This is a multi-part message in MIME format. --------------000200020402080206070203 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To clarify: the "Still re-use of active Token for re-registration" CON applies to all alternatives, right (as it is only mentioned here)? To comment on the no-response option alternative, is there an acknowledge from the server to the observer that the observer was removed from the list? In case the cancellation request was sent as a CON message, this cancellation ack could coincide with the message ACK (i.e. only the resource representation is elided from the response)? Going through draft-tcs-coap-no-response-option-05, this was not clear to me as it is ignored for CON messages. Floris op 06-03-14 14:49, Thoma, Matthias schreef: > Hi, > > to add one more implementator point of view: > > What we are currently using is also the "get without observe" option, but with an additional optional no-response option (like it has been proposed here) to save some energy (otherwise the sensor would have to gather information which might just been thrown away at the receiver side). The RST also had something appealing, but as it supported by alternative transport (*) I can understand why people think it is a no-go. Generally, I agree with Peter and Esko that the current way CoAP-observe is working is not very RESTful, but on the other hand, a more RESTful solution might already be too resource intensive for very constrained devices. > > Furthermore, why not giving people a choice? I also see some valid points for the RST+MID in CoAP over UDP, when you are in a very constrained device as the parsing complexity is way smaller and you can cancel an observer by examining the 4-byte header only. The problem with clean but resource hungry or too complex solutions (which might work with every transport-layer protocol) is that people might start just ignoring it, looking for less energy/computation/memory whatever-consuming ways of doing things. I wouldn't prematurely give up on nice elegant resource-saving solutions, even if they are transport layer specific. Additionally, to a one works-for-all solution, of course. > > > (*) Looking into the websockets alternative transport, I got the feeling that the unlayered "mixing" of concepts (transport layer, application layer) in CoAP is, while maybe justified from a constraintness point of view, is very unfortunate from a general engineering point of view. After all, even the header of the protocol changed so it is not as easy as it could be to move from one transport layer (CoAP over UDP) to another (CoAP over websockets) as it could be. > > Best, > Matthias > --------------000200020402080206070203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To clarify: the "Still re-use of active Token for re-registration" CON applies to all alternatives, right (as it is only mentioned here)?

To comment on the no-response option alternative, is there an acknowledge from the server to the observer that the observer was removed from the list? In case the cancellation request was sent as a CON message, this cancellation ack could coincide with the message ACK (i.e. only the resource representation is elided from the response)? Going through draft-tcs-coap-no-response-option-05, this was not clear to me as it is ignored for CON messages.

Floris
op 06-03-14 14:49, Thoma, Matthias schreef:
Hi,

to add one more implementator point of view: 

What we are currently using is also the "get without observe" option, but with an additional optional no-response option (like it has been proposed here) to save some energy (otherwise the sensor would have to gather information which might just been thrown away at the receiver side). The RST also had something appealing, but as it supported by alternative transport  (*) I can understand why people think it is a no-go.  Generally, I agree with Peter and Esko that the current way CoAP-observe is working is not very RESTful, but on the other hand, a more RESTful solution might already be too resource intensive for very constrained devices. 

Furthermore, why not giving people a choice? I also see some valid points for the RST+MID in CoAP over UDP, when you are in a very constrained device as the parsing complexity is way smaller and you can cancel an observer by examining the 4-byte header only. The problem with clean but resource hungry or too complex solutions (which might work with every transport-layer protocol) is that people might start just ignoring it, looking for less energy/computation/memory whatever-consuming ways of doing things.  I wouldn't prematurely give up on nice  elegant  resource-saving solutions, even if they are transport layer specific.  Additionally, to a one works-for-all solution, of course.


(*) Looking into the websockets alternative transport, I got the feeling that the unlayered "mixing" of concepts (transport layer, application layer) in CoAP is, while maybe justified from a constraintness point of view, is  very unfortunate from a general engineering point of view.  After all, even the header of the protocol changed so it is not as easy as it could be to move from one transport layer (CoAP over UDP) to another (CoAP over websockets) as it could be. 

Best,
  Matthias
--------------000200020402080206070203-- From nobody Thu Mar 6 06:07:31 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A95B1A0137 for ; Thu, 6 Mar 2014 06:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhhDH8BkHhgI for ; Thu, 6 Mar 2014 06:07:25 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id F0E681A0297 for ; Thu, 6 Mar 2014 06:07:23 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s26E7H0E014842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Mar 2014 08:07:19 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s26E7Giw021292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 15:07:17 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.236]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 6 Mar 2014 15:07:16 +0100 From: "FOSSATI, Thomas (Thomas)" To: "Dijk, Esko" , Carsten Bormann Thread-Topic: [core] Observe Cancellation Thread-Index: Ac83r+3jwpuMU0icTxO/RDVFtTNfYgA3WpJWACFj1VD///W/AIAACYMAgABU6YA= Date: Thu, 6 Mar 2014 14:07:15 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> <86216A3E-8F93-4A23-959E-5EE4E6FEFD44@tzi.org> <031DD135F9160444ABBE3B0C36CED6180D65B164@AMSPRD9003MB066.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180D65B164@AMSPRD9003MB066.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-ID: <101811B40B6EDD4993BD5D7A65EF3DA2@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/core/oCvYDLA4qN6-T6qwi5oCtHPYEbA Cc: "core@ietf.org" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:07:28 -0000 T24gMDYvMDMvMjAxNCAwOTowMywgIkRpamssIEVza28iIDxlc2tvLmRpamtAcGhpbGlwcy5jb20+ IHdyb3RlOg0KPkluIHN1bW1hcnksIGFsc28gaGVyZSBJIHNlZSBzb21lICJkYW5nZXIgb2YgbXV0 YXRpb24gaW50byBhIHZlcnkNCj51blJFU1RmdWwgcHJvdG9jb2wiDQoNCjEwMCUgYWdyZWUgd2l0 aCBFc2tv4oCZcyBjb25jZXJuLg0KDQpJIHNoYXJlIHRoZSBpZGVhIHRoYXQgdGhlIGZ1bmRhbWVu dGFsIHByb2JsZW0gaGVyZSBpcyB0aGF0IHRoZSBPYnNlcnZlDQpzdGF0ZSBhdCB0aGUgc2VydmVy IGlzIG5vdCBtb2RlbGxlZCBhcyBhIHJlc291cmNlLCBhbmQgdGh1cyBpdCBjYW7igJl0IGJlDQpj b250cm9sbGVkIGluIGEgUkVTVGZ1bCB3YXkuICBUaGF04oCZcyBpdC4NCg0KQXMgSeKAmXZlIGFs cmVhZHkgc2FpZCwgSeKAmWQgcmVhbGx5IHByZWZlciB0byB1c2UgYSBjb250cm9sIHNpZ25hbCB0 aGVuDQpvdmVycmlkaW5nIHRoZSBzZW1hbnRpY3Mgb2YgYSBtZXRob2QgYXMgYmFzaWMgYXMgR0VU Lg0KDQoNCk9uIHRoZSBvdGhlciBoYW5kIEnigJltIGFsc28gY29uY2VybmVkIGJ5IHRoZSBjaGFu Z2VzIHRvIHRoZSBwcm90b2NvbCBzdGF0ZQ0KbWFjaGluZSBpbXBsaWVkIGJ5IGEgbmV3IGNvbnRy b2wgc2lnbmFsIGFzIGl04oCZcyBiZWVuIGhpZ2hsaWdodGVkIGJ5IEJlcnQsDQpNYXR0aGlhcywg YW5kIFphY2ggKGFtb25nIHRoZSBvdGhlcnMpLCBhbmQgdGhlIGZhY3QgdGhhdCB0aGVzZSBjaGFu Z2VzIGFyZQ0KZ29pbmcgdG8gaGF2ZSBhIGJpZyBpbXBhY3Qgb24gZXhpc3RpbmcgaW1wbGVtZW50 YXRpb25zLg0KDQoNClNvLCBteSBodW1ibGUgc3VnZ2VzdGlvbiBpcyB0aGF0IGZvciB0aGUgdGlt ZSBiZWluZyB3ZSBhY2NlcHQgdGhhdCB3ZSBoYXZlDQphbHJlYWR5IOKAnGRhbmdlcm91c2x5IG11 dGF0ZWQgaW50byBhIHZlcnkgdW5SRVNUZnVsIHByb3RvY29s4oCdIGFuZCBqdXN0IHRyeQ0KdG8g d29yayBhcm91bmQgT2JzZXJ2ZSdzIHVuLVJFU1RmdWwtbmVzcyBpbiB0aGUgc2ltcGxlc3QgcG9z c2libGUgd2F5Lg0KDQpUaGUgcXVpY2tlciB3ZSBtb3ZlIC1vYnNlcnZlIHRvIExDLCB0aGUgZWFy bGllciB3ZSBjYW4gc3RhcnQgcmUtdGhpbmtpbmcNCml0IChiYXNlZCBvbiB3aGF0IHdl4oCZdmUg bGVhcm5lZCkgYW5kIHRyeSB0byBnZXQgaXQgcGVyZmVjdGx5IHJpZ2h0IHRoaXMNCnRpbWUuDQoN Cg0KQ2hlZXJzDQoNClBTOiBJIGRvbuKAmXQgd2FudCB0aGlzIGVtYWlsIHNvdW5kcyBkZXJvZ2F0 b3J5IHRvd2FyZHMgS2xhdXMgd2hvIEkgdGhpbmsNCmhhcyBkb25lIGEgc3VwZXIgc3VwZXIgam9i IHdpdGggdGhpcyBkcmFmdC4NCg0K From nobody Thu Mar 6 06:31:31 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B651A0282 for ; Thu, 6 Mar 2014 06:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcF-t4GLILnm for ; Thu, 6 Mar 2014 06:31:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AFB661A00FE for ; Thu, 6 Mar 2014 06:31:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEH51259; Thu, 06 Mar 2014 14:31:22 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Mar 2014 14:30:44 +0000 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Mar 2014 14:31:15 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.94]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Thu, 6 Mar 2014 22:31:09 +0800 From: Bert Greevenbosch To: Klaus Hartke Thread-Topic: [core] Observe Cancellation Thread-Index: Ac83r+3jwpuMU0icTxO/RDVFtTNfYgA3WpJWABT6tQAAGM1uRg== Date: Thu, 6 Mar 2014 14:31:08 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E456307@SZXEMA510-MBX.china.huawei.com> References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com>, In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.72.51] Content-Type: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB63E456307SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/-ICESSiknxFrPVcnxOWH_LOhc_0 Cc: "Szymon.Sasin@arm.com" , "core@ietf.org" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:31:30 -0000 --_000_46A1DF3F04371240B504290A071B4DB63E456307SZXEMA510MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Klaus, Thank you for your feedback. True, requesting the payload may unnecessarily take energy. The sleep issue= is only relevant in case of a proxy handling the observe relationship (whi= ch indeed may quite frequently be the case), since if there was no proxy th= e client had to wait until the server waked up for any message, including o= bserve cancellation. For servers that support observe and thus the observe option, we could also= include something in the observe option payload of the request, e.g. a cod= e for cancel. That would not resolve the issue with the non-supporting serv= er though. Such a device wouldn't generate an observation relationship on r= eceiving the observation registration request, but send a response with a p= ayload, and would behave similarly when receiving the observation cancellat= ion request. What do servers do when they receive unknown message codes? Would the messa= ge be discarded, or will the server send a 4.00 "bad request" response? It = seems to be undefined right now, but whatever it is, it would happen when n= on-supporting servers receive a 7.31 code. Notice that section 5.8 says: "A request with an unrecognized or unsupported Method Code MUST generate a 4.05 (Method Not Allowed) piggy-backed response. " So that could argue for e.g. a 0.05 code (note that GET is 0.01, POST 0.02 = etc.) as an alternative to 7.31. At least it would fit the request/response= architecture then, and there is clearly defined behaviour of non-supportin= g servers. A new method "CANCEL"? Could be useful for e.g. cancelling block= PUT transactions too (informing the server to discard whatever it has alre= ady received). Just thinking aloud here, not really proposing it as a solut= ion at this time. Best regards, Bert ________________________________ From: Klaus Hartke [hartke@tzi.org] Sent: 06 March 2014 18:10 To: Bert Greevenbosch Cc: Kovatsch Matthias; core@ietf.org; Szymon.Sasin@arm.com; Klaus Hartke (h= artke@tzi.org) Subject: Re: [core] Observe Cancellation Hi Bert! Bert Greevenbosch wrote: I prefer "GET without Observe Option" (using the same token). Works fine, and doesn't give issues to non-supporting devices. I don't really worry about the token-reuse issue, especially since the toke= n is related to that observe transaction anyway. The issue here is more that cancellation by itself is a very simple thing r= eally: one hop tells the next hop to stop, done. However, the usage of the = GET method naturally drags in the whole semantics of resource representatio= n retrieval: in addition to simply updating some internal data structure, t= he next hop now must acquire a current representation of the target resourc= e to return. This may involve just checking the local cache, but may also i= nvolve requesting the representation from the next hop, which may have to a= cquire it from the next hop, and so on. This may involve waiting for sleepy= devices to wake up, powering up radios, establishing secure connections --= all of which are expensive operations. It seems that cancellation is a fairly frequent interaction in some scenari= os, i.e., there are scenarios where observations are short-lived and predom= inantly ended by proactive cancellation. I don't know if the cost of a full= GET request every time is acceptable here. Best regards, Klaus --_000_46A1DF3F04371240B504290A071B4DB63E456307SZXEMA510MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Klaus,

 

Thank you for your feedback.

 

True, requesting the payload may unnecessarily take energy. The sleep is= sue is only relevant in case of a proxy handling the observe relationship (= which indeed may quite frequently be the case), since if there was no proxy= the client had to wait until the server waked up for any message, including observe cancellation.

 

For servers that support observe and thus the observe option, we could a= lso include something in the observe option payload of the request, e.= g. a code for cancel. That would not resolve the issue with the non-support= ing server though. Such a device wouldn't generate an observation relationship on receiving the observation registra= tion request, but send a response with a payload, and would behave similarl= y when receiving the observation cancellation request.

 

What do servers do when they receive unknown message codes? Would the me= ssage be discarded, or will the server send a 4.00 "bad requ= est" response? It seems to be undefined right now, but whatever it is,= it would happen when non-supporting servers receive a 7.31 code.

 

Notice that section 5.8 says:

"A
   request with an unrecognized or unsupported Method Code MUST g= enerate
   a 4.05 (Method Not Allowed) piggy-backed response.
"

 

So that could argue for e.g. a 0.05 code (note that GET is 0.01, POST 0.= 02 etc.) as an alternative to 7.31. At least it would fit the request/respo= nse architecture then, and there is clearly defined behaviour of non-suppor= ting servers. A new method "CANCEL"? Could be useful for e.g. cancelling block PUT transactions too (informing = the server to discard whatever it has already received). Just thinking alou= d here, not really proposing it as a solution at this time.

 

Best regards,

Bert

 

From: Klaus Hartke [hartke@tzi.org]
Sent: 06 March 2014 18:10
To: Bert Greevenbosch
Cc: Kovatsch Matthias; core@ietf.org; Szymon.Sasin@arm.com; Klaus Ha= rtke (hartke@tzi.org)
Subject: Re: [core] Observe Cancellation

Hi Bert!

Bert Greevenbosch wrote:
I prefer "GET without Observe Option" (using the same token).

Works fine, and doesn't give issues to non-supporting devices.

I don't really worry about the token-reuse issue, especially since the toke= n is related to that observe transaction anyway.

The issue here is more that cancellation by itself is a very simple th= ing really: one hop tells the next hop to stop, done. However, the usage of the GET method naturally drags = in the whole semantics of resource representation retrieval: in addition to simply updating some internal data structure, th= e next hop now must acquire a current representation of the target resource=  to return. This may involve just checking the local cache, but may al= so involve requesting the representation from the next hop, which may have to acquire it from the next hop, an= d so on. This may involve waiting for sleepy devices to wake up, power= ing up radios, establishing secure connections -- all of which are&nbs= p;expensive operations.

It seems that cancellation is a fairly frequent interaction in some sc= enarios, i.e., there are scenarios where observations are short-lived and p= redominantly ended by proactive cancellation. I don't know if the cost= of a full GET request every time is acceptable here.

Best regards,
Klaus
--_000_46A1DF3F04371240B504290A071B4DB63E456307SZXEMA510MBXchi_-- From nobody Thu Mar 6 06:32:14 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DC21A0282 for ; Thu, 6 Mar 2014 06:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdgBVfjXGI4k for ; Thu, 6 Mar 2014 06:32:12 -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 1D7901A00FE for ; Thu, 6 Mar 2014 06:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s26EW2ib000294; Thu, 6 Mar 2014 15:32:02 +0100 (CET) Received: from dhcp-9d1b.meeting.ietf.org (dhcp-9d1b.meeting.ietf.org [31.133.157.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 90E888CE; Thu, 6 Mar 2014 15:32:01 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: Date: Thu, 6 Mar 2014 14:32:00 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> <86216A3E-8F93-4A23-959E-5EE4E6FEFD44@tzi.org> <031DD135F9160444ABBE3B0C36CED6180D65B164@AMSPRD9003MB066.MGDPHG.emi.philips.com> <53186E78.90102@pabigot.com> To: "Thoma, Matthias" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/HJCcCPvp4ekwCnSKd1OKM_GG9Z0 Cc: "core@ietf.org" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:32:13 -0000 On 06 Mar 2014, at 13:49, Thoma, Matthias = wrote: > Furthermore, why not giving people a choice? I also see some valid = points for the RST+MID in CoAP over UDP, when you are in a very = constrained device as the parsing complexity is way smaller and you can = cancel an observer by examining the 4-byte header only. The problem with = clean but resource hungry or too complex solutions (which might work = with every transport-layer protocol) is that people might start just = ignoring it, looking for less energy/computation/memory = whatever-consuming ways of doing things. I wouldn't prematurely give up = on nice elegant resource-saving solutions, even if they are transport = layer specific. Additionally, to a one works-for-all solution, of = course. RST is great for reactive cancellation (at least if the message layer = for your transport has a RST) and is not going away. Reactive cancellation is needed if you receive a notification that you = forget you (or your previous incarnation) ordered, and RST is the right = way to handle this case. (Note that this is less applicable on connection-oriented transports, = which are likely to fate-share with the observation relationships.) The current discussion is about proactive cancellation: You have set up = an observation and want to get rid of it at a particular point in time, = without necessarily having a fresh notification in hand. Gr=FC=DFe, Carsten From nobody Thu Mar 6 06:32:33 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FC81A03DB for ; Thu, 6 Mar 2014 06:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tGOx7JVUJ6F for ; Thu, 6 Mar 2014 06:32:30 -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 203F01A00DC for ; Thu, 6 Mar 2014 06:32: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.5/8.14.5) with ESMTP id s26EViBs029480; Thu, 6 Mar 2014 15:31:45 +0100 (CET) Received: from dhcp-9d1b.meeting.ietf.org (dhcp-9d1b.meeting.ietf.org [31.133.157.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EA38C8CD; Thu, 6 Mar 2014 15:31:43 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: Date: Thu, 6 Mar 2014 14:31:41 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9FFF2892-C986-45B9-ADB8-CF82D7B1B57D@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> <86216A3E-8F93-4A23-959E-5EE4E6FEFD44@tzi.org> <031DD135F9160444ABBE3B0C36CED6180D65B164@AMSPRD9003MB066.MGDPHG.emi.philips.com> To: "FOSSATI, Thomas (Thomas)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/Een1PDK3_jstMyG5ymLaf4MMwRg Cc: "core@ietf.org" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:32:32 -0000 On 06 Mar 2014, at 14:07, FOSSATI, Thomas (Thomas) = wrote: > I share the idea that the fundamental problem here is that the Observe > state at the server is not modelled as a resource, and thus it can=92t = be > controlled in a RESTful way. That=92s it. The TCP connections that carry HTTP also cannot be modeled as a = resource. This doesn=92t seem to make HTTP =93unrestful=94. We tried to skip defining a teardown message for long running requests = such as observation relationships, and that may have been a mistake. Klaus wants to fix this outright, which is relatively simple as the = token provides a good handle to do that. The other proposals will allow us to live without such a message for = now, by going through the ordinary request code path and detecting the = cancellation based on some option matching. I don=92t have a strong opinion here, except that I am in a plugtest in = less than 24 hours and we want to run tests for whatever we decide... Gr=FC=DFe, Carsten From nobody Thu Mar 6 06:42:17 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C1B1A036D for ; Thu, 6 Mar 2014 06:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_12=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5AXGiwnRnTI for ; Thu, 6 Mar 2014 06:42: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 F25E11A0440 for ; Thu, 6 Mar 2014 06:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s26Eftrv019839; Thu, 6 Mar 2014 15:41:55 +0100 (CET) Received: from dhcp-9d1b.meeting.ietf.org (dhcp-9d1b.meeting.ietf.org [31.133.157.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7694D8E1; Thu, 6 Mar 2014 15:41:48 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E456307@SZXEMA510-MBX.china.huawei.com> Date: Thu, 6 Mar 2014 14:41:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0321E805-0B13-4972-A51E-F49EF678951A@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com>, <46A1DF3F04371240B504290A071B4DB63E456307@SZXEMA510-MBX.china.huawei.com> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/pmSoUZDPYW0SL4Ee3ROsveklYDc Cc: "Szymon.Sasin@arm.com" , "core@ietf.org" , Klaus Hartke Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:42:16 -0000 On 06 Mar 2014, at 14:31, Bert Greevenbosch = wrote: > So that could argue for e.g. a 0.05 code (note that GET is 0.01, POST = 0.02 etc.) as an alternative to 7.31.=20 Pro: The rule which side is the owner of the token space stays simple = (0.xx =3D my space, y.xx =3D your space). Cons: =97 Cancel isn=92t really a request on a resource, so this is still = confusing. =97 The method code space is relatively small. If we are going this way, we should probably use 0.31 to clearly = separate request method codes from this new kind of other method codes = like cancel. =46rom an implementation point of view, all other issues cited with = retrofitting 7.31 cancel remain. Gr=FC=DFe, Carsten From nobody Thu Mar 6 06:48:59 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28981A0070 for ; Thu, 6 Mar 2014 06:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQyJjQ22IFQw for ; Thu, 6 Mar 2014 06:48:52 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5981A0002 for ; Thu, 6 Mar 2014 06:48:52 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s26Emkkj018109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Mar 2014 08:48:48 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s26Emjuo030759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 15:48:45 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.236]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 6 Mar 2014 15:48:45 +0100 From: "FOSSATI, Thomas (Thomas)" To: Carsten Bormann Thread-Topic: [core] Observe Cancellation Thread-Index: Ac83r+3jwpuMU0icTxO/RDVFtTNfYgA3WpJWACFj1VD///W/AIAACYMAgABU6YCAAAbWgIAABMOA Date: Thu, 6 Mar 2014 14:48:45 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> <86216A3E-8F93-4A23-959E-5EE4E6FEFD44@tzi.org> <031DD135F9160444ABBE3B0C36CED6180D65B164@AMSPRD9003MB066.MGDPHG.emi.philips.com> <9FFF2892-C986-45B9-ADB8-CF82D7B1B57D@tzi.org> In-Reply-To: <9FFF2892-C986-45B9-ADB8-CF82D7B1B57D@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-ID: <660266933AE1A946B8CE1EF6E1E7B971@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/core/oFi-wTTqhwxBuuoAKlBJDIPh_Lw Cc: "core@ietf.org" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:48:56 -0000 T24gMDYvMDMvMjAxNCAxNDozMSwgIkNhcnN0ZW4gQm9ybWFubiIgPGNhYm9AdHppLm9yZz4gd3Jv dGU6DQo+T24gMDYgTWFyIDIwMTQsIGF0IDE0OjA3LCBGT1NTQVRJLCBUaG9tYXMgKFRob21hcykN Cj48dGhvbWFzLmZvc3NhdGlAYWxjYXRlbC1sdWNlbnQuY29tPiB3cm90ZToNCj4NCj4+IEkgc2hh cmUgdGhlIGlkZWEgdGhhdCB0aGUgZnVuZGFtZW50YWwgcHJvYmxlbSBoZXJlIGlzIHRoYXQgdGhl IE9ic2VydmUNCj4+IHN0YXRlIGF0IHRoZSBzZXJ2ZXIgaXMgbm90IG1vZGVsbGVkIGFzIGEgcmVz b3VyY2UsIGFuZCB0aHVzIGl0IGNhbuKAmXQgYmUNCj4+IGNvbnRyb2xsZWQgaW4gYSBSRVNUZnVs IHdheS4gIFRoYXTigJlzIGl0Lg0KPg0KPlRoZSBUQ1AgY29ubmVjdGlvbnMgdGhhdCBjYXJyeSBI VFRQIGFsc28gY2Fubm90IGJlIG1vZGVsZWQgYXMgYSByZXNvdXJjZS4NCj5UaGlzIGRvZXNu4oCZ dCBzZWVtIHRvIG1ha2UgSFRUUCDigJx1bnJlc3RmdWzigJ0uDQoNCkJ1dCB0aGV5IHdlcmUgd2lz ZSBlbm91Z2ggbm90IHRvIGludHJvZHVjZSBhbnkgZXhwbGljaXQgInJlc291cmNlDQpvYnNlcnZh dGlvbiIgY29uY2VwdCB0aGVyZSA6LSkNCg0KDQpGb3IgdGhlIHJlY29yZDogUm95IEZpZWxkaW5n 4oCZcyBXYWthIFsqXSwgYW4gZXhwZXJpbWVudGFsIHJlcGxhY2VtZW50IGZvcg0KSFRUUC8xLngs IGludHJvZHVjZWQgYSBNT05JVE9SIG1ldGhvZCB3aGljaCBoYXMgdGhlIGV4YWN0IHNlbWFudGlj cyBhcw0KT2JzZXJ2ZS4gIEkgZG9u4oCZdCBrbm93IGlmIGFuZCBob3cgdGhhdCBldm9sdmVkIHRo b3VnaC4NCg0KWypdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9hZ2VuZGEvODMvc2xpZGVzL3NsaWRl cy04My1odHRwYmlzLTUucGRmDQoNCg== From nobody Thu Mar 6 07:00:11 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6391B1A01A5 for ; Thu, 6 Mar 2014 07:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5Cl4PKNuVLF for ; Thu, 6 Mar 2014 07:00:08 -0800 (PST) Received: from smtpgw.sap-ag.de (smtpgw03.sap-ag.de [155.56.66.98]) by ietfa.amsl.com (Postfix) with ESMTP id 25E1E1A017E for ; Thu, 6 Mar 2014 07:00:05 -0800 (PST) From: "Thoma, Matthias" To: "core@ietf.org" Thread-Topic: [core] Observe Cancellation Thread-Index: Ac83r+3jwpuMU0icTxO/RDVFtTNfYgA3WpJWACFj1VD///W/AIAACYMAgAA+vgD//+aIEIAANpAA///uv/A= Date: Thu, 6 Mar 2014 14:59:59 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> <86216A3E-8F93-4A23-959E-5EE4E6FEFD44@tzi.org> <031DD135F9160444ABBE3B0C36CED6180D65B164@AMSPRD9003MB066.MGDPHG.emi.philips.com> <53186E78.90102@pabigot.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.40.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/core/c5iY9vYCzpgYXgT2sfiYZPLeTt0 Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:00:10 -0000 > RST is great for reactive cancellation (at least if the message layer for= your transport has a RST) and is not going away. > Reactive cancellation is needed if you receive a notification that you fo= rget you (or your previous incarnation) ordered, and RST is=20 > the right way to handle this case. > (Note that this is less applicable on connection-oriented transports, whi= ch are likely to fate-share with the observation relationships.) > > The current discussion is about proactive cancellation: You have set up a= n observation and want to get rid of it at a particular point in time, with= out=20 > necessarily having a fresh notification in hand. I didn't want to write anything about reactive cancellation. I completely= understand that part. But if it is already 90% there, it is nice and elega= nt, resource-saving and relatively easy to implement why not (optionally)= also use it for active cancellation as well. Other, future, CoAP over some= thing, might have even nicer solutions at equally low levels which save som= e resources. Just wanted to make the point, that apart from one-fits-all s= olutions, given the domain "constraint devices" considering further transpo= rt-layer active cancellation mechanisms might still be worth being consider= ed. If this is considered a good thing or a bad thing depends on your speci= fic use-cases, of course, and on what one considers "resource constrained".= An equally nice higher level solution is, of course, even better.=20 If the GET + non-observe option is considered the right solution, then I ca= n tell you from our implementation: It is reliable and works well, but need= s more computation time and energy, than the RST solution. We didn't had a= ny problems with it. The cleanest solution (but not the best in terms of energy or computation) = would be to go the ReSTFul way as suggest by others here, but I assume ther= e were good reasons not to do that in the first place. - Matthias From nobody Thu Mar 6 07:14:55 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337F61A0092 for ; Thu, 6 Mar 2014 07:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1jAyyGZMRyU for ; Thu, 6 Mar 2014 07:14:52 -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 069191A00A2 for ; Thu, 6 Mar 2014 07:14:51 -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.5/8.14.5) with ESMTP id s26FEiKp023538; Thu, 6 Mar 2014 16:14:44 +0100 (CET) Received: from dhcp-9d1b.meeting.ietf.org (dhcp-9d1b.meeting.ietf.org [31.133.157.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6E23D916; Thu, 6 Mar 2014 16:14:44 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: Date: Thu, 6 Mar 2014 15:14:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> <86216A3E-8F93-4A23-959E-5EE4E6FEFD44@tzi.org> <031DD135F9160444ABBE3B0C36CED6180D65B164@AMSPRD9003MB066.MGDPHG.emi.philips.com> <53186E78.90102@pabigot.com> To: "Thoma, Matthias" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/9SsDnwlzpJXlCV1lSNiBpRiiMh0 Cc: "core@ietf.org" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:14:53 -0000 On 06 Mar 2014, at 14:59, Thoma, Matthias = wrote: > why not (optionally) also use it for active cancellation as well.=20 reactive works so well because the server has active state (the context = of the notification message being delivered) while the RST arrives. (In some implementations, that is already a stretch for NON = notifications, which is why RST handling is not mandatory there.) If there has been no recent notification, you don=92t have a message-ID = to key the RST to, so RST cannot be used for proactive cancellation. The closest one can do is key on the token, which is exactly what Klaus=92= proposal is about. However, some implementations on the server side key on the request = parameters, so these have to match to get even close to the place where = the observation state is managed. (This is not a problem for an observation renewal, which has all those = request parameters, and not for the =93superfluous GET=94 approach.) Gr=FC=DFe, Carsten From nobody Thu Mar 6 07:26:14 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0CC1A00EC for ; Thu, 6 Mar 2014 07:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BI8nZiIsUbwD for ; Thu, 6 Mar 2014 07:26:09 -0800 (PST) Received: from smtpgw.sap-ag.de (smtpgw04.sap-ag.de [155.56.66.99]) by ietfa.amsl.com (Postfix) with ESMTP id DED3A1A00E2 for ; Thu, 6 Mar 2014 07:26:08 -0800 (PST) From: "Thoma, Matthias" To: "core@ietf.org" Thread-Topic: [core] Observe Cancellation Thread-Index: Ac83r+3jwpuMU0icTxO/RDVFtTNfYgA3WpJWACFj1VD///W/AIAACYMAgAA+vgD//+aIEIAANpAA///uv/CAAB0vAP//7gpw Date: Thu, 6 Mar 2014 15:26:02 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> <86216A3E-8F93-4A23-959E-5EE4E6FEFD44@tzi.org> <031DD135F9160444ABBE3B0C36CED6180D65B164@AMSPRD9003MB066.MGDPHG.emi.philips.com> <53186E78.90102@pabigot.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.40.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/core/dFGD_LGA8HsD6MXuut9DHhtcfsI Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:26:10 -0000 > If there has been no recent notification, you don't have a message-ID to = key the RST to, so RST cannot be used for proactive cancellation. The original idea said "RST with Last Notification MID", so there is the la= st notification id. When I was saying active RST I always referred to that = idea and something I just made up. My intention was to add some more points= on the pro-side, like the fact that it needs less processing power than a = "GET without Observe Option" as the resource (as in energy or computing pow= er) saving aspect was not on the pro/con list of any item and I would consi= der that important in some constrained environments. Furthermore more compa= ct implementations would be possible. Didn't want to start a religious thre= ad... :-) Best, Matthias From nobody Thu Mar 6 08:08:50 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0F81A0030 for ; Thu, 6 Mar 2014 08:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4poE7829E_Yv for ; Thu, 6 Mar 2014 08:08:47 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AA4521A0074 for ; Thu, 6 Mar 2014 08:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s26G8XLj009425; Thu, 6 Mar 2014 17:08:33 +0100 (CET) Received: from dhcp-9d1b.meeting.ietf.org (dhcp-9d1b.meeting.ietf.org [31.133.157.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 364DA971; Thu, 6 Mar 2014 17:08:33 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: Date: Thu, 6 Mar 2014 16:08:29 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9D2CB3FC-E842-4C2A-B21E-12CE94C21E5F@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <031DD135F9160444ABBE3B0C36CED6180D65B12D@AMSPRD9003MB066.MGDPHG.emi.philips.com> <86216A3E-8F93-4A23-959E-5EE4E6FEFD44@tzi.org> <031DD135F9160444ABBE3B0C36CED6180D65B164@AMSPRD9003MB066.MGDPHG.emi.philips.com> <53186E78.90102@pabigot.com> To: "Thoma, Matthias" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/yKENcy2BRt3zSnTHy1dhdeWj2V4 Cc: "core@ietf.org" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:08:48 -0000 On 06 Mar 2014, at 15:26, Thoma, Matthias = wrote: > "RST with Last Notification MID" The main problem here is that this message ID may have been reused = since. Enabling this extended usage of message-IDs would require reserving the = last message ID used on the server side for each observed resource. This requires new message-ID handling techniques (can=92t just = garbage-collect after EXCHANGE_LIFETIME). (There also is the obvious limit to the number of observation = relationships, but I don=92t think one is likely to hit that.) You wouldn=92t always be able to cancel an observation relationship that = hasn=92t had its first notification beyond the initial response (which = is likely to be piggy-backed, hence does not have a server-side = message-ID). Gr=FC=DFe, Carsten From nobody Thu Mar 6 09:07:05 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D541A0048 for ; Thu, 6 Mar 2014 09:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9fvya4o5q-R for ; Thu, 6 Mar 2014 09:07:00 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 77D121A0088 for ; Thu, 6 Mar 2014 09:07:00 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s26H6mU2011237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Mar 2014 11:06:50 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s26H6FJI032348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 18:06:47 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.236]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 6 Mar 2014 18:06:25 +0100 From: "FOSSATI, Thomas (Thomas)" To: Carsten Bormann , Bert Greevenbosch Thread-Topic: [core] Observe Cancellation Thread-Index: Ac83r+3jwpuMU0icTxO/RDVFtTNfYgA3WpJWACOlzQAACRlZAAAAXuyAAAUM+QA= Date: Thu, 6 Mar 2014 17:06:25 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63E456307@SZXEMA510-MBX.china.huawei.com> <0321E805-0B13-4972-A51E-F49EF678951A@tzi.org> In-Reply-To: <0321E805-0B13-4972-A51E-F49EF678951A@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-ID: <5DF4D8D768ADF840AE601A035578F425@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/core/TpPrVQPb9B3hw7qeelcIxC5rmlg Cc: "Szymon.Sasin@arm.com" , Klaus Hartke , "core@ietf.org" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 17:07:02 -0000 T24gMDYvMDMvMjAxNCAxNDo0MSwgIkNhcnN0ZW4gQm9ybWFubiIgPGNhYm9AdHppLm9yZz4gd3Jv dGU6DQo+T24gMDYgTWFyIDIwMTQsIGF0IDE0OjMxLCBCZXJ0IEdyZWV2ZW5ib3NjaA0KPjxCZXJ0 LkdyZWV2ZW5ib3NjaEBodWF3ZWkuY29tPiB3cm90ZToNCj4+IFNvIHRoYXQgY291bGQgYXJndWUg Zm9yIGUuZy4gYSAwLjA1IGNvZGUgKG5vdGUgdGhhdCBHRVQgaXMgMC4wMSwgUE9TVA0KPj4wLjAy IGV0Yy4pIGFzIGFuIGFsdGVybmF0aXZlIHRvIDcuMzEuDQo+DQo+UHJvOiBUaGUgcnVsZSB3aGlj aCBzaWRlIGlzIHRoZSBvd25lciBvZiB0aGUgdG9rZW4gc3BhY2Ugc3RheXMgc2ltcGxlDQo+KDAu eHggPSBteSBzcGFjZSwgeS54eCA9IHlvdXIgc3BhY2UpLg0KPkNvbnM6DQo+4oCUIENhbmNlbCBp c27igJl0IHJlYWxseSBhIHJlcXVlc3Qgb24gYSByZXNvdXJjZSwgc28gdGhpcyBpcyBzdGlsbCBj b25mdXNpbmcuDQo+4oCUIFRoZSBtZXRob2QgY29kZSBzcGFjZSBpcyByZWxhdGl2ZWx5IHNtYWxs Lg0KPg0KPklmIHdlIGFyZSBnb2luZyB0aGlzIHdheSwgd2Ugc2hvdWxkIHByb2JhYmx5IHVzZSAw LjMxIHRvIGNsZWFybHkgc2VwYXJhdGUNCj5yZXF1ZXN0IG1ldGhvZCBjb2RlcyBmcm9tIHRoaXMg bmV3IGtpbmQgb2Ygb3RoZXIgbWV0aG9kIGNvZGVzIGxpa2UgY2FuY2VsLg0KDQpUaGlzIGlzIHBv c3NpYmx5IHRoZSBsZXNzZXIgb2YgdHdvIGV2aWxzLg0KDQpBbmQgYnR3IEkgc3VwcG9ydCB0aGUg aWRlYSBvZiDigJxpbmZvcm1hbGx5IiBwYXJ0aXRpb25pbmcgdGhlIDAtMzEgc3BhY2UNCmludG8g MjogbG93ZXIgZm9yIGdlbnVpbmUgcmVxdWVzdHMsIGhpZ2hlciBmb3IgY29udHJvbCBjb2Rlcy4g KFRvbyBiYWQgd2UNCnVzZWQgMCBmb3IgcGluZyBhbHJlYWR54oCmKQ0KDQo+RnJvbSBhbiBpbXBs ZW1lbnRhdGlvbiBwb2ludCBvZiB2aWV3LCBhbGwgb3RoZXIgaXNzdWVzIGNpdGVkIHdpdGgNCj5y ZXRyb2ZpdHRpbmcgNy4zMSBjYW5jZWwgcmVtYWluLg0KDQpBY3R1YWxseSwgdGhpcyBtYXkgbm90 IGJlIGFzIHRlcnJpYmxlIGFzIGl0IHNvdW5kcy4gIFlvdSBzdXJlbHkgbmVlZCB0bw0KZGlzcGF0 Y2ggdGhlIOKAnGV4cGxpY2l0IGNhbmNlbGxhdGlvbuKAnSBzaWduYWwgZnJvbSB0aGUgY2xpZW50 IHRvIHRoZQ0KInRlYXJkb3duIG9ic2VydmF0aW9uIHN0YXRl4oCdIGZ1bmN0aW9uIGJsb2NrLiAg RXhwcmVzc2luZyB0aGUg4oCcZXhwbGljaXQNCmNhbmNlbGxhdGlvbuKAnSBpbiBhIHdheSBvciBh bm90aGVyIG1ha2VzIHRoYXQgbXVjaCBkaWZmZXJlbmNlPyAgRXNwZWNpYWxseQ0KaWYgd2UgbW92 ZSBpdCB0byB0aGUgMS4uMzEgc3BhY2Ugc28gdGhhdCBhbiBoeWJyaWQgaW1wbGVtZW50YXRpb24g Y2FuDQpmb3J3YXJkIGl0IHRvIHRoZSByaWdodCBwcm9jZXNzaW5nIHBpcGVsaW5lIHVwZnJvbnQu DQoNCg== From nobody Thu Mar 6 10:03:27 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2861A00E3 for ; Thu, 6 Mar 2014 10:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5DV5LXKZ_Lm for ; Thu, 6 Mar 2014 10:03:22 -0800 (PST) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8B00F1A0040 for ; Thu, 6 Mar 2014 10:03:19 -0800 (PST) Received: from usa-sjc-gw1.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Thu, 06 Mar 2014 18:03:13 +0000 Received: from usa-sjc-gw2.usa.Arm.com (10.72.50.52) by usa-sjc-gw1.usa.Arm.com (10.72.50.51) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 6 Mar 2014 10:03:19 -0800 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw2.usa.Arm.com ([::1]) with mapi; Thu, 6 Mar 2014 10:03:19 -0800 From: Zach Shelby To: Bert Greevenbosch Date: Thu, 6 Mar 2014 10:03:13 -0800 Thread-Topic: [core] Observe Cancellation Thread-Index: Ac85Zlq8onlH+POLT72YNyNt1Aw+gA== Message-ID: References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MC-Unique: 114030618031400202 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/core/CVDNb9epcJN9aAIlBwqa29NNjzo Cc: "core@ietf.org WG" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 18:03:25 -0000 "GET without Observe Option (using the same token)" would also be my prefer= ence. Zach On Mar 5, 2014, at 4:10 PM, Bert Greevenbosch wrote: > Hi Matthias, > > I prefer "GET without Observe Option" (using the same token). > > Works fine, and doesn't give issues to non-supporting devices. > > I don't really worry about the token-reuse issue, especially since the to= ken is related to that observe transaction anyway. > > Best regards, > Bert > > > ________________________________________ > From: core [core-bounces@ietf.org] on behalf of Kovatsch Matthias [kovat= sch@inf.ethz.ch] > Sent: 04 March 2014 23:21 > To: core@ietf.org > Cc: Szymon.Sasin@arm.com; 'Klaus Hartke (hartke@tzi.org)' > Subject: [core] Observe Cancellation > > Dear list > > I want to start the discussion about what to do about Observe cancellatio= n. Today's session showed that we have two options to finish -observe: (i) = fix something by the end of the week and (ii) eject the cancellation mechan= ism and deal with it in a separate draft. > > To help finding consensus by the end of this week, I started a pro/con li= st for the possible solutions we have. Please comment, amend, etc., especia= lly when you are an implementer! > > RST with Last Notification MID > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > PRO > + No re-use of active Token > + No representation on cancel > CON > - Needs special rule to keep MIDs beyond lifetime > -- Not available over alternative transports > > I think this does not work because of the alternative transports. > > PUT/POST/DELETE with Observe Option > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > PRO > + It is not a GET > CON > -- Observe is elective and unsafe methods might corrupt the resource stat= e > > I think it is a really bad idea to overload an unsafe method for this. > > GET without Observe Option > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > PRO > + Modular design based on GET > + Already tested > CON > - Transmission of representation despite disinterest (including caches) > - Re-use of active Token > - Needs special rule to keep request the same (similar to re-registration= ) > > The GET without Observe option allows many different implementation strat= egies: first dividing into requests or responses (for the hybrid CoAP clien= t-and-server implementations for LWM2M), first delivering a request to its = resource before further inspection (Observe support could be added within a= resource handler implementation), having a clean processing pipeline, .... > > 7.xx Control Messages > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > PRO > + No re-use of active Token (as request) > + No representation on cancel > CON > - Still re-use of active Token for re-registration > - Control message class brings the danger of mutation into a very unRESTf= ul protocol > - New class at late state (why is CoAP ping not a control message?) > - Conflict with DTLS message detection (if kept at end of 7.xx) > - Management of remote Tokens (different namespaces...) or hooks that sho= rtcut the protocol control flow > > The control message cancellation is also useful for separate responses as= well as the liveliness checks of the full liveliness draft. However, this = goes beyond Observe. Observe without active cancellation still works and LW= M2M could include the liveliness module to have the required active cancell= ation. > > > Hoping for your input > Matthias > > _______________________________________________ > 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 > Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 Skype: zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/ -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 From nobody Thu Mar 6 11:39:24 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010EB1A00F8 for ; Thu, 6 Mar 2014 11:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYk_e0MCe2ZM for ; Thu, 6 Mar 2014 11:39:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CEC971A00F2 for ; Thu, 6 Mar 2014 11:39:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBU94041; Thu, 06 Mar 2014 19:39:13 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Mar 2014 19:38:40 +0000 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Mar 2014 19:39:12 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.94]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Fri, 7 Mar 2014 03:39:09 +0800 From: Bert Greevenbosch To: "core@ietf.org WG" Thread-Topic: [core] Observe Cancellation Thread-Index: Ac83r+3jwpuMU0icTxO/RDVFtTNfYgA3WpJWACV8O4AAE8ZJLQ== Date: Thu, 6 Mar 2014 19:39:07 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E4568B5@SZXEMA510-MBX.china.huawei.com> References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com>, In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.76.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/oJ58jD6XlnF3jw8OlYY57HYOEII Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 19:39:20 -0000 Hi all, Klaus, Thomas, Kepeng and I had some discussion on this today. Some extra things that came up in this discussion and may need consideratio= n: - Using "GET without observe" to cancel an observation relationship require= s executing code related to observe for every GET request, even if the clie= nt has never subscribed to the resource. - A response may not be required, since it is enough for the observation to= be cancelled on the server side, and the client may not require knowledge = on the result of the deletion.* *) when the server receives a "cancel observation", there two possibilities= : - the server knows the token, and deletes the related observationship - the related observation relationship does not exist In both cases, the result is that the observation relationship does not exi= st on the server after receipt of the message. Best regards, Bert= From nobody Thu Mar 6 14:18:16 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34241A0179 for ; Thu, 6 Mar 2014 14:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuoPw7_T_rtu for ; Thu, 6 Mar 2014 14:18:01 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 70D001A0180 for ; Thu, 6 Mar 2014 14:18:00 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s26MHqVT003710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Mar 2014 16:17:53 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s26MHpNK016514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 23:17:51 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.236]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 6 Mar 2014 23:17:51 +0100 From: "FOSSATI, Thomas (Thomas)" To: Bert Greevenbosch , "core@ietf.org WG" Thread-Topic: [core] Observe Cancellation Thread-Index: Ac83r+3jwpuMU0icTxO/RDVFtTNfYgA3WpJWADQnU4AAA1lpgAAFc1iA Date: Thu, 6 Mar 2014 22:17:50 +0000 Message-ID: References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63E4568B5@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E4568B5@SZXEMA510-MBX.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/core/7XOcF1KhCR6UlLfUDOusVF0D_54 Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 22:18:09 -0000 T24gMDYvMDMvMjAxNCAxOTozOSwgIkJlcnQgR3JlZXZlbmJvc2NoIiA8QmVydC5HcmVldmVuYm9z Y2hAaHVhd2VpLmNvbT4NCndyb3RlOg0KPlNvbWUgZXh0cmEgdGhpbmdzIHRoYXQgY2FtZSB1cCBp biB0aGlzIGRpc2N1c3Npb24gYW5kIG1heSBuZWVkDQo+Y29uc2lkZXJhdGlvbjoNCj4NCj4tIFVz aW5nICJHRVQgd2l0aG91dCBvYnNlcnZlIiB0byBjYW5jZWwgYW4gb2JzZXJ2YXRpb24gcmVsYXRp b25zaGlwDQo+cmVxdWlyZXMgZXhlY3V0aW5nIGNvZGUgcmVsYXRlZCB0byBvYnNlcnZlIGZvciBl dmVyeSBHRVQgcmVxdWVzdCwgZXZlbiBpZg0KPnRoZSBjbGllbnQgaGFzIG5ldmVyIHN1YnNjcmli ZWQgdG8gdGhlIHJlc291cmNlLg0KPi0gQSByZXNwb25zZSBtYXkgbm90IGJlIHJlcXVpcmVkLCBz aW5jZSBpdCBpcyBlbm91Z2ggZm9yIHRoZSBvYnNlcnZhdGlvbg0KPnRvIGJlIGNhbmNlbGxlZCBv biB0aGUgc2VydmVyIHNpZGUsIGFuZCB0aGUgY2xpZW50IG1heSBub3QgcmVxdWlyZQ0KPmtub3ds ZWRnZSBvbiB0aGUgcmVzdWx0IG9mIHRoZSBkZWxldGlvbi4qDQo+DQo+Kikgd2hlbiB0aGUgc2Vy dmVyIHJlY2VpdmVzIGEgImNhbmNlbCBvYnNlcnZhdGlvbiIsIHRoZXJlIHR3bw0KPnBvc3NpYmls aXRpZXM6DQo+ICAtIHRoZSBzZXJ2ZXIga25vd3MgdGhlIHRva2VuLCBhbmQgZGVsZXRlcyB0aGUg cmVsYXRlZCBvYnNlcnZhdGlvbnNoaXANCj4gIC0gdGhlIHJlbGF0ZWQgb2JzZXJ2YXRpb24gcmVs YXRpb25zaGlwIGRvZXMgbm90IGV4aXN0DQo+SW4gYm90aCBjYXNlcywgdGhlIHJlc3VsdCBpcyB0 aGF0IHRoZSBvYnNlcnZhdGlvbiByZWxhdGlvbnNoaXAgZG9lcyBub3QNCj5leGlzdCBvbiB0aGUg c2VydmVyIGFmdGVyIHJlY2VpcHQgb2YgdGhlIG1lc3NhZ2UuDQoNCkFub3RoZXIgcG9pbnQgdGhh dCB3ZeKAmXZlIGNsZWFyZWQgaXMgdGhhdCB1c2luZyBhIGNvZGUgZm9yIHRoZSBjYW5jZWxsYXRp b24NCmluIHRoZSA1LTMxIHNwYWNlIGRvZXNu4oCZdCBsb29rIHF1aXRlIHJpZ2h0Og0KDQogICJB IENvQVAgcmVxdWVzdCBjb25zaXN0cyBvZiB0aGUgbWV0aG9kIHRvIGJlIGFwcGxpZWQgdG8gdGhl IHJlc291cmNl4oCdDQoNClRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIGNhbmNlbGxhdGlvbiBkb2Vz IG5vdCBhcHBseSB0byBhIHJlc291cmNlLCBidXQNCnJhdGhlciB0byB0aGUgc3RhdGUgdGhhdCBl bmNvZGVzIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgY2xpZW50LCB0aGUNCnNlcnZlciwg YW5kIGEgcmVzb3VyY2UuDQoNCg== From nobody Thu Mar 6 20:28:20 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9EA1A0091 for ; Thu, 6 Mar 2014 20:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ0Lve9lb--I for ; Thu, 6 Mar 2014 20:28:10 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id D4D281A0090 for ; Thu, 6 Mar 2014 20:28:06 -0800 (PST) Received: from WeiGengyuPC (unknown [10.103.240.155]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 15CD119FCAE; Fri, 7 Mar 2014 12:27:57 +0800 (HKT) Message-ID: From: "weigengyu" To: "Kovatsch Matthias" Date: Fri, 7 Mar 2014 12:27:55 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/HBOsKhX_q78PfIifrjWk-ynpYhM Cc: core@ietf.org Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 04:28:17 -0000 HI all, My suggestion is to define a bit of flag in Observer option to identifify either to add a subject or to delete a subject. A message of Observe option with positive value causes the notification response(s); and a message of Observe option with negtive value stops nofication, as a cacellation. Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: weigengyu Sent: Wednesday, March 05, 2014 2:29 PM To: Kovatsch Matthias Subject: Re: [core] Observe Cancellation Hi Matthias, My sugggestion is to define a bit of flag in observe option, the bit means positive/negative request. If the GET with option of positive request, the server adds an subject to observe.; if the GET with option of negtive request, the server will delete the subject. So, the negative request functiosn as cancellation. I think that GET without observer option may have high efficiency, but it is a little vague in terms of sematics. regards, Gengyu Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Kovatsch Matthias Sent: Tuesday, March 04, 2014 11:21 PM To: core@ietf.org Cc: Szymon.Sasin@arm.com ; 'Klaus Hartke (hartke@tzi.org)' Subject: [core] Observe Cancellation Dear list I want to start the discussion about what to do about Observe cancellation. Today's session showed that we have two options to finish -observe: (i) fix something by the end of the week and (ii) eject the cancellation mechanism and deal with it in a separate draft. To help finding consensus by the end of this week, I started a pro/con list for the possible solutions we have. Please comment, amend, etc., especially when you are an implementer! RST with Last Notification MID ======================= PRO + No re-use of active Token + No representation on cancel CON - Needs special rule to keep MIDs beyond lifetime -- Not available over alternative transports I think this does not work because of the alternative transports. PUT/POST/DELETE with Observe Option ============================== PRO + It is not a GET CON -- Observe is elective and unsafe methods might corrupt the resource state I think it is a really bad idea to overload an unsafe method for this. GET without Observe Option ====================== PRO + Modular design based on GET + Already tested CON - Transmission of representation despite disinterest (including caches) - Re-use of active Token - Needs special rule to keep request the same (similar to re-registration) The GET without Observe option allows many different implementation strategies: first dividing into requests or responses (for the hybrid CoAP client-and-server implementations for LWM2M), first delivering a request to its resource before further inspection (Observe support could be added within a resource handler implementation), having a clean processing pipeline, .... 7.xx Control Messages ================= PRO + No re-use of active Token (as request) + No representation on cancel CON - Still re-use of active Token for re-registration - Control message class brings the danger of mutation into a very unRESTful protocol - New class at late state (why is CoAP ping not a control message?) - Conflict with DTLS message detection (if kept at end of 7.xx) - Management of remote Tokens (different namespaces...) or hooks that shortcut the protocol control flow The control message cancellation is also useful for separate responses as well as the liveliness checks of the full liveliness draft. However, this goes beyond Observe. Observe without active cancellation still works and LWM2M could include the liveliness module to have the required active cancellation. Hoping for your input Matthias _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Mar 6 23:55:54 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17E71A023B for ; Thu, 6 Mar 2014 23:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Rsu9KQZseAL for ; Thu, 6 Mar 2014 23:55:51 -0800 (PST) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id B16B61A0245 for ; Thu, 6 Mar 2014 23:55:50 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id j17so3857326oag.28 for ; Thu, 06 Mar 2014 23:55:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gb8fy7KrhfNlvmSoUGTY7OlPdH+5hevILn23lbUwfv4=; b=kIDytzbBJ+yRFaPnRfRwZ6kx3TxGXtI+/aGV2Z27iXCRZFz6qqUl0fUvKfOYwSglvr Z/Qs4XsQ2R6DDY2JdE29a95Hd9LWAZIKa6UxYkU63cX/HBbYMlr+4hMD/Tywdyny0lMt M/briITnHNewVlsx6jK7GsUf0+WK1VU8nCpn9Z4LEn5cnKKebrqMdcKjfW9opc4c7qcX G0mXSlvZiOs0Vbcx3TvXSg/iQNTmyKgmcsr6DLZHHhcJfXha6uBhmDUQsB475jyqNmgG dddhb1qaM4wywsZFxntpEt6Go12GsoVurQojMsk9ogwDfIDaFElBgVT3ahnGdekodq63 YswA== MIME-Version: 1.0 X-Received: by 10.60.44.8 with SMTP id a8mr9779955oem.19.1394178946479; Thu, 06 Mar 2014 23:55:46 -0800 (PST) Received: by 10.76.79.195 with HTTP; Thu, 6 Mar 2014 23:55:46 -0800 (PST) Received: by 10.76.79.195 with HTTP; Thu, 6 Mar 2014 23:55:46 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Mar 2014 13:25:46 +0530 Message-ID: From: Abhijan Bhattacharyya To: weigengyu Content-Type: multipart/alternative; boundary=001a11c2e458dbbe3a04f3ff94d9 Archived-At: http://mailarchive.ietf.org/arch/msg/core/6JWUgRnyNnpP9kv366YVdDU04kg Cc: Abhijan Bhattacharyya , core@ietf.org Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 07:55:53 -0000 --001a11c2e458dbbe3a04f3ff94d9 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Can we think about something like GET with both Observe and No-response options to indicate cancellation? This way we do not need to change the observe semantics and also will avoid the problem of executing the Observe code for every GET without Observe. Sorry if I have missed something here. On Mar 7, 2014 4:28 AM, "weigengyu" wrote: > HI all, > > My suggestion is to define a bit of flag in Observer option to identifify > either to add a subject or to delete a subject. > > A message of Observe option with positive value causes the notification > response(s); > and a message of Observe option with negtive value stops nofication, as a > cacellation. > > Regards, > > Gengyu > > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > > -----=D4=AD=CA=BC=D3=CA=BC=FE----- From: weigengyu > Sent: Wednesday, March 05, 2014 2:29 PM > To: Kovatsch Matthias > Subject: Re: [core] Observe Cancellation > > Hi Matthias, > > My sugggestion is to define a bit of flag in observe option, the bit mean= s > positive/negative request. > > If the GET with option of positive request, the server adds an subject to > observe.; > if the GET with option of negtive request, the server will delete the > subject. > So, the negative request functiosn as cancellation. > > I think that GET without observer option may have high efficiency, > but it is a little vague in terms of sematics. > > regards, > > Gengyu > > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > > -----=D4=AD=CA=BC=D3=CA=BC=FE----- From: Kovatsch Matthias > Sent: Tuesday, March 04, 2014 11:21 PM > To: core@ietf.org > Cc: Szymon.Sasin@arm.com ; 'Klaus Hartke (hartke@tzi.org)' > Subject: [core] Observe Cancellation > > Dear list > > I want to start the discussion about what to do about Observe cancellatio= n. > Today's session showed that we have two options to finish -observe: (i) f= ix > something by the end of the week and (ii) eject the cancellation mechanis= m > and deal with it in a separate draft. > > To help finding consensus by the end of this week, I started a pro/con li= st > for the possible solutions we have. Please comment, amend, etc., especial= ly > when you are an implementer! > > RST with Last Notification MID > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > PRO > + No re-use of active Token > + No representation on cancel > CON > - Needs special rule to keep MIDs beyond lifetime > -- Not available over alternative transports > > I think this does not work because of the alternative transports. > > PUT/POST/DELETE with Observe Option > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > PRO > + It is not a GET > CON > -- Observe is elective and unsafe methods might corrupt the resource stat= e > > I think it is a really bad idea to overload an unsafe method for this. > > GET without Observe Option > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > PRO > + Modular design based on GET > + Already tested > CON > - Transmission of representation despite disinterest (including caches) > - Re-use of active Token > - Needs special rule to keep request the same (similar to re-registration= ) > > The GET without Observe option allows many different implementation > strategies: first dividing into requests or responses (for the hybrid CoA= P > client-and-server implementations for LWM2M), first delivering a request = to > its resource before further inspection (Observe support could be added > within a resource handler implementation), having a clean processing > pipeline, .... > > 7.xx Control Messages > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > PRO > + No re-use of active Token (as request) > + No representation on cancel > CON > - Still re-use of active Token for re-registration > - Control message class brings the danger of mutation into a very unRESTf= ul > protocol > - New class at late state (why is CoAP ping not a control message?) > - Conflict with DTLS message detection (if kept at end of 7.xx) > - Management of remote Tokens (different namespaces...) or hooks that > shortcut the protocol control flow > > The control message cancellation is also useful for separate responses as > well as the liveliness checks of the full liveliness draft. However, this > goes beyond Observe. Observe without active cancellation still works and > LWM2M could include the liveliness module to have the required active > cancellation. > > > Hoping for your input > Matthias > > _______________________________________________ > 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 > --001a11c2e458dbbe3a04f3ff94d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Can we think about something like GET with both Observe and No-response = options to indicate cancellation? This way we do not need to change the obs= erve semantics and also will avoid the problem of executing the Observe cod= e for every GET without Observe. Sorry if I have missed something here.

On Mar 7, 2014 4:28 AM, "weigengyu" &l= t;weigengyu@bupt.edu.cn> wr= ote:
HI all,

My suggestion is to define a bit of flag in Observer option to identifify e= ither to add a subject or to delete a subject.

A message of Observe option with positive value causes the notification res= ponse(s);
and a message of Observe option with negtive value stops nofication, as a c= acellation.

Regards,

Gengyu

Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: weigengyu
Sent: Wednesday, March 05, 2014 2:29 PM
To: Kovatsch Matthias
Subject: Re: [core] Observe Cancellation

Hi Matthias,

My sugggestion is to define a bit of flag in observe option, the bit means<= br> positive/negative request.

If the GET with option of positive request, the server adds an subject to observe.;
if the GET with option of negtive request, the server will delete the
subject.
So, the negative request functiosn as cancellation.

I think that GET without observer option may have high efficiency,
but it is a little vague in terms of sematics.

regards,

Gengyu

Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Kovatsch Matthias
Sent: Tuesday, March 04, 2014 11:21 PM
To: core@ietf.org Cc: Szymon.Sasin@= arm.com ; 'Klaus Hartke (hartke@tzi.org)'
Subject: [core] Observe Cancellation

Dear list

I want to start the discussion about what to do about Observe cancellation.=
Today's session showed that we have two options to finish -observe: (i)= fix
something by the end of the week and (ii) eject the cancellation mechanism<= br> and deal with it in a separate draft.

To help finding consensus by the end of this week, I started a pro/con list=
for the possible solutions we have. Please comment, amend, etc., especially=
when you are an implementer!

RST with Last Notification MID
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
PRO
+ No re-use of active Token
+ No representation on cancel
CON
- Needs special rule to keep MIDs beyond lifetime
-- Not available over alternative transports

I think this does not work because of the alternative transports.

PUT/POST/DELETE with Observe Option
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
PRO
+ It is not a GET
CON
-- Observe is elective and unsafe methods might corrupt the resource state<= br>
I think it is a really bad idea to overload an unsafe method for this.

GET without Observe Option
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
PRO
+ Modular design based on GET
+ Already tested
CON
- Transmission of representation despite disinterest (including caches)
- Re-use of active Token
- Needs special rule to keep request the same (similar to re-registration)<= br>
The GET without Observe option allows many different implementation
strategies: first dividing into requests or responses (for the hybrid CoAP<= br> client-and-server implementations for LWM2M), first delivering a request to=
its resource before further inspection (Observe support could be added
within a resource handler implementation), having a clean processing
pipeline, ....

7.xx Control Messages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
PRO
+ No re-use of active Token (as request)
+ No representation on cancel
CON
- Still re-use of active Token for re-registration
- Control message class brings the danger of mutation into a very unRESTful=
protocol
- New class at late state (why is CoAP ping not a control message?)
- Conflict with DTLS message detection (if kept at end of 7.xx)
- Management of remote Tokens (different namespaces...) or hooks that
shortcut the protocol control flow

The control message cancellation is also useful for separate responses as well as the liveliness checks of the full liveliness draft. However, this goes beyond Observe. Observe without active cancellation still works and LWM2M could include the liveliness module to have the required active
cancellation.


Hoping for your input
Matthias

_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core
--001a11c2e458dbbe3a04f3ff94d9-- From nobody Fri Mar 7 00:56:43 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A071A010F for ; Fri, 7 Mar 2014 00:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MSGID_FROM_MTA_HEADER=0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvnDNkZaQSGH for ; Fri, 7 Mar 2014 00:56:41 -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 A103A1A0123 for ; Fri, 7 Mar 2014 00:56:40 -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.5/8.14.5) with ESMTP id s278uP3R003582; Fri, 7 Mar 2014 09:56:25 +0100 (CET) Message-Id: <201403070856.s278uP3R003582@informatik.uni-bremen.de> Received: from [172.16.22.125] (host-79-77-62-176.static.as9105.com [79.77.62.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C5E55C0C; Fri, 7 Mar 2014 09:56:24 +0100 (CET) Date: Fri, 07 Mar 2014 08:56:20 +0000 From: Olaf Bergmann To: Abhijan Bhattacharyya MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/core/JNDcHoxRW0nm_1n8pZn16AsmbDA Cc: Abhijan Bhattacharyya , core@ietf.org Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 08:56:42 -0000 VGhlIG1vcmUgSSB0aGluayBhYm91dCB0aGlzIHRoZSBsZXNzIEkgbGlrZSBvdmVybG9hZGluZyBv ZiBhbnkgbWV0aG9kLiBGb3IgbWUsIGFueSBuZXcgbWVjaGFuaXNtIHN1Y2ggYXMgdGhlIDcueHgg b3IgMC54eCB3b3VsZCBiZSB0aGUgZWFzaWVzdCB0byBpbXBsZW1lbnQuIFdpdGggR0VUIChvciB0 aGUgcG90ZW50aWFsbHnCoCBtb3N0IFJFU1RmdWwgUE9TVC9ERUxFVEUgYXBwcm9hY2gpLCB0aGUg YnVyZGVuIHdhcyBvbiB0aGUgQXBwbGljYXRpb24gd2hpbGUgdGhlIG90aGVyIG1ldGhvZHMgY291 bGQgYmUgaGFuZGxlZCBieSB0aGUgbWVzc2FnZSBwcm9jZXNzb3IuCgpCZXN0IHJlZ2FyZHMKT2xh Zg== From nobody Fri Mar 7 01:30:05 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEBF1A0282 for ; Fri, 7 Mar 2014 01:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySam-dpiwQo5 for ; Fri, 7 Mar 2014 01:29:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6913F1A0276 for ; Fri, 7 Mar 2014 01:29:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEI18739; Fri, 07 Mar 2014 09:29:52 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Mar 2014 09:29:14 +0000 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Mar 2014 09:29:51 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Fri, 7 Mar 2014 17:29:45 +0800 From: Likepeng To: Abhijan Bhattacharyya , weigengyu Thread-Topic: [core] Observe Cancellation Thread-Index: AQHPOb2cwpuMU0icTxO/RDVFtTNfYprUu7MAgACe94A= Date: Fri, 7 Mar 2014 09:29:43 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B01357@SZXEMA501-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.93.6] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B01357SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/oJwXv6aLUoyjWEWpFNZeBxnVy6s Cc: Abhijan Bhattacharyya , "core@ietf.org" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 09:30:03 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B01357SZXEMA501MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PkNhbiB3ZSB0aGluayBhYm91dCBzb21ldGhpbmcgbGlrZSBHRVQgd2l0aCBib3RoIE9ic2VydmUg YW5kIE5vLXJlc3BvbnNlIG9wdGlvbnMgdG8gaW5kaWNhdGUgY2FuY2VsbGF0aW9uPw0KDQpUaGlz IGlzIGFsc28gd2VpcmQgYW5kIGhhcyBpbXBhY3RzIHRvIHRoZSBleGlzdGluZyBPYnNlcnZlIGFu ZCBOby1yZXNwb25zZSBoYW5kbGluZyBwcm9jZXNzLg0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0K DQrlj5Hku7bkuro6IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBB YmhpamFuIEJoYXR0YWNoYXJ5eWENCuWPkemAgeaXtumXtDogMjAxNOW5tDPmnIg35pelIDc6NTYN CuaUtuS7tuS6ujogd2VpZ2VuZ3l1DQrmioTpgIE6IEFiaGlqYW4gQmhhdHRhY2hhcnl5YTsgY29y ZUBpZXRmLm9yZw0K5Li76aKYOiBSZTogW2NvcmVdIE9ic2VydmUgQ2FuY2VsbGF0aW9uDQoNCg0K Q2FuIHdlIHRoaW5rIGFib3V0IHNvbWV0aGluZyBsaWtlIEdFVCB3aXRoIGJvdGggT2JzZXJ2ZSBh bmQgTm8tcmVzcG9uc2Ugb3B0aW9ucyB0byBpbmRpY2F0ZSBjYW5jZWxsYXRpb24/IFRoaXMgd2F5 IHdlIGRvIG5vdCBuZWVkIHRvIGNoYW5nZSB0aGUgb2JzZXJ2ZSBzZW1hbnRpY3MgYW5kIGFsc28g d2lsbCBhdm9pZCB0aGUgcHJvYmxlbSBvZiBleGVjdXRpbmcgdGhlIE9ic2VydmUgY29kZSBmb3Ig ZXZlcnkgR0VUIHdpdGhvdXQgT2JzZXJ2ZS4gU29ycnkgaWYgSSBoYXZlIG1pc3NlZCBzb21ldGhp bmcgaGVyZS4NCk9uIE1hciA3LCAyMDE0IDQ6MjggQU0sICJ3ZWlnZW5neXUiIDx3ZWlnZW5neXVA YnVwdC5lZHUuY248bWFpbHRvOndlaWdlbmd5dUBidXB0LmVkdS5jbj4+IHdyb3RlOg0KSEkgYWxs LA0KDQpNeSBzdWdnZXN0aW9uIGlzIHRvIGRlZmluZSBhIGJpdCBvZiBmbGFnIGluIE9ic2VydmVy IG9wdGlvbiB0byBpZGVudGlmaWZ5IGVpdGhlciB0byBhZGQgYSBzdWJqZWN0IG9yIHRvIGRlbGV0 ZSBhIHN1YmplY3QuDQoNCkEgbWVzc2FnZSBvZiBPYnNlcnZlIG9wdGlvbiB3aXRoIHBvc2l0aXZl IHZhbHVlIGNhdXNlcyB0aGUgbm90aWZpY2F0aW9uIHJlc3BvbnNlKHMpOw0KYW5kIGEgbWVzc2Fn ZSBvZiBPYnNlcnZlIG9wdGlvbiB3aXRoIG5lZ3RpdmUgdmFsdWUgc3RvcHMgbm9maWNhdGlvbiwg YXMgYSBjYWNlbGxhdGlvbi4NCg0KUmVnYXJkcywNCg0KR2VuZ3l1DQoNCk5ldHdvcmsgVGVjaG5v bG9neSBDZW50ZXINClNjaG9vbCBvZiBDb21wdXRlcg0KQmVpamluZyBVbml2ZXJzaXR5IG9mIFBv c3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMNCg0KLS0tLS3ljp/lp4vpgq7ku7YtLS0tLSBGcm9t OiB3ZWlnZW5neXUNClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDUsIDIwMTQgMjoyOSBQTQ0KVG86 IEtvdmF0c2NoIE1hdHRoaWFzDQpTdWJqZWN0OiBSZTogW2NvcmVdIE9ic2VydmUgQ2FuY2VsbGF0 aW9uDQoNCkhpIE1hdHRoaWFzLA0KDQpNeSBzdWdnZ2VzdGlvbiBpcyB0byBkZWZpbmUgYSBiaXQg b2YgZmxhZyBpbiBvYnNlcnZlIG9wdGlvbiwgdGhlIGJpdCBtZWFucw0KcG9zaXRpdmUvbmVnYXRp dmUgcmVxdWVzdC4NCg0KSWYgdGhlIEdFVCB3aXRoIG9wdGlvbiBvZiBwb3NpdGl2ZSByZXF1ZXN0 LCB0aGUgc2VydmVyIGFkZHMgYW4gc3ViamVjdCB0bw0Kb2JzZXJ2ZS47DQppZiB0aGUgR0VUIHdp dGggb3B0aW9uIG9mIG5lZ3RpdmUgcmVxdWVzdCwgdGhlIHNlcnZlciB3aWxsIGRlbGV0ZSB0aGUN CnN1YmplY3QuDQpTbywgdGhlIG5lZ2F0aXZlIHJlcXVlc3QgZnVuY3Rpb3NuIGFzIGNhbmNlbGxh dGlvbi4NCg0KSSB0aGluayB0aGF0IEdFVCB3aXRob3V0IG9ic2VydmVyIG9wdGlvbiBtYXkgaGF2 ZSBoaWdoIGVmZmljaWVuY3ksDQpidXQgaXQgaXMgYSBsaXR0bGUgdmFndWUgaW4gdGVybXMgb2Yg c2VtYXRpY3MuDQoNCnJlZ2FyZHMsDQoNCkdlbmd5dQ0KDQpOZXR3b3JrIFRlY2hub2xvZ3kgQ2Vu dGVyDQpTY2hvb2wgb2YgQ29tcHV0ZXINCkJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyBhbmQg VGVsZWNvbW11bmljYXRpb25zDQoNCi0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0gRnJvbTogS292YXRz Y2ggTWF0dGhpYXMNClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDA0LCAyMDE0IDExOjIxIFBNDQpUbzog Y29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4NCkNjOiBTenltb24uU2FzaW5AYXJt LmNvbTxtYWlsdG86U3p5bW9uLlNhc2luQGFybS5jb20+IDsgJ0tsYXVzIEhhcnRrZSAoaGFydGtl QHR6aS5vcmc8bWFpbHRvOmhhcnRrZUB0emkub3JnPiknDQpTdWJqZWN0OiBbY29yZV0gT2JzZXJ2 ZSBDYW5jZWxsYXRpb24NCg0KRGVhciBsaXN0DQoNCkkgd2FudCB0byBzdGFydCB0aGUgZGlzY3Vz c2lvbiBhYm91dCB3aGF0IHRvIGRvIGFib3V0IE9ic2VydmUgY2FuY2VsbGF0aW9uLg0KVG9kYXkn cyBzZXNzaW9uIHNob3dlZCB0aGF0IHdlIGhhdmUgdHdvIG9wdGlvbnMgdG8gZmluaXNoIC1vYnNl cnZlOiAoaSkgZml4DQpzb21ldGhpbmcgYnkgdGhlIGVuZCBvZiB0aGUgd2VlayBhbmQgKGlpKSBl amVjdCB0aGUgY2FuY2VsbGF0aW9uIG1lY2hhbmlzbQ0KYW5kIGRlYWwgd2l0aCBpdCBpbiBhIHNl cGFyYXRlIGRyYWZ0Lg0KDQpUbyBoZWxwIGZpbmRpbmcgY29uc2Vuc3VzIGJ5IHRoZSBlbmQgb2Yg dGhpcyB3ZWVrLCBJIHN0YXJ0ZWQgYSBwcm8vY29uIGxpc3QNCmZvciB0aGUgcG9zc2libGUgc29s dXRpb25zIHdlIGhhdmUuIFBsZWFzZSBjb21tZW50LCBhbWVuZCwgZXRjLiwgZXNwZWNpYWxseQ0K d2hlbiB5b3UgYXJlIGFuIGltcGxlbWVudGVyIQ0KDQpSU1Qgd2l0aCBMYXN0IE5vdGlmaWNhdGlv biBNSUQNCj09PT09PT09PT09PT09PT09PT09PT09DQpQUk8NCisgTm8gcmUtdXNlIG9mIGFjdGl2 ZSBUb2tlbg0KKyBObyByZXByZXNlbnRhdGlvbiBvbiBjYW5jZWwNCkNPTg0KLSBOZWVkcyBzcGVj aWFsIHJ1bGUgdG8ga2VlcCBNSURzIGJleW9uZCBsaWZldGltZQ0KLS0gTm90IGF2YWlsYWJsZSBv dmVyIGFsdGVybmF0aXZlIHRyYW5zcG9ydHMNCg0KSSB0aGluayB0aGlzIGRvZXMgbm90IHdvcmsg YmVjYXVzZSBvZiB0aGUgYWx0ZXJuYXRpdmUgdHJhbnNwb3J0cy4NCg0KUFVUL1BPU1QvREVMRVRF IHdpdGggT2JzZXJ2ZSBPcHRpb24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUFJP DQorIEl0IGlzIG5vdCBhIEdFVA0KQ09ODQotLSBPYnNlcnZlIGlzIGVsZWN0aXZlIGFuZCB1bnNh ZmUgbWV0aG9kcyBtaWdodCBjb3JydXB0IHRoZSByZXNvdXJjZSBzdGF0ZQ0KDQpJIHRoaW5rIGl0 IGlzIGEgcmVhbGx5IGJhZCBpZGVhIHRvIG92ZXJsb2FkIGFuIHVuc2FmZSBtZXRob2QgZm9yIHRo aXMuDQoNCkdFVCB3aXRob3V0IE9ic2VydmUgT3B0aW9uDQo9PT09PT09PT09PT09PT09PT09PT09 DQpQUk8NCisgTW9kdWxhciBkZXNpZ24gYmFzZWQgb24gR0VUDQorIEFscmVhZHkgdGVzdGVkDQpD T04NCi0gVHJhbnNtaXNzaW9uIG9mIHJlcHJlc2VudGF0aW9uIGRlc3BpdGUgZGlzaW50ZXJlc3Qg KGluY2x1ZGluZyBjYWNoZXMpDQotIFJlLXVzZSBvZiBhY3RpdmUgVG9rZW4NCi0gTmVlZHMgc3Bl Y2lhbCBydWxlIHRvIGtlZXAgcmVxdWVzdCB0aGUgc2FtZSAoc2ltaWxhciB0byByZS1yZWdpc3Ry YXRpb24pDQoNClRoZSBHRVQgd2l0aG91dCBPYnNlcnZlIG9wdGlvbiBhbGxvd3MgbWFueSBkaWZm ZXJlbnQgaW1wbGVtZW50YXRpb24NCnN0cmF0ZWdpZXM6IGZpcnN0IGRpdmlkaW5nIGludG8gcmVx dWVzdHMgb3IgcmVzcG9uc2VzIChmb3IgdGhlIGh5YnJpZCBDb0FQDQpjbGllbnQtYW5kLXNlcnZl ciBpbXBsZW1lbnRhdGlvbnMgZm9yIExXTTJNKSwgZmlyc3QgZGVsaXZlcmluZyBhIHJlcXVlc3Qg dG8NCml0cyByZXNvdXJjZSBiZWZvcmUgZnVydGhlciBpbnNwZWN0aW9uIChPYnNlcnZlIHN1cHBv cnQgY291bGQgYmUgYWRkZWQNCndpdGhpbiBhIHJlc291cmNlIGhhbmRsZXIgaW1wbGVtZW50YXRp b24pLCBoYXZpbmcgYSBjbGVhbiBwcm9jZXNzaW5nDQpwaXBlbGluZSwgLi4uLg0KDQo3Lnh4IENv bnRyb2wgTWVzc2FnZXMNCj09PT09PT09PT09PT09PT09DQpQUk8NCisgTm8gcmUtdXNlIG9mIGFj dGl2ZSBUb2tlbiAoYXMgcmVxdWVzdCkNCisgTm8gcmVwcmVzZW50YXRpb24gb24gY2FuY2VsDQpD T04NCi0gU3RpbGwgcmUtdXNlIG9mIGFjdGl2ZSBUb2tlbiBmb3IgcmUtcmVnaXN0cmF0aW9uDQot IENvbnRyb2wgbWVzc2FnZSBjbGFzcyBicmluZ3MgdGhlIGRhbmdlciBvZiBtdXRhdGlvbiBpbnRv IGEgdmVyeSB1blJFU1RmdWwNCnByb3RvY29sDQotIE5ldyBjbGFzcyBhdCBsYXRlIHN0YXRlICh3 aHkgaXMgQ29BUCBwaW5nIG5vdCBhIGNvbnRyb2wgbWVzc2FnZT8pDQotIENvbmZsaWN0IHdpdGgg RFRMUyBtZXNzYWdlIGRldGVjdGlvbiAoaWYga2VwdCBhdCBlbmQgb2YgNy54eCkNCi0gTWFuYWdl bWVudCBvZiByZW1vdGUgVG9rZW5zIChkaWZmZXJlbnQgbmFtZXNwYWNlcy4uLikgb3IgaG9va3Mg dGhhdA0Kc2hvcnRjdXQgdGhlIHByb3RvY29sIGNvbnRyb2wgZmxvdw0KDQpUaGUgY29udHJvbCBt ZXNzYWdlIGNhbmNlbGxhdGlvbiBpcyBhbHNvIHVzZWZ1bCBmb3Igc2VwYXJhdGUgcmVzcG9uc2Vz IGFzDQp3ZWxsIGFzIHRoZSBsaXZlbGluZXNzIGNoZWNrcyBvZiB0aGUgZnVsbCBsaXZlbGluZXNz IGRyYWZ0LiBIb3dldmVyLCB0aGlzDQpnb2VzIGJleW9uZCBPYnNlcnZlLiBPYnNlcnZlIHdpdGhv dXQgYWN0aXZlIGNhbmNlbGxhdGlvbiBzdGlsbCB3b3JrcyBhbmQNCkxXTTJNIGNvdWxkIGluY2x1 ZGUgdGhlIGxpdmVsaW5lc3MgbW9kdWxlIHRvIGhhdmUgdGhlIHJlcXVpcmVkIGFjdGl2ZQ0KY2Fu Y2VsbGF0aW9uLg0KDQoNCkhvcGluZyBmb3IgeW91ciBpbnB1dA0KTWF0dGhpYXMNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBs aXN0DQpjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmc8bWFp bHRvOmNvcmVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NvcmUNCg== --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B01357SZXEMA501MBSchi_ 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 CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7Q2FuIHdlIHRoaW5rIGFib3V0 IHNvbWV0aGluZyBsaWtlIEdFVCB3aXRoIGJvdGggT2JzZXJ2ZSBhbmQgTm8tcmVzcG9uc2Ugb3B0 aW9ucyB0byBpbmRpY2F0ZSBjYW5jZWxsYXRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoaXMgaXMgYWxzbyB3ZWlyZCBhbmQgaGFzIGltcGFjdHMgdG8gdGhlIGV4aXN0 aW5nIE9ic2VydmUgYW5kIE5vLXJlc3BvbnNlIGhhbmRsaW5nIHByb2Nlc3MuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPktpbmQgUmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+S2VwZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiBjb3JlIFtt YWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij7ku6PooaggPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPkFiaGlqYW4gQmhhdHRhY2hhcnl5YTxicj4NCjwvc3Bhbj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4t VVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiAyMDE0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lubQ8 c3BhbiBsYW5nPSJFTi1VUyI+Mzwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+Nzwvc3Bhbj7m l6U8c3BhbiBsYW5nPSJFTi1VUyI+IDc6NTY8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4g bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gd2VpZ2VuZ3l1PGJy Pg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyI+IEFiaGlqYW4gQmhhdHRhY2hhcnl5YTsgY29yZUBpZXRmLm9yZzxicj4NCjwv c3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiPiBSZTogW2NvcmVdIE9ic2VydmUgQ2FuY2VsbGF0aW9uPG86cD48L286cD48L3NwYW4+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5D YW4gd2UgdGhpbmsgYWJvdXQgc29tZXRoaW5nIGxpa2UgR0VUIHdpdGggYm90aCBPYnNlcnZlIGFu ZCBOby1yZXNwb25zZSBvcHRpb25zIHRvIGluZGljYXRlIGNhbmNlbGxhdGlvbj8gVGhpcyB3YXkg d2UgZG8gbm90IG5lZWQgdG8gY2hhbmdlIHRoZSBvYnNlcnZlIHNlbWFudGljcyBhbmQgYWxzbyB3 aWxsIGF2b2lkIHRoZSBwcm9ibGVtIG9mIGV4ZWN1dGluZyB0aGUgT2JzZXJ2ZSBjb2RlIGZvciBl dmVyeSBHRVQNCiB3aXRob3V0IE9ic2VydmUuIFNvcnJ5IGlmIEkgaGF2ZSBtaXNzZWQgc29tZXRo aW5nIGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBNYXIgNywgMjAxNCA0OjI4IEFNLCAmcXVvdDt3ZWln ZW5neXUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp3ZWlnZW5neXVAYnVwdC5lZHUuY24iPndl aWdlbmd5dUBidXB0LmVkdS5jbjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5ISSBhbGwsPGJyPg0KPGJy Pg0KTXkgc3VnZ2VzdGlvbiBpcyB0byBkZWZpbmUgYSBiaXQgb2YgZmxhZyBpbiBPYnNlcnZlciBv cHRpb24gdG8gaWRlbnRpZmlmeSBlaXRoZXIgdG8gYWRkIGEgc3ViamVjdCBvciB0byBkZWxldGUg YSBzdWJqZWN0Ljxicj4NCjxicj4NCkEgbWVzc2FnZSBvZiBPYnNlcnZlIG9wdGlvbiB3aXRoIHBv c2l0aXZlIHZhbHVlIGNhdXNlcyB0aGUgbm90aWZpY2F0aW9uIHJlc3BvbnNlKHMpOzxicj4NCmFu ZCBhIG1lc3NhZ2Ugb2YgT2JzZXJ2ZSBvcHRpb24gd2l0aCBuZWd0aXZlIHZhbHVlIHN0b3BzIG5v ZmljYXRpb24sIGFzIGEgY2FjZWxsYXRpb24uPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+ DQpHZW5neXU8YnI+DQo8YnI+DQpOZXR3b3JrIFRlY2hub2xvZ3kgQ2VudGVyPGJyPg0KU2Nob29s IG9mIENvbXB1dGVyPGJyPg0KQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29t bXVuaWNhdGlvbnM8YnI+DQo8YnI+DQotLS0tLTwvc3Bhbj7ljp/lp4vpgq7ku7Y8c3BhbiBsYW5n PSJFTi1VUyI+LS0tLS0gRnJvbTogd2VpZ2VuZ3l1PGJyPg0KU2VudDogV2VkbmVzZGF5LCBNYXJj aCAwNSwgMjAxNCAyOjI5IFBNPGJyPg0KVG86IEtvdmF0c2NoIE1hdHRoaWFzPGJyPg0KU3ViamVj dDogUmU6IFtjb3JlXSBPYnNlcnZlIENhbmNlbGxhdGlvbjxicj4NCjxicj4NCkhpIE1hdHRoaWFz LDxicj4NCjxicj4NCk15IHN1Z2dnZXN0aW9uIGlzIHRvIGRlZmluZSBhIGJpdCBvZiBmbGFnIGlu IG9ic2VydmUgb3B0aW9uLCB0aGUgYml0IG1lYW5zPGJyPg0KcG9zaXRpdmUvbmVnYXRpdmUgcmVx dWVzdC48YnI+DQo8YnI+DQpJZiB0aGUgR0VUIHdpdGggb3B0aW9uIG9mIHBvc2l0aXZlIHJlcXVl c3QsIHRoZSBzZXJ2ZXIgYWRkcyBhbiBzdWJqZWN0IHRvPGJyPg0Kb2JzZXJ2ZS47PGJyPg0KaWYg dGhlIEdFVCB3aXRoIG9wdGlvbiBvZiBuZWd0aXZlIHJlcXVlc3QsIHRoZSBzZXJ2ZXIgd2lsbCBk ZWxldGUgdGhlPGJyPg0Kc3ViamVjdC48YnI+DQpTbywgdGhlIG5lZ2F0aXZlIHJlcXVlc3QgZnVu Y3Rpb3NuIGFzIGNhbmNlbGxhdGlvbi48YnI+DQo8YnI+DQpJIHRoaW5rIHRoYXQgR0VUIHdpdGhv dXQgb2JzZXJ2ZXIgb3B0aW9uIG1heSBoYXZlIGhpZ2ggZWZmaWNpZW5jeSw8YnI+DQpidXQgaXQg aXMgYSBsaXR0bGUgdmFndWUgaW4gdGVybXMgb2Ygc2VtYXRpY3MuPGJyPg0KPGJyPg0KcmVnYXJk cyw8YnI+DQo8YnI+DQpHZW5neXU8YnI+DQo8YnI+DQpOZXR3b3JrIFRlY2hub2xvZ3kgQ2VudGVy PGJyPg0KU2Nob29sIG9mIENvbXB1dGVyPGJyPg0KQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3Rz IGFuZCBUZWxlY29tbXVuaWNhdGlvbnM8YnI+DQo8YnI+DQotLS0tLTwvc3Bhbj7ljp/lp4vpgq7k u7Y8c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS0gRnJvbTogS292YXRzY2ggTWF0dGhpYXM8YnI+DQpT ZW50OiBUdWVzZGF5LCBNYXJjaCAwNCwgMjAxNCAxMToyMSBQTTxicj4NClRvOiA8YSBocmVmPSJt YWlsdG86Y29yZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNvcmVAaWV0Zi5vcmc8L2E+PGJy Pg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpTenltb24uU2FzaW5AYXJtLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPlN6eW1vbi5TYXNpbkBhcm0uY29tPC9hPiA7ICdLbGF1cyBIYXJ0a2UgKDxhIGhyZWY9Im1h aWx0bzpoYXJ0a2VAdHppLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmhhcnRrZUB0emkub3JnPC9hPikn PGJyPg0KU3ViamVjdDogW2NvcmVdIE9ic2VydmUgQ2FuY2VsbGF0aW9uPGJyPg0KPGJyPg0KRGVh ciBsaXN0PGJyPg0KPGJyPg0KSSB3YW50IHRvIHN0YXJ0IHRoZSBkaXNjdXNzaW9uIGFib3V0IHdo YXQgdG8gZG8gYWJvdXQgT2JzZXJ2ZSBjYW5jZWxsYXRpb24uPGJyPg0KVG9kYXkncyBzZXNzaW9u IHNob3dlZCB0aGF0IHdlIGhhdmUgdHdvIG9wdGlvbnMgdG8gZmluaXNoIC1vYnNlcnZlOiAoaSkg Zml4PGJyPg0Kc29tZXRoaW5nIGJ5IHRoZSBlbmQgb2YgdGhlIHdlZWsgYW5kIChpaSkgZWplY3Qg dGhlIGNhbmNlbGxhdGlvbiBtZWNoYW5pc208YnI+DQphbmQgZGVhbCB3aXRoIGl0IGluIGEgc2Vw YXJhdGUgZHJhZnQuPGJyPg0KPGJyPg0KVG8gaGVscCBmaW5kaW5nIGNvbnNlbnN1cyBieSB0aGUg ZW5kIG9mIHRoaXMgd2VlaywgSSBzdGFydGVkIGEgcHJvL2NvbiBsaXN0PGJyPg0KZm9yIHRoZSBw b3NzaWJsZSBzb2x1dGlvbnMgd2UgaGF2ZS4gUGxlYXNlIGNvbW1lbnQsIGFtZW5kLCBldGMuLCBl c3BlY2lhbGx5PGJyPg0Kd2hlbiB5b3UgYXJlIGFuIGltcGxlbWVudGVyITxicj4NCjxicj4NClJT VCB3aXRoIExhc3QgTm90aWZpY2F0aW9uIE1JRDxicj4NCj09PT09PT09PT09PT09PT09PT09PT09 PGJyPg0KUFJPPGJyPg0KJiM0MzsgTm8gcmUtdXNlIG9mIGFjdGl2ZSBUb2tlbjxicj4NCiYjNDM7 IE5vIHJlcHJlc2VudGF0aW9uIG9uIGNhbmNlbDxicj4NCkNPTjxicj4NCi0gTmVlZHMgc3BlY2lh bCBydWxlIHRvIGtlZXAgTUlEcyBiZXlvbmQgbGlmZXRpbWU8YnI+DQotLSBOb3QgYXZhaWxhYmxl IG92ZXIgYWx0ZXJuYXRpdmUgdHJhbnNwb3J0czxicj4NCjxicj4NCkkgdGhpbmsgdGhpcyBkb2Vz IG5vdCB3b3JrIGJlY2F1c2Ugb2YgdGhlIGFsdGVybmF0aXZlIHRyYW5zcG9ydHMuPGJyPg0KPGJy Pg0KUFVUL1BPU1QvREVMRVRFIHdpdGggT2JzZXJ2ZSBPcHRpb248YnI+DQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT08YnI+DQpQUk88YnI+DQomIzQzOyBJdCBpcyBub3QgYSBHRVQ8YnI+ DQpDT048YnI+DQotLSBPYnNlcnZlIGlzIGVsZWN0aXZlIGFuZCB1bnNhZmUgbWV0aG9kcyBtaWdo dCBjb3JydXB0IHRoZSByZXNvdXJjZSBzdGF0ZTxicj4NCjxicj4NCkkgdGhpbmsgaXQgaXMgYSBy ZWFsbHkgYmFkIGlkZWEgdG8gb3ZlcmxvYWQgYW4gdW5zYWZlIG1ldGhvZCBmb3IgdGhpcy48YnI+ DQo8YnI+DQpHRVQgd2l0aG91dCBPYnNlcnZlIE9wdGlvbjxicj4NCj09PT09PT09PT09PT09PT09 PT09PT08YnI+DQpQUk88YnI+DQomIzQzOyBNb2R1bGFyIGRlc2lnbiBiYXNlZCBvbiBHRVQ8YnI+ DQomIzQzOyBBbHJlYWR5IHRlc3RlZDxicj4NCkNPTjxicj4NCi0gVHJhbnNtaXNzaW9uIG9mIHJl cHJlc2VudGF0aW9uIGRlc3BpdGUgZGlzaW50ZXJlc3QgKGluY2x1ZGluZyBjYWNoZXMpPGJyPg0K LSBSZS11c2Ugb2YgYWN0aXZlIFRva2VuPGJyPg0KLSBOZWVkcyBzcGVjaWFsIHJ1bGUgdG8ga2Vl cCByZXF1ZXN0IHRoZSBzYW1lIChzaW1pbGFyIHRvIHJlLXJlZ2lzdHJhdGlvbik8YnI+DQo8YnI+ DQpUaGUgR0VUIHdpdGhvdXQgT2JzZXJ2ZSBvcHRpb24gYWxsb3dzIG1hbnkgZGlmZmVyZW50IGlt cGxlbWVudGF0aW9uPGJyPg0Kc3RyYXRlZ2llczogZmlyc3QgZGl2aWRpbmcgaW50byByZXF1ZXN0 cyBvciByZXNwb25zZXMgKGZvciB0aGUgaHlicmlkIENvQVA8YnI+DQpjbGllbnQtYW5kLXNlcnZl ciBpbXBsZW1lbnRhdGlvbnMgZm9yIExXTTJNKSwgZmlyc3QgZGVsaXZlcmluZyBhIHJlcXVlc3Qg dG88YnI+DQppdHMgcmVzb3VyY2UgYmVmb3JlIGZ1cnRoZXIgaW5zcGVjdGlvbiAoT2JzZXJ2ZSBz dXBwb3J0IGNvdWxkIGJlIGFkZGVkPGJyPg0Kd2l0aGluIGEgcmVzb3VyY2UgaGFuZGxlciBpbXBs ZW1lbnRhdGlvbiksIGhhdmluZyBhIGNsZWFuIHByb2Nlc3Npbmc8YnI+DQpwaXBlbGluZSwgLi4u Ljxicj4NCjxicj4NCjcueHggQ29udHJvbCBNZXNzYWdlczxicj4NCj09PT09PT09PT09PT09PT09 PGJyPg0KUFJPPGJyPg0KJiM0MzsgTm8gcmUtdXNlIG9mIGFjdGl2ZSBUb2tlbiAoYXMgcmVxdWVz dCk8YnI+DQomIzQzOyBObyByZXByZXNlbnRhdGlvbiBvbiBjYW5jZWw8YnI+DQpDT048YnI+DQot IFN0aWxsIHJlLXVzZSBvZiBhY3RpdmUgVG9rZW4gZm9yIHJlLXJlZ2lzdHJhdGlvbjxicj4NCi0g Q29udHJvbCBtZXNzYWdlIGNsYXNzIGJyaW5ncyB0aGUgZGFuZ2VyIG9mIG11dGF0aW9uIGludG8g YSB2ZXJ5IHVuUkVTVGZ1bDxicj4NCnByb3RvY29sPGJyPg0KLSBOZXcgY2xhc3MgYXQgbGF0ZSBz dGF0ZSAod2h5IGlzIENvQVAgcGluZyBub3QgYSBjb250cm9sIG1lc3NhZ2U/KTxicj4NCi0gQ29u ZmxpY3Qgd2l0aCBEVExTIG1lc3NhZ2UgZGV0ZWN0aW9uIChpZiBrZXB0IGF0IGVuZCBvZiA3Lnh4 KTxicj4NCi0gTWFuYWdlbWVudCBvZiByZW1vdGUgVG9rZW5zIChkaWZmZXJlbnQgbmFtZXNwYWNl cy4uLikgb3IgaG9va3MgdGhhdDxicj4NCnNob3J0Y3V0IHRoZSBwcm90b2NvbCBjb250cm9sIGZs b3c8YnI+DQo8YnI+DQpUaGUgY29udHJvbCBtZXNzYWdlIGNhbmNlbGxhdGlvbiBpcyBhbHNvIHVz ZWZ1bCBmb3Igc2VwYXJhdGUgcmVzcG9uc2VzIGFzPGJyPg0Kd2VsbCBhcyB0aGUgbGl2ZWxpbmVz cyBjaGVja3Mgb2YgdGhlIGZ1bGwgbGl2ZWxpbmVzcyBkcmFmdC4gSG93ZXZlciwgdGhpczxicj4N CmdvZXMgYmV5b25kIE9ic2VydmUuIE9ic2VydmUgd2l0aG91dCBhY3RpdmUgY2FuY2VsbGF0aW9u IHN0aWxsIHdvcmtzIGFuZDxicj4NCkxXTTJNIGNvdWxkIGluY2x1ZGUgdGhlIGxpdmVsaW5lc3Mg bW9kdWxlIHRvIGhhdmUgdGhlIHJlcXVpcmVkIGFjdGl2ZTxicj4NCmNhbmNlbGxhdGlvbi48YnI+ DQo8YnI+DQo8YnI+DQpIb3BpbmcgZm9yIHlvdXIgaW5wdXQ8YnI+DQpNYXR0aGlhczxicj4NCjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Y29yZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPC9hPg0KPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpjb3JlIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y29y ZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NvcmUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NvcmU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B01357SZXEMA501MBSchi_-- From nobody Fri Mar 7 01:46:24 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EB91A02BB for ; Fri, 7 Mar 2014 01:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzWY21vfV0i1 for ; Fri, 7 Mar 2014 01:46:18 -0800 (PST) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 42C921A02AC for ; Fri, 7 Mar 2014 01:46:18 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id g12so3847022oah.22 for ; Fri, 07 Mar 2014 01:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zWdbVJC4TYVsumC440+Ts88eRXZYIr0CVv2Ut1aHiT8=; b=sGLfI3/gjHtupnwdGaF4Pt+arcSr2yZQy5+kC7WgftaAyLcq8dALaaAsKEyC1G9ddS na+ue14XZ62DLfQ89uSGuiZaPnDJ00WZkD8YgFhceRuGwvmAmIoBAiRgkwp/AK2ZjpNe 6mYgJOhPYzGQs2B/kOu6u1xGLy25mW3SNpLPLK6CT1IQFy9K90qKUowhZNnGt6qBasbF Fj4pdiNcx2FttRhMRitc/12PZKlEKDGZWyAIZd+jSoOAh95dq/Ko1D1MJoAlp4Mk3Tvc cVfmkHrQSKnDxk2OpEzr1wfVobwVsAU9GJj9HPIaNDKSgS9XKFeq2Z0jpDPXcAKpDLL/ CuMQ== MIME-Version: 1.0 X-Received: by 10.182.120.40 with SMTP id kz8mr14543389obb.6.1394185574007; Fri, 07 Mar 2014 01:46:14 -0800 (PST) Received: by 10.76.79.195 with HTTP; Fri, 7 Mar 2014 01:46:13 -0800 (PST) In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252B01357@SZXEMA501-MBS.china.huawei.com> References: <34966E97BE8AD64EAE9D3D6E4DEE36F252B01357@SZXEMA501-MBS.china.huawei.com> Date: Fri, 7 Mar 2014 15:16:13 +0530 Message-ID: From: Abhijan Bhattacharyya To: Likepeng Content-Type: multipart/alternative; boundary=089e0139fc3ae3cbc204f4011ff6 Archived-At: http://mailarchive.ietf.org/arch/msg/core/D9T_kPFk9dpLmFvRC30Sc9YVgiE Cc: Abhijan Bhattacharyya , "core@ietf.org" Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 09:46:21 -0000 --089e0139fc3ae3cbc204f4011ff6 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Well, so far as No-Response is concerned, the draft is still a work in progress and very much open to new use cases. On Fri, Mar 7, 2014 at 2:59 PM, Likepeng wrote: > >Can we think about something like GET with both Observe and No-response > options to indicate cancellation? > > > > This is also weird and has impacts to the existing Observe and No-respons= e > handling process. > > > > Kind Regards > > Kepeng > > > > *=B7=A2=BC=FE=C8=CB:* core [mailto:core-bounces@ietf.org] *=B4=FA=B1=ED *= Abhijan Bhattacharyya > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2014=C4=EA3=D4=C27=C8=D5 7:56 > *=CA=D5=BC=FE=C8=CB:* weigengyu > *=B3=AD=CB=CD:* Abhijan Bhattacharyya; core@ietf.org > *=D6=F7=CC=E2:* Re: [core] Observe Cancellation > > > > Can we think about something like GET with both Observe and No-response > options to indicate cancellation? This way we do not need to change the > observe semantics and also will avoid the problem of executing the Observ= e > code for every GET without Observe. Sorry if I have missed something here= . > > On Mar 7, 2014 4:28 AM, "weigengyu" wrote: > > HI all, > > My suggestion is to define a bit of flag in Observer option to identifify > either to add a subject or to delete a subject. > > A message of Observe option with positive value causes the notification > response(s); > and a message of Observe option with negtive value stops nofication, as a > cacellation. > > Regards, > > Gengyu > > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > > -----=D4=AD=CA=BC=D3=CA=BC=FE----- From: weigengyu > Sent: Wednesday, March 05, 2014 2:29 PM > To: Kovatsch Matthias > Subject: Re: [core] Observe Cancellation > > Hi Matthias, > > My sugggestion is to define a bit of flag in observe option, the bit mean= s > positive/negative request. > > If the GET with option of positive request, the server adds an subject to > observe.; > if the GET with option of negtive request, the server will delete the > subject. > So, the negative request functiosn as cancellation. > > I think that GET without observer option may have high efficiency, > but it is a little vague in terms of sematics. > > regards, > > Gengyu > > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > > -----=D4=AD=CA=BC=D3=CA=BC=FE----- From: Kovatsch Matthias > Sent: Tuesday, March 04, 2014 11:21 PM > To: core@ietf.org > Cc: Szymon.Sasin@arm.com ; 'Klaus Hartke (hartke@tzi.org)' > Subject: [core] Observe Cancellation > > Dear list > > I want to start the discussion about what to do about Observe cancellatio= n. > Today's session showed that we have two options to finish -observe: (i) f= ix > something by the end of the week and (ii) eject the cancellation mechanis= m > and deal with it in a separate draft. > > To help finding consensus by the end of this week, I started a pro/con li= st > for the possible solutions we have. Please comment, amend, etc., especial= ly > when you are an implementer! > > RST with Last Notification MID > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > PRO > + No re-use of active Token > + No representation on cancel > CON > - Needs special rule to keep MIDs beyond lifetime > -- Not available over alternative transports > > I think this does not work because of the alternative transports. > > PUT/POST/DELETE with Observe Option > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > PRO > + It is not a GET > CON > -- Observe is elective and unsafe methods might corrupt the resource stat= e > > I think it is a really bad idea to overload an unsafe method for this. > > GET without Observe Option > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > PRO > + Modular design based on GET > + Already tested > CON > - Transmission of representation despite disinterest (including caches) > - Re-use of active Token > - Needs special rule to keep request the same (similar to re-registration= ) > > The GET without Observe option allows many different implementation > strategies: first dividing into requests or responses (for the hybrid CoA= P > client-and-server implementations for LWM2M), first delivering a request = to > its resource before further inspection (Observe support could be added > within a resource handler implementation), having a clean processing > pipeline, .... > > 7.xx Control Messages > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > PRO > + No re-use of active Token (as request) > + No representation on cancel > CON > - Still re-use of active Token for re-registration > - Control message class brings the danger of mutation into a very unRESTf= ul > protocol > - New class at late state (why is CoAP ping not a control message?) > - Conflict with DTLS message detection (if kept at end of 7.xx) > - Management of remote Tokens (different namespaces...) or hooks that > shortcut the protocol control flow > > The control message cancellation is also useful for separate responses as > well as the liveliness checks of the full liveliness draft. However, this > goes beyond Observe. Observe without active cancellation still works and > LWM2M could include the liveliness module to have the required active > cancellation. > > > Hoping for your input > Matthias > > _______________________________________________ > 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 > --089e0139fc3ae3cbc204f4011ff6 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Well, so far as No-Response is concerned, the draft is sti= ll a work in progress and very much open to new use cases.  


On Fri, Mar 7, 20= 14 at 2:59 PM, Likepeng <likepeng@huawei.com> wrote:

>Can we= think about something like GET with both Observe and No-response options t= o indicate cancellation?

&nb= sp;

This= is also weird and has impacts to the existing Observe and No-response hand= ling process.

&nb= sp;

Kind Regar= ds

Kepeng<= /u>

&nb= sp;

=B7=A2=BC=FE=C8= =CB: core [mailto:core-bounces@ietf.org] =B4=FA=B1=ED Abhijan Bhattacharyya
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA3=D4=C27=C8=D5 7:= 56
=CA=D5=BC=FE=C8=CB: weigengyu
=B3=AD=CB=CD: Abhijan Bhattacharyya; core@ietf.org
=D6=F7=CC=E2: Re: [core] Observe Cancellation

 

Can we think about something like GET with both Obs= erve and No-response options to indicate cancellation? This way we do not n= eed to change the observe semantics and also will avoid the problem of exec= uting the Observe code for every GET without Observe. Sorry if I have missed something here.

On Mar 7, 2014 4:28 AM, "w= eigengyu" <weigengyu@bupt.edu.cn> wrote:

HI all,

My suggestion is to define a bit of flag in Observer option to identifify e= ither to add a subject or to delete a subject.

A message of Observe option with positive value causes the notification res= ponse(s);
and a message of Observe option with negtive value stops nofication, as a c= acellation.

Regards,

Gengyu

Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

-----=D4=AD=CA=BC=D3=CA=BC=FE----- From: weigen= gyu
Sent: Wednesday, March 05, 2014 2:29 PM
To: Kovatsch Matthias
Subject: Re: [core] Observe Cancellation

Hi Matthias,

My sugggestion is to define a bit of flag in observe option, the bit means<= br> positive/negative request.

If the GET with option of positive request, the server adds an subject to observe.;
if the GET with option of negtive request, the server will delete the
subject.
So, the negative request functiosn as cancellation.

I think that GET without observer option may have high efficiency,
but it is a little vague in terms of sematics.

regards,

Gengyu

Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

-----=D4=AD=CA=BC=D3=CA=BC=FE----- From: Kovats= ch Matthias
Sent: Tuesday, March 04, 2014 11:21 PM
To: core@ietf.org Cc: Szymon.Sasin@= arm.com ; 'Klaus Hartke (hartke@tzi.org)'
Subject: [core] Observe Cancellation

Dear list

I want to start the discussion about what to do about Observe cancellation.=
Today's session showed that we have two options to finish -observe: (i)= fix
something by the end of the week and (ii) eject the cancellation mechanism<= br> and deal with it in a separate draft.

To help finding consensus by the end of this week, I started a pro/con list=
for the possible solutions we have. Please comment, amend, etc., especially=
when you are an implementer!

RST with Last Notification MID
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
PRO
+ No re-use of active Token
+ No representation on cancel
CON
- Needs special rule to keep MIDs beyond lifetime
-- Not available over alternative transports

I think this does not work because of the alternative transports.

PUT/POST/DELETE with Observe Option
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
PRO
+ It is not a GET
CON
-- Observe is elective and unsafe methods might corrupt the resource state<= br>
I think it is a really bad idea to overload an unsafe method for this.

GET without Observe Option
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
PRO
+ Modular design based on GET
+ Already tested
CON
- Transmission of representation despite disinterest (including caches)
- Re-use of active Token
- Needs special rule to keep request the same (similar to re-registration)<= br>
The GET without Observe option allows many different implementation
strategies: first dividing into requests or responses (for the hybrid CoAP<= br> client-and-server implementations for LWM2M), first delivering a request to=
its resource before further inspection (Observe support could be added
within a resource handler implementation), having a clean processing
pipeline, ....

7.xx Control Messages
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
PRO
+ No re-use of active Token (as request)
+ No representation on cancel
CON
- Still re-use of active Token for re-registration
- Control message class brings the danger of mutation into a very unRESTful=
protocol
- New class at late state (why is CoAP ping not a control message?)
- Conflict with DTLS message detection (if kept at end of 7.xx)
- Management of remote Tokens (different namespaces...) or hooks that
shortcut the protocol control flow

The control message cancellation is also useful for separate responses as well as the liveliness checks of the full liveliness draft. However, this goes beyond Observe. Observe without active cancellation still works and LWM2M could include the liveliness module to have the required active
cancellation.


Hoping for your input
Matthias

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


--089e0139fc3ae3cbc204f4011ff6-- From nobody Fri Mar 7 02:08:54 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402701A0133 for ; Fri, 7 Mar 2014 02:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-gu6qiSp8n8 for ; Fri, 7 Mar 2014 02:08:52 -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 D79AB1A0159 for ; Fri, 7 Mar 2014 02:08:51 -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.5/8.14.5) with ESMTP id s27A8bUj023572 for ; Fri, 7 Mar 2014 11:08:37 +0100 (CET) Received: from dhcp-9d1b.meeting.ietf.org (dhcp-9d1b.meeting.ietf.org [31.133.157.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3C98ECCB; Fri, 7 Mar 2014 11:08:37 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann Date: Fri, 7 Mar 2014 10:08:34 +0000 X-Mao-Original-Outgoing-Id: 415879714.332617-fd6d2dbddc97651ab56ea2d5af761a6c Content-Transfer-Encoding: quoted-printable Message-Id: To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/fmrOxX9B--U7Tc6maZFk57KGeh8 Subject: [core] Input for discussion of constrained management today X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 10:08:53 -0000 Bill Silverajan points out: http://urn.fi/URN:ISBN:978-952-15-3219-1 (CoAP-SNMP Interworking in IoT Scenarios) A recent result by Olaf Bergmann et al.: = http://tzi.de/~cabo/noms2014.pdf (REST-based Access to SMIv2-structured Information on Constrained = Devices) The coman drafts are: http://tools.ietf.org/html/draft-ietf-opsawg-coman-probstate-reqs-01 http://tools.ietf.org/html/draft-ietf-opsawg-coman-use-cases-01 You still have more than an hour for reading :-) Gr=FC=DFe, Carsten From nobody Fri Mar 7 02:42:02 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE7F1A012B for ; Fri, 7 Mar 2014 02:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z36vbUH4KN34 for ; Fri, 7 Mar 2014 02:41:54 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 577A11A018A for ; Fri, 7 Mar 2014 02:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s27Aflkp029761 for ; Fri, 7 Mar 2014 11:41:47 +0100 (CET) Received: from dhcp-9d1b.meeting.ietf.org (dhcp-9d1b.meeting.ietf.org [31.133.157.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E582BD2F; Fri, 7 Mar 2014 11:41:46 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann Date: Fri, 7 Mar 2014 10:41:44 +0000 X-Mao-Original-Outgoing-Id: 415881704.94752-57bf38f9b7c44de5c181bfca51cb0d7f Content-Transfer-Encoding: quoted-printable Message-Id: <309942CD-DAD7-4338-BE20-883C21BF5A9C@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/LpnU5p6q5AaNS3pjMHmRJ36xJig Subject: [core] Slides updated for Friday meeting X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 10:41:55 -0000 ... are at: = http://www.ietf.org/proceedings/89/slides/slides-89-core-0.pdf As the minutes seem to reference Tuesday=E2=80=99s slides by number, new = slides have been appended (i.e., are out of order). Slide 57 has the updated agenda: 11:50=E2=80=9311:55 Intro 11:55=E2=80=9312:10 CoAP for management part deux=20 =C2=9F12:10=E2=80=9312:25 ACE BOF post-processing =C2=9F12:25=E2=80=9313:05 -observe part deux =C2=9F13:05=E2=80=9313:15 alternate transport URIs part deux =C2=9F13:05=E2=80=9313:20 Sleep next steps (AR) =C2=9F13:05=E2=80=9313:20 Flextime The observant reader will notice that we don=E2=80=99t have all the time = we need. I hope we can get done with the items before sleepy ahead of schedule. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Mar 7 04:35:07 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5881A01E0 for ; Fri, 7 Mar 2014 04:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3w35DNrFr2T for ; Fri, 7 Mar 2014 04:35:02 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 157211A0251 for ; Fri, 7 Mar 2014 04:35:02 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 53EF4223F for ; Fri, 7 Mar 2014 13:34:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1LzGtcI-9zmx for ; Fri, 7 Mar 2014 13:34:56 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP for ; Fri, 7 Mar 2014 13:34:56 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF72A2002C for ; Fri, 7 Mar 2014 13:34:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bmBlhvG4X0GG; Fri, 7 Mar 2014 13:34:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C196020017; Fri, 7 Mar 2014 13:34:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C0B5E2BAAFFE; Fri, 7 Mar 2014 13:34:51 +0100 (CET) Date: Fri, 7 Mar 2014 13:34:51 +0100 From: Juergen Schoenwaelder To: core@ietf.org Message-ID: <20140307123451.GA69641@elstar.local> Mail-Followup-To: core@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/core/zaCGLi1x76oBJUY_i98y5Z1oBEA Subject: [core] core management pointers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 12:35:05 -0000 Hi, concerning the management of constrained devices and CoAPs potential roles in this, let me provide a few pointers. First the two COMAN documents being discussed in the OPSAWG: http://tools.ietf.org/html/draft-ietf-opsawg-coman-use-cases-01 http://tools.ietf.org/html/draft-ietf-opsawg-coman-probstate-reqs-01 The later one has a new section 1.7 which I think if very useful to distinguish different configuration and monitoring levels. CoAP based solutions may want to look at which levels they target. The NETCONF working group has been rechartered to work on RESTCONF, a REST-like protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF. http://tools.ietf.org/html/draft-bierman-netconf-restconf-04 RESTCONF is not cast into stone yet. It would be very useful to find out whether RESTCONF can be mapped to CoAP or whether any changes of RESTCONF would make such a mapping easier. I also like to repeat what I said at the meeting: what really matters a lot is reuse of data models. Integration into existing management systems becomes much easier as long as the naming and the semantics of management data received via different management protocols is the same. For monitoring, there are many definitions that can be reused and MIB data models usually work fine for defining collections of counters. For configuration, YANG data models are the recommended way to go these days. But keep in mind that configuration can mean very different things (section 1.7 in opsawg-coman-probstate-reqs). I think having a side meeting in Toronto to further discuss CoAP usage for management and how it relates to RESTCONF and existing data models and data modeling approaches is a very good idea. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Mar 7 08:26:34 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4E11A0273 for ; Fri, 7 Mar 2014 05:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_fW3ez7s-lC for ; Fri, 7 Mar 2014 05:08:08 -0800 (PST) Received: from p3plsmtpa06-10.prod.phx3.secureserver.net (p3plsmtpa06-10.prod.phx3.secureserver.net [173.201.192.111]) by ietfa.amsl.com (Postfix) with ESMTP id BB9C61A0164 for ; Fri, 7 Mar 2014 05:08:07 -0800 (PST) Received: from Study ([216.246.69.52]) by p3plsmtpa06-10.prod.phx3.secureserver.net with id ad811n00J17gBDU01d82t0; Fri, 07 Mar 2014 06:08:03 -0700 From: "Victor Blake" To: "'FOSSATI, Thomas \(Thomas\)'" , "'Bert Greevenbosch'" , References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63E4568B5@SZXEMA510-MBX.china.huawei.com> In-Reply-To: Date: Fri, 7 Mar 2014 08:08:12 -0500 Message-ID: <001701cf3a06$4c4a0d50$e4de27f0$@victorblake.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1hFNWeeAVMYfIAXgCEhKXW6QZ4wJjLR48AQZBPmwBUSzr3AKfcOO4mk4zZ9A= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/core/_XwQ9CJBmu4zi-Durn733HJTiHI X-Mailman-Approved-At: Fri, 07 Mar 2014 08:26:33 -0800 Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 13:08:09 -0000 ...And using a code isn't exactly RESTful. -Victor -----Original Message----- From: FOSSATI, Thomas (Thomas) = [mailto:thomas.fossati@alcatel-lucent.com]=20 Sent: Thursday, March 06, 2014 5:18 PM To: Bert Greevenbosch; core@ietf.org WG Subject: Re: [core] Observe Cancellation On 06/03/2014 19:39, "Bert Greevenbosch" wrote: >Some extra things that came up in this discussion and may need >consideration: > >- Using "GET without observe" to cancel an observation relationship=20 >requires executing code related to observe for every GET request, even=20 >if the client has never subscribed to the resource. >- A response may not be required, since it is enough for the=20 >observation to be cancelled on the server side, and the client may not=20 >require knowledge on the result of the deletion.* > >*) when the server receives a "cancel observation", there two >possibilities: > - the server knows the token, and deletes the related observationship > - the related observation relationship does not exist In both cases,=20 >the result is that the observation relationship does not exist on the=20 >server after receipt of the message. Another point that we=E2=80=99ve cleared is that using a code for the = cancellation in the 5-31 space doesn=E2=80=99t look quite right: "A CoAP request consists of the method to be applied to the = resource=E2=80=9D The problem is that the cancellation does not apply to a resource, but = rather to the state that encodes the relationship between the client, = the server, and a resource. From nobody Fri Mar 7 08:31:00 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D8B1A02BD for ; Fri, 7 Mar 2014 08:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hA5THAdae6zm for ; Fri, 7 Mar 2014 08:30:57 -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 B5DF01A02AE for ; Fri, 7 Mar 2014 08:30: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.5/8.14.5) with ESMTP id s27GUZQ4012009; Fri, 7 Mar 2014 17:30:35 +0100 (CET) Received: from [10.109.74.208] (unknown [62.232.113.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 72461F5B; Fri, 7 Mar 2014 17:30:33 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <001701cf3a06$4c4a0d50$e4de27f0$@victorblake.com> Date: Fri, 7 Mar 2014 16:30:32 +0000 X-Mao-Original-Outgoing-Id: 415902632.63652-b477c3671b53509c738e63bd901f99f7 Content-Transfer-Encoding: quoted-printable Message-Id: <14C0ACCC-C642-4077-833E-F9120E98D685@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63E4568B5@SZXEMA510-MBX.china.huawei.com> <001701cf3a06$4c4a0d50$e4de27f0$@victorblake.com> To: Victor Blake X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/xx0PgT3yVmcyVzTnkP6MJjvQLEU Cc: core@ietf.org Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 16:30:58 -0000 > ...And using a code isn't exactly RESTful. The =93code=94 is just the second byte of the message, which, depending = on content, is interpreted as an empty message indicator (0.00), a = method (0.xx), or a response code (y.xx). What is not RESTful about this method of encoding? Gr=FC=DFe, Carsten From nobody Fri Mar 7 09:08:39 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459ED1A02DA for ; Fri, 7 Mar 2014 09:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXb6ILiiCjNq for ; Fri, 7 Mar 2014 09:08:38 -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 360E41A02D9 for ; Fri, 7 Mar 2014 09:08:38 -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.5/8.14.5) with ESMTP id s27H8WOO024994 for ; Fri, 7 Mar 2014 18:08:32 +0100 (CET) Received: from [10.109.74.208] (unknown [62.232.113.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DD5FAF75; Fri, 7 Mar 2014 18:08:31 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann Date: Fri, 7 Mar 2014 17:08:30 +0000 X-Mao-Original-Outgoing-Id: 415904910.721969-a047ab492b68ef03b7dcf8e8d1450e67 Content-Transfer-Encoding: quoted-printable Message-Id: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/IYAmAN7_Gd_McK5Ie8NP8BB4XeY Subject: [core] Observe Cancellation: The outcome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 17:08:39 -0000 After extensive discussion both in person at IETF89 and on the mailing = list the CoRE WG today met to close the issue. Two solutions emerged as the winners in their respective class: 1) a GET that looks like an Observation renewal (i.e., carries the = options and the token of the ongoing request), but has a (TBD) value of = the Observe option =E2=89=A0 0, cancels the Observation relationship = instead. 2) a new code (0.31 possibly was the most favored one) indicates a = cancel message; the ongoing request identified by the token in the = cancel message is canceled. After some more discussion, we first checked whether there was anyone = that couldn=E2=80=99t live with one of the solutions. Nobody showed their hands for either solution. (Thomas indicated that he was unhappy with both, but that wouldn=E2=80=99t= have helped with deciding.) So we went to a hum. There was a strong, but not unanimous consensus = for solution 1. With respect to the value of TBD, the most basic value that is different = from 0 (the vale of an empty Observe option, which we use for setting up = and renewing Observation relationships) is 1. Actually, any bits beyond the low order bit of the uint in the option = should be ignored just in case we want to extend the (elective) request = option later. The successful cancellation is indicated by a GET response without an = Observe option. Any need to suppress the normal response of the GET will need to be = handled by additional mechanisms such as the No-response Option. As usual, we have to validate this result on the mailing list. Please = indicate on the mailing list any serious problems you see with this = result until 2014-03-14, 24:00 UTC We will ship -observe-13 to the IESG on that date unless there is a = major issue; that will be submitted in the next couple of days. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Mar 8 00:26:09 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9623B1A01B5 for ; Sat, 8 Mar 2014 00:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jN9sQig79cGe for ; Sat, 8 Mar 2014 00:26:07 -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 D82B51A008F for ; Sat, 8 Mar 2014 00:26:06 -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.5/8.14.5) with ESMTP id s288Q04c012893 for ; Sat, 8 Mar 2014 09:26:00 +0100 (CET) Received: from aung.tzi.org (host-79-77-62-176.static.as9105.com [79.77.62.176]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4D83B54; Sat, 8 Mar 2014 09:26:00 +0100 (CET) From: Olaf Bergmann To: Carsten Bormann References: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) Date: Sat, 08 Mar 2014 08:25:58 +0000 Message-ID: <87d2hxp04p.fsf@tzi.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/core/NXMqc0vk0IJaZ0tI5wHo9KPe5vs Cc: "core@ietf.org WG" Subject: Re: [core] Observe Cancellation: The outcome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 08:26:08 -0000 Carsten Bormann writes: > indicate on the mailing list any serious problems you see with this > result FWIW, I still hold up my concerns that I have expressed earlier[0]. [0] http://www.ietf.org/mail-archive/web/core/current/msg05323.html Gruesse Olaf From nobody Sat Mar 8 04:06:06 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1421A026E for ; Sat, 8 Mar 2014 04:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U75_F8u3kUTV for ; Sat, 8 Mar 2014 04:06: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 EBF081A0277 for ; Sat, 8 Mar 2014 04:06: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.5/8.14.5) with ESMTP id s28C5rIN011858 for ; Sat, 8 Mar 2014 13:05:53 +0100 (CET) Received: from [10.200.60.3] (unknown [62.232.113.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 59D0D9D; Sat, 8 Mar 2014 13:05:53 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <87d2hxp04p.fsf@tzi.org> Date: Sat, 8 Mar 2014 11:32:04 +0000 X-Mao-Original-Outgoing-Id: 415971124.792291-2642d63023ad220b49f27edce7df4d46 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> <87d2hxp04p.fsf@tzi.org> To: Olaf Bergmann X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/jd4FzJW28vB9SYaSwvKxnucmkjs Cc: "core@ietf.org WG" Subject: Re: [core] Observe Cancellation: The outcome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 12:06:05 -0000 On 08 Mar 2014, at 08:25, Olaf Bergmann wrote: > FWIW, I still hold up my concerns that I have expressed earlier[0]. >=20 > [0] http://www.ietf.org/mail-archive/web/core/current/msg05323.html Noted. To move the current design into that direction, we would need to = find a better way to to an observe-renew as well. The current approach to observe-renew is near optimal in that it is = single-exchange idempotent (i.e. it does not matter whether it is = actually renewing an existing observation relationship or setting up an = observation relationship that the server forgot about). Apart from the fact that it interoperates well, this makes it unlikely = that we want to change it at this point. Modelling the observation cancellation in the same way means that at = least you don=92t have to put in another code path (i.e., you can handle = observe-cancel parallel to the observe-renew logic). Gr=FC=DFe, Carsten From nobody Sat Mar 8 06:05:31 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6583C1A0264 for ; Sat, 8 Mar 2014 06:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S87jMSObVfJ0 for ; Sat, 8 Mar 2014 06:05: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 848C51A0268 for ; Sat, 8 Mar 2014 06:05:28 -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.5/8.14.5) with ESMTP id s28E5LmZ001678 for ; Sat, 8 Mar 2014 15:05:21 +0100 (CET) Received: from [10.200.60.3] (unknown [62.232.113.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B0B73CA; Sat, 8 Mar 2014 15:05:20 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> Date: Sat, 8 Mar 2014 14:05:15 +0000 X-Mao-Original-Outgoing-Id: 415980315.351894-eeeecde78f79472143e45bd49270e009 Content-Transfer-Encoding: quoted-printable Message-Id: <5FD9B668-7403-432E-8E2B-151AC01174E4@tzi.org> References: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/LG76Pibx5aY2azRY6lDRjiGk_Rw Subject: Re: [core] Observe Cancellation: The outcome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 14:05:30 -0000 On 07 Mar 2014, at 17:08, Carsten Bormann wrote: > There was a strong, but not unanimous consensus for solution 1. =85 and I can report that we are already happily interop-testing that = outcome at CoAP#4 (TD_COAP_OBS_12 for those who follow this). You can find the new test available on the test client at http://coap.me = as well (through "ETSI CoAP#4 test client=94), a compatible server is up = e.g. at coap://vs0.inf.ethz.ch (so the abbreviated entry point into the = tests for this test pairing is at: = http://coap.me/test/coap://vs0.inf.ethz.ch). Enjoy. Gr=FC=DFe, Carsten From nobody Sat Mar 8 08:11:18 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74CF1A0292 for ; Sat, 8 Mar 2014 08:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lo3ZwL1ldfvU for ; Sat, 8 Mar 2014 08:11:06 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8081A01FC for ; Sat, 8 Mar 2014 08:11:06 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s28GB0CR021498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 8 Mar 2014 10:11:01 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s28GAwqo024652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Mar 2014 17:10:59 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.236]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sat, 8 Mar 2014 17:10:59 +0100 From: "FOSSATI, Thomas (Thomas)" To: Carsten Bormann , "core@ietf.org WG" Thread-Topic: [core] Observe Cancellation: The outcome Thread-Index: AQHPOif1L2Wy44nq40+SKPlHprhXi5rXTOUA Date: Sat, 8 Mar 2014 16:10:58 +0000 Message-ID: References: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> In-Reply-To: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-ID: <6FDCA57425B42C4C9ECD655C60CC199C@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/core/BLWiVThvE21tu3RrfHQVpybmo_c Subject: Re: [core] Observe Cancellation: The outcome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 16:11:16 -0000 T24gMDcvMDMvMjAxNCAxNzowOCwgIkNhcnN0ZW4gQm9ybWFubiIgPGNhYm9AdHppLm9yZz4gd3Jv dGU6DQo+KFRob21hcyBpbmRpY2F0ZWQgdGhhdCBoZSB3YXMgdW5oYXBweSB3aXRoIGJvdGgsIGJ1 dCB0aGF0IHdvdWxkbuKAmXQgaGF2ZQ0KPmhlbHBlZCB3aXRoIGRlY2lkaW5nLikNCg0KU2luY2Ug aXTigJlzIG5vdCBpbiB0aGUgbWVldGluZyBtaW51dGVzLCBhbmQgZm9yIHRoZSBiZW5lZml0IG9m IGZ1dHVyZQ0KZ2VuZXJhdGlvbnMgb2YgQ29BUCBpbXBsZW1lbnRlcnMgOi0pIEnigJlsbCByZXN0 YXRlIHRoZSBjb25jZXJucyBJ4oCZdmUNCmV4cHJlc3NlZCBhdCB0aGUgbWlrZSBvbiBGcmlkYXkg Zm9yIHRoZSB0d28gcHJvcG9zZWQgYWx0ZXJuYXRpdmVzLg0KDQoNClRoZSBtYWluIGlzc3VlIHdp dGggY2FuY2VsbGF0aW9uIGlzIHRoYXQgaXQgY2Fu4oCZdCBiZSB0cmVhdGVkIGFzIGEgcmVxdWVz dA0KYmVjYXVzZSBpdCBzaW1wbHkgZG9lc24ndCB0YXJnZXQgYSByZXNvdXJjZTogaXQgdGFyZ2V0 cyB0aGUgcmVsYXRpb25zaGlwDQpiZXR3ZWVuIHRoZSByZXNvdXJjZSwgdGhlIG9ic2VydmluZyBj bGllbnQsIGFuZCB0aGUgc2VydmVyLiAgU28sIGl0J3MgYQ0KZmFpcmx5IGRpZmZlcmVudCBiZWFz dC4NCg0KU3RyaWN0bHkgc3BlYWtpbmcsIHRoZSB0ZXh0IHdlIGhhdmUgaW4gc2VjdGlvbiA1LjEg b2Ygb3VyIHNvb24tdG8tYmUtUkZDDQp3b3VsZCB0aGVvcmV0aWNhbGx5IHJ1bGUgb3V0IHR3byB0 aGluZ3M6DQphKSB1c2luZyBhIG5ldyByZXF1ZXN0IGNvZGUgKDUtMzEpOw0KYikgcmV1c2luZyBh biBleGlzdGluZyByZXF1ZXN0IGNvZGUgYXMgR0VUIChvciBhbnkgb3RoZXIgYWxyZWFkeSBhbGxv Y2F0ZWQNCiAgIG1ldGhvZCkuDQoNCkJlc2lkZXMsIHRvIHJlaW5mb3JjZSBwb2ludCBiKSwgSSdk IHJlYWxseSBsaWtlIHdlIGRvIG5vdCAoZnVydGhlcikNCm92ZXJyaWRlIHRoZSBzZW1hbnRpY3Mg b2YgYSBzaW1wbGUgYW5kIHdlbGwgdW5kZXJzdG9vZCBtZXRob2QgYXMgR0VULA0Kd2hlcmUgd2Ug c2hvdWxkIGJlIHVsdHJhIGNhcmVmdWwgd2l0aCBwcmVzZXJ2aW5nIHRoZSBzYWZlL2lkZW1wb3Rl bnQNCnByb3BlcnRpZXMuICAoVGhvdWdoIG9uZSBtYXkgYXJndWUgdGhhdCBHRVQrb2JzZXJ2ZSBh bHJlYWR5IGNoYWxsZW5nZXMgdGhlDQpzYWZlLW5lc3Mgb2YgR0VULCBJ4oCZZCByZWFsbHkgcHJl ZmVyIHdlIGRvIG5vdCByZXBlYXQgdGhlIHNhbWUgZXJyb3IgdHdpY2UNCmp1c3QgZm9yIHRoZSBz YWtlIG9mIOKAnGNvbnNpc3RlbmN5Ii4pDQoNCg== From nobody Sat Mar 8 08:17:30 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918621A02AC for ; Sat, 8 Mar 2014 08:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvYyBtIbFxs4 for ; Sat, 8 Mar 2014 08:17:26 -0800 (PST) Received: from p3plsmtpa11-07.prod.phx3.secureserver.net (p3plsmtpa11-07.prod.phx3.secureserver.net [68.178.252.108]) by ietfa.amsl.com (Postfix) with ESMTP id AF8501A029C for ; Sat, 8 Mar 2014 08:17:26 -0800 (PST) Received: from Study ([216.246.69.52]) by p3plsmtpa11-07.prod.phx3.secureserver.net with id b4HJ1n00817gBDU014HK08; Sat, 08 Mar 2014 09:17:21 -0700 From: "Victor Blake" To: "'Carsten Bormann'" References: <55877B3AFB359744BA0F2140E36F52B51C27492A@MBX20.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63E45405B@SZXEMA510-MBX.china.huawei.com> <46A1DF3F04371240B504290A071B4DB63E4568B5@SZXEMA510-MBX.china.huawei.com> <001701cf3a06$4c4a0d50$e4de27f0$@victorblake.com> <14C0ACCC-C642-4077-833E-F9120E98D685@tzi.org> In-Reply-To: <14C0ACCC-C642-4077-833E-F9120E98D685@tzi.org> Date: Sat, 8 Mar 2014 11:17:34 -0500 Message-ID: <007701cf3ae9$ebc71ec0$c3555c40$@victorblake.org> 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: AQH1hFNWeeAVMYfIAXgCEhKXW6QZ4wJjLR48AQZBPmwBUSzr3AKfcOO4AjUJQ6YCTXYUJJor5YLg Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/core/WWIdtwrx3dXScLyEn78PWXGkD4Y Cc: core@ietf.org Subject: Re: [core] Observe Cancellation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 16:17:28 -0000 Perhaps REST in general, but RESTful implies that the state is shown in = the locator and further (I understand it doesn't require this, but again -- = a distinguishing characteristic of the RESTful style) human readable = format so instead of for example coded data, you might have /param_name=3Dcancel = or =3Dyes or =3Dy or =3Dno or =3Dn in the case of a positive/negative state = change. -Victor -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Friday, March 07, 2014 11:31 AM To: Victor Blake Cc: FOSSATI, Thomas (Thomas); Bert Greevenbosch; core@ietf.org Subject: Re: [core] Observe Cancellation > ...And using a code isn't exactly RESTful. The =93code=94 is just the second byte of the message, which, depending = on content, is interpreted as an empty message indicator (0.00), a method (0.xx), or a response code (y.xx). What is not RESTful about this method of encoding? Gr=FC=DFe, Carsten From nobody Sat Mar 8 09:16:15 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753DE1A02DE for ; Sat, 8 Mar 2014 09:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NobYsgl9mZMB for ; Sat, 8 Mar 2014 09:15:52 -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 7B4781A02D0 for ; Sat, 8 Mar 2014 09:15:52 -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.5/8.14.5) with ESMTP id s28HFaK7005391; Sat, 8 Mar 2014 18:15:36 +0100 (CET) Received: from [10.200.2.4] (unknown [62.232.113.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 10E9BF4; Sat, 8 Mar 2014 18:15:35 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: Date: Sat, 8 Mar 2014 17:15:30 +0000 X-Mao-Original-Outgoing-Id: 415991730.059636-3189fc390a0e470f30e1d0b1fe1f836e Content-Transfer-Encoding: quoted-printable Message-Id: <307ACD9F-86D9-47A9-8D4B-DEA9BCB9C360@tzi.org> References: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> To: "FOSSATI, Thomas (Thomas)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/SPtxUjBCmku2UcsMkRtJdDJyOn4 Cc: "core@ietf.org WG" Subject: Re: [core] Observe Cancellation: The outcome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 17:15:58 -0000 On 08 Mar 2014, at 16:10, FOSSATI, Thomas (Thomas) = wrote: > b) reusing an existing request code as GET (or any other already = allocated > method). (Personal view follows, no hat:) There is no =93reuse=94. This is still a GET: A client is obtaining a representation of the = resource. At the level of the REST model, there is no change: These = representations are cacheable, they can be operated on by chains of = proxies (=93layered system=94) only some of which make use of Observe, = maintaining a uniform interface, and so on. The details of how the GET request is operated are in the Observe = request option (absent, =3D0, =3D1). Setting up an Observation relationship asks for future representations = as well; renewing checks and possible re-establishes it, canceling ends = the indication of interest. But this is not application state: This is entirely an optimization that = saves polling (or, long-polling, which goes much further in the way of = bending the REST principles). Saying this is =93not RESTful=94 is tantamount to claiming HTTP is not = RESTful because it involves setting up TCP state. The Observation relationship state is not modeled as a resource, because = it really isn=92t one. Passing this information along with a normal GET request leads to some = unneeded semantics (e.g., many use cases of a cancel do not need a final = representation). That causes tremendous cognitive dissonance in a = design that is otherwise as clean as that of CoAP, but is not really a = big problem in practice. A more general comment (not directed to Thomas): I would prefer it if = people actually applied the principles laid out in section 5 of [REST] = before calling something more or less =93RESTful=94. E.g., textual = representation of protocol elements is completely irrelevant to REST = (and CoAP does away with ease with this principle, which is indeed very = useful in more powerful systems). =20 Exercise for the reader: Find the places in [REST] where the author = criticizes HTTP for getting something wrong that we did get right in = CoAP. Gr=FC=DFe, Carsten [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, . From nobody Sat Mar 8 10:52:45 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A76D1A022C for ; Sat, 8 Mar 2014 10:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWaeGvmf_gQ0 for ; Sat, 8 Mar 2014 10:52:42 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD661A0142 for ; Sat, 8 Mar 2014 10:52:42 -0800 (PST) Received: from localhost ([127.0.0.1]:33952 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WMMMG-0006Ci-PM; Sat, 08 Mar 2014 19:52:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-block@tools.ietf.org, kovatsch@inf.ethz.ch X-Trac-Project: core Date: Sat, 08 Mar 2014 18:52:28 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/367 Message-ID: <059.c382556ea7a7abaeb2001d71014e58e2@trac.tools.ietf.org> X-Trac-Ticket-ID: 367 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, kovatsch@inf.ethz.ch, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, zach@sensinode.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/46w8Mb-Z7yELT0K479H2yOBFh3g Cc: core@ietf.org Subject: [core] #367 (block): Reaction for Content-Format mismatch X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 08 Mar 2014 18:52:44 -0000 #367: Reaction for Content-Format mismatch The Content-Format option applies to the body, not to the payload. What if the Content-Format of a block is different from the rest? Even if non-atomic transfers are allowed, a different Content-Format cannot be patched into a representation body. A server should (aiming for a MUST) not process such Block1 requests and return an error, e.g., 4.08 Request Entity Incomplete. For Block2, it should be up to the client to interpret non-atomic blocks correctly. Atomic transfers should (aiming for a MUST) be aborted when the Content- Format changes during the transfer. This might apply to more options. Servers probably should return the same error as for the non-atomic case. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- kovatsch@inf.ethz.ch | block@tools.ietf.org Type: protocol | Status: new defect | Milestone: Priority: minor | Version: block-14 Component: block | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: core From nobody Sat Mar 8 16:19:53 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B721C1A02FC for ; Sat, 8 Mar 2014 16:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zLFwqD7hRJI for ; Sat, 8 Mar 2014 16:19:48 -0800 (PST) Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) by ietfa.amsl.com (Postfix) with ESMTP id 501401A013A for ; Sat, 8 Mar 2014 16:19:48 -0800 (PST) Received: from [192.168.65.10] ([66.41.60.82]) by p3plsmtpa09-06.prod.phx3.secureserver.net with id bCKi1n0041mTNtu01CKinX; Sat, 08 Mar 2014 17:19:43 -0700 Message-ID: <531BB39E.7050109@pabigot.com> Date: Sat, 08 Mar 2014 18:19:42 -0600 From: "Peter A. Bigot" Organization: Peter Bigot Consulting, LLC User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: core@ietf.org References: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> <307ACD9F-86D9-47A9-8D4B-DEA9BCB9C360@tzi.org> In-Reply-To: <307ACD9F-86D9-47A9-8D4B-DEA9BCB9C360@tzi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/core/hybD46jhZO3xJgDamG2wyazNr2I Subject: Re: [core] Observe Cancellation: The outcome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 00:19:51 -0000 On 03/08/2014 11:15 AM, Carsten Bormann wrote: > On 08 Mar 2014, at 16:10, FOSSATI, Thomas (Thomas) wrote: > >> b) reusing an existing request code as GET (or any other already allocated >> method). > (Personal view follows, no hat:) > > There is no “reuse”. > > This is still a GET: A client is obtaining a representation of the resource. > At the level of the REST model, there is no change: These representations are cacheable, they can be operated on by chains of proxies (“layered system”) only some of which make use of Observe, maintaining a uniform interface, and so on. > > The details of how the GET request is operated are in the Observe request option (absent, =0, =1). > Setting up an Observation relationship asks for future representations as well; renewing checks and possible re-establishes it, canceling ends the indication of interest. > But this is not application state: This is entirely an optimization that saves polling (or, long-polling, which goes much further in the way of bending the REST principles). > Saying this is “not RESTful” is tantamount to claiming HTTP is not RESTful because it involves setting up TCP state. Agreed: There is no state at the HTTP (request/response transaction) layer; it's present at the TCP (data transport) layer, which is conceptually decoupled from HTTP in a RESTful system (e.g., HTTP/SMTP). In CoAP, the state that's being created for -observe is being created and destroyed as a side-effect of a GET request (transaction), and is identified through a transaction-layer concept (Token). So we can say there's no inter-transaction state preserved in an -observe operation because the transaction simply hasn't completed until something causes it to stop; all those requests/responses over long periods are the moral equivalent of IP packets, and the state required to support them the moral equivalent of TCP state. This is an interesting perspective, and I see the argument. > The Observation relationship state is not modeled as a resource, because it really isn’t one. It's not a resource only because it was decided that it shouldn't be. It'd be a resource if you think of handling observation this way: 1) Create a resource representing a subscription from a client to a server, containing the URI of the resource to be observed and a URI to which changes to the observed resource should be sent. (Creation does not have to be done on a server that hosts the observed resource. Exercise: why might this be desirable?) 2) Sit back and wait for updates. (Notifications don't need to be sent by the owner of the observed resource. Exercise: why might this be desirable?) 3) Delete the subscription resource when the subscription is no longer desired. Sure there are details to be worked out, but this seems more RESTful (and clean and harmonious) than having subscriptions (aka state, at whatever layer) created and destroyed as a side effect of requesting transfer of a (representation of a) resource. Something for CoAPbis to consider, or not. Peter From nobody Sun Mar 9 11:17:07 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6221A028C for ; Sun, 9 Mar 2014 11:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJFElVzPKzHm for ; Sun, 9 Mar 2014 11:17:04 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D7E301A00DE for ; Sun, 9 Mar 2014 11:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s29IGql9001563 for ; Sun, 9 Mar 2014 19:16:52 +0100 (CET) Received: from [10.109.75.237] (unknown [62.232.113.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 92D5F231; Sun, 9 Mar 2014 19:16:46 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann Date: Sun, 9 Mar 2014 18:16:45 +0000 X-Mao-Original-Outgoing-Id: 416081805.747889-16e784c0717a716ed21c0532658b1edf Content-Transfer-Encoding: quoted-printable Message-Id: <07326969-B456-4E89-9417-5C07BDE8B3CA@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/p539wP2H0PNmekHFnlB2bJfXXZQ Subject: [core] Preliminary Summary from CoAP#4 plugtest in London X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 18:17:06 -0000 Here is an impression from the CoAP#4 plugtest that is ending today: For the CoAP test suite, overall interoperability was 98.5 %, with 1346 interoperable out of 1367 tests completed. The core-coap tests were interoperable at 99.3 % this time. More spectacularly, the tests for Observe achieved 99.4 %. This result really reinforces shipping this specification to the IESG now. I'm even more impressed that 48 hours after the Friday decision on Observation cancellation, seven pairings (unfortunately, not everyone had the local access to source code needed to do this) completed testing the outcome, with 100 % interoperability. Link-format fell back a little at 96.5 % (with problems mostly in complex queries), and Block is at 95.1 %. A remaining hotspot is Block1 POST, which for over half of the pairings both sides had implemented, but only achieved 70 % interoperability within this group. On the other hand, while only seven pairings had both implemented Block1/Block2 POST, these achieved 100 % interoperability. Thanks go to ETSI for running and to OMA for supporting the event, as well as to all the participants for bringing lots of implementations to the event. After the IETF (and, for some of us, STRINT), this was quite a marathon. For those who just can=92t stop testing (or have missed the event): I have deployed the updates for CoAP#4 to http://coap.me, so you can use coap://coap.me as a test CoAP server and use the web interface of coap.me as a test CoAP client against your server. The test descriptions for CoAP and DTLS can be found at https://github.com/cabo/td-coap4 =97 these are not the official ETSI document (which will be available soon) but the =93source code=94 for that. Also don't miss testing with http://vs0.inf.ethz.ch, which complements coap.me (e.g., it has an Observe implementation in the server, which coap.me hasn't got around to). If you want to arrange some timeslot for attended remote testing, please don=92t hesitate to ask me. Gr=FC=DFe, Carsten From nobody Sun Mar 9 14:08:53 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC9C1A0392 for ; Sun, 9 Mar 2014 14:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmJO_9Z9VYfo for ; Sun, 9 Mar 2014 14:08:43 -0700 (PDT) Received: from p3plsmtpa06-10.prod.phx3.secureserver.net (p3plsmtpa06-10.prod.phx3.secureserver.net [173.201.192.111]) by ietfa.amsl.com (Postfix) with ESMTP id 021711A0391 for ; Sun, 9 Mar 2014 14:08:42 -0700 (PDT) Received: from Study ([216.246.69.52]) by p3plsmtpa06-10.prod.phx3.secureserver.net with id bZ8c1n00917gBDU01Z8cTh; Sun, 09 Mar 2014 14:08:37 -0700 From: "Victor Blake" To: "'Peter A. Bigot'" , References: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> <307ACD9F-86D9-47A9-8D4B-DEA9BCB9C360@tzi.org> <531BB39E.7050109@pabigot.com> In-Reply-To: <531BB39E.7050109@pabigot.com> Date: Sun, 9 Mar 2014 17:08:57 -0400 Message-ID: <003701cf3bdb$c9a6c460$5cf44d20$@victorblake.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI3KNd7qygjE7xcYsJFNERKx8P53gLCSvCIAYk9lgsB5mIWe5nX1kGg Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/core/-XujQM6mThZC3kBwPxsY6WXn-iY Subject: Re: [core] Observe Cancellation: The outcome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 21:08:47 -0000 Well stated Peter. I agree, it's a choice to "create a resource representing a subscription" and thereafter treat it as such. -Victor -----Original Message----- From: Peter A. Bigot [mailto:pab@pabigot.com] Sent: Saturday, March 08, 2014 7:20 PM To: core@ietf.org Subject: Re: [core] Observe Cancellation: The outcome On 03/08/2014 11:15 AM, Carsten Bormann wrote: > On 08 Mar 2014, at 16:10, FOSSATI, Thomas (Thomas) wrote: > >> b) reusing an existing request code as GET (or any other already allocated >> method). > (Personal view follows, no hat:) > > There is no "reuse". > > This is still a GET: A client is obtaining a representation of the resource. > At the level of the REST model, there is no change: These representations are cacheable, they can be operated on by chains of proxies ("layered system") only some of which make use of Observe, maintaining a uniform interface, and so on. > > The details of how the GET request is operated are in the Observe request option (absent, =0, =1). > Setting up an Observation relationship asks for future representations as well; renewing checks and possible re-establishes it, canceling ends the indication of interest. > But this is not application state: This is entirely an optimization that saves polling (or, long-polling, which goes much further in the way of bending the REST principles). > Saying this is "not RESTful" is tantamount to claiming HTTP is not RESTful because it involves setting up TCP state. Agreed: There is no state at the HTTP (request/response transaction) layer; it's present at the TCP (data transport) layer, which is conceptually decoupled from HTTP in a RESTful system (e.g., HTTP/SMTP). In CoAP, the state that's being created for -observe is being created and destroyed as a side-effect of a GET request (transaction), and is identified through a transaction-layer concept (Token). So we can say there's no inter-transaction state preserved in an -observe operation because the transaction simply hasn't completed until something causes it to stop; all those requests/responses over long periods are the moral equivalent of IP packets, and the state required to support them the moral equivalent of TCP state. This is an interesting perspective, and I see the argument. > The Observation relationship state is not modeled as a resource, because it really isn't one. It's not a resource only because it was decided that it shouldn't be. It'd be a resource if you think of handling observation this way: 1) Create a resource representing a subscription from a client to a server, containing the URI of the resource to be observed and a URI to which changes to the observed resource should be sent. (Creation does not have to be done on a server that hosts the observed resource. Exercise: why might this be desirable?) 2) Sit back and wait for updates. (Notifications don't need to be sent by the owner of the observed resource. Exercise: why might this be desirable?) 3) Delete the subscription resource when the subscription is no longer desired. Sure there are details to be worked out, but this seems more RESTful (and clean and harmonious) than having subscriptions (aka state, at whatever layer) created and destroyed as a side effect of requesting transfer of a (representation of a) resource. Something for CoAPbis to consider, or not. Peter From nobody Mon Mar 10 03:07:10 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9843A1A0404 for ; Mon, 10 Mar 2014 03:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhYQ-N06H-sA for ; Mon, 10 Mar 2014 03:07:07 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id CAFA21A0408 for ; Mon, 10 Mar 2014 03:07:06 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s2AA6xSs016701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Mar 2014 05:07:00 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s2AA6vxB029673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Mar 2014 11:06:59 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.236]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 10 Mar 2014 11:06:58 +0100 From: "FOSSATI, Thomas (Thomas)" To: Carsten Bormann Thread-Topic: [core] Observe Cancellation: The outcome Thread-Index: AQHPOif1L2Wy44nq40+SKPlHprhXi5rXTOUAgAASCgCAAqzrgA== Date: Mon, 10 Mar 2014 10:06:57 +0000 Message-ID: References: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> <307ACD9F-86D9-47A9-8D4B-DEA9BCB9C360@tzi.org> In-Reply-To: <307ACD9F-86D9-47A9-8D4B-DEA9BCB9C360@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-ID: <770073A247E95A41AE75691D0DF4754F@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/core/FEeNBNPU_rbotLr3qgQuXYk8jco Cc: "core@ietf.org WG" Subject: Re: [core] Observe Cancellation: The outcome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 10:07:08 -0000 SGkgQ2Fyc3Rlbi4NCg0KT24gMDgvMDMvMjAxNCAxNzoxNSwgIkNhcnN0ZW4gQm9ybWFubiIgPGNh Ym9AdHppLm9yZz4gd3JvdGU6DQo+VGhlIGRldGFpbHMgb2YgaG93IHRoZSBHRVQgcmVxdWVzdCBp cyBvcGVyYXRlZCBhcmUgaW4gdGhlIE9ic2VydmUgcmVxdWVzdA0KPm9wdGlvbiAoYWJzZW50LCA9 MCwgPTEpLg0KPlNldHRpbmcgdXAgYW4gT2JzZXJ2YXRpb24gcmVsYXRpb25zaGlwIGFza3MgZm9y IGZ1dHVyZSByZXByZXNlbnRhdGlvbnMgYXMNCj53ZWxsOyByZW5ld2luZyBjaGVja3MgYW5kIHBv c3NpYmxlIHJlLWVzdGFibGlzaGVzIGl0LCBjYW5jZWxpbmcgZW5kcyB0aGUNCj5pbmRpY2F0aW9u IG9mIGludGVyZXN0Lg0KPkJ1dCB0aGlzIGlzIG5vdCBhcHBsaWNhdGlvbiBzdGF0ZTogVGhpcyBp cyBlbnRpcmVseSBhbiBvcHRpbWl6YXRpb24gdGhhdA0KPnNhdmVzIHBvbGxpbmcgKG9yLCBsb25n LXBvbGxpbmcsIHdoaWNoIGdvZXMgbXVjaCBmdXJ0aGVyIGluIHRoZSB3YXkgb2YNCj5iZW5kaW5n IHRoZSBSRVNUIHByaW5jaXBsZXMpLg0KDQpDdXJyZW50IC1vYnNlcnZlIGRlc2lnbiBoYXMgYmVl biBzdHJldGNoaW5nIEdFVOKAmXMgc2FmZS1uZXNzIHRvIHRoZQ0KcG9pbnQgSeKAmW0gbm90IHN1 cmUgd2UgY2FuIGNvbnNpZGVyIGl0IGEgc2FmZSBtZXRob2QgYW55bW9yZS4NCkJ1dCBJIGd1ZXNz IHdlIGNhbiBkZWJhdGUgZW5kbGVzc2x5IGFib3V0IHRoaXMuDQoNCj5TYXlpbmcgdGhpcyBpcyDi gJxub3QgUkVTVGZ1bOKAnSBpcyB0YW50YW1vdW50IHRvIGNsYWltaW5nIEhUVFAgaXMgbm90DQo+ UkVTVGZ1bCBiZWNhdXNlIGl0IGludm9sdmVzIHNldHRpbmcgdXAgVENQIHN0YXRlLg0KDQpXZWxs LCBpdCBsb29rcyBsaWtlIHlvdSdyZSBmbGlwcGluZyB0aGUgbGF5ZXJzIGhlcmUgOy0pICBCdXQg YWdhaW4sIHRoaXMNCmtpbmQgb2YgY29uc2lkZXJhdGlvbnMgdGVuZHMgdG8gYmUgdmVyeSBzdWJq ZWN0aXZlLg0KDQpXaGF0IGlzIG9iamVjdGl2ZSBpcyB0aGUgY29uc2Vuc3VzIG9mIHRoZSByb29t LCB3aGljaCB3YXMgZGVmaW5pdGVseSBpbg0KZmF2b3VyIG9mIHRoZSBHRVQrb3B0aW9uIHByb3Bv c2FsLCBhbmQgdGhlIDk5LjQlIG9mIGludGVyb3BlcmFiaWxpdHkgaW4NCnRoZSBwbHVnIHRlc3Qg c2Vzc2lvbiAtLSBpLmUuICJyb3VnaCBjb25zZW5zdXMgYW5kIHJ1bm5pbmcgY29kZeKAnSBhdA0K aXRzIGJlc3QuDQoNCg0KVGhlIHNvb25lciB3ZSBtb3ZlIG9uIHRvIGRlbGl2ZXIgLW9ic2VydmUg dG8gSUVTRywgdGhlIHNvb25lciB3ZSBjYW4NCnJlc3RhcnQgZGlzY3Vzc2luZyBpZi9ob3cgdG8g ZW5oYW5jZSBpdHMgZGVzaWduLg0KDQpDaGVlcnMNCg0K From nobody Mon Mar 10 09:42:23 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFD51A063C for ; Mon, 10 Mar 2014 09:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c49Ba2imfEJe for ; Mon, 10 Mar 2014 09:42:19 -0700 (PDT) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id C70061A0639 for ; Mon, 10 Mar 2014 09:42:18 -0700 (PDT) Received: from usa-sjc-gw1.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Mon, 10 Mar 2014 16:42:12 +0000 Received: from usa-sjc-gw2.usa.Arm.com (10.72.50.52) by usa-sjc-gw1.usa.Arm.com (10.72.50.51) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 10 Mar 2014 09:42:19 -0700 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw2.usa.Arm.com ([::1]) with mapi; Mon, 10 Mar 2014 09:42:19 -0700 From: Zach Shelby To: "FOSSATI, Thomas (Thomas)" Date: Mon, 10 Mar 2014 09:42:07 -0700 Thread-Topic: [core] Observe Cancellation: The outcome Thread-Index: Ac88f7OTXP7fIS5LTeGyMoJ1qaJz1g== Message-ID: <5D801808-6C9E-4D87-841D-8A9B27D1A2F8@arm.com> References: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> <307ACD9F-86D9-47A9-8D4B-DEA9BCB9C360@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MC-Unique: 114031016421207502 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/core/1YUBTwkv_WL16jA_G_PCpwC7F-g Cc: "core@ietf.org WG" Subject: Re: [core] Observe Cancellation: The outcome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 16:42:21 -0000 On Mar 10, 2014, at 3:06 AM, "FOSSATI, Thomas (Thomas)" wrote: > What is objective is the consensus of the room, which was definitely in > favour of the GET+option proposal, and the 99.4% of interoperability in > the plug test session -- i.e. "rough consensus and running code=94 at > its best. > > The sooner we move on to deliver -observe to IESG, the sooner we can > restart discussing if/how to enhance its design. Yep, the consensus was clear, and it worked very well for CoAP implementati= ons. Looking forward to shipping this to the IESG. Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 Skype: zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/ -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 From nobody Tue Mar 11 10:52:17 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72981A0747 for ; Tue, 11 Mar 2014 10:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fqa8PBpmN5h9 for ; Tue, 11 Mar 2014 10:52:14 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 57BD11A0736 for ; Tue, 11 Mar 2014 10:52:14 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s2BHq6Ok004254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Mar 2014 12:52:07 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s2BHq5FV012636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Mar 2014 18:52:06 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.236]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 11 Mar 2014 18:52:06 +0100 From: "FOSSATI, Thomas (Thomas)" To: Carsten Bormann Thread-Topic: draft-ietf-core-links-json-01 review Thread-Index: AQHPPVKd12SgOxUEOkmGDtwQGVY9wQ== Date: Tue, 11 Mar 2014 17:52:05 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/core/XnDxHFxq92Xw1m5lA_NLNSFqsZg Cc: "core@ietf.org WG" Subject: [core] draft-ietf-core-links-json-01 review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 17:52:16 -0000 SGkgQ2Fyc3RlbiwNCg0Kd2Ugd2FudGVkIHRvIHVzZSB0aGUgZm9ybWF0IGluIEpTT04gbGluayBJ LUQgZm9yIEhUVFAtQ29BUCBwcm94eSBkaXNjb3ZlcnkuDQoNClNvIEkgdG9vayBhIGxvb2sgYXQg aXQsIGFuZCB0aGlzIGlzIG15IGJyaWVmIHJldmlldy4NCg0KPS09LT0tPQ0KDQpCb3RoIEFic3Ry YWN0IGFuZCBJbnRyb2R1Y3Rpb24gc2F5IOKAnFvigKZdIG1heSBiZSB1c2VmdWwgdG8gcmVwcmVz ZW50IHRoZXNlDQpjb2xsZWN0aW9ucyBpbiBKU09O4oCdLiAgUGVyaGFwcyB3b3J0aCBhZGRpbmcg c29tZSB0ZXh0IHRvIGJldHRlcg0Kc3Vic3RhbnRpYXRlIGl0cyB1c2VmdWwtbmVzcyBvdmVyIFJG QzU5ODggc2VyaWFsaXNhdGlvbj8gIEkgZ3Vlc3Mgb25lIG9mDQp0aGUgbWFpbiBtb3RpdmF0aW9u cyBmb3IgcHJlZmVycmluZyBKU09OIG92ZXIgTGluayBpcyB0aGUgaW5jcmVhc2VkICJ3ZWINCkFQ SSBmcmllbmRsaW5lc3MiIChpLmUuIG5vIGFkZGVkIHBhcnNpbmcgY29zdCBmb3IgZXh0cmFjdGlu ZyBsaW5rDQppbmZvcm1hdGlvbiwgZm9ybWF0IGhvbW9nZW5pc2F0aW9uLCBldGMuKS4gIElzIGl0 IGNvcnJlY3Q/DQoNCk9uIHRoZSBzYW1lIHRvcGljOiBJIGZpbmQgdGhlIGFyZ3VtZW50IGdpdmVu IGluIHRoZSBzZWNvbmQgcGFyYSBvZiB0aGUNCkludHJvZHVjdGlvbiAtLSBpZS4gdGhlICJwcm9h Y3RpdmVseSB0cnkgdG8gc3RvcCBmb3JtYXRzJyBwcm9saWZlcmF0aW9uIg0KZnVuY3Rpb24gb2Yg dGhpcyBzcGVjIOKAlCBub3QgdmVyeSBjb21wZWxsaW5nLiAgIEJ1dCB0aGlzIG1pZ2h0IGp1c3Qg YmUgbWUNCjotKQ0KDQpBbHNvIEkgdGhpbmsgdGhhdCBpdCdkIGJlIG5pY2UgdG8gZ2l2ZSB0aGUg cmVhZGVyIGVub3VnaCBjb250ZXh0IHRvDQp1bmRlcnN0YW5kIGhvdyBKU09OIGxpbmsgZGlmZmVy cyBmcm9tIG90aGVyIHNpbWlsYXIgcHJvcG9zYWxzIChKU09ODQpmb3JtYXRzIEpTT04tTEQsIEpT T04gUmVmZXJlbmNlLCBIQUwsIGV0Yy4pIGFuZCB3aHkgaXQgaXMgYSBiZXR0ZXIgY2hvaWNlDQp0 aGFuIGFueSBvZiB0aG9zZSBmb3Igb3VyIHVzZSBjYXNlLg0KDQpSZTogdGhlIGltcGxpY2l0IHZz IGV4cGxpY2l0IHJlbD0iaG9zdHMiIGluIFNlY3Rpb24gMiwgSSdkIGJlIGluY2xpbmVkIHRvDQph ZGQgaXQgZXhwbGljaXRseSBiZWNhdXNlIGluIHRoZSB3aWRlciB3ZWIgaXQgY2Fu4oCZdCBiZSBh c3N1bWVkLCBidXQgd291bGQNCmxvdmUgdG8gaGVhciBmcm9tIHlvdSBhbmQvb3IgIG90aGVycyBm b3IgcmVhc29ucyB3aHkgaXQgc2hvdWxkbid0Lg0KDQpJbiBzZWN0aW9uIDIuMSwgaXQnZCBiZSBu aWNlIHRvIGhhdmUgZXhhbXBsZXMgdGhhdCBzaG93IHRoZSBsZXNzIG9idmlvdXMNCmJpdHMsIGUu Zy4gbXVsdGktdmFsdWVkIGF0dHJpYnV0ZSB0byBhcnJheSwgZXNjYXBlIGNoYXJzLCBldGMuDQoN Cj0tPS09LT0NCg0KVGhhdCBzYWlkLCB0aGUgZG9jIGlzIGluIHByZXR0eSBnb29kIHNoYXBlISAg QW55IHBsYW4gZm9yIGFuIHVwZGF0ZWQNCnZlcnNpb24/DQoNCkNoZWVycywgdA0KDQo= From nobody Tue Mar 11 13:36:44 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3121A0643 for ; Tue, 11 Mar 2014 13:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXUjmxyyZXpv for ; Tue, 11 Mar 2014 13:36:41 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 529CF1A0488 for ; Tue, 11 Mar 2014 13:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2BKaWrS007213 for ; Tue, 11 Mar 2014 21:36:33 +0100 (CET) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 983E25C for ; Tue, 11 Mar 2014 21:36:32 +0100 (CET) Received: by mail-vc0-f170.google.com with SMTP id hu8so9342722vcb.29 for ; Tue, 11 Mar 2014 13:36:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=wKpNwps/p5Za6TgZvcbogvUKVisaucTt7JtPZdCWoa4=; b=W6j4Gs8zsVj7cFmyhh1c0+1WY/7w5UbtKkdtXG6gz868oSC6LPghhsLQzbNehV/ts8 1ky/Pa8MrbPBDMG9unNfV/vYcRx6JGHioybfT4IDphjKs2N3s8VdtE+Ckm0Tphf9r2i1 EFV3V5JlNzqnAciLc6yjIajybYEBEuQQi8JG36jiIq4V6F84GY61oSFY5v+KUbDSLwBX oerV3doucnxK7UWmTJiXxjFlkqKJ1jaBhWqG2xcAiXBeQwxYY4bbe4fAqFgxjtOz5TQt z+ULkIgNGCRefiz8JVIbiJa3Oqw6NNJxM/3D+ws8d+0h39bd/cIf/BxkVQ1lgcVw4sX/ JwnQ== X-Received: by 10.220.48.194 with SMTP id s2mr23696vcf.43.1394570191133; Tue, 11 Mar 2014 13:36:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.242 with HTTP; Tue, 11 Mar 2014 13:35:50 -0700 (PDT) In-Reply-To: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> References: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> From: Klaus Hartke Date: Tue, 11 Mar 2014 21:35:50 +0100 Message-ID: To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/core/sXp6XYKnJ50AP0eQ2JpdWOK6eMM Subject: Re: [core] Observe Cancellation: The outcome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 20:36:43 -0000 Within the class of solutions we agreed on (overloading the GET method), the simplest solution is a GET request without Observe option and with the token in use. How bad is its drawback (having to check for a potential observation to be canceled on every GET request) really? Klaus From nobody Tue Mar 11 13:46:54 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5001A072C for ; Tue, 11 Mar 2014 13:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxqNHEuHUg84 for ; Tue, 11 Mar 2014 13:46:51 -0700 (PDT) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id F3BEF1A048A for ; Tue, 11 Mar 2014 13:46:50 -0700 (PDT) Received: from usa-sjc-gw1.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Tue, 11 Mar 2014 20:46:43 +0000 Received: from usa-sjc-gw2.usa.Arm.com (10.72.50.52) by usa-sjc-gw1.usa.Arm.com (10.72.50.51) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 11 Mar 2014 13:46:51 -0700 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw2.usa.Arm.com ([::1]) with mapi; Tue, 11 Mar 2014 13:46:52 -0700 From: Zach Shelby To: Klaus Hartke Date: Tue, 11 Mar 2014 13:46:38 -0700 Thread-Topic: [core] Observe Cancellation: The outcome Thread-Index: Ac89awcc8d4MXqEZSr6X1Y2XEzbTzQ== Message-ID: References: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MC-Unique: 114031120464400102 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/core/PECvUhogycEzkyjO8lOlRYIj3bw Cc: "core@ietf.org WG" Subject: Re: [core] Observe Cancellation: The outcome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 20:46:53 -0000 On Mar 11, 2014, at 1:35 PM, Klaus Hartke wrote: > Within the class of solutions we agreed on (overloading the GET > method), the simplest solution is a GET request without Observe option > and with the token in use. How bad is its drawback (having to check > for a potential observation to be canceled on every GET request) > really? At least for our implementation the effect is minimal. We only need to a ca= ncellation check when the Observe option is present, which we need to do an= yways for renewal. Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 Skype: zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/ -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 From nobody Tue Mar 11 14:13:57 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4324D1A0815 for ; Tue, 11 Mar 2014 14:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Drlfozp62jdL for ; Tue, 11 Mar 2014 14:13:54 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E3A5C1A0811 for ; Tue, 11 Mar 2014 14:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2BLDe1E022853 for ; Tue, 11 Mar 2014 22:13:42 +0100 (CET) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B5DDD67 for ; Tue, 11 Mar 2014 22:13:40 +0100 (CET) Received: by mail-ve0-f176.google.com with SMTP id cz12so9054454veb.21 for ; Tue, 11 Mar 2014 14:13:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UvTiDkdQ5IIiug0zT28D9WMzxmjlWeA1ZZbOX+oNRmM=; b=dwq8PACB5RemyegkoDMGvWyB4wdtRqUktws4paO13EYQ4yXGQT2C0mQNFrYMNzDAHv xGIQM4B4636XC17rGJaULXMET/Y+lAzSsM6Q6TPxwMN5LCS0k41Ojt2kzU0d+1f01Moi 08usdskR+xQWEKF42k0hJ8VsLj2tI9eDk4aa7hP+i9XxB+8AqYm9mT7hMi/Q4Y84r2+T KO1WvXU0Dl7BA3NOhBgnOB5in5+jm55mmyJaFozMQOqrdbLnCxOuwwngDaDjyyGsLUhT UZrksGjtLKCw1DYDlj0O5jtJDSyjjSa1ozh64lBpC4eT6wG/8heamqRo4od7pXbmVvQr wrjQ== MIME-Version: 1.0 X-Received: by 10.58.161.101 with SMTP id xr5mr193106veb.36.1394572419510; Tue, 11 Mar 2014 14:13:39 -0700 (PDT) Received: by 10.52.89.242 with HTTP; Tue, 11 Mar 2014 14:13:39 -0700 (PDT) In-Reply-To: References: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> Date: Tue, 11 Mar 2014 22:13:39 +0100 Message-ID: From: Klaus Hartke To: Zach Shelby Content-Type: multipart/alternative; boundary=047d7b5d5b0aadbaed04f45b3196 Archived-At: http://mailarchive.ietf.org/arch/msg/core/jVLZNofPkR2CZ9_NE8z5dsRmxqU Cc: "core@ietf.org WG" , Klaus Hartke Subject: Re: [core] Observe Cancellation: The outcome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 21:13:56 -0000 --047d7b5d5b0aadbaed04f45b3196 Content-Type: text/plain; charset=ISO-8859-1 I'm asking about the alternative solution where the Observe option is *not* present. How bad is the impact of the cancellation check there? In my implementation, it's basically free, because I'm performing a similar check anyway. Klaus On Tuesday, 11 March 2014, Zach Shelby wrote: > On Mar 11, 2014, at 1:35 PM, Klaus Hartke > > wrote: > > > Within the class of solutions we agreed on (overloading the GET > > method), the simplest solution is a GET request without Observe option > > and with the token in use. How bad is its drawback (having to check > > for a potential observation to be canceled on every GET request) > > really? > > At least for our implementation the effect is minimal. We only need to a > cancellation check when the Observe option is present, which we need to do > anyways for renewal. > > Zach Shelby > Director of Technology > ARM Internet of Things BU > www.arm.com > mobile: +1 (408) 203-9434 > Skype: zdshelby > LinkedIn: fi.linkedin.com/in/zachshelby/ > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2548782 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --047d7b5d5b0aadbaed04f45b3196 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm asking about=A0the alte= rnative=A0solution where the Observe option is *not* present. How bad is th= e impact of the=A0cancellation check there?=A0In my implementation, it's basically free, because I&#= 39;m performing a similar check anyway.=A0

Klaus

On Tuesday, 11 March 2014, Zach = Shelby <Zach.Shelby@arm.com&g= t; wrote:
On Mar 11, 2014, at 1:35 PM, Klaus Hartke <hartke@tzi.org<= /a>> wrote:

> Within the class of solutions we agreed on (overloading the GET
> method), the simplest solution is a GET request without Observe option=
> and with the token in use. How bad is its drawback (having to check > for a potential observation to be canceled on every GET request)
> really?

At least for our implementation the effect is minimal. We only need to a ca= ncellation check when the Observe option is present, which we need to do an= yways for renewal.

Zach Shelby
Director of Technology
ARM Internet of Things BU
www.arm.com
mobile: +1 (408) 203-9434
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/


-- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. =A0Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: =A02557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: =A02548782

_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core
--047d7b5d5b0aadbaed04f45b3196-- From nobody Tue Mar 11 14:35:16 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F9E1A0834 for ; Tue, 11 Mar 2014 14:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIk1eQ2muQXD for ; Tue, 11 Mar 2014 14:35:12 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 271141A0831 for ; Tue, 11 Mar 2014 14:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s2BLYswh005771; Tue, 11 Mar 2014 22:34:55 +0100 (CET) Received: from [192.168.217.105] (p548917BF.dip0.t-ipconnect.de [84.137.23.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 6886571; Tue, 11 Mar 2014 22:34:54 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: Date: Tue, 11 Mar 2014 22:34:52 +0100 X-Mao-Original-Outgoing-Id: 416266492.855595-51400258af67366c6de3f557ae915c75 Content-Transfer-Encoding: quoted-printable Message-Id: <22537787-6932-42B4-AB4E-65E2FC1DDF55@tzi.org> References: To: "FOSSATI, Thomas (Thomas)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/1xKOIt0U1Zhdw0rEbLZaqGc-Zk0 Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-links-json-01 review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 21:35:13 -0000 Hi Thomas, thank you for the review. > Both Abstract and Introduction say =93[=85] may be useful to represent = these > collections in JSON=94. Perhaps worth adding some text to better > substantiate its useful-ness over RFC5988 serialisation? I guess one = of > the main motivations for preferring JSON over Link is the increased = "web > API friendliness" (i.e. no added parsing cost for extracting link > information, format homogenisation, etc.). Is it correct? This is a very short draft, and I wouldn=92t want to load it with text = that second-guesses when it is better to use link-format and when it is = better to convert to JSON. But yes, friendliness to the Big Web is the = main point of this specification. Implicitly there is also a normative = effect on application-internal APIs to link-format =96 ideally, the = programmer no longer has to guess how link-format documents are = represented internally. I=92ll try to add some, but not too much, text to this effect. > On the same topic: I find the argument given in the second para of the > Introduction -- ie. the "proactively try to stop formats' = proliferation" > function of this spec =97 not very compelling. But this might just = be me > :-) This is mostly about the above-mentioned implicit effect. > Also I think that it'd be nice to give the reader enough context to > understand how JSON link differs from other similar proposals (JSON > formats JSON-LD, JSON Reference, HAL, etc.) and why it is a better = choice > than any of those for our use case. The current text is mentioning MNOT11. Again, I wouldn=92t want to = expand this too much. It may be worth to add explanation on the difference between =93Linking = from JSON=94 (which JSON-LD is about) and =93JSON representation of = links=94, which this is about. > Re: the implicit vs explicit rel=3D"hosts" in Section 2, I'd be = inclined to > add it explicitly because in the wider web it can=92t be assumed, but = would > love to hear from you and/or others for reasons why it shouldn=92t. Great question. My assumption so far was that both the link-format and = the links-json consumer operate from the same semantics, so the two = representations only differ in syntax. The alternative, adding a semantic transform, may make the JSON easier = to process without knowledge of the link-format semantics, but adds = roundtripping headaches. Is it worth it? > In section 2.1, it'd be nice to have examples that show the less = obvious > bits, e.g. multi-valued attribute to array, escape chars, etc. Very good point! I=92ll update the draft in the next 5 days or so based on this input. Previously, we said that we wanted to wait with advancing this draft = until we have more implementation experience. I think it is worth checking if there are now more implementations, and, = if yes, and assuming they don=92t reveal groundbreaking flaws, going for = a WGLC soon. (This would also allow us to stay reasonably close to our = Jan 2014 milestone for this.) Gr=FC=DFe, Carsten From nobody Tue Mar 11 20:15:09 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7801A08B4 for ; Tue, 11 Mar 2014 20:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhk5EvZ-FFeA for ; Tue, 11 Mar 2014 20:14:59 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 81FE01A08D3 for ; Tue, 11 Mar 2014 20:14:56 -0700 (PDT) Received: from WeiGengyuPC (unknown [10.103.240.155]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 9432019F3B9; Wed, 12 Mar 2014 11:14:40 +0800 (HKT) Message-ID: <99F741693CE649BEAF289E58EF76BAC0@WeiGengyuPC> From: "weigengyu" To: "Klaus Hartke" , "Zach Shelby" References: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> In-Reply-To: Date: Wed, 12 Mar 2014 11:14:39 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01CF3DE4.425CF5A0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/6sAVCw5M-jf6UuaoAAZHUG2qkSE Cc: core@ietf.org Subject: Re: [core] Observe Cancellation: The outcome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 03:15:07 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0049_01CF3DE4.425CF5A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Klaus and all,=20 To define =E2=80=9Cthe Observe option is *not* present=E2=80=9D means = =E2=80=9CCancellation=E2=80=9D is not good choice, I think.=20 Why not to make the sematics clear. =20 It seems that Get with Observe option of BEING intereted can do = subscription, and Get with Observe option of NOT interested will do = cancellation. =20 I think that the CoAP observation operatoins are much like operations of = subcription/unsubscription of IETF mailing list. Regards,=20 Gengyu=20 Network Technology Center School of Computer Beijing University of Posts and Telecommunications From: Klaus Hartke=20 Sent: Wednesday, March 12, 2014 5:13 AM To: Zach Shelby=20 Cc: mailto:core@ietf.org ; Klaus Hartke=20 Subject: Re: [core] Observe Cancellation: The outcome I'm asking about the alternative solution where the Observe option is = *not* present. How bad is the impact of the cancellation check there? In = my implementation, it's basically free, because I'm performing a similar = check anyway.=20 Klaus On Tuesday, 11 March 2014, Zach Shelby wrote: On Mar 11, 2014, at 1:35 PM, Klaus Hartke wrote: > Within the class of solutions we agreed on (overloading the GET > method), the simplest solution is a GET request without Observe = option > and with the token in use. How bad is its drawback (having to check > for a potential observation to be canceled on every GET request) > really? At least for our implementation the effect is minimal. We only need to = a cancellation check when the Observe option is present, which we need = to do anyways for renewal. Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 Skype: zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/ -- IMPORTANT NOTICE: The contents of this email and any attachments = are confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, = Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 = 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ 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 ------=_NextPart_000_0049_01CF3DE4.425CF5A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Klaus and all,
 
To define =E2=80=9Cthe Observe option is *not* present=E2=80=9D = means =E2=80=9CCancellation=E2=80=9D is not=20 good choice, I think.
 
Why not to make the sematics clear. 
It seems that Get with Observe option of BEING intereted can do=20 subscription, and Get with Observe option of  NOT interested will = do=20 cancellation. 
 
I think that the CoAP observation operatoins are much like = operations of=20 subcription/unsubscription of IETF mailing list.
 
Regards,
 
Gengyu
 
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
Sent: Wednesday, March 12, 2014 5:13 AM
Subject: Re: [core] Observe Cancellation: The=20 outcome
 
I'm asking about the alternative = solution=20 where the Observe option is *not* present. How bad is the impact of the=20 cancellation check there? In my=20 implementation, it's basically free, because I'm performing a similar = check=20 anyway. 
 
Klaus

On Tuesday, 11 March 2014, Zach Shelby <Zach.Shelby@arm.com> = wrote:
On=20 Mar 11, 2014, at 1:35 PM, Klaus Hartke <hartke@tzi.org> wrote:

> Within = the class=20 of solutions we agreed on (overloading the GET
> method), the = simplest=20 solution is a GET request without Observe option
> and with the = token in=20 use. How bad is its drawback (having to check
> for a potential=20 observation to be canceled on every GET request)
> = really?

At=20 least for our implementation the effect is minimal. We only need to a=20 cancellation check when the Observe option is present, which we need = to do=20 anyways for renewal.

Zach Shelby
Director of = Technology
ARM=20 Internet of Things BU
www.arm.com
mobile: +1 (408) 203-9434
Skype: = zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/


-- = IMPORTANT=20 NOTICE: The contents of this email and any attachments are = confidential and=20 may also be privileged. If you are not the intended recipient, please = notify=20 the sender immediately and do not disclose the contents to any other = person,=20 use it for any purpose, or store or copy the information in any = medium. =20 Thank you.

ARM Limited, Registered office 110 Fulbourn Road, = Cambridge=20 CB1 9NJ, Registered in England & Wales, Company No:  = 2557590
ARM=20 Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,=20 Registered in England & Wales, Company No: =20 2548782

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

_______________________________________________
core mailing=20 list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
------=_NextPart_000_0049_01CF3DE4.425CF5A0-- From nobody Tue Mar 11 23:43:42 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0DA1A08F1 for ; Tue, 11 Mar 2014 23:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDCVZ-DfOOOe for ; Tue, 11 Mar 2014 23:43:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 84E991A08EF for ; Tue, 11 Mar 2014 23:43:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEM15493; Wed, 12 Mar 2014 06:43:30 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Mar 2014 06:42:37 +0000 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Mar 2014 06:43:28 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Wed, 12 Mar 2014 14:43:24 +0800 From: Likepeng To: weigengyu , Klaus Hartke , "Zach Shelby" Thread-Topic: [core] Observe Cancellation: The outcome Thread-Index: AQHPOifkc+gjrGQQoE+OT2/m2KC1u5rb2I4AgAADBQCAAAeMgIAAZN2AgACGo7A= Date: Wed, 12 Mar 2014 06:43:24 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B03166@SZXEMA501-MBS.china.huawei.com> References: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> <99F741693CE649BEAF289E58EF76BAC0@WeiGengyuPC> In-Reply-To: <99F741693CE649BEAF289E58EF76BAC0@WeiGengyuPC> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B03166SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/6z8PIrVcHFM9Bn2AkpoKQfNobTU Cc: "core@ietf.org" Subject: Re: [core] Observe Cancellation: The outcome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 06:43:41 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B03166SZXEMA501MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PlRvIGRlZmluZSDigJx0aGUgT2JzZXJ2ZSBvcHRpb24gaXMgKm5vdCogcHJlc2VudOKAnSBtZWFu cyDigJxDYW5jZWxsYXRpb27igJ0gaXMgbm90IGdvb2QgY2hvaWNlLCBJIHRoaW5rLg0KDQpBZ3Jl ZSwgdGhhdCBpcyB3aGVyZSB0aGUgaXNzdWUgKGhhdmluZyB0byBjaGVjayBmb3IgYSBwb3RlbnRp YWwgb2JzZXJ2YXRpb24gdG8gYmUgY2FuY2VsZWQgb24gZXZlcnkgR0VUIHJlcXVlc3QpIGNvbWlu ZyBmcm9tLg0KDQo+V2h5IG5vdCB0byBtYWtlIHRoZSBzZW1hbnRpY3MgY2xlYXIuDQo+SXQgc2Vl bXMgdGhhdCBHZXQgd2l0aCBPYnNlcnZlIG9wdGlvbiBvZiBCRUlORyBpbnRlcmVzdGVkIGNhbiBk byBzdWJzY3JpcHRpb24sIGFuZCBHZXQgd2l0aCBPYnNlcnZlIG9wdGlvbiBvZiAgTk9UIGludGVy ZXN0ZWQgd2lsbCBkbyBjYW5jZWxsYXRpb24uDQoNCkFncmVlIHRvIG1ha2UgaXQgY2xlYXIsIHRo YXQgaXMuIEdpdmUg4oCcT2JzZXJ2ZeKAnSBvcHRpb24gYSB2YWx1ZS4NCg0KS2luZCBSZWdhcmRz DQpLZXBlbmcNCg0K5Y+R5Lu25Lq6OiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3Jn XSDku6Pooaggd2VpZ2VuZ3l1DQrlj5HpgIHml7bpl7Q6IDIwMTTlubQz5pyIMTLml6UgMTE6MTUN CuaUtuS7tuS6ujogS2xhdXMgSGFydGtlOyBaYWNoIFNoZWxieQ0K5oqE6YCBOiBjb3JlQGlldGYu b3JnDQrkuLvpopg6IFJlOiBbY29yZV0gT2JzZXJ2ZSBDYW5jZWxsYXRpb246IFRoZSBvdXRjb21l DQoNCkhpIEtsYXVzIGFuZCBhbGwsDQoNClRvIGRlZmluZSDigJx0aGUgT2JzZXJ2ZSBvcHRpb24g aXMgKm5vdCogcHJlc2VudOKAnSBtZWFucyDigJxDYW5jZWxsYXRpb27igJ0gaXMgbm90IGdvb2Qg Y2hvaWNlLCBJIHRoaW5rLg0KDQpXaHkgbm90IHRvIG1ha2UgdGhlIHNlbWF0aWNzIGNsZWFyLg0K SXQgc2VlbXMgdGhhdCBHZXQgd2l0aCBPYnNlcnZlIG9wdGlvbiBvZiBCRUlORyBpbnRlcmV0ZWQg Y2FuIGRvIHN1YnNjcmlwdGlvbiwgYW5kIEdldCB3aXRoIE9ic2VydmUgb3B0aW9uIG9mICBOT1Qg aW50ZXJlc3RlZCB3aWxsIGRvIGNhbmNlbGxhdGlvbi4NCg0KSSB0aGluayB0aGF0IHRoZSBDb0FQ IG9ic2VydmF0aW9uIG9wZXJhdG9pbnMgYXJlIG11Y2ggbGlrZSBvcGVyYXRpb25zIG9mIHN1YmNy aXB0aW9uL3Vuc3Vic2NyaXB0aW9uIG9mIElFVEYgbWFpbGluZyBsaXN0Lg0KDQpSZWdhcmRzLA0K DQpHZW5neXUNCg0KTmV0d29yayBUZWNobm9sb2d5IENlbnRlcg0KU2Nob29sIG9mIENvbXB1dGVy DQpCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgYW5kIFRlbGVjb21tdW5pY2F0aW9ucw0KRnJv bTogS2xhdXMgSGFydGtlPG1haWx0bzpoYXJ0a2VAdHppLm9yZz4NClNlbnQ6IFdlZG5lc2RheSwg TWFyY2ggMTIsIDIwMTQgNToxMyBBTQ0KVG86IFphY2ggU2hlbGJ5PG1haWx0bzpaYWNoLlNoZWxi eUBhcm0uY29tPg0KQ2M6IG1haWx0bzpjb3JlQGlldGYub3JnIDsgS2xhdXMgSGFydGtlPG1haWx0 bzpoYXJ0a2VAdHppLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0gT2JzZXJ2ZSBDYW5jZWxsYXRp b246IFRoZSBvdXRjb21lDQoNCkknbSBhc2tpbmcgYWJvdXQgdGhlIGFsdGVybmF0aXZlIHNvbHV0 aW9uIHdoZXJlIHRoZSBPYnNlcnZlIG9wdGlvbiBpcyAqbm90KiBwcmVzZW50LiBIb3cgYmFkIGlz IHRoZSBpbXBhY3Qgb2YgdGhlIGNhbmNlbGxhdGlvbiBjaGVjayB0aGVyZT8gSW4gbXkgaW1wbGVt ZW50YXRpb24sIGl0J3MgYmFzaWNhbGx5IGZyZWUsIGJlY2F1c2UgSSdtIHBlcmZvcm1pbmcgYSBz aW1pbGFyIGNoZWNrIGFueXdheS4NCg0KS2xhdXMNCg0KT24gVHVlc2RheSwgMTEgTWFyY2ggMjAx NCwgWmFjaCBTaGVsYnkgPFphY2guU2hlbGJ5QGFybS5jb208bWFpbHRvOlphY2guU2hlbGJ5QGFy bS5jb20+PiB3cm90ZToNCk9uIE1hciAxMSwgMjAxNCwgYXQgMTozNSBQTSwgS2xhdXMgSGFydGtl IDxoYXJ0a2VAdHppLm9yZzxqYXZhc2NyaXB0Ojs+PiB3cm90ZToNCg0KPiBXaXRoaW4gdGhlIGNs YXNzIG9mIHNvbHV0aW9ucyB3ZSBhZ3JlZWQgb24gKG92ZXJsb2FkaW5nIHRoZSBHRVQNCj4gbWV0 aG9kKSwgdGhlIHNpbXBsZXN0IHNvbHV0aW9uIGlzIGEgR0VUIHJlcXVlc3Qgd2l0aG91dCBPYnNl cnZlIG9wdGlvbg0KPiBhbmQgd2l0aCB0aGUgdG9rZW4gaW4gdXNlLiBIb3cgYmFkIGlzIGl0cyBk cmF3YmFjayAoaGF2aW5nIHRvIGNoZWNrDQo+IGZvciBhIHBvdGVudGlhbCBvYnNlcnZhdGlvbiB0 byBiZSBjYW5jZWxlZCBvbiBldmVyeSBHRVQgcmVxdWVzdCkNCj4gcmVhbGx5Pw0KDQpBdCBsZWFz dCBmb3Igb3VyIGltcGxlbWVudGF0aW9uIHRoZSBlZmZlY3QgaXMgbWluaW1hbC4gV2Ugb25seSBu ZWVkIHRvIGEgY2FuY2VsbGF0aW9uIGNoZWNrIHdoZW4gdGhlIE9ic2VydmUgb3B0aW9uIGlzIHBy ZXNlbnQsIHdoaWNoIHdlIG5lZWQgdG8gZG8gYW55d2F5cyBmb3IgcmVuZXdhbC4NCg0KWmFjaCBT aGVsYnkNCkRpcmVjdG9yIG9mIFRlY2hub2xvZ3kNCkFSTSBJbnRlcm5ldCBvZiBUaGluZ3MgQlUN Cnd3dy5hcm0uY29tPGh0dHA6Ly93d3cuYXJtLmNvbT4NCm1vYmlsZTogKzEgKDQwOCkgMjAzLTk0 MzQNClNreXBlOiB6ZHNoZWxieQ0KTGlua2VkSW46IGZpLmxpbmtlZGluLmNvbS9pbi96YWNoc2hl bGJ5LzxodHRwOi8vZmkubGlua2VkaW4uY29tL2luL3phY2hzaGVsYnkvPg0KDQoNCi0tIElNUE9S VEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBw ZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9y bWF0aW9uIGluIGFueSBtZWRpdW0uICBUaGFuayB5b3UuDQoNCkFSTSBMaW1pdGVkLCBSZWdpc3Rl cmVkIG9mZmljZSAxMTAgRnVsYm91cm4gUm9hZCwgQ2FtYnJpZGdlIENCMSA5TkosIFJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCAmIFdhbGVzLCBDb21wYW55IE5vOiAgMjU1NzU5MA0KQVJNIEhvbGRpbmdz IHBsYywgUmVnaXN0ZXJlZCBvZmZpY2UgMTEwIEZ1bGJvdXJuIFJvYWQsIENhbWJyaWRnZSBDQjEg OU5KLCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcywgQ29tcGFueSBObzogIDI1NDg3ODIN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUg bWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnPGphdmFzY3JpcHQ6Oz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpj b3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B03166SZXEMA501MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseTrlrovkvZM7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0 ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaW h+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bh bg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxl LW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7 VG8gZGVmaW5lIOKAnHRoZSBPYnNlcnZlIG9wdGlvbiBpcyAqbm90KiBwcmVzZW504oCdIG1lYW5z IOKAnENhbmNlbGxhdGlvbuKAnSBpcyBub3QgZ29vZCBjaG9pY2UsIEkgdGhpbmsuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFncmVlLCB0 aGF0IGlzIHdoZXJlIHRoZSBpc3N1ZSAoaGF2aW5nIHRvIGNoZWNrIGZvciBhIHBvdGVudGlhbCBv YnNlcnZhdGlvbiB0byBiZSBjYW5jZWxlZCBvbiBldmVyeSBHRVQgcmVxdWVzdCkgY29taW5nIGZy b20uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPiZndDtXaHkgbm90IHRvIG1ha2UgdGhlIHNlbWFudGljcyBjbGVhci4mbmJzcDsNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7SXQgc2VlbXMgdGhhdCBHZXQgd2l0aCBPYnNlcnZlIG9w dGlvbiBvZiBCRUlORyBpbnRlcmVzdGVkIGNhbiBkbyBzdWJzY3JpcHRpb24sIGFuZCBHZXQgd2l0 aCBPYnNlcnZlIG9wdGlvbiBvZiZuYnNwOyBOT1QgaW50ZXJlc3RlZCB3aWxsIGRvIGNhbmNlbGxh dGlvbi4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFncmVlIHRvIG1ha2UgaXQgY2xlYXIsIHRo YXQgaXMuIEdpdmUg4oCcT2JzZXJ2ZeKAnSBvcHRpb24gYSB2YWx1ZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPktpbmQgUmVnYXJkczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5LZXBlbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20g MGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkeS7tuS6 ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRm Lm9yZ10NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Luj6KGoIDwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij53ZWln ZW5neXU8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkemA geaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gMjAxNDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjM8L3NwYW4+5pyIPHNwYW4g bGFuZz0iRU4tVVMiPjEyPC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4gMTE6MTU8YnI+DQo8 L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gS2xhdXMgSGFydGtlOyBaYWNoIFNoZWxieTxicj4NCjwvc3Bhbj48Yj7mioTp gIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBjb3Jl QGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbY29yZV0gT2JzZXJ2ZSBDYW5jZWxsYXRpb246 IFRoZSBvdXRjb21lPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkhpIEtsYXVzIGFuZCBhbGwsDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRvIGRlZmluZSDigJx0aGUgT2JzZXJ2ZSBvcHRp b24gaXMgKm5vdCogcHJlc2VudOKAnSBtZWFucyDigJxDYW5jZWxsYXRpb27igJ0gaXMgbm90IGdv b2QgY2hvaWNlLCBJIHRoaW5rLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5XaHkgbm90 IHRvIG1ha2UgdGhlIHNlbWF0aWNzIGNsZWFyLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkl0IHNlZW1zIHRoYXQgR2V0IHdpdGggT2JzZXJ2ZSBvcHRpb24g b2YgQkVJTkcgaW50ZXJldGVkIGNhbiBkbyBzdWJzY3JpcHRpb24sIGFuZCBHZXQgd2l0aCBPYnNl cnZlIG9wdGlvbiBvZiZuYnNwOyBOT1QgaW50ZXJlc3RlZCB3aWxsIGRvIGNhbmNlbGxhdGlvbi4m bmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SSB0aGluayB0aGF0IHRoZSBDb0FQ IG9ic2VydmF0aW9uIG9wZXJhdG9pbnMgYXJlIG11Y2ggbGlrZSBvcGVyYXRpb25zIG9mIHN1YmNy aXB0aW9uL3Vuc3Vic2NyaXB0aW9uIG9mIElFVEYgbWFpbGluZyBsaXN0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+UmVnYXJkcywNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+R2Vu Z3l1DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5ldHdvcmsgVGVjaG5vbG9neSBDZW50 ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U2Nob29sIG9mIENvbXB1 dGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkJlaWppbmcgVW5pdmVy c2l0eSBvZiBQb3N0cyBhbmQgVGVsZWNvbW11bmljYXRpb25zPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGVzbW9rZSI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjxhIGhyZWY9Im1h aWx0bzpoYXJ0a2VAdHppLm9yZyIgdGl0bGU9ImhhcnRrZUB0emkub3JnIj5LbGF1cyBIYXJ0a2U8 L2E+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlc21va2UiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U2VudDo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IFdlZG5lc2Rh eSwNCiBNYXJjaCAxMiwgMjAxNCA1OjEzIEFNPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGVzbW9r ZSI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5Ubzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+DQo8YSBocmVmPSJtYWlsdG86WmFjaC5TaGVsYnlAYXJtLmNvbSIgdGl0bGU9 IlphY2guU2hlbGJ5QGFybS5jb20iPlphY2ggU2hlbGJ5PC9hPiA8bzpwPg0KPC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlc21va2UiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+Q2M6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmci IHRpdGxlPSJjb3JlQGlldGYub3JnIj5tYWlsdG86Y29yZUBpZXRmLm9yZzwvYT4gOyA8YSBocmVm PSJtYWlsdG86aGFydGtlQHR6aS5vcmciIHRpdGxlPSJoYXJ0a2VAdHppLm9yZyI+DQpLbGF1cyBI YXJ0a2U8L2E+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlc21va2UiPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U3ViamVjdDo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ IFJlOg0KIFtjb3JlXSBPYnNlcnZlIENhbmNlbGxhdGlvbjogVGhlIG91dGNvbWU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SSdtIGFza2luZyBhYm91dCB0aGUgYWx0ZXJuYXRpdmUg c29sdXRpb24gd2hlcmUgdGhlIE9ic2VydmUgb3B0aW9uIGlzICpub3QqIHByZXNlbnQuIEhvdyBi YWQgaXMgdGhlIGltcGFjdCBvZiB0aGUgY2FuY2VsbGF0aW9uIGNoZWNrDQogdGhlcmU/IEluIG15 IGltcGxlbWVudGF0aW9uLCBpdCdzIGJhc2ljYWxseSBmcmVlLCBiZWNhdXNlIEknbSBwZXJmb3Jt aW5nIGEgc2ltaWxhciBjaGVjayBhbnl3YXkuJm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPktsYXVzPGJyPg0KPGJyPg0KT24gVHVlc2RheSwgMTEgTWFyY2ggMjAxNCwg WmFjaCBTaGVsYnkgJmx0OzxhIGhyZWY9Im1haWx0bzpaYWNoLlNoZWxieUBhcm0uY29tIj5aYWNo LlNoZWxieUBhcm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk9u IE1hciAxMSwgMjAxNCwgYXQgMTozNSBQTSwgS2xhdXMgSGFydGtlICZsdDs8YSBocmVmPSJqYXZh c2NyaXB0OjsiPmhhcnRrZUB0emkub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBX aXRoaW4gdGhlIGNsYXNzIG9mIHNvbHV0aW9ucyB3ZSBhZ3JlZWQgb24gKG92ZXJsb2FkaW5nIHRo ZSBHRVQ8YnI+DQomZ3Q7IG1ldGhvZCksIHRoZSBzaW1wbGVzdCBzb2x1dGlvbiBpcyBhIEdFVCBy ZXF1ZXN0IHdpdGhvdXQgT2JzZXJ2ZSBvcHRpb248YnI+DQomZ3Q7IGFuZCB3aXRoIHRoZSB0b2tl biBpbiB1c2UuIEhvdyBiYWQgaXMgaXRzIGRyYXdiYWNrIChoYXZpbmcgdG8gY2hlY2s8YnI+DQom Z3Q7IGZvciBhIHBvdGVudGlhbCBvYnNlcnZhdGlvbiB0byBiZSBjYW5jZWxlZCBvbiBldmVyeSBH RVQgcmVxdWVzdCk8YnI+DQomZ3Q7IHJlYWxseT88YnI+DQo8YnI+DQpBdCBsZWFzdCBmb3Igb3Vy IGltcGxlbWVudGF0aW9uIHRoZSBlZmZlY3QgaXMgbWluaW1hbC4gV2Ugb25seSBuZWVkIHRvIGEg Y2FuY2VsbGF0aW9uIGNoZWNrIHdoZW4gdGhlIE9ic2VydmUgb3B0aW9uIGlzIHByZXNlbnQsIHdo aWNoIHdlIG5lZWQgdG8gZG8gYW55d2F5cyBmb3IgcmVuZXdhbC48YnI+DQo8YnI+DQpaYWNoIFNo ZWxieTxicj4NCkRpcmVjdG9yIG9mIFRlY2hub2xvZ3k8YnI+DQpBUk0gSW50ZXJuZXQgb2YgVGhp bmdzIEJVPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5hcm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ d3d3LmFybS5jb208L2E+PGJyPg0KbW9iaWxlOiAmIzQzOzEgKDQwOCkgMjAzLTk0MzQ8YnI+DQpT a3lwZTogemRzaGVsYnk8YnI+DQpMaW5rZWRJbjogPGEgaHJlZj0iaHR0cDovL2ZpLmxpbmtlZGlu LmNvbS9pbi96YWNoc2hlbGJ5LyIgdGFyZ2V0PSJfYmxhbmsiPmZpLmxpbmtlZGluLmNvbS9pbi96 YWNoc2hlbGJ5LzwvYT48YnI+DQo8YnI+DQo8YnI+DQotLSBJTVBPUlRBTlQgTk9USUNFOiBUaGUg Y29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRp YWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8g bm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9y IGFueQ0KIHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBt ZWRpdW0uJm5ic3A7IFRoYW5rIHlvdS48YnI+DQo8YnI+DQpBUk0gTGltaXRlZCwgUmVnaXN0ZXJl ZCBvZmZpY2UgMTEwIEZ1bGJvdXJuIFJvYWQsIENhbWJyaWRnZSBDQjEgOU5KLCBSZWdpc3RlcmVk IGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMsIENvbXBhbnkgTm86Jm5ic3A7IDI1NTc1OTA8YnI+DQpB Uk0gSG9sZGluZ3MgcGxjLCBSZWdpc3RlcmVkIG9mZmljZSAxMTAgRnVsYm91cm4gUm9hZCwgQ2Ft YnJpZGdlIENCMSA5TkosIFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcywgQ29tcGFu eSBObzombmJzcDsgMjU0ODc4Mjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJqYXZhc2NyaXB0OjsiPmNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMyIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50 ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY29yZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_34966E97BE8AD64EAE9D3D6E4DEE36F252B03166SZXEMA501MBSchi_-- From nobody Wed Mar 12 01:35:25 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864161A0915 for ; Wed, 12 Mar 2014 01:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.873 X-Spam-Level: *** X-Spam-Status: No, score=3.873 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dd1qk4rU6lPm for ; Wed, 12 Mar 2014 01:35:16 -0700 (PDT) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id C36141A0916 for ; Wed, 12 Mar 2014 01:35:15 -0700 (PDT) Received: by mail-ea0-f180.google.com with SMTP id m10so4781253eaj.11 for ; Wed, 12 Mar 2014 01:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=q/B13abEYOZUGcospVKlUNXrTJyfQgWxKxq2Q8CtZtk=; b=Yev6KWBollYbfx2bOpCPnPHr2a9hLyvA57OI8ztll0q8OaGK6JHt2MBQAbx2hR0zwU tv0I6jZ1ts9fDOKFvDQzVWZYrH96nHkxB4CRurVM4gTbbSpe1JkXbMEVfHc8ukAoMxZA oEfGH9ozR4JJf2QBaU6UTzCAAJQD71njfoMgzoetWa5mjYbipqcbzjycswLtoLr+tE1U qwS0uYnwh6vmqVCDSJrLfieDcRk4QbzK0E4hK27oz7nyK2fk1gfXSPXwvuQXgnV2Ga7f GpKPXz9LHIzy6tOG/yY/jU3GjHHeoR21PkG8bpO6gJ0qum/hGGDFXQqp3/rzJdv4cwQc muCA== MIME-Version: 1.0 X-Received: by 10.14.111.201 with SMTP id w49mr1751504eeg.92.1394613309292; Wed, 12 Mar 2014 01:35:09 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.14.116.131 with HTTP; Wed, 12 Mar 2014 01:35:09 -0700 (PDT) In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252B03166@SZXEMA501-MBS.china.huawei.com> References: <5A8F12CD-25B5-4915-A298-0AB0F6FA47F7@tzi.org> <99F741693CE649BEAF289E58EF76BAC0@WeiGengyuPC> <34966E97BE8AD64EAE9D3D6E4DEE36F252B03166@SZXEMA501-MBS.china.huawei.com> Date: Wed, 12 Mar 2014 08:35:09 +0000 X-Google-Sender-Auth: 1tad1T5cGLr0YkjnxY1tBlD7_uA Message-ID: From: Robert Cragie To: Likepeng Content-Type: multipart/alternative; boundary=089e016815eae645eb04f464b6ad Archived-At: http://mailarchive.ietf.org/arch/msg/core/VQLS1CmjWEsQ1q3164wiH3VHJAs Cc: "core@ietf.org" , Klaus Hartke Subject: Re: [core] Observe Cancellation: The outcome X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 08:35:20 -0000 --089e016815eae645eb04f464b6ad Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable +! - the semantics should be clear. The absence of the option does not imply cancellation in the actual message itself. Robert On 12 March 2014 06:43, Likepeng wrote: > >To define =A1=B0the Observe option is *not* present=A1=B1 means =A1=B0C= ancellation=A1=B1 is > not good choice, I think. > > > > Agree, that is where the issue (having to check for a potential > observation to be canceled on every GET request) coming from. > > > > >Why not to make the semantics clear. > > >It seems that Get with Observe option of BEING interested can do > subscription, and Get with Observe option of NOT interested will do > cancellation. > > > > Agree to make it clear, that is. Give =A1=B0Observe=A1=B1 option a value. > > > > Kind Regards > > Kepeng > > > > *=B7=A2=BC=FE=C8=CB:* core [mailto:core-bounces@ietf.org] *=B4=FA=B1=ED *= weigengyu > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2014=C4=EA3=D4=C212=C8=D5 11:15 > *=CA=D5=BC=FE=C8=CB:* Klaus Hartke; Zach Shelby > *=B3=AD=CB=CD:* core@ietf.org > *=D6=F7=CC=E2:* Re: [core] Observe Cancellation: The outcome > > > > Hi Klaus and all, > > > > To define =A1=B0the Observe option is *not* present=A1=B1 means =A1=B0Can= cellation=A1=B1 is > not good choice, I think. > > > > Why not to make the sematics clear. > > It seems that Get with Observe option of BEING intereted can do > subscription, and Get with Observe option of NOT interested will do > cancellation. > > > > I think that the CoAP observation operatoins are much like operations of > subcription/unsubscription of IETF mailing list. > > > > Regards, > > > > Gengyu > > > > Network Technology Center > > School of Computer > > Beijing University of Posts and Telecommunications > > *From:* Klaus Hartke > > *Sent:* Wednesday, March 12, 2014 5:13 AM > > *To:* Zach Shelby > > *Cc:* mailto:core@ietf.org ; Klaus Hartke > > *Subject:* Re: [core] Observe Cancellation: The outcome > > > > I'm asking about the alternative solution where the Observe option is > *not* present. How bad is the impact of the cancellation check there? In = my > implementation, it's basically free, because I'm performing a similar che= ck > anyway. > > > > Klaus > > On Tuesday, 11 March 2014, Zach Shelby wrote: > > On Mar 11, 2014, at 1:35 PM, Klaus Hartke wrote: > > > Within the class of solutions we agreed on (overloading the GET > > method), the simplest solution is a GET request without Observe option > > and with the token in use. How bad is its drawback (having to check > > for a potential observation to be canceled on every GET request) > > really? > > At least for our implementation the effect is minimal. We only need to a > cancellation check when the Observe option is present, which we need to d= o > anyways for renewal. > > Zach Shelby > Director of Technology > ARM Internet of Things BU > www.arm.com > mobile: +1 (408) 203-9434 > Skype: zdshelby > LinkedIn: fi.linkedin.com/in/zachshelby/ > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2548782 > > _______________________________________________ > 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 > > --089e016815eae645eb04f464b6ad Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
+! - the semantics should be clear. The absence of the opt= ion does not imply cancellation in the actual message itself.

Robert


On 12 March 2014 06:43, Likepeng <likepeng@huawei.com> wro= te:

>To define “the Observe option i= s *not* present” means “Cancellation” is not good choice,= I think.

 

Agree, that is where the issue (hav= ing to check for a potential observation to be canceled on every GET reques= t) coming from.

 

>Why not to make the semantics clear.&= nbsp;

>It seems that Get with Observe option= of BEING interested can do subscription, and Get with Observe option of&nb= sp; NOT interested will do cancellation. 

&nb= sp;

Agree to make it clear, that is. Give &ld= quo;Observe” option a value.

 

Kind Regards

Kepeng

&nb= sp;

=B7=A2=BC=FE=C8= =CB: core [mailto:core-bounces@ietf.org] =B4=FA=B1=ED weigengyu
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA3=D4=C212=C8=D5 1= 1:15
=CA=D5=BC=FE=C8=CB: Klaus Hartke; Zach Shelby
=B3=AD=CB=CD: core@ietf.org
=D6=F7=CC=E2: Re: [core] Observe Cancellation: The outcome<= /p>

 

Hi Klaus and all,

 

To define “the Observe option is *n= ot* present” means “Cancellation” is not good choice, I t= hink.

 

Why not to make the sematics clear. 

It seems that Get with Observe option of = BEING intereted can do subscription, and Get with Observe option of  N= OT interested will do cancellation. 

 

I think that the CoAP observation operato= ins are much like operations of subcription/unsubscription of IETF mailing = list.

 

Regards,

 

Gengyu

 

Network Technology Center

School of Computer

Beijing University of Posts and Telecommu= nications

From: Klaus Hartke

Sent: Wednesday, March 12, 2014 5:13 AM

Subject: Re: [core] Observe Cancellation: The outcome

 

I'm asking about the alternativ= e solution where the Observe option is *not* present. How bad is the impact= of the cancellation check there? In my implementation, it's basically free, because I'm perf= orming a similar check anyway. =

 

Klaus

On Tuesday, 11 March 2014, Zach Shelby <Zach.Shelby@arm.com> wrote:

On Mar 11, 2014, at 1:35 PM, Klaus Hartke= <hartke@tzi.org> wrote:

> Within the class of solutions we agreed on (overloading the GET
> method), the simplest solution is a GET request without Observe option=
> and with the token in use. How bad is its drawback (having to check > for a potential observation to be canceled on every GET request)
> really?

At least for our implementation the effect is minimal. We only need to a ca= ncellation check when the Observe option is present, which we need to do an= yways for renewal.

Zach Shelby
Director of Technology
ARM Internet of Things BU
www.arm.com
mobile: +1 (408) 203-9434
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/


-- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.<= br>
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No:  2548782

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

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


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


--089e016815eae645eb04f464b6ad-- From nobody Wed Mar 12 02:51:12 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDEC1A0944 for ; Wed, 12 Mar 2014 02:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04l0_PAeSLeS for ; Wed, 12 Mar 2014 02:50:55 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 407AB1A093F for ; Wed, 12 Mar 2014 02:50:51 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2C9ohnd008851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Mar 2014 04:50:45 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2C9ohH2023571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Mar 2014 10:50:43 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.236]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 12 Mar 2014 10:50:43 +0100 From: "FOSSATI, Thomas (Thomas)" To: Carsten Bormann Thread-Topic: draft-ietf-core-links-json-01 review Thread-Index: AQHPPVKd12SgOxUEOkmGDtwQGVY9wZrcWBAAgADNlAA= Date: Wed, 12 Mar 2014 09:50:43 +0000 Message-ID: References: <22537787-6932-42B4-AB4E-65E2FC1DDF55@tzi.org> In-Reply-To: <22537787-6932-42B4-AB4E-65E2FC1DDF55@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/core/ainye3YtO1dgEWJhSWbgAs7OYu0 Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-links-json-01 review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 09:51:05 -0000 T24gMTEvMDMvMjAxNCAyMTozNCwgIkNhcnN0ZW4gQm9ybWFubiIgPGNhYm9AdHppLm9yZz4gd3Jv dGU6DQo+SeKAmWxsIHRyeSB0byBhZGQgc29tZSwgYnV0IG5vdCB0b28gbXVjaCwgdGV4dCB0byB0 aGlzIGVmZmVjdC4NCg0KR3JlYXQsIHRoYW5rcy4NCg0KPj5BbHNvIEkgdGhpbmsgdGhhdCBpdCdk IGJlIG5pY2UgdG8gZ2l2ZSB0aGUgcmVhZGVyIGVub3VnaCBjb250ZXh0IHRvDQo+PiB1bmRlcnN0 YW5kIGhvdyBKU09OIGxpbmsgZGlmZmVycyBmcm9tIG90aGVyIHNpbWlsYXIgcHJvcG9zYWxzIChK U09ODQo+PiBmb3JtYXRzIEpTT04tTEQsIEpTT04gUmVmZXJlbmNlLCBIQUwsIGV0Yy4pIGFuZCB3 aHkgaXQgaXMgYSBiZXR0ZXINCj4+Y2hvaWNlDQo+PiB0aGFuIGFueSBvZiB0aG9zZSBmb3Igb3Vy IHVzZSBjYXNlLg0KPg0KPlRoZSBjdXJyZW50IHRleHQgaXMgbWVudGlvbmluZyBNTk9UMTEuICBB Z2FpbiwgSSB3b3VsZG7igJl0IHdhbnQgdG8gZXhwYW5kDQo+dGhpcyB0b28gbXVjaC4NCj5JdCBt YXkgYmUgd29ydGggdG8gYWRkIGV4cGxhbmF0aW9uIG9uIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4g 4oCcTGlua2luZw0KPmZyb20gSlNPTuKAnSAod2hpY2ggSlNPTi1MRCBpcyBhYm91dCkgYW5kIOKA nEpTT04gcmVwcmVzZW50YXRpb24gb2YgbGlua3PigJ0sDQo+d2hpY2ggdGhpcyBpcyBhYm91dC4N Cg0KSeKAmWQgYXZvaWQgcmVmZXJlbmNpbmcgbW5vdCdzIGJsb2csIGFuZCB3b3VsZCByYXRoZXIg YWRkIHRoZSBwb2ludGVyIGZvcg0KdGhlIEpTT04tTEQgVzND4oCZcyBUUj8NCg0KPj4gUmU6IHRo ZSBpbXBsaWNpdCB2cyBleHBsaWNpdCByZWw9Imhvc3RzIiBpbiBTZWN0aW9uIDIsIEknZCBiZSBp bmNsaW5lZA0KPj50bw0KPj4gYWRkIGl0IGV4cGxpY2l0bHkgYmVjYXVzZSBpbiB0aGUgd2lkZXIg d2ViIGl0IGNhbuKAmXQgYmUgYXNzdW1lZCwgYnV0DQo+PndvdWxkDQo+PiBsb3ZlIHRvIGhlYXIg ZnJvbSB5b3UgYW5kL29yICBvdGhlcnMgZm9yIHJlYXNvbnMgd2h5IGl0IHNob3VsZG7igJl0Lg0K Pg0KPkdyZWF0IHF1ZXN0aW9uLiAgTXkgYXNzdW1wdGlvbiBzbyBmYXIgd2FzIHRoYXQgYm90aCB0 aGUgbGluay1mb3JtYXQgYW5kDQo+dGhlIGxpbmtzLWpzb24gY29uc3VtZXIgb3BlcmF0ZSBmcm9t IHRoZSBzYW1lIHNlbWFudGljcywgc28gdGhlIHR3bw0KPnJlcHJlc2VudGF0aW9ucyBvbmx5IGRp ZmZlciBpbiBzeW50YXguDQo+VGhlIGFsdGVybmF0aXZlLCBhZGRpbmcgYSBzZW1hbnRpYyB0cmFu c2Zvcm0sIG1heSBtYWtlIHRoZSBKU09OIGVhc2llciB0bw0KPnByb2Nlc3Mgd2l0aG91dCBrbm93 bGVkZ2Ugb2YgdGhlIGxpbmstZm9ybWF0IHNlbWFudGljcywgYnV0IGFkZHMNCj5yb3VuZHRyaXBw aW5nIGhlYWRhY2hlcy4gIElzIGl0IHdvcnRoIGl0Pw0KDQpXaGF0IGRvIHlvdSBtZWFuIGV4YWN0 bHkgYnkg4oCccm91bmR0cmlwcGluZyBoZWFkYWNoZXPigJ0/DQoNCkxvb2tpbmcgYXQgb3VyIHVz ZSBjYXNlIChIVFRQLUNvQVAgcHJveHkgZGlzY292ZXJ5KSwgSSBkb27igJl0IHNlZSBhbnkNCnBy b2JsZW0gaW4gd2FzdGluZyB+MTAgYnl0ZXMgb24gdGhlIHVuY29uc3RyYWluZWQgc2lkZSBvZiB0 aGUgcHJveHkgdG8NCm1ha2UgdGhlIHJlbGF0aW9uIGV4cGxpY2l0Lg0KDQo+SeKAmWxsIHVwZGF0 ZSB0aGUgZHJhZnQgaW4gdGhlIG5leHQgNSBkYXlzIG9yIHNvIGJhc2VkIG9uIHRoaXMgaW5wdXQu DQo+DQo+UHJldmlvdXNseSwgd2Ugc2FpZCB0aGF0IHdlIHdhbnRlZCB0byB3YWl0IHdpdGggYWR2 YW5jaW5nIHRoaXMgZHJhZnQNCj51bnRpbCB3ZSBoYXZlIG1vcmUgaW1wbGVtZW50YXRpb24gZXhw ZXJpZW5jZS4NCj5JIHRoaW5rIGl0IGlzIHdvcnRoIGNoZWNraW5nIGlmIHRoZXJlIGFyZSBub3cg bW9yZSBpbXBsZW1lbnRhdGlvbnMsIGFuZCwNCj5pZiB5ZXMsIGFuZCBhc3N1bWluZyB0aGV5IGRv buKAmXQgcmV2ZWFsIGdyb3VuZGJyZWFraW5nIGZsYXdzLCBnb2luZyBmb3IgYQ0KPldHTEMgc29v bi4gIChUaGlzIHdvdWxkIGFsc28gYWxsb3cgdXMgdG8gc3RheSByZWFzb25hYmx5IGNsb3NlIHRv IG91ciBKYW4NCj4yMDE0IG1pbGVzdG9uZSBmb3IgdGhpcy4pDQoNClRoYW5rIHlvdSB2ZXJ5IG11 Y2g7IEnigJltIGxvb2tpbmcgZm9yd2FyZCBmb3IgdGhlIHVwZGF0ZS4NCg0KQW5kIEJUVywgZG8g eW91IHRoaW5rIGl04oCZZCBiZSBzZW5zaWJsZSB0byBzcGVjaWZ5IEpTT04gbGluayBhcyB0aGUN ClJFQ09NTUVOREVEIHNlcmlhbGlzYXRpb24gZm9ybWF0IGZvciB0aGUgSEMgcHJveHkgZGlzY292 ZXJ5IG1lY2hhbmlzbSBpbg0KdGhlIGh0dHAtbWFwcGluZyBJLUQ/DQoNCkNoZWVycw0KDQo= From nobody Thu Mar 27 15:18:28 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1C81A03DA for ; Thu, 27 Mar 2014 15:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9m7rkvvWT2n for ; Thu, 27 Mar 2014 15:18:19 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC511A03D1 for ; Thu, 27 Mar 2014 15:18:19 -0700 (PDT) X-ASG-Debug-ID: 1395958695-06daaa1bd853e80001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id p3HADBXY0pkteEGq for ; Thu, 27 Mar 2014 18:18:15 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Mar 2014 18:18:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CF4A0A.897487B9" Date: Thu, 27 Mar 2014 18:18:52 -0400 X-ASG-Orig-Subj: RE: [core] Fw: New Version Notification for draft-bhattacharyya-core-coap-lite-auth-00 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Fw: New Version Notification for draft-bhattacharyya-core-coap-lite-auth-00 Thread-Index: Ac826bcMGw3faaadTjmlQqkZpojyIgTHH9bw References: From: "Rahman, Akbar" To: "Abhijan Bhattacharyya" X-OriginalArrivalTime: 27 Mar 2014 22:18:53.0538 (UTC) FILETIME=[89949C20:01CF4A0A] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1395958695 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO, DRUGS_MUSCLE, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.4319 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 DRUGS_MUSCLE Refers to a muscle relaxant Archived-At: http://mailarchive.ietf.org/arch/msg/core/Il3IK_sajjRJ7RziQb2aVp9UPuE Cc: core@ietf.org Subject: Re: [core] Fw: New Version Notification for draft-bhattacharyya-core-coap-lite-auth-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 22:18:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CF4A0A.897487B9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Abhijan, =20 =20 I had a chance to read your interesting draft, and had some initial questions: =20 =20 * If you carry the Authentication payload in the POST (e.g. Figure 2) does that mean it is carried in clear text? Or do you actually already have a DTLS session underneath CoAP? The sequence of events is not clear to me. =20 * Did you consider taking your draft to DICE ( http://datatracker.ietf.org/wg/dice/charter/ ) where it seems to fit the charter much better than CORE? * Editorial: What was the "WIP" in the title referring to? =20 =20 Thanks, =20 =20 Akbar =20 =20 =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyya Sent: Monday, March 03, 2014 9:04 AM To: core@ietf.org WG Subject: [core] Fw: New Version Notification for draft-bhattacharyya-core-coap-lite-auth-00 =20 Dear All, We have uploaded a proposal on a lightweight application-layer mutual authentication scheme for CoAP. Since this was specific to CoAP we have uploaded in CoRE. Not sure if ACE would have been a suitable place. But, ACE is yet come up with a concrete problem definition. So, keeping it in CoRE so that at least the proposal could be publicly accessed if considered as a potential solution to some requirements. =20 The draft is part of a larger work in progress with some promising results. =20 =20 Comments, suggestions are welcome. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----Forwarded by Abhijan Bhattacharyya/KOL/TCS on 03/03/2014 07:23PM ----- To: Soma Bandyopadhyay , "Soma Bandyopadhyay" , "Abhijan Bhattacharyya" , "Arijit Ukil" , Arijit Ukil , Arpan Pal , "Arpan Pal" , "Tulika Bose" , Abhijan Bhattacharyya , Tulika Bose From: internet-drafts@ietf.org Date: 03/03/2014 07:07PM Subject: New Version Notification for draft-bhattacharyya-core-coap-lite-auth-00.txt A new version of I-D, draft-bhattacharyya-core-coap-lite-auth-00.txt has been successfully submitted by Abhijan Bhattacharyya and posted to the IETF repository. Name: draft-bhattacharyya-core-coap-lite-auth Revision: 00 Title: Lightweight mutual authentication for CoAP (WIP) Document date: 2014-03-03 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-bhattacharyya-core-coap-lite-a uth-00.txt Status: https://datatracker.ietf.org/doc/draft-bhattacharyya-core-coap-lite-auth / Htmlized: http://tools.ietf.org/html/draft-bhattacharyya-core-coap-lite-auth-00 Abstract: This draft presents a work-in-progress on a challenge-response based lightweight authentication scheme to mutually authenticate CoAP client and server for establishing a secure unicast communication channel. The draft discusses the generic idea behind the proposed authentication scheme, as well as presents its CoAP specific adoption. The proposed scheme has low communication overhead and can be a robust alternative against the usual DTLS based connection initiation scheme with PSK. =20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain=20 confidential or privileged information. If you are=20 not the intended recipient, any dissemination, use,=20 review, distribution, printing or copying of the=20 information contained in this e-mail message=20 and/or attachments to it are strictly prohibited. If=20 you have received this communication in error,=20 please notify us by reply e-mail or telephone and=20 immediately and permanently delete the message=20 and any attachments. Thank you ------_=_NextPart_001_01CF4A0A.897487B9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Abhijan,

 

 

I had a chance to read your interesting draft, and had some initial = questions:

 

 

·         = If you carry the Authentication payload in the POST (e.g. Figure 2) = does that mean it is carried in clear text?  Or do  you = actually already have a DTLS session underneath CoAP?  The sequence = of events is not clear to me.

 

·         = Did you consider taking your draft to DICE ( http://datatracker.= ietf.org/wg/dice/charter/ ) where it seems to fit the charter much = better than CORE?

·         = Editorial: What was the “WIP” in the title referring = to?

 

 

Thanks,

 

 

Akbar

 

 

 

From:= = core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan = Bhattacharyya
Sent: Monday, March 03, 2014 9:04 = AM
To: core@ietf.org WG
Subject: [core] Fw: New = Version Notification for = draft-bhattacharyya-core-coap-lite-auth-00

 

Dear = All,

We have = uploaded a proposal on a lightweight application-layer mutual = authentication scheme for CoAP. Since this was specific to CoAP we have = uploaded in CoRE. Not sure if ACE would have been a suitable place. But, = ACE is yet come up with a concrete problem definition. So, keeping it in = CoRE so that at least the proposal could be publicly accessed if = considered as a potential solution to some = requirements.

 =

The draft = is part of a larger work in progress with some promising results. =  

 =

Comments, = suggestions are welcome.


Regards
Abhijan = Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, = Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.c= om
Website: http://www.tcs.com
___________________= _________________________
Experience certainty. IT = Services
Business = Solutions
Consulting
____________________________________________



-----Forwarded by Abhijan = Bhattacharyya/KOL/TCS on 03/03/2014 07:23PM = -----

To: Soma = Bandyopadhyay <soma.bandyopadhyay@tcs.com= >, "Soma Bandyopadhyay" <soma.bandyopadhyay@tcs.com= >, "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.c= om>, "Arijit Ukil" <arijit.ukil@tcs.com>, Arijit = Ukil <arijit.ukil@tcs.com>, Arpan = Pal <arpan.pal@tcs.com>, = "Arpan Pal" <arpan.pal@tcs.com>, = "Tulika Bose" <tulika.bose@tcs.com>, Abhijan = Bhattacharyya <abhijan.bhattacharyya@tcs.c= om>, Tulika Bose <tulika.bose@tcs.com>
From: = internet-drafts@ietf.org
= Date: 03/03/2014 07:07PM
Subject: New Version Notification for = draft-bhattacharyya-core-coap-lite-auth-00.txt

=

A new version of I-D, = draft-bhattacharyya-core-coap-lite-auth-00.txt
has been successfully = submitted by Abhijan Bhattacharyya and posted to the
IETF = repository.

Name: = draft-bhattacharyya-core-coap-lite-auth
Revision: 00
Title: = Lightweight mutual authentication for CoAP (WIP)
Document date: = 2014-03-03
Group: Individual Submission
Pages: 11
URL:   =          http://www.ietf.org/internet-drafts/draft-bhattacharyy= a-core-coap-lite-auth-00.txt
Status:         = https://datatracker.ietf.org/doc/draft-bhattacharyya-core-coap-= lite-auth/
Htmlized:       http://tools.ietf.org/html/draft-bhattacharyya-core-coap-lite-auth-= 00


Abstract:
   This draft presents a = work-in-progress on a challenge-response based
   = lightweight authentication scheme to mutually authenticate = CoAP
   client and server for establishing a secure unicast = communication
   channel. The draft discusses the generic = idea behind the proposed
   authentication scheme, as well = as presents its CoAP specific
   adoption. The proposed = scheme has low communication overhead and can
   be a = robust alternative against the usual DTLS based = connection
   initiation scheme with = PSK.

               =                     =                     =                     =        


Please note that it may take a = couple of minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

The IETF = Secretariat=

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

------_=_NextPart_001_01CF4A0A.897487B9-- From nobody Thu Mar 27 20:03:56 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9BB1A0427 for ; Thu, 27 Mar 2014 20:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m12IEY8ZGoBn for ; Thu, 27 Mar 2014 20:03:51 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id EB9F81A006D for ; Thu, 27 Mar 2014 20:03:49 -0700 (PDT) Received: from WeiGengyuPC (unknown [10.103.244.154]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id EE72E19F36A; Fri, 28 Mar 2014 11:03:44 +0800 (HKT) Message-ID: <146BA183A28B4C6DBF8EA90D49B5724C@WeiGengyuPC> From: "weigengyu" To: Date: Fri, 28 Mar 2014 11:03:43 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01CF4A75.624FCDE0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/vkMVruOoSet8yOv4W4Ilym28iyk Cc: core@ietf.org Subject: Re: [core] draft-rahman-core-sleepy-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 03:03:55 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_005F_01CF4A75.624FCDE0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Akbar, About draft-rahman-core-sleepy-05 Enhanced Sleepy Node Support for CoAP, = I have a question.=20 Defining Sleep Para to tackle sleep nodes in CoRE networks is an = essential work and important.=20 By the Figure 3: Prototype Configuration, you propose to add RD Sleep Para into proxy (CoAP Reverse Proxy).=20 Is it possible to transfer Sleep Para into CoAP Client?=20 It is the CoAP Client to intial each CoAP request, =20 and the CoAP Client may get the infomations about the resources from the = ACK of the first access, if possible.=20 With this knowledge, the CoAP client could choose the adquate chance to = send request,=20 and estimate the duration to wait for response. =20 Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts and Telecommunications. ------=_NextPart_000_005F_01CF4A75.624FCDE0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Akbar,
 
About draft-rahman-core-sleepy-05 Enhanced Sleepy Node Support for CoAP, I have a question. =
 
Defining Sleep Para to tackle sleep nodes in = CoRE=20 networks is an essential work and important.
 
By the Figure 3: Prototype = Configuration,
you propose to add RD Sleep Para into proxy = (CoAP=20 Reverse Proxy).
 
Is it possible to transfer Sleep Para into = CoAP Client?=20
It is the CoAP Client to intial each CoAP = request, =20
and the CoAP Client may get the infomations = about the=20 resources from the ACK of the first access, = if=20 possible.
 
With this knowledge, the CoAP client could = choose the=20 adquate chance to send request,
and estimate the duration to wait for = response.=20  
 
 
Regards,
 
Gengyu
 
Network Technology Center
School of Computer
Beijing University of Posts and=20 Telecommunications.
 
------=_NextPart_000_005F_01CF4A75.624FCDE0-- From nobody Mon Mar 31 02:57:32 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494B91A0988 for ; Mon, 31 Mar 2014 02:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Veqvh_x4KTnd for ; Mon, 31 Mar 2014 02:57:28 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7C31A0820 for ; Mon, 31 Mar 2014 02:57:27 -0700 (PDT) Received: from WeiGengyuPC (unknown [10.103.244.154]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 1FA7519F372; Mon, 31 Mar 2014 17:57:22 +0800 (HKT) Message-ID: <24D85E520FCE4FD0AF1A451A102FA5FB@WeiGengyuPC> From: "weigengyu" To: References: <146BA183A28B4C6DBF8EA90D49B5724C@WeiGengyuPC> In-Reply-To: <146BA183A28B4C6DBF8EA90D49B5724C@WeiGengyuPC> Date: Mon, 31 Mar 2014 17:57:21 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01CF4D0A.A9F10370" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/B8zVVTXBx4NT8Qxq3g6bBCYmAM0 Cc: core@ietf.org Subject: Re: [core] draft-rahman-core-sleepy-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 09:57:31 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0010_01CF4D0A.A9F10370 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Akbai,=20 I would like to make my question clear. In your work, =A1=B0Enhanced Sleepy Node Support for CoAP IETF 87, July = 2013, Sleepy Node Performance Analysis=A1=B1 in the PPT page of =A1=B0Reverse Proxy Features for Sleepy Node = Support=A1=B1=20 there are following descriptions:=20 =A1=B0Sleep-aware CoAP 5.03 Response Capability=20 If CoAP request to a sleeping server is received (and there is no valid = cache for that request), proxy returns a =A1=AE5.03 Retry-After=A1=AF = response to client =20 5.03 contains a timestamp indicating when the sever will wake back up = (timestamp delivered in CoAP maxAge option) =A1=B0=20 In our researching work, the CoAP server has three working modes: = active, receive-only, and sleep. active mode: the server can send and receiv; receive-only mode: the server can receive, not send; sleep mode: the server can neither send nor receive. So, in the situation when the CoAP server is in receive-only mode, the = proxy should forward the request to the server.=20 The CoAP server could receive the request and give a response after a = while.=20 The proxy need to return =A1=B0Waiting for a while=A1=B1 instead of = =A1=B0The Retry =A8CAfter=A1=B1.=20 This may be due to how we define the sleepy node.=20 And, the requirement is to consider three working modes of CoAP server = when handling sleepy nodes.=20 if the CoAP Client get this knowledge it may be good to get better the = communication efficiency in CoRE networks. Regards,=20 Gengyu=20 Network Techonolgy Center School of Computer Beijing University of Posts and Telecommunications From: weigengyu=20 Sent: Friday, March 28, 2014 11:03 AM To: Akbar.Rahman@InterDigital.com=20 Cc: core@ietf.org=20 Subject: Re: [core] draft-rahman-core-sleepy-05 Hi Akbar, About draft-rahman-core-sleepy-05 Enhanced Sleepy Node Support for CoAP, = I have a question.=20 Defining Sleep Para to tackle sleep nodes in CoRE networks is an = essential work and important.=20 By the Figure 3: Prototype Configuration, you propose to add RD Sleep Para into proxy (CoAP Reverse Proxy).=20 Is it possible to transfer Sleep Para into CoAP Client?=20 It is the CoAP Client to intial each CoAP request, =20 and the CoAP Client may get the infomations about the resources from the = ACK of the first access, if possible.=20 With this knowledge, the CoAP client could choose the adquate chance to = send request,=20 and estimate the duration to wait for response. =20 Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts and Telecommunications. -------------------------------------------------------------------------= ------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_0010_01CF4D0A.A9F10370 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Akbai,
 
I would like to make my question clear.
 
In your work, =A1=B0Enhanced Sleepy Node Support for CoAP IETF 87, = July 2013,=20 Sleepy Node Performance Analysis=A1=B1
in the PPT page of =A1=B0Reverse Proxy Features for Sleepy Node = Support=A1=B1
there are following descriptions:
=A1=B0Sleep-aware CoAP 5.03 Response Capability
If CoAP request to a sleeping server is received (and there is no = valid=20 cache for that request), proxy returns a =A1=AE5.03 Retry-After=A1=AF = response to=20 client 
5.03 contains a timestamp indicating when the sever will wake back = up=20 (timestamp delivered in CoAP maxAge option) =A1=B0
 
In our researching work, the CoAP server has three=20 working modes: active, receive-only, and sleep.
active mode: the server can send and receiv;
receive-only mode: the server can receive, not send;
sleep mode: the server can neither send nor receive.
 
So, in the situation when the CoAP server is in receive-only mode, = the=20 proxy should forward the request to the server.
The CoAP server could receive the request and give a  response = after a=20 while.
The proxy need to return =A1=B0Waiting for a while=A1=B1 instead of = =A1=B0The Retry=20 =A8CAfter=A1=B1.
 
This may be due to how we define the sleepy node.
And, the requirement is to consider three working modes of CoAP = server when=20 handling sleepy nodes.
 
if the CoAP Client get this knowledge it may be good to get better = the=20 communication efficiency in CoRE networks.
 
Regards,
 
Gengyu
 
Network Techonolgy = Center
School of Computer
Beijing University of Posts and=20 Telecommunications
 
From: weigengyu
Sent: Friday, March 28, 2014 11:03 AM
Subject: Re: [core] = draft-rahman-core-sleepy-05
 
Hi Akbar,
 
About draft-rahman-core-sleepy-05 Enhanced Sleepy Node Support for CoAP, I have a question. =
 
Defining Sleep Para to tackle sleep nodes in = CoRE=20 networks is an essential work and important.
 
By the Figure 3: Prototype = Configuration,
you propose to add RD Sleep Para into proxy = (CoAP=20 Reverse Proxy).
 
Is it possible to transfer Sleep Para into = CoAP Client?=20
It is the CoAP Client to intial each CoAP = request, =20
and the CoAP Client may get the infomations = about the=20 resources from the ACK of the first access, = if=20 possible.
 
With this knowledge, the CoAP client could = choose the=20 adquate chance to send request,
and estimate the duration to wait for = response.=20  
 
 
Regards,
 
Gengyu
 
Network Technology Center
School of Computer
Beijing University of Posts and=20 Telecommunications.
 

_______________________________________________
core mailing=20 list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
------=_NextPart_000_0010_01CF4D0A.A9F10370-- From nobody Mon Mar 31 05:27:25 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A541A07C2 for ; Mon, 31 Mar 2014 05:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVxL-DdZLQtq for ; Mon, 31 Mar 2014 05:27:19 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 45F911A07B0 for ; Mon, 31 Mar 2014 05:27:19 -0700 (PDT) X-ASG-Debug-ID: 1396268834-06daaa1bd995e50001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id 6M4Lfz6CatbKXEZh for ; Mon, 31 Mar 2014 08:27:14 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Mar 2014 08:27:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CF4CDC.9B07A0DB" Date: Mon, 31 Mar 2014 08:27:38 -0400 X-ASG-Orig-Subj: RE: [core] draft-rahman-core-sleepy-05 Message-ID: In-Reply-To: <24D85E520FCE4FD0AF1A451A102FA5FB@WeiGengyuPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] draft-rahman-core-sleepy-05 Thread-Index: Ac9Mx73x7NVmChxiRVmoQ1X+CwRr/wAEyRvQ References: <146BA183A28B4C6DBF8EA90D49B5724C@WeiGengyuPC> <24D85E520FCE4FD0AF1A451A102FA5FB@WeiGengyuPC> From: "Rahman, Akbar" To: "weigengyu" X-OriginalArrivalTime: 31 Mar 2014 12:27:40.0167 (UTC) FILETIME=[9B74C170:01CF4CDC] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1396268834 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.4454 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/core/zORx2zMYK3Y1ez-i-ZoVJ1i_JKs Cc: core@ietf.org Subject: Re: [core] draft-rahman-core-sleepy-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 12:27:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CF4CDC.9B07A0DB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Weigengyu, =20 =20 =20 Thank you for the good questions. Following is my feedback: =20 =20 >So, in the situation when the CoAP server is in receive-only mode, the proxy should forward the request to the server.=20 >The CoAP server could receive the request and give a response after a while.=20 >The proxy need to return "Waiting for a while" instead of "The Retry -After".=20 =20 Is "Waiting for a while" a new CoAP Response code that needs to be defined? =20 =20 =20 >In our researching work, the CoAP server has three working modes: active, receive-only, and sleep. >active mode: the server can send and receiv; >receive-only mode: the server can receive, not send; >sleep mode: the server can neither send nor receive. =20 This is interesting. But, what is the main benefit of the receive-only mode? That is, since the CoAP model is request/response, what is the value of being able to send the request (e.g. GET) without knowing the response? =20 =20 =20 Best Regards, =20 =20 Akbar =20 =20 =20 From: weigengyu [mailto:weigengyu@bupt.edu.cn]=20 Sent: Monday, March 31, 2014 5:57 AM To: Rahman, Akbar Cc: core@ietf.org Subject: Re: [core] draft-rahman-core-sleepy-05 =20 Hi Akbai,=20 =20 I would like to make my question clear. =20 In your work, "Enhanced Sleepy Node Support for CoAP IETF 87, July 2013, Sleepy Node Performance Analysis" in the PPT page of "Reverse Proxy Features for Sleepy Node Support"=20 there are following descriptions:=20 "Sleep-aware CoAP 5.03 Response Capability=20 If CoAP request to a sleeping server is received (and there is no valid cache for that request), proxy returns a '5.03 Retry-After' response to client =20 5.03 contains a timestamp indicating when the sever will wake back up (timestamp delivered in CoAP maxAge option) "=20 =20 In our researching work, the CoAP server has three working modes: active, receive-only, and sleep. active mode: the server can send and receiv; receive-only mode: the server can receive, not send; sleep mode: the server can neither send nor receive. =20 So, in the situation when the CoAP server is in receive-only mode, the proxy should forward the request to the server.=20 The CoAP server could receive the request and give a response after a while.=20 The proxy need to return "Waiting for a while" instead of "The Retry -After".=20 =20 This may be due to how we define the sleepy node.=20 And, the requirement is to consider three working modes of CoAP server when handling sleepy nodes.=20 =20 if the CoAP Client get this knowledge it may be good to get better the communication efficiency in CoRE networks. =20 Regards,=20 =20 Gengyu=20 =20 Network Techonolgy Center School of Computer Beijing University of Posts and Telecommunications =20 From: weigengyu =20 Sent: Friday, March 28, 2014 11:03 AM To: Akbar.Rahman@InterDigital.com=20 Cc: core@ietf.org=20 Subject: Re: [core] draft-rahman-core-sleepy-05 =20 Hi Akbar, =20 About draft-rahman-core-sleepy-05 Enhanced Sleepy Node Support for CoAP, I have a question.=20 =20 Defining Sleep Para to tackle sleep nodes in CoRE networks is an essential work and important.=20 =20 By the Figure 3: Prototype Configuration, you propose to add RD Sleep Para into proxy (CoAP Reverse Proxy).=20 =20 Is it possible to transfer Sleep Para into CoAP Client?=20 It is the CoAP Client to intial each CoAP request, =20 and the CoAP Client may get the infomations about the resources from the ACK of the first access, if possible.=20 =20 With this knowledge, the CoAP client could choose the adquate chance to send request,=20 and estimate the duration to wait for response. =20 =20 =20 Regards, =20 Gengyu =20 Network Technology Center School of Computer Beijing University of Posts and Telecommunications. =20 ________________________________ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------_=_NextPart_001_01CF4CDC.9B07A0DB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Weigengyu,

 

 

 

Thank you for the good questions.  Following is my = feedback:

 

 

>So, in the = situation when the CoAP server is in receive-only mode, the proxy should = forward the request to the server.

>The CoAP = server could receive the request and give a  response after a = while.

>The proxy = need to return “Waiting for a while” instead of “The = Retry –After”.

 

Is = “Waiting for a while” a new CoAP Response code that needs to = be defined?

 

 

 

>In our = researching work, the CoAP server has three working modes: active, = receive-only, and sleep.

>active = mode: the server can send and receiv;

>receive-only= mode: the server can receive, not send;

>sleep mode: = the server can neither send nor receive.

 

This is = interesting.  But, what is the main benefit of the receive-only = mode?  That is, since the CoAP model is request/response, what is = the value of being able to send the request (e.g. GET) without knowing = the response?

 <= /o:p>

 <= /o:p>

 <= /o:p>

Best = Regards,

 <= /o:p>

 <= /o:p>

Akbar

 

 

 

From:= = weigengyu [mailto:weigengyu@bupt.edu.cn]
Sent: Monday, March = 31, 2014 5:57 AM
To: Rahman, Akbar
Cc: = core@ietf.org
Subject: Re: [core] = draft-rahman-core-sleepy-05

 

Hi Akbai, =

 

I would like to = make my question clear.

 

In your work, = “Enhanced Sleepy Node Support for CoAP IETF 87, July 2013, Sleepy = Node Performance Analysis”

in the PPT page = of “Reverse Proxy Features for Sleepy Node Support” =

there are = following descriptions:

“Sleep-awa= re CoAP 5.03 Response Capability

If CoAP request = to a sleeping server is received (and there is no valid cache for that = request), proxy returns a ‘5.03 Retry-After’ response to = client 

5.03 contains a = timestamp indicating when the sever will wake back up (timestamp = delivered in CoAP maxAge option) “ =

 

In our = researching work, the CoAP server has three working modes: active, = receive-only, and sleep.

active mode: = the server can send and receiv;

receive-only = mode: the server can receive, not = send;

sleep mode: the = server can neither send nor receive.

 

So, in the = situation when the CoAP server is in receive-only mode, the proxy should = forward the request to the server.

The CoAP server = could receive the request and give a  response after a while. =

The proxy need = to return “Waiting for a while” instead of “The Retry = –After”.

 

This may be due = to how we define the sleepy node.

And, the = requirement is to consider three working modes of CoAP server when = handling sleepy nodes.

 

if the CoAP = Client get this knowledge it may be good to get better the communication = efficiency in CoRE networks.

 

Regards, =

 

Gengyu =

=  

Network = Techonolgy Center=

School of = Computer=

Beijing = University of Posts and Telecommunications=

=  

= From:= weigengyu =

= Sent:= Friday, March 28, 2014 11:03 AM

= Cc:= core@ietf.org =

= Subject:= Re: [core] = draft-rahman-core-sleepy-05

<= p class=3DMsoNormal> 

Hi = Akbar,

 

About = draft-rahman-core-sleepy-05 Enhanced Sleepy Node Support for CoAP, I = have a question.

 

Defining Sleep Para = to tackle sleep nodes in CoRE networks is an essential work and = important.

 

By the Figure 3: = Prototype Configuration,

you propose to add = RD Sleep Para into proxy (CoAP Reverse Proxy).

 

Is it possible to = transfer Sleep Para into CoAP Client?

It is the CoAP = Client to intial each CoAP request, 

and the CoAP Client = may get the infomations about the resources from the ACK of the first = access, if possible.

 

With this knowledge, = the CoAP client could choose the adquate chance to send request, =

and estimate the = duration to wait for response.  

 

 

Regards,

 

Gengyu

 

Network Technology = Center

School of = Computer

Beijing University = of Posts and Telecommunications.

 

________________= _______________________________
core mailing list
core@ietf.org
https://www.ietf.org/= mailman/listinfo/core

------_=_NextPart_001_01CF4CDC.9B07A0DB-- From c.amsuess@energyharvesting.at Mon Mar 31 13:37:52 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D2E1A7001 for ; Mon, 31 Mar 2014 13:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ekwT2coXHbW for ; Mon, 31 Mar 2014 13:37:50 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) by ietfa.amsl.com (Postfix) with ESMTP id 777CB1A6FEB for ; Mon, 31 Mar 2014 13:37:49 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129201174.i1.akis.net [95.129.201.174]) by prometheus.amsuess.com (Postfix) with ESMTPS id 2F76042962 for ; Mon, 31 Mar 2014 22:37:45 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0559423 for ; Mon, 31 Mar 2014 22:37:44 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.153]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id D977E90 for ; Mon, 31 Mar 2014 22:37:43 +0200 (CEST) Received: (nullmailer pid 28872 invoked by uid 1000); Mon, 31 Mar 2014 20:37:43 -0000 Date: Mon, 31 Mar 2014 22:37:43 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "core@ietf.org WG" Message-ID: <20140331203743.GA6736@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/core/wlk5c-LrnOnUrrTdEVhHnn4vRUM X-Mailman-Approved-At: Mon, 31 Mar 2014 13:50:14 -0700 Subject: [core] Observing core-interfaces batches live and in history X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 20:39:52 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello working group, I've been using CoAP for some time in data monitoring applications, and observed patterns emerge that work well, but not necessarily fully conform to the specifications; I'd like to work out with you which parts of it can be generally useful, among other things allowing continuous logging of batches. * Having history available: core-interfaces mentions returning the latest measurements as a SenML time series. We are using the same concept for batches too, and internally compress lengthier histories (ie. more that you'd just send along in a single-block piggy-backed response) in our nodes' ram. I think it would be wise to advertise the capability of providing history, and to provide a common interface to querying it. Something like if=3D"core.s core.h" could indicate that some form of history is provided by the sensor, and a query with parameters similar to those in core-interfaces 5.9 would be ?tmin=3D1396134000, returning values no earlier than 00:00 today. A tmax query would set an upper limit. (So far, this is a minor suggestion for addition in coap-interfaces, but it is relevant for setting the context for the next items.) * A proxy might understand the semantics of a core.h (as it might understand a core.b and update included resources after querying a newer batch), and provide time slices by itself, provided it has the complete slice freshly cached. (The original server will probably assign a long max-age to an reply that has a tmax in its clock's past.) * If a proxy observes such a resource, that observation alone would not be sufficient to keep the cache accurate, as observation only provides eventual consistency, and intermediate events could be missed based on the guarantees of core-observe. The only reason I found in observe-12 that would prevent more than just eventual consistency from being provided is the presence of proxies, which might eat an intermediate state. (Of course, the original server would need to send every single state as CON, or include the last NON packages' states until a CON is sent). Have mechanisms to support such behavior been discussed before? * A comparatively different mode of observations we are currently using are partial updates of batches. As having many observations running for individual resources can be costly, and some resources are often queried together (eg. individual multi-value sensors in a multi-sensor device, or all sensor values of a device), observable batches are a practical thing. If only parts of that batch change, our test implementations send only the modified "e" items. This would confuse non-aware proxies, and generally has the same issues as above. On the practical side, this not only saves bandwidth, but helps with latency, as the typical update now fits in a single block again. (I don't know how it could at all fit with multiblock updates.) If no mechanism to provide fast updates of batches and event streams exists, I would consider proposing an option (let's call it Observe-Aggregate, an unsafe option that may be present in observe replies multiple times, and has an integer value similar to Accept; a proxy that wants to utilize the information needs to aggregate it according to a well-known method indicated by the option value) -- but that is something that'd need some input first, especially on other use cases. There are some still unresolved issues with SenML batches related to this, which I brought up a while ago (back then, not with my business but with my free-software developer hat on and under the nickname of chrysn ); if you'd find time to review the mails concerning 'SenML unit in link format response' and '"n" in SenML examples vs SenML spec' of 2013-08-02, they fit very well with the issues discussed above. The latest SenML proposal is generally a little outdated, but used in recent core-interfaces drafts. If desired, I'd happily provide patches where I can; I think it is a good thing to have in the context of CoRE. Best regards Christian --=20 Christian Ams=FCss Energy Harvesting Solutions GmbH http://www.energyharvesting.at/ --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJTOdITAAoJEDmNERLTpL3hIAUQANDHSHB8g5+gSNWz9UYAfnxc CVX85zgqMkRk9c2ab3KoVrFHMX8k5QSqHeMBYhNpfF4zr0swzyJU+BlfZkSTy/v0 MKwz47pvz35mapiKygoHBTPrtbJSRheZgur1F0jQWn0MhvWwgnSpjp1Xcme7EHmB 2ipHpBCQ2Q0lm8F50FlP78vQrlBWbGaGSFksYVavXNjsCZx+aH6dSUA7HG+w9ROG B79Y6KIkAZUO7nFn6krnuXH4AQHyaJsn7OpnO5dHUMT88g5HpurkC8nRe7MpqlQF edRPVuEGrJfpFxuweWjoMPPzqFoX3IcUyVvm/L4t59VNXzysRIEXcWjSOm4jpQop 6127ZMDbnAefBXvjiItugUEXZTEV1R4V4s6Z1GnWWv0FHmJP0wYhmNoi6pzjTyJk /CxiaRm1/sBCelkv/jZnq9X+fq3d176VTc0a2kcCYMrYtakdld/WAfNDEMv+HzGn IwGJylurcujDPwib+I2t9GeC47nQQ4ToS6IGSQtEZYbXB8LzKSAJtGo/dgm7anw+ DGUtz+X+FdO4Ad4SkdLvNEdmj4heBO06yRXHfD2tfLBGqIH2lEvGvrCd7IK2VlRw XAYmuKTV5+AR5YNOO/3I9BSo71/th5YxPgQVoRzv1pKLnNDut3Ihr+e26SUIMMTm 7KrTTui4pOUahUfzC5QS =EOrt -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q--