From nobody Mon Aug 3 09:17:56 2015 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 CC5631ACE3B for ; Mon, 3 Aug 2015 09:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.971 X-Spam-Level: X-Spam-Status: No, score=0.971 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35] 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 Gc207_x03UGk for ; Mon, 3 Aug 2015 09:17:54 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45BA1ACE25 for ; Mon, 3 Aug 2015 09:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t73GHn6f028826 for ; Mon, 3 Aug 2015 18:17:49 +0200 (CEST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mlPWd3BsGzDJfn for ; Mon, 3 Aug 2015 18:17:49 +0200 (CEST) Received: by wibud3 with SMTP id ud3so142767281wib.1 for ; Mon, 03 Aug 2015 09:17:49 -0700 (PDT) X-Received: by 10.180.219.41 with SMTP id pl9mr35087482wic.30.1438618661177; Mon, 03 Aug 2015 09:17:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.21.201 with HTTP; Mon, 3 Aug 2015 09:17:01 -0700 (PDT) In-Reply-To: <55B6EF25.2020804@tzi.org> References: <55B0DE45.2060701@tzi.org> <16FC8F43-3BBF-4AAE-9EC5-4F23C1272470@arm.com> <55B6EF25.2020804@tzi.org> From: Klaus Hartke Date: Mon, 3 Aug 2015 18:17:01 +0200 Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Michelle Cotton , "core@ietf.org" Subject: Re: [core] Range issue in core-parameters registry 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 Aug 2015 16:17:56 -0000 Carsten Bormann wrote: > Zach Shelby wrote: >> Maybe time to give up on the great unification experiment? >> We need to do it very soon, or end up with a bunch of duplicates. > > To me it seems we should accelerate the unification. > The most expedient approach would be to simply assign the values from > > https://svn.tools.ietf.org/svn/wg/core/mediatypes.txt > > for each combination of an existing media type and the identity content > coding that is being requested. The problem with assigning the number in bulk is that many media types define required and/or optional parameters (see for a quick overview). Parameter values are often open-ended. So it's not possible to simply assign one number for each media type or for each media type/parameter value combination. The intention for the 256-9999 range was that they're used for media types registered in the IANA Media Type registry. So my proposal would be: if someone needs a content format number allocated for a registered media type, they should be able to get that done easily without having to publish an RFC first. Media types with a closed set of parameter values would get allocated one number per parameter value. Media types with an open-ended set of parameter values would not be supported. Thoughts? Klaus From nobody Mon Aug 3 19:51:59 2015 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 D389A1B33B5 for ; Mon, 3 Aug 2015 19:51:57 -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 tmVTa1SPgrdq for ; Mon, 3 Aug 2015 19:51:54 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 774AC1B33B0 for ; Mon, 3 Aug 2015 19:51:52 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 795F819F921 for ; Tue, 4 Aug 2015 10:51:50 +0800 (HKT) Received: from WeiGengyuPC (unknown [125.34.194.63]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 2A1CE19F7F5; Tue, 4 Aug 2015 10:51:50 +0800 (HKT) Message-ID: <5416B5903CF249719A3299837FF3AC86@WeiGengyuPC> From: "weigengyu" To: References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> In-Reply-To: Date: Tue, 4 Aug 2015 10:51:44 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BF_01D0CEA3.8D67B700" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: core@ietf.org Subject: Re: [core] Patch idempotent? 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 Aug 2015 02:51:58 -0000 这是一封 MIME 格式的多方邮件。 ------=_NextPart_000_01BF_01D0CEA3.8D67B700 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Robert:=20 Robert Cragie wrote: > The partial operation of PATCH also implies its operation in a = sequence. > Then the idempotency of the whole sequence needs to be considered.=20 Yes, it needs considering for some applications.=20 According to the reference RFC about HTTP Patch, =E2=80=9Cthe client = can use a strong ETag [RFC2616] in an If-Match header on the PATCH = request." For beign defined CoAP Patch, it is possible to use the same( or = similar) way for getting idmpotent.=20 So, one CoAP Patch would be enough. and CoAP iPatch would not be = required. Regards, Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: Robert Cragie=20 Sent: Thursday, July 30, 2015 4:27 PM To: weigengyu=20 Cc: mailto:consultancy@vanderstok.org ; core@ietf.org=20 Subject: Re: [core] Patch idempotent? I tend to agree - why does PATCH need to be idempotent? Only two of its = applications (replace, delete) seem obviously idempotent. The partial = operation of PATCH also implies its operation in a sequence. Then the = idempotency of the whole sequence needs to be considered.=20 Robert On 29 July 2015 at 10:22, weigengyu wrote: HI Peter, It seems not to be a critical issue to be idempotent. Probably, conditional request can handle this issue. In RFC5789, "PATCH is neither safe nor idempotent as defined by [RFC2616], Section = 9.1." "A PATCH request can be issued in such a way as to be idempotent, which also helps prevent bad outcomes from collisions between two PATCH requests on the same resource in a similar time frame. Collisions from multiple PATCH requests may be more dangerous than PUT collisions because some patch formats need to operate from a known base-point or else they will corrupt the resource. Clients using this kind of patch application SHOULD use a conditional request such that the request will fail if the resource has been updated since the client last accessed the resource. For example, the client can use a strong ETag [RFC2616] in an If-Match header on the PATCH = request." In RFC 6902, it is not mention to be idempotent. "JavaScript Object Notation (JSON) [RFC4627] is a common format for the exchange and storage of structured data. HTTP PATCH [RFC5789] extends the Hypertext Transfer Protocol (HTTP) [RFC2616] with a method to perform partial modifications to resources." "JSON Patch is a format (identified by the media type "application/ json-patch+json") for expressing a sequence of operations to apply = to a target JSON document; it is suitable for use with the HTTP PATCH = method." Regards, Gengyu WEI 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: peter van der = Stok Sent: Tuesday, July 28, 2015 5:42 PM To: Core Subject: [core] Patch idempotent?=20 Hi all, During the CoRE meeting on friday, the suggestion was done that an idem-potent patch in CoAP should be called iPatch and that Patch = itself is not necessarily idempotent. I can identify 2 reasons why patch should not be idempotent: 1) the patch adds new sections to a resource and is not idem-potent = when for example new sections are identified by invocation date and time. 2) the patch changes the content of the resource as function of the resource state e.g. incrementing its values Other possibilities, not identified by me, may exist. 3) An idempotent Patch can be restricted to replacing a subset of the variables in the resource to the same subset with possibly different values. RF6902 restricts its operations to add, remove, move, copy, replace. The way the operations add, remove, replace are specified in 6902 implies their idem-potency; copy and move are not because dependent on the resource state. RFC7396 supports only the operations add, remove and replace, and is consequently an idem-potent format. My proposal is to specify Patch for CoAP to be non-idempotent = conforming to the http interpretation. This being said, we can add a new method to CoAP, called "iPatch", = which is idem-potent and probably fulfils what most applications want Patch = to do (RFC7396 semantics). The Patch command could then also include RPC semantics like toggle, = or INC(x), or actuator settings, currently excluded by an idem-potent PUT in CoAP. Looking forward to other opinions, peter --=20 Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 _______________________________________________ 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_01BF_01D0CEA3.8D67B700 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi Robert:
 
Robert Cragie wrote:
> The partial operation of PATCH also implies its operation in a = sequence.
> Then the idempotency of the whole sequence needs to be = considered.=20
 
Yes, it needs considering for some applications.
According to the reference RFC about HTTP Patch, =E2=80=9Cthe = client  can use=20 a strong ETag [RFC2616] in an If-Match header on the PATCH = request."
For beign defined CoAP Patch, it is possible to use the same( or = similar)=20 way for getting idmpotent.
 
So, one CoAP Patch would be enough. and CoAP iPatch would not be=20 required.
 
Regards,
 
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications
 
Sent: Thursday, July 30, 2015 4:27 PM
Subject: Re: [core] Patch idempotent?
 
I tend to agree - why does PATCH need to be idempotent? = Only two of=20 its applications (replace, delete) seem obviously idempotent. The = partial=20 operation of PATCH also implies its operation in a sequence. Then the=20 idempotency of the whole sequence needs to be considered.=20
 
Robert
 
On 29 July 2015 at 10:22, weigengyu <weigengyu@bupt.edu.cn> wrote:
HI=20 Peter,

It seems not to be a critical issue to be=20 idempotent.
Probably, conditional request can handle this = issue.

In=20 RFC5789,
"PATCH is neither safe nor idempotent as defined by = [RFC2616],=20 Section 9.1."
"A PATCH request can be issued in such a way as to be = idempotent,
  which also helps prevent bad outcomes from = collisions=20 between two
  PATCH requests on the same resource in a similar = time=20 frame.
Collisions from multiple PATCH requests may be more = dangerous=20 than
PUT collisions because some patch formats need to operate from = a
known base-point or else they will corrupt the resource. =20 Clients
using this kind of patch application SHOULD use a = conditional=20 request
such that the request will fail if the resource has been=20 updated
since the client last accessed the resource.  For = example, the=20 client
can use a strong ETag [RFC2616] in an If-Match header on the = PATCH=20 request."

In RFC 6902, it is not mention to be=20 idempotent.
"JavaScript Object Notation (JSON) [RFC4627] is a = common format=20 for
the exchange and storage of structured data.  HTTP PATCH=20 [RFC5789]
extends the Hypertext Transfer Protocol (HTTP) [RFC2616] = with=20 a
method to perform partial modifications to resources."
"JSON = Patch is=20 a format (identified by the media type "application/
 =20 json-patch+json") for expressing a sequence of operations to apply=20 to
  a target JSON document; it is suitable for use with the = HTTP=20 PATCH method."


Regards,

Gengyu WEI
Network = Technology=20 Center
School of Computer
Beijing University of Posts and=20 Telecommunications
-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- = From: peter van der Stok
Sent:=20 Tuesday, July 28, 2015 5:42 PM
To: Core
Subject: [core] Patch=20 idempotent?=20


Hi all,

During the CoRE meeting on = friday, the=20 suggestion was done that an
idem-potent patch in CoAP should be = called=20 iPatch and that Patch itself
is not necessarily = idempotent.

I can=20 identify 2 reasons why patch should not be idempotent:

1) the = patch=20 adds new sections to a resource and is not idem-potent when
for = example new=20 sections are identified by invocation date and time.
2) the patch = changes=20 the content of the resource as function of the
resource state e.g.=20 incrementing its values

Other possibilities, not identified by = me, may=20 exist.

3) An idempotent Patch can be restricted to replacing a = subset=20 of the
variables in the resource to the same subset with possibly=20 different
values.

RF6902 restricts its operations to add, = remove,=20 move, copy, replace.
The way the operations add, remove, replace = are=20 specified in 6902
implies their idem-potency; copy and move are not = because=20 dependent on
the resource state.

RFC7396 supports only the=20 operations add, remove and replace, and is
consequently an = idem-potent=20 format.

My proposal is to specify Patch for CoAP to be = non-idempotent=20 conforming
to the http interpretation.
This being said, we can = add a new=20 method to CoAP, called "iPatch", which
is idem-potent and probably = fulfils=20 what most applications want Patch to
do (RFC7396 = semantics).

The=20 Patch command could then also include RPC semantics like toggle, = or
INC(x),=20 or actuator settings, currently excluded by an idem-potent PUT
in=20 CoAP.

Looking forward to other = opinions,

peter



--=20
Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok.org
www: www.vanderstok.org
tel NL: +31(0)492474673     F: = +33(0)966015248

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

_______________________________________________
core=20 mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
<= /DIV>
 
------=_NextPart_000_01BF_01D0CEA3.8D67B700-- From nobody Wed Aug 5 11:55:06 2015 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 581481A8AFC for ; Wed, 5 Aug 2015 11:55:05 -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 JHsjcWVi4Tmi for ; Wed, 5 Aug 2015 11:55:03 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765081A8AF4 for ; Wed, 5 Aug 2015 11:55:03 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id B749F44C7B; Wed, 5 Aug 2015 20:55:00 +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 4E4FC23; Wed, 5 Aug 2015 20:54:59 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 19410CF; Wed, 5 Aug 2015 20:54:59 +0200 (CEST) Received: (nullmailer pid 20757 invoked by uid 1000); Wed, 05 Aug 2015 18:54:58 -0000 Date: Wed, 5 Aug 2015 20:54:58 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Ari =?iso-8859-1?Q?Ker=E4nen?= Message-ID: <20150805185458.GC3989@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="98e8jtXdkpgskNou" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: core@ietf.org Subject: [core] Status of SenML syntax 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 Aug 2015 18:55:05 -0000 --98e8jtXdkpgskNou Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Ari, hello everybody interested in SenML, I've seen the currently pending questions w/rt SenML posed in the IETF93 slides[1], and the recordings[2] give me the impression that a list [base dict, values, updating base dict, more values] is the way to go. Would you accept patches to update the sections on JSON and CBOR serializations and the examples? (If so, which is the master file to patch, the markdown or the XML?) Some points have been raised in the discussion I'd like to ask about / comment on: * Concerning "be consistent on being streamable" / order of items inside an event: Has there been further discussion on this afterwards? I do see the necessity in certain use cases (think {'sv':'...much text','n': oh that's where this all should have gone}), even though I'd figure they are rare; has a suggestion on how to deal with this been proposed? Unlike the base value case, this affects the XML representation as well. * "It's usually not gigabytes": Just a side note -- my proxy for sleepy devices is using SenML for backup and replication purposes. Extrapolating, the largest SenML involved will hit the gigabyte in a few months. * A google monitoring format has been mentioned that is similar to SenML; could I have some context on that? Best regards Christian [1] https://www.ietf.org/proceedings/93/slides/slides-93-core-0.pdf [2] http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF9= 3_CORE_II&chapter=3Dchapter_1 starting at 1:18 --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --98e8jtXdkpgskNou Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVwlv9AAoJEDmNERLTpL3hTVEP/3hp8BPb3CqWNZeludM+4hSX EQwCDR/tnWgG0I559XEHlf0R7EwxyKwRpX2i8kU5gaVmJAulG9NYQm4Sii7ZbFTp cpHXIprVuz1pKJL/GOyZqIrFAPNNsTL9R8mppnjg9nLOFRTF0pD6Xj+IsVfB+pZL bPEU+pe2dwEd9I7pipI6cdbXbcTDZPzun7F9v+9FZxzMzS1nheKX6GwPjaNtNoa6 eDiuOw4i/mn5WBPfeo83FKUH/B5Cd9Q/Fna3A+MU6hcj0pLVmAb3xA7+GOU5lUtt EIjBwdwUCFuxflOXdvzv5stW1TXxzSwONl/jZXLrS0CNkqHRoUa0LZXj1GhdvMQV 1ZfFWT7erqvY2eEFmkwn9biZEDbx42GLsoGTMS9XI9EwcTuPuzdY5SrHotkQwk4K Jb75T53vnX7HjoqkNCWJVlRZPexOe/3zJH+6Dv1jAQfSEzxLtxYGqMFItIxcAfP3 Fvi6s1MAvzEal1M1gA37frB+1aXcEZZvGsejb6RDmdNCzUGPV6YQG6CLqX3qN4yA jAx9fM8Nju0oBXcL5/c69m4Eu9+9HGFdlRoFasSBDOCzZkc9GCF7RkeKl/vH7CKh dsZA+MFo42OFteZDL7jIxxDzZj/Y67vu2uI7nj4MKOKJjocqYHNqNUWvhxLcBn5N njvDPFxtZ/Vbsuxx1rdF =iPjb -----END PGP SIGNATURE----- --98e8jtXdkpgskNou-- From nobody Thu Aug 6 07:40:44 2015 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 086FC1A8F3D for ; Thu, 6 Aug 2015 07:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 AZmjQYmlWu2a for ; Thu, 6 Aug 2015 07:40:42 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C311A8ABE for ; Thu, 6 Aug 2015 07:40:29 -0700 (PDT) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 6 Aug 2015 16:40:23 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.03.0248.002; Thu, 6 Aug 2015 16:40:27 +0200 From: "Kovatsch Matthias" To: "core@ietf.org" Thread-Topic: [core] Patch idempotent? Thread-Index: AQHQyRnD64vZ1u/NA0WKvHzR1WgUlp3yDH4AgAGC6oCAB33bAIAECxIQ Date: Thu, 6 Aug 2015 14:40:27 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B54C813E72@MBX210.d.ethz.ch> References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> <5416B5903CF249719A3299837FF3AC86@WeiGengyuPC> In-Reply-To: <5416B5903CF249719A3299837FF3AC86@WeiGengyuPC> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B54C813E72MBX210dethzch_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] Patch idempotent? 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 Aug 2015 14:40:44 -0000 --_000_55877B3AFB359744BA0F2140E36F52B54C813E72MBX210dethzch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsDQoNCkl0IG1pZ2h0IGJlIHdvcnRoIGNoZWNrIHRoaXMgYWxzbyBpbiB0aGUgY29udGV4 dCBvZiBSRCBhbmQgdGhlIHJlZ2lzdHJhdGlvbiB1cGRhdGU6IE9yaWdpbmFsbHksIFJEIHVzZWQg UFVUIHRvIGxldmVyYWdlIHRoZSBpZGVtcG90ZW5jeSBwcm9wZXJ0eSB3aGVuIGFkZGluZyByZXNv dXJjZXMvbGlua3MuIFdlIG5vdyBjaGFuZ2VkIHRoaXMgdG8gUE9TVCwgc2luY2UgdGhlIGludGVu dCBpcyBub3QgdG8gcmVwbGFjZSB0aGUgcmVzb3VyY2Ugc3RhdGUgd2l0aCB0aGUgcmVxdWVzdCBi b2R5LCBidXQgdG8gbW9kaWZ5IGl0LiBUaGlzIGlzIGEgY2FsbCBmb3IgUEFUQ0guIElzIGl0IGVu b3VnaCB0aGF0IGluIHRoZSBjb250ZXh0IG9mIExpbmsgRm9ybWF0LCBhIFBBVENIIHdvdWxkIGJl IGlkZW1wb3RlbnQgYmVjYXVzZSBsaW5rIGVudHJpZXMgbXVzdCBiZSB1bmlxdWUgYW5kIGR1cGxp Y2F0ZSBhdHRyaWJ1dGVzIG1ha2Ugbm8gc2Vuc2U/DQoNCkNpYW8NCk1hdHRoaWFzDQoNCg0K --_000_55877B3AFB359744BA0F2140E36F52B54C813E72MBX210dethzch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4w Y20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFLUNIIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkhpIGFsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JdCBtaWdodCBiZSB3b3J0aCBjaGVjayB0aGlzIGFsc28g aW4gdGhlIGNvbnRleHQgb2YgUkQgYW5kIHRoZSByZWdpc3RyYXRpb24gdXBkYXRlOiBPcmlnaW5h bGx5LCBSRCB1c2VkIFBVVCB0byBsZXZlcmFnZQ0KIHRoZSBpZGVtcG90ZW5jeSBwcm9wZXJ0eSB3 aGVuIGFkZGluZyByZXNvdXJjZXMvbGlua3MuIFdlIG5vdyBjaGFuZ2VkIHRoaXMgdG8gUE9TVCwg c2luY2UgdGhlIGludGVudCBpcyBub3QgdG8gcmVwbGFjZSB0aGUgcmVzb3VyY2Ugc3RhdGUgd2l0 aCB0aGUgcmVxdWVzdCBib2R5LCBidXQgdG8gbW9kaWZ5IGl0LiBUaGlzIGlzIGEgY2FsbCBmb3Ig UEFUQ0guIElzIGl0IGVub3VnaCB0aGF0IGluIHRoZSBjb250ZXh0IG9mIExpbmsgRm9ybWF0LCBh IFBBVENIDQogd291bGQgYmUgaWRlbXBvdGVudCBiZWNhdXNlIGxpbmsgZW50cmllcyBtdXN0IGJl IHVuaXF1ZSBhbmQgZHVwbGljYXRlIGF0dHJpYnV0ZXMgbWFrZSBubyBzZW5zZT88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ Q2lhbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+TWF0dGhpYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_55877B3AFB359744BA0F2140E36F52B54C813E72MBX210dethzch_-- From nobody Thu Aug 6 07:48:06 2015 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 B47041AC41F for ; Thu, 6 Aug 2015 07:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 VBCq6YVdE2IR for ; Thu, 6 Aug 2015 07:48:03 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73CA31B3011 for ; Thu, 6 Aug 2015 07:46:33 -0700 (PDT) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 6 Aug 2015 16:46:27 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.03.0248.002; Thu, 6 Aug 2015 16:46:31 +0200 From: "Kovatsch Matthias" To: core WG Thread-Topic: Common request/response API Thread-Index: AdDQVeNuAPt1Zq9NRquldRnePYfjpA== Date: Thu, 6 Aug 2015 14:46:30 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B54C813E91@MBX210.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [core] Common request/response API 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 Aug 2015 14:48:04 -0000 Dear list In Prague, the problem of a common request/response API for all possible tr= ansports was raised. We now have something similar in the Californium proje= ct, where we want to improve the error handling for the CoapClient API as w= ell as improve the information flow between Scandium (DTLS) and Californium= (or rather the application code). As a start, I collected possible exceptions that could signal what went wro= ng. While this might be a bit Java-centric, the intent is universal: have a= common set of signals to tell the application above the request/response A= PI what went wrong. Network layer - DestinationNotReachableException - PacketTooBigException Transport layer - ConnectionRefusedException - AuthenticationException - TooManyOpenFilesException / InsufficientResourcesException (more OS-relat= ed, but happens at the socket level) Application layer - TimeoutException / NoReplyException - InvalidURIException / InvalidTransportException (alternative transports A= PI) - RejectedException (not sure if the same as ConnectionRefusedException) It would be great, if you could have a look, suggest more exceptions/signal= s/error codes, propose thinning/merging, or just comment on the direction.= =20 Ciao Matthias From nobody Thu Aug 6 12:28:31 2015 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 F14941B3171 for ; Thu, 6 Aug 2015 12:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 dwRL7SIXxEOq for ; Thu, 6 Aug 2015 12:28:28 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9F91AC44B for ; Thu, 6 Aug 2015 12:28:27 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 4792FD782F801; Thu, 6 Aug 2015 19:28:23 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t76JSOcl029435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Aug 2015 19:28:24 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Thu, 6 Aug 2015 15:28:23 -0400 From: "Carey, Timothy (Timothy)" To: "Kovatsch Matthias" , core WG Thread-Topic: [core] Common request/response API Thread-Index: AQHQ0HpEydKVqprn8kKMXYdIv3GcLZ3/WrTg Date: Thu, 6 Aug 2015 19:28:24 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC22E65A@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <55877B3AFB359744BA0F2140E36F52B54C813E91@MBX210.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54C813E91@MBX210.d.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] Common request/response API 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 Aug 2015 19:28:30 -0000 Matthias, In your view the Application Layer that would receive these indications is = the Request/Response Layer which then you return the appropriate Error code= ? BR, Tim -----Original Message----- From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]=20 Sent: Thursday, August 06, 2015 9:47 AM To: core WG Subject: [core] Common request/response API Dear list In Prague, the problem of a common request/response API for all possible tr= ansports was raised. We now have something similar in the Californium proje= ct, where we want to improve the error handling for the CoapClient API as w= ell as improve the information flow between Scandium (DTLS) and Californium= (or rather the application code). As a start, I collected possible exceptions that could signal what went wro= ng. While this might be a bit Java-centric, the intent is universal: have a= common set of signals to tell the application above the request/response A= PI what went wrong. Network layer - DestinationNotReachableException - PacketTooBigException Transport layer - ConnectionRefusedException - AuthenticationException - TooManyOpenFilesException / InsufficientResourcesException (more OS-relat= ed, but happens at the socket level) Application layer - TimeoutException / NoReplyException - InvalidURIException / InvalidTransportException (alternative transports A= PI) - RejectedException (not sure if the same as ConnectionRefusedException) It would be great, if you could have a look, suggest more exceptions/signal= s/error codes, propose thinning/merging, or just comment on the direction.= =20 Ciao Matthias From nobody Fri Aug 7 00:45:08 2015 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 2B0381B380A for ; Fri, 7 Aug 2015 00:45:07 -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 JWTW6BhI2UpQ for ; Fri, 7 Aug 2015 00:45:04 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A691A1BB4 for ; Fri, 7 Aug 2015 00:45:04 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.205]) by smtp-cloud6.xs4all.net with ESMTP id 1jl11r00G4RV18J01jl13S; Fri, 07 Aug 2015 09:45:02 +0200 Received: from [2001:983:a264:1:50c3:cedf:df41:f440] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 07 Aug 2015 09:45:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 07 Aug 2015 09:45:01 +0200 From: peter van der Stok To: Kovatsch Matthias Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54C813E72@MBX210.d.ethz.ch> References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> <5416B5903CF249719A3299837FF3AC86@WeiGengyuPC> <55877B3AFB359744BA0F2140E36F52B54C813E72@MBX210.d.ethz.ch> Message-ID: <1d4331c57230d49d35bef6df5e5ba4ed@xs4all.nl> X-Sender: stokcons@xs4all.nl (gBJRA1u8lpJgzX2LbCMpTZ3dPRXpOUDY) User-Agent: XS4ALL Webmail Archived-At: Cc: core@ietf.org Subject: Re: [core] Patch idempotent? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 07:45:07 -0000 Hi Matthias, It is possibly a good approach to use Patch for RD and make the patch invocation idem-potent. However, this is different from demanding that Patch is idem-potent on all servers. Is the provision of iPatch an asset for servers which, in the absence of iPatch, assure that Patch is idem-potent? Peter Kovatsch Matthias schreef op 2015-08-06 16:40: > Hi all > > It might be worth check this also in the context of RD and the > registration update: Originally, RD used PUT to leverage the > idempotency property when adding resources/links. We now changed this > to POST, since the intent is not to replace the resource state with > the request body, but to modify it. This is a call for PATCH. Is it > enough that in the context of Link Format, a PATCH would be idempotent > because link entries must be unique and duplicate attributes make no > sense? > > Ciao > > Matthias > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Aug 7 06:18:27 2015 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 8EBD41B2CAB for ; Fri, 7 Aug 2015 06:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 is0XOfH-LKHL for ; Fri, 7 Aug 2015 06:18:13 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D0A31B2CA0 for ; Fri, 7 Aug 2015 06:18:13 -0700 (PDT) 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.248.2; Fri, 7 Aug 2015 15:18:07 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.03.0248.002; Fri, 7 Aug 2015 15:18:10 +0200 From: "Kovatsch Matthias" To: "Carey, Timothy (Timothy)" , core WG Thread-Topic: [core] Common request/response API Thread-Index: AdDQVeNuAPt1Zq9NRquldRnePYfjpAAF2igAACjsw5A= Date: Fri, 7 Aug 2015 13:18:10 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B54C814F8D@MBX210.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B54C813E91@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22E65A@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC22E65A@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.57.170.130] Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B54C814F8DMBX210dethzch_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] Common request/response API 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 Aug 2015 13:18:18 -0000 --_000_55877B3AFB359744BA0F2140E36F52B54C814F8DMBX210dethzch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tim > In your view the Application Layer that would receive these indications i= s the > Request/Response Layer which then you return the appropriate Error code? No, the Request/Response Layer is part of CoAP and defines the methods, res= ponse codes, options, etc. The user application uses an API ("Req/Res Layer= API") to issue requests and receive responses and will receive these error= codes. The codes need to be transport-agnostic. The transport itself can b= e chosen through the scheme used in the URI passed to the Req/Res API. In C= alifornium, I will probably add additional API calls that only have effect = on some transports (e.g., CON/NON). The user application can call them depe= nding on what scheme/transport it chose. I tried to depict it: +---------------------------------------------------+ | | | Application (custom / LWM2M / IPSO) | | | +---------------[ Req/Res Layer API ]---------------+ <-- | | | Request/Response Layer (CoAP spec) | | | +---------------------------------------------------+ | Message Layer (CoAP spec / alternative transport) | +---------------------------------------------------+ | Transport Layer (UDP / DTLS / TCP / TLS / SMS) = | Ciao Matthias > -----Original Message----- > From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] > Sent: Thursday, August 06, 2015 9:47 AM > To: core WG > Subject: [core] Common request/response API > > Dear list > > In Prague, the problem of a common request/response API for all possible > transports was raised. We now have something similar in the Californium > project, where we want to improve the error handling for the CoapClient A= PI as > well as improve the information flow between Scandium (DTLS) and Californ= ium > (or rather the application code). > > As a start, I collected possible exceptions that could signal what went w= rong. > While this might be a bit Java-centric, the intent is universal: have a c= ommon set > of signals to tell the application above the request/response API what we= nt > wrong. > > Network layer > - DestinationNotReachableException > - PacketTooBigException > > Transport layer > - ConnectionRefusedException > - AuthenticationException > - TooManyOpenFilesException / InsufficientResourcesException (more OS- > related, but happens at the socket level) > > Application layer > - TimeoutException / NoReplyException > - InvalidURIException / InvalidTransportException (alternative transports= API) > - RejectedException (not sure if the same as ConnectionRefusedException) > > It would be great, if you could have a look, suggest more > exceptions/signals/error codes, propose thinning/merging, or just comment= on > the direction. > > Ciao > Matthias > --_000_55877B3AFB359744BA0F2140E36F52B54C814F8DMBX210dethzch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tim

 

> In your view the Application Layer that woul= d receive these indications is the

> Request/Response Layer which then you return= the appropriate Error code?

 

No, the Request/Respo= nse Layer is part of CoAP and defines the methods, response codes, options,= etc. The user application uses an API (“Req/Res Layer API”) to= issue requests and receive responses and will receive these error codes. The codes need to be transport-agnostic. The transport = itself can be chosen through the scheme used in the URI passed to the Req/R= es API. In Californium, I will probably add additional API calls that only = have effect on some transports (e.g., CON/NON). The user application can call them depending on what scheme/tran= sport it chose. I tried to depict it:

 

+---------------------------------------------------+= ;

|          = ;            &n= bsp;            = ;            &n= bsp;   |

|        Application (cus= tom / LWM2M / IPSO)        |<= /span>

|          = ;            &n= bsp;            = ;            &n= bsp;   |

+---------------[ Req/Res Layer API ]---------------+= ; <--

|          &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  |

|         Request/Re= sponse Layer (CoAP spec)        |

|          &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  |

+---------------------------------------------------+= ;

| Message Layer (CoAP spec / alternative transport) |

+---------------------------------------------------+= ;

|   &n= bsp;            = ;         Transport Layer (UDP / DT= LS / TCP / TLS / SMS)         =             &nb= sp;         |

 

Ciao

Matthias

 

> -----Original Message-----

> From: Kovatsch Matthias [= mailto:kovatsch@inf.ethz.ch]

> Sent: Thursday, August 06, 2015 9:47 AM

> To: core WG

> Subject: [core] Common request/response API<= /p>

>

> Dear list

>

> In Prague, the problem of a common request/r= esponse API for all possible

> transports was raised. We now have something= similar in the Californium

> project, where we want to improve the error = handling for the CoapClient API as

> well as improve the information flow between= Scandium (DTLS) and Californium

> (or rather the application code).

>

> As a start, I collected possible exceptions = that could signal what went wrong.

> While this might be a bit Java-centric, the = intent is universal: have a common set

> of signals to tell the application above the= request/response API what went

> wrong.

>

> Network layer

> - DestinationNotReachableException

> - PacketTooBigException

>

> Transport layer

> - ConnectionRefusedException

> - AuthenticationException

> - TooManyOpenFilesException / InsufficientRe= sourcesException (more OS-

> related, but happens at the socket level)

>

> Application layer

> - TimeoutException / NoReplyException

> - InvalidURIException / InvalidTransportExce= ption (alternative transports API)

> - RejectedException (not sure if the same as= ConnectionRefusedException)

>

> It would be great, if you could have a look,= suggest more

> exceptions/signals/error codes, propose thin= ning/merging, or just comment on

> the direction.

>

> Ciao

> Matthias

>

 

--_000_55877B3AFB359744BA0F2140E36F52B54C814F8DMBX210dethzch_-- From nobody Fri Aug 7 06:32:52 2015 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 1599D1B2CE9 for ; Fri, 7 Aug 2015 06:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 QZ0d4mfKiuNv for ; Fri, 7 Aug 2015 06:32:48 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7D81B2CE6 for ; Fri, 7 Aug 2015 06:32:47 -0700 (PDT) Received: from CAS11.d.ethz.ch (172.31.38.211) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 7 Aug 2015 15:32:42 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.03.0248.002; Fri, 7 Aug 2015 15:32:45 +0200 From: "Kovatsch Matthias" To: "consultancy@vanderstok.org" Thread-Topic: [core] Patch idempotent? Thread-Index: AQHQyRnD64vZ1u/NA0WKvHzR1WgUlp3yDH4AgAGC6oCAB33bAIAECxIQgAD93oCAAH7EgA== Date: Fri, 7 Aug 2015 13:32:45 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B54C815017@MBX210.d.ethz.ch> References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> <5416B5903CF249719A3299837FF3AC86@WeiGengyuPC> <55877B3AFB359744BA0F2140E36F52B54C813E72@MBX210.d.ethz.ch> <1d4331c57230d49d35bef6df5e5ba4ed@xs4all.nl> In-Reply-To: <1d4331c57230d49d35bef6df5e5ba4ed@xs4all.nl> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.57.170.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Patch idempotent? 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 Aug 2015 13:32:50 -0000 Hi Peter > It is possibly a good approach to use Patch for RD and make the patch > invocation idem-potent. > However, this is different from demanding that Patch is idem-potent on al= l > servers. Clients usually do not know the server implementation. They have to rely on= the properties given through the methods. For instance, a client can alway= s be sure that a GET has no side-effects on the server (unless the server h= as an erroneous implementation...). For RD, we would have out-of-band infor= mation, but this is exactly the kind of coupling REST tries to avoid. > Is the provision of iPatch an asset for servers which, in the absence of = iPatch, > assure that Patch is idem-potent? Not for servers, but for clients. Recovery in case of no response becomes m= uch easier, for instance. However, I am not in favor of having two different PATCH methods... let's k= eep it simple! :) Ciao Matthias From nobody Fri Aug 7 07:31:08 2015 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 B1F841A002C for ; Fri, 7 Aug 2015 07:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 S3UD6EOoMV1F for ; Fri, 7 Aug 2015 07:31:03 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C6A1A00C7 for ; Fri, 7 Aug 2015 07:31:02 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 146AD6BAF8D15; Fri, 7 Aug 2015 14:30:57 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t77EUw6J026808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Aug 2015 14:30:59 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 7 Aug 2015 10:30:57 -0400 From: "Carey, Timothy (Timothy)" To: "Kovatsch Matthias" , core WG Thread-Topic: [core] Common request/response API Thread-Index: AQHQ0HpEydKVqprn8kKMXYdIv3GcLZ3/WrTggAFuaAD//9DgIA== Date: Fri, 7 Aug 2015 14:30:56 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC22EFEA@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <55877B3AFB359744BA0F2140E36F52B54C813E91@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22E65A@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C814F8D@MBX210.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54C814F8D@MBX210.d.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC22EFEAUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] Common request/response API 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 Aug 2015 14:31:07 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC22EFEAUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Matthias, Then the exceptions you have listed should be reflected in Resp Codes? BR, Tim From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, August 07, 2015 8:18 AM To: Carey, Timothy (Timothy); core WG Subject: RE: [core] Common request/response API Hi Tim > In your view the Application Layer that would receive these indications i= s the > Request/Response Layer which then you return the appropriate Error code? No, the Request/Response Layer is part of CoAP and defines the methods, res= ponse codes, options, etc. The user application uses an API ("Req/Res Layer= API") to issue requests and receive responses and will receive these error= codes. The codes need to be transport-agnostic. The transport itself can b= e chosen through the scheme used in the URI passed to the Req/Res API. In C= alifornium, I will probably add additional API calls that only have effect = on some transports (e.g., CON/NON). The user application can call them depe= nding on what scheme/transport it chose. I tried to depict it: +---------------------------------------------------+ | | | Application (custom / LWM2M / IPSO) | | | +---------------[ Req/Res Layer API ]---------------+ <-- | | | Request/Response Layer (CoAP spec) | | | +---------------------------------------------------+ | Message Layer (CoAP spec / alternative transport) | +---------------------------------------------------+ | Transport Layer (UDP / DTLS / TCP / TLS / SMS) = | Ciao Matthias > -----Original Message----- > From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] > Sent: Thursday, August 06, 2015 9:47 AM > To: core WG > Subject: [core] Common request/response API > > Dear list > > In Prague, the problem of a common request/response API for all possible > transports was raised. We now have something similar in the Californium > project, where we want to improve the error handling for the CoapClient A= PI as > well as improve the information flow between Scandium (DTLS) and Californ= ium > (or rather the application code). > > As a start, I collected possible exceptions that could signal what went w= rong. > While this might be a bit Java-centric, the intent is universal: have a c= ommon set > of signals to tell the application above the request/response API what we= nt > wrong. > > Network layer > - DestinationNotReachableException > - PacketTooBigException > > Transport layer > - ConnectionRefusedException > - AuthenticationException > - TooManyOpenFilesException / InsufficientResourcesException (more OS- > related, but happens at the socket level) > > Application layer > - TimeoutException / NoReplyException > - InvalidURIException / InvalidTransportException (alternative transports= API) > - RejectedException (not sure if the same as ConnectionRefusedException) > > It would be great, if you could have a look, suggest more > exceptions/signals/error codes, propose thinning/merging, or just comment= on > the direction. > > Ciao > Matthias > --_000_9966516C6EB5FC4381E05BF80AA55F77DC22EFEAUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Matthias,

 

Then the exceptions you have listed s= hould be reflected in Resp Codes?

 

BR,

Tim

 

From: Kovatsch= Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, August 07, 2015 8:18 AM
To: Carey, Timothy (Timothy); core WG
Subject: RE: [core] Common request/response API

 

Hi Tim

 

> In your view the Application Layer that woul= d receive these indications is the

> Request/Response Layer which then you return= the appropriate Error code?

 

No, the Request/Respo= nse Layer is part of CoAP and defines the methods, response codes, options,= etc. The user application uses an API (“Req/Res Layer API”) to= issue requests and receive responses and will receive these error codes. The codes need to be transport-agnostic. The transport = itself can be chosen through the scheme used in the URI passed to the Req/R= es API. In Californium, I will probably add additional API calls that only = have effect on some transports (e.g., CON/NON). The user application can call them depending on what scheme/tran= sport it chose. I tried to depict it:

 

+---------------------------------------------------+= ;

|          = ;            &n= bsp;            = ;            &n= bsp;   |

|        Application (cus= tom / LWM2M / IPSO)        |<= /span>

|          = ;            &n= bsp;            = ;            &n= bsp;   |

+---------------[ Req/Res Layer API ]---------------+= ; <--

|          &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  |

|         Request/Re= sponse Layer (CoAP spec)        |

|          &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  |

+---------------------------------------------------+= ;

| Message Layer (CoAP spec / alternative transport) |

+---------------------------------------------------+= ;

|   &n= bsp;            = ;         Transport Layer (UDP / DT= LS / TCP / TLS / SMS)         =             &nb= sp;         |

 

Ciao

Matthias

 

> -----Original Message-----

> From: Kovatsch Matthias [= mailto:kovatsch@inf.ethz.ch]

> Sent: Thursday, August 06, 2015 9:47 AM=

> To: core WG

> Subject: [core] Common request/response API<= o:p>

>

> Dear list

>

> In Prague, the problem of a common request/r= esponse API for all possible

> transports was raised. We now have something= similar in the Californium

> project, where we want to improve the error = handling for the CoapClient API as

> well as improve the information flow between= Scandium (DTLS) and Californium

> (or rather the application code).=

>

> As a start, I collected possible exceptions = that could signal what went wrong.

> While this might be a bit Java-centric, the = intent is universal: have a common set

> of signals to tell the application above the= request/response API what went

> wrong.

>

> Network layer

> - DestinationNotReachableException

> - PacketTooBigException

>

> Transport layer

> - ConnectionRefusedException

> - AuthenticationException

> - TooManyOpenFilesException / InsufficientRe= sourcesException (more OS-

> related, but happens at the socket level)

>

> Application layer

> - TimeoutException / NoReplyException

> - InvalidURIException / InvalidTransportExce= ption (alternative transports API)

> - RejectedException (not sure if the same as= ConnectionRefusedException)

>

> It would be great, if you could have a look,= suggest more

> exceptions/signals/error codes, propose thin= ning/merging, or just comment on

> the direction.

>

> Ciao

> Matthias

>

 

--_000_9966516C6EB5FC4381E05BF80AA55F77DC22EFEAUS70UWXCHMBA05z_-- From nobody Fri Aug 7 08:12:09 2015 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 372A01B2E2B for ; Fri, 7 Aug 2015 08:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 okdoOanV4Apq for ; Fri, 7 Aug 2015 08:12:02 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A1A1B2E28 for ; Fri, 7 Aug 2015 08:11:47 -0700 (PDT) Received: from CAS21.d.ethz.ch (172.31.51.111) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 7 Aug 2015 17:11:42 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.03.0248.002; Fri, 7 Aug 2015 17:11:45 +0200 From: "Kovatsch Matthias" To: "Carey, Timothy (Timothy)" , core WG Thread-Topic: [core] Common request/response API Thread-Index: AdDQVeNuAPt1Zq9NRquldRnePYfjpAAF2igAACjsw5D///fSAP//1AKw Date: Fri, 7 Aug 2015 15:11:45 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B54C815218@MBX210.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B54C813E91@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22E65A@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C814F8D@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22EFEA@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC22EFEA@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.57.170.130] Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B54C815218MBX210dethzch_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] Common request/response API 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 Aug 2015 15:12:08 -0000 --_000_55877B3AFB359744BA0F2140E36F52B54C815218MBX210dethzch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, response codes reflect success in this context (even 4.xx and 5.xx), si= nce the request could be delivered and a response was received. Exceptions = are for the things that could go wrong during transmission/reception. From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: Friday, 7 August 2015 16:31 To: Kovatsch Matthias ; core WG Subject: RE: [core] Common request/response API Matthias, Then the exceptions you have listed should be reflected in Resp Codes? BR, Tim From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, August 07, 2015 8:18 AM To: Carey, Timothy (Timothy); core WG Subject: RE: [core] Common request/response API Hi Tim > In your view the Application Layer that would receive these indications i= s the > Request/Response Layer which then you return the appropriate Error code? No, the Request/Response Layer is part of CoAP and defines the methods, res= ponse codes, options, etc. The user application uses an API ("Req/Res Layer= API") to issue requests and receive responses and will receive these error= codes. The codes need to be transport-agnostic. The transport itself can b= e chosen through the scheme used in the URI passed to the Req/Res API. In C= alifornium, I will probably add additional API calls that only have effect = on some transports (e.g., CON/NON). The user application can call them depe= nding on what scheme/transport it chose. I tried to depict it: +---------------------------------------------------+ | | | Application (custom / LWM2M / IPSO) | | | +---------------[ Req/Res Layer API ]---------------+ <-- | | | Request/Response Layer (CoAP spec) | | | +---------------------------------------------------+ | Message Layer (CoAP spec / alternative transport) | +---------------------------------------------------+ | Transport Layer (UDP / DTLS / TCP / TLS / SMS) = | Ciao Matthias > -----Original Message----- > From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] > Sent: Thursday, August 06, 2015 9:47 AM > To: core WG > Subject: [core] Common request/response API > > Dear list > > In Prague, the problem of a common request/response API for all possible > transports was raised. We now have something similar in the Californium > project, where we want to improve the error handling for the CoapClient A= PI as > well as improve the information flow between Scandium (DTLS) and Californ= ium > (or rather the application code). > > As a start, I collected possible exceptions that could signal what went w= rong. > While this might be a bit Java-centric, the intent is universal: have a c= ommon set > of signals to tell the application above the request/response API what we= nt > wrong. > > Network layer > - DestinationNotReachableException > - PacketTooBigException > > Transport layer > - ConnectionRefusedException > - AuthenticationException > - TooManyOpenFilesException / InsufficientResourcesException (more OS- > related, but happens at the socket level) > > Application layer > - TimeoutException / NoReplyException > - InvalidURIException / InvalidTransportException (alternative transports= API) > - RejectedException (not sure if the same as ConnectionRefusedException) > > It would be great, if you could have a look, suggest more > exceptions/signals/error codes, propose thinning/merging, or just comment= on > the direction. > > Ciao > Matthias > --_000_55877B3AFB359744BA0F2140E36F52B54C815218MBX210dethzch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, response codes ref= lect success in this context (even 4.xx and 5.xx), since the request could = be delivered and a response was received. Exceptions are for the things tha= t could go wrong during transmission/reception.

 

 

From: Carey, Timothy (Timothy) [mailto:timoth= y.carey@alcatel-lucent.com]
Sent: Friday, 7 August 2015 16:31
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>; core WG <core= @ietf.org>
Subject: RE: [core] Common request/response API

 

Matthias,

 

Then the exceptions you have listed should be ref= lected in Resp Codes?

 

BR,

Tim

 

From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, August 07, 2015 8:18 AM
To: Carey, Timothy (Timothy); core WG
Subject: RE: [core] Common request/response API

 

Hi Tim

 

> In your view the Application Layer that woul= d receive these indications is the

> Request/Response Layer which then you return= the appropriate Error code?

 

No, the Request/Respo= nse Layer is part of CoAP and defines the methods, response codes, options,= etc. The user application uses an API (“Req/Res Layer API”) to= issue requests and receive responses and will receive these error codes. The codes need to be transport-agnostic. The transport = itself can be chosen through the scheme used in the URI passed to the Req/R= es API. In Californium, I will probably add additional API calls that only = have effect on some transports (e.g., CON/NON). The user application can call them depending on what scheme/tran= sport it chose. I tried to depict it:

 

+---------------------------------------------------+= ;

|          = ;            &n= bsp;            = ;            &n= bsp;   |

|        Application (cus= tom / LWM2M / IPSO)        |<= /span>

|          = ;            &n= bsp;            = ;            &n= bsp;   |

+---------------[ Req/Res Layer API ]---------------+= ; <--

|          &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  |

|         Request/Re= sponse Layer (CoAP spec)        |

|          &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  |

+---------------------------------------------------+= ;

| Message Layer (CoAP spec / alternative transport) |

+---------------------------------------------------+= ;

|   &n= bsp;            = ;         Transport Layer (UDP / DT= LS / TCP / TLS / SMS)         =             &nb= sp;         |

 

Ciao

Matthias

 

> -----Original Message-----

> From: Kovatsch Matthias [= mailto:kovatsch@inf.ethz.ch]

> Sent: Thursday, August 06, 2015 9:47 AM=

> To: core WG

> Subject: [core] Common request/response API<= o:p>

>

> Dear list

>

> In Prague, the problem of a common request/r= esponse API for all possible

> transports was raised. We now have something= similar in the Californium

> project, where we want to improve the error = handling for the CoapClient API as

> well as improve the information flow between= Scandium (DTLS) and Californium

> (or rather the application code).=

>

> As a start, I collected possible exceptions = that could signal what went wrong.

> While this might be a bit Java-centric, the = intent is universal: have a common set

> of signals to tell the application above the= request/response API what went

> wrong.

>

> Network layer

> - DestinationNotReachableException

> - PacketTooBigException

>

> Transport layer

> - ConnectionRefusedException

> - AuthenticationException

> - TooManyOpenFilesException / InsufficientRe= sourcesException (more OS-

> related, but happens at the socket level)

>

> Application layer

> - TimeoutException / NoReplyException

> - InvalidURIException / InvalidTransportExce= ption (alternative transports API)

> - RejectedException (not sure if the same as= ConnectionRefusedException)

>

> It would be great, if you could have a look,= suggest more

> exceptions/signals/error codes, propose thin= ning/merging, or just comment on

> the direction.

>

> Ciao

> Matthias

>

 

--_000_55877B3AFB359744BA0F2140E36F52B54C815218MBX210dethzch_-- From nobody Fri Aug 7 09:28:09 2015 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 1CFAF1B2F6E for ; Fri, 7 Aug 2015 09:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 cErqzY6ysIu6 for ; Fri, 7 Aug 2015 09:28:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE521B2F5B for ; Fri, 7 Aug 2015 09:27:18 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 8F217F1E35E40; Fri, 7 Aug 2015 16:27:13 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t77GREv5004458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Aug 2015 16:27:15 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Fri, 7 Aug 2015 12:27:14 -0400 From: "Carey, Timothy (Timothy)" To: "Kovatsch Matthias" , core WG Thread-Topic: [core] Common request/response API Thread-Index: AQHQ0HpEydKVqprn8kKMXYdIv3GcLZ3/WrTggAFuaAD//9DgIIAATtyA///OEDA= Date: Fri, 7 Aug 2015 16:27:12 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC22F1C6@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <55877B3AFB359744BA0F2140E36F52B54C813E91@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22E65A@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C814F8D@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22EFEA@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C815218@MBX210.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54C815218@MBX210.d.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC22F1C6US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] Common request/response API 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 Aug 2015 16:28:05 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC22F1C6US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Matthias, So are you suggesting then that the API between the End Application and the= Request Response Layer be: REQ /\ /\ Application Layer (LWM2M,IPSO) | | | ------|------|------|------ | | \/ RESP Abort REQ/RESP Layer I just wanted to be clear that this is an additional type of interaction. BR, Tim From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, August 07, 2015 10:12 AM To: Carey, Timothy (Timothy); core WG Subject: RE: [core] Common request/response API No, response codes reflect success in this context (even 4.xx and 5.xx), si= nce the request could be delivered and a response was received. Exceptions = are for the things that could go wrong during transmission/reception. From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: Friday, 7 August 2015 16:31 To: Kovatsch Matthias >; = core WG > Subject: RE: [core] Common request/response API Matthias, Then the exceptions you have listed should be reflected in Resp Codes? BR, Tim From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, August 07, 2015 8:18 AM To: Carey, Timothy (Timothy); core WG Subject: RE: [core] Common request/response API Hi Tim > In your view the Application Layer that would receive these indications i= s the > Request/Response Layer which then you return the appropriate Error code? No, the Request/Response Layer is part of CoAP and defines the methods, res= ponse codes, options, etc. The user application uses an API ("Req/Res Layer= API") to issue requests and receive responses and will receive these error= codes. The codes need to be transport-agnostic. The transport itself can b= e chosen through the scheme used in the URI passed to the Req/Res API. In C= alifornium, I will probably add additional API calls that only have effect = on some transports (e.g., CON/NON). The user application can call them depe= nding on what scheme/transport it chose. I tried to depict it: +---------------------------------------------------+ | | | Application (custom / LWM2M / IPSO) | | | +---------------[ Req/Res Layer API ]---------------+ <-- | | | Request/Response Layer (CoAP spec) | | | +---------------------------------------------------+ | Message Layer (CoAP spec / alternative transport) | +---------------------------------------------------+ | Transport Layer (UDP / DTLS / TCP / TLS / SMS) = | Ciao Matthias > -----Original Message----- > From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] > Sent: Thursday, August 06, 2015 9:47 AM > To: core WG > Subject: [core] Common request/response API > > Dear list > > In Prague, the problem of a common request/response API for all possible > transports was raised. We now have something similar in the Californium > project, where we want to improve the error handling for the CoapClient A= PI as > well as improve the information flow between Scandium (DTLS) and Californ= ium > (or rather the application code). > > As a start, I collected possible exceptions that could signal what went w= rong. > While this might be a bit Java-centric, the intent is universal: have a c= ommon set > of signals to tell the application above the request/response API what we= nt > wrong. > > Network layer > - DestinationNotReachableException > - PacketTooBigException > > Transport layer > - ConnectionRefusedException > - AuthenticationException > - TooManyOpenFilesException / InsufficientResourcesException (more OS- > related, but happens at the socket level) > > Application layer > - TimeoutException / NoReplyException > - InvalidURIException / InvalidTransportException (alternative transports= API) > - RejectedException (not sure if the same as ConnectionRefusedException) > > It would be great, if you could have a look, suggest more > exceptions/signals/error codes, propose thinning/merging, or just comment= on > the direction. > > Ciao > Matthias > --_000_9966516C6EB5FC4381E05BF80AA55F77DC22F1C6US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Matthias,

 

So are you suggesting then that the A= PI between the End Application and the Request Response Layer be:

 

     REQ    /\  =    /\      Application Layer (LWM2M,IPSO= )

      |     = ; |      |

------|------|------|------

      |     = ; |

     \/     RESP = ; Abort    REQ/RESP Layer

 

I just wanted to be clear that this is an additional type of = interaction.

 

BR,

Tim

 

From: Kovatsch= Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, August 07, 2015 10:12 AM
To: Carey, Timothy (Timothy); core WG
Subject: RE: [core] Common request/response API

 

No, response codes ref= lect success in this context (even 4.xx and 5.xx), since the request could = be delivered and a response was received. Exceptions are for the things tha= t could go wrong during transmission/reception.

 

 

From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.= com]
Sent: Friday, 7 August 2015 16:31
To: Kovatsch Matthias <ko= vatsch@inf.ethz.ch>; core WG <co= re@ietf.org>
Subject: RE: [core] Common request/response API

 

Matthias,

 

Then the exceptions you have listed s= hould be reflected in Resp Codes?

 

BR,

Tim

 

From: Kovatsch= Matthias [mailto:kovatsch@inf.ethz= .ch]
Sent: Friday, August 07, 2015 8:18 AM
To: Carey, Timothy (Timothy); core WG
Subject: RE: [core] Common request/response API

 

Hi Tim

 

> In your view the Application Layer that woul= d receive these indications is the

> Request/Response Layer which then you return= the appropriate Error code?

 

No, the Request/Respo= nse Layer is part of CoAP and defines the methods, response codes, options,= etc. The user application uses an API (“Req/Res Layer API”) to= issue requests and receive responses and will receive these error codes. The codes need to be transport-agnostic. The transport = itself can be chosen through the scheme used in the URI passed to the Req/R= es API. In Californium, I will probably add additional API calls that only = have effect on some transports (e.g., CON/NON). The user application can call them depending on what scheme/tran= sport it chose. I tried to depict it:

 

+---------------------------------------------------+= ;

|          = ;            &n= bsp;            = ;            &n= bsp;   |

|        Application (cus= tom / LWM2M / IPSO)        |<= /span>

|          = ;            &n= bsp;            = ;            &n= bsp;   |

+---------------[ Req/Res Layer API ]---------------+= ; <--

|          &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  |

|         Request/Re= sponse Layer (CoAP spec)        |

|          &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  |

+---------------------------------------------------+= ;

| Message Layer (CoAP spec / alternative transport) |

+---------------------------------------------------+= ;

|   &n= bsp;            = ;         Transport Layer (UDP / DT= LS / TCP / TLS / SMS)         =             &nb= sp;         |

 

Ciao

Matthias

 

> -----Original Message-----

> From: Kovatsch Matthias [= mailto:kovatsch@inf.ethz.ch]

> Sent: Thursday, August 06, 2015 9:47 AM=

> To: core WG

> Subject: [core] Common request/response API<= o:p>

>

> Dear list

>

> In Prague, the problem of a common request/r= esponse API for all possible

> transports was raised. We now have something= similar in the Californium

> project, where we want to improve the error = handling for the CoapClient API as

> well as improve the information flow between= Scandium (DTLS) and Californium

> (or rather the application code).=

>

> As a start, I collected possible exceptions = that could signal what went wrong.

> While this might be a bit Java-centric, the = intent is universal: have a common set

> of signals to tell the application above the= request/response API what went

> wrong.

>

> Network layer

> - DestinationNotReachableException

> - PacketTooBigException

>

> Transport layer

> - ConnectionRefusedException

> - AuthenticationException

> - TooManyOpenFilesException / InsufficientRe= sourcesException (more OS-

> related, but happens at the socket level)

>

> Application layer

> - TimeoutException / NoReplyException

> - InvalidURIException / InvalidTransportExce= ption (alternative transports API)

> - RejectedException (not sure if the same as= ConnectionRefusedException)

>

> It would be great, if you could have a look,= suggest more

> exceptions/signals/error codes, propose thin= ning/merging, or just comment on

> the direction.

>

> Ciao

> Matthias

>

 

--_000_9966516C6EB5FC4381E05BF80AA55F77DC22F1C6US70UWXCHMBA05z_-- From nobody Sun Aug 9 23:25:15 2015 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 69DC71A92F5 for ; Sun, 9 Aug 2015 23:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 f1Elw7jh5-6f for ; Sun, 9 Aug 2015 23:25:11 -0700 (PDT) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F261A92FD for ; Sun, 9 Aug 2015 23:25:10 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.205]) by smtp-cloud3.xs4all.net with ESMTP id 2uR81r00K4RV18J01uR84D; Mon, 10 Aug 2015 08:25:09 +0200 Received: from [2001:983:a264:1:480f:2f20:60a1:afe9] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 10 Aug 2015 08:25:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 10 Aug 2015 08:25:08 +0200 From: peter van der Stok To: Kovatsch Matthias Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54C815017@MBX210.d.ethz.ch> References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> <5416B5903CF249719A3299837FF3AC86@WeiGengyuPC> <55877B3AFB359744BA0F2140E36F52B54C813E72@MBX210.d.ethz.ch> <1d4331c57230d49d35bef6df5e5ba4ed@xs4all.nl> <55877B3AFB359744BA0F2140E36F52B54C815017@MBX210.d.ethz.ch> Message-ID: X-Sender: stokcons@xs4all.nl (sfRSY1GFY/XdqAtons0mt+ogMLTpwdSt) User-Agent: XS4ALL Webmail Archived-At: Cc: core@ietf.org Subject: Re: [core] Patch idempotent? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 06:25:14 -0000 Hi Matthias, Not sure what your recommendations is: - No iPatch and Patch must be idempotent - No iPatch and Patch is preferred to be idempotent. Peter Kovatsch Matthias schreef op 2015-08-07 15:32: > Hi Peter > >> It is possibly a good approach to use Patch for RD and make the patch >> invocation idem-potent. >> However, this is different from demanding that Patch is idem-potent on >> all >> servers. > > Clients usually do not know the server implementation. They have to > rely on the properties given through the methods. For instance, a > client can always be sure that a GET has no side-effects on the server > (unless the server has an erroneous implementation...). For RD, we > would have out-of-band information, but this is exactly the kind of > coupling REST tries to avoid. > >> Is the provision of iPatch an asset for servers which, in the absence >> of iPatch, >> assure that Patch is idem-potent? > > Not for servers, but for clients. Recovery in case of no response > becomes much easier, for instance. > However, I am not in favor of having two different PATCH methods... > let's keep it simple! :) > > Ciao > Matthias From nobody Tue Aug 11 05:00:26 2015 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 9D88F1A88A9 for ; Tue, 11 Aug 2015 05:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 nOT8kMkul2pL for ; Tue, 11 Aug 2015 05:00:22 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3F11A88A6 for ; Tue, 11 Aug 2015 05:00:20 -0700 (PDT) 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.248.2; Tue, 11 Aug 2015 14:00:16 +0200 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.03.0248.002; Tue, 11 Aug 2015 14:00:15 +0200 From: "Kovatsch Matthias" To: "consultancy@vanderstok.org" Thread-Topic: [core] Patch idempotent? Thread-Index: AQHQyRnD64vZ1u/NA0WKvHzR1WgUlp3yDH4AgAGC6oCAB33bAIAECxIQgAD93oCAAH7EgIAEIekAgAIMGZA= Date: Tue, 11 Aug 2015 12:00:14 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B54C820DEC@MBX110.d.ethz.ch> References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> <5416B5903CF249719A3299837FF3AC86@WeiGengyuPC> <55877B3AFB359744BA0F2140E36F52B54C813E72@MBX210.d.ethz.ch> <1d4331c57230d49d35bef6df5e5ba4ed@xs4all.nl> <55877B3AFB359744BA0F2140E36F52B54C815017@MBX210.d.ethz.ch> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Patch idempotent? 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 Aug 2015 12:00:24 -0000 Hi Peter > Not sure what your recommendations is In my opinion, we should: - Keep things simple - Only have one PATCH method in CoAP - Design PATCH in such a way that it actually has a benefit over POST, that= is, clear semantics and/or better properties (e.g., idempotency) However, I am sure people thought a lot about HTTP PATCH and idempotency is= hard to achieve. Some random thoughts (sorry, I currently cannot work on t= his properly...): Do we always require "patch documents" (i.e., special media types)? We coul= d make PATCH with a "normal media type" behave like what was intended with = PUT in RD, that is, adding the entries of the request body to the resource = without replacing the entire resource (which is expected from PUT). I am not sure if a MUST for ETags would be a valid approach: servers/resour= ces supporting PATCH must provide ETags and clients must include the If-Mat= ch option in PATCH requests with. Maybe the latter can be limited to patch = document types, which are hard to make idempotent. Regards Matthias From nobody Tue Aug 11 05:19:54 2015 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 D490E1A883C for ; Tue, 11 Aug 2015 05:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 45dN6PaN01wy for ; Tue, 11 Aug 2015 05:19:49 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 390981A8931 for ; Tue, 11 Aug 2015 05:19:48 -0700 (PDT) Received: from CAS22.d.ethz.ch (172.31.51.112) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 11 Aug 2015 14:19:43 +0200 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.03.0248.002; Tue, 11 Aug 2015 14:19:46 +0200 From: "Kovatsch Matthias" To: "Carey, Timothy (Timothy)" , core WG Thread-Topic: [core] Common request/response API Thread-Index: AdDQVeNuAPt1Zq9NRquldRnePYfjpAAF2igAACjsw5D///fSAP//1AKwgABMegD/+d9z0A== Date: Tue, 11 Aug 2015 12:19:45 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B54C821E7A@MBX110.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B54C813E91@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22E65A@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C814F8D@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22EFEA@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C815218@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22F1C6@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC22F1C6@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B54C821E7AMBX110dethzch_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] Common request/response API 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 Aug 2015 12:19:54 -0000 --_000_55877B3AFB359744BA0F2140E36F52B54C821E7AMBX110dethzch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, the application also needs to be informed of failures that are unrelat= ed to CoAP such as failures at lower layers or the operating system (I woul= dn't call it "Abort," though, but an exception or error). How many "arrows" you have in the API between Req/Res Layer and Application= Layer depends on your implementation. Note that they are equivalent: - Downward o 1 down: attach all lower-layer-specific information to the request call= (useful if the requirements change for each request) o 2 down: have separate calls to configure the lower layers (e.g., choose= the network operator for the cellular modem or relax the requirement for a= ll requests to NON) - Upward o 1 up: use a wrapper response struct/object that has either a CoAP respo= nse or an exception/error o 2 up: split responses (return value or onSuccess(Response) handler) and= exceptions (e.g., catch blocks or in an onError(Exception) handler). The question for here is whether we can identify a common set of Exceptions= that is agnostic of specific lower layers. Regards Matthias From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: Freitag, 7. August 2015 18:27 To: Kovatsch Matthias ; core WG Subject: RE: [core] Common request/response API Matthias, So are you suggesting then that the API between the End Application and the= Request Response Layer be: REQ /\ /\ Application Layer (LWM2M,IPSO) | | | ------|------|------|------ | | \/ RESP Abort REQ/RESP Layer I just wanted to be clear that this is an additional type of interaction. BR, Tim From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, August 07, 2015 10:12 AM To: Carey, Timothy (Timothy); core WG Subject: RE: [core] Common request/response API No, response codes reflect success in this context (even 4.xx and 5.xx), si= nce the request could be delivered and a response was received. Exceptions = are for the things that could go wrong during transmission/reception. From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com] Sent: Friday, 7 August 2015 16:31 To: Kovatsch Matthias >; = core WG > Subject: RE: [core] Common request/response API Matthias, Then the exceptions you have listed should be reflected in Resp Codes? BR, Tim From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Friday, August 07, 2015 8:18 AM To: Carey, Timothy (Timothy); core WG Subject: RE: [core] Common request/response API Hi Tim > In your view the Application Layer that would receive these indications i= s the > Request/Response Layer which then you return the appropriate Error code? No, the Request/Response Layer is part of CoAP and defines the methods, res= ponse codes, options, etc. The user application uses an API ("Req/Res Layer= API") to issue requests and receive responses and will receive these error= codes. The codes need to be transport-agnostic. The transport itself can b= e chosen through the scheme used in the URI passed to the Req/Res API. In C= alifornium, I will probably add additional API calls that only have effect = on some transports (e.g., CON/NON). The user application can call them depe= nding on what scheme/transport it chose. I tried to depict it: +---------------------------------------------------+ | | | Application (custom / LWM2M / IPSO) | | | +---------------[ Req/Res Layer API ]---------------+ <-- | | | Request/Response Layer (CoAP spec) | | | +---------------------------------------------------+ | Message Layer (CoAP spec / alternative transport) | +---------------------------------------------------+ | Transport Layer (UDP / DTLS / TCP / TLS / SMS) = | Ciao Matthias > -----Original Message----- > From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] > Sent: Thursday, August 06, 2015 9:47 AM > To: core WG > Subject: [core] Common request/response API > > Dear list > > In Prague, the problem of a common request/response API for all possible > transports was raised. We now have something similar in the Californium > project, where we want to improve the error handling for the CoapClient A= PI as > well as improve the information flow between Scandium (DTLS) and Californ= ium > (or rather the application code). > > As a start, I collected possible exceptions that could signal what went w= rong. > While this might be a bit Java-centric, the intent is universal: have a c= ommon set > of signals to tell the application above the request/response API what we= nt > wrong. > > Network layer > - DestinationNotReachableException > - PacketTooBigException > > Transport layer > - ConnectionRefusedException > - AuthenticationException > - TooManyOpenFilesException / InsufficientResourcesException (more OS- > related, but happens at the socket level) > > Application layer > - TimeoutException / NoReplyException > - InvalidURIException / InvalidTransportException (alternative transports= API) > - RejectedException (not sure if the same as ConnectionRefusedException) > > It would be great, if you could have a look, suggest more > exceptions/signals/error codes, propose thinning/merging, or just comment= on > the direction. > > Ciao > Matthias > --_000_55877B3AFB359744BA0F2140E36F52B54C821E7AMBX110dethzch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, the application also needs to be informed of failu= res that are unrelated to CoAP such as failures at lower layers or the oper= ating system (I wouldn’t call it “Abort,” though, but an exception or error).

 

How many “arrows” you have in the API betwe= en Req/Res Layer and Application Layer depends on your implementation. Note= that they are equivalent:

 

-      = ;    Downward

o &n= bsp; 1 down: attach all lower-layer-specific informa= tion to the request call (useful if the requirements change for each reques= t)

o &n= bsp; 2 down: have separate calls to configure the lo= wer layers (e.g., choose the network operator for the cellular modem or rel= ax the requirement for all requests to NON)

-      = ;    Upward

o &n= bsp; 1 up: use a wrapper response struct/object that= has either a CoAP response or an exception/error

o &n= bsp; 2 up: split responses (return value or onSucces= s(Response) handler) and exceptions (e.g., catch blocks or in an onError(Ex= ception) handler).

 

The question for here is whether we can identify a comm= on set of Exceptions that is agnostic of specific lower layers.<= /span>

 

Regards

Matthias

 

 

From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.c= om]
Sent: Freitag, 7. August 2015 18:27
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>; core WG <core= @ietf.org>
Subject: RE: [core] Common request/response API

 

Matthias,

 

So are you suggesting then that th= e API between the End Application and the Request Response Layer be:

 

     REQ   = /\     /\      Application La= yer (LWM2M,IPSO)

      |  &n= bsp;   |      |

------|------|------|------<= /p>

      |  &n= bsp;   |

     \/    =  RESP  Abort    REQ/RESP Layer

 

I just wanted to be clear that this is an addi= tional type of interaction.

 

BR,

Tim

 

From: Ko= vatsch Matthias [mailto:kovatsch@in= f.ethz.ch]
Sent: Friday, August 07, 2015 10:12 AM
To: Carey, Timothy (Timothy); core WG
Subject: RE: [core] Common request/response API

 

No, res= ponse codes reflect success in this context (even 4.xx and 5.xx), since the= request could be delivered and a response was received. Exceptions are for= the things that could go wrong during transmission/reception.

&n= bsp;

&n= bsp;

From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: Friday, 7 August 2015 16:31
To: Kovatsch Matthias <ko= vatsch@inf.ethz.ch>; core WG <co= re@ietf.org>
Subject: RE: [core] Common request/response API

 

Matthias,

 

Then the exceptions you have liste= d should be reflected in Resp Codes?

 

BR,

Tim

 

From: Ko= vatsch Matthias [mailto:kovatsch@in= f.ethz.ch]
Sent: Friday, August 07, 2015 8:18 AM
To: Carey, Timothy (Timothy); core WG
Subject: RE: [core] Common request/response API

 

Hi Tim

&= nbsp;

> In your view the Applic= ation Layer that would receive these indications is the

> Request/Response Layer = which then you return the appropriate Error code?

&= nbsp;

No, th= e Request/Response Layer is part of CoAP and defines the methods, response = codes, options, etc. The user application uses an API (“Req/Res Layer= API”) to issue requests and receive responses and will receive these error codes. The codes need to be transport-agnosti= c. The transport itself can be chosen through the scheme used in the URI pa= ssed to the Req/Res API. In Californium, I will probably add additional API= calls that only have effect on some transports (e.g., CON/NON). The user application can call them depend= ing on what scheme/transport it chose. I tried to depict it:

&= nbsp;

+----------------------------------------= -----------+

|       &n= bsp;            = ;            &n= bsp;            = ;      |

|        A= pplication (custom / LWM2M / IPSO)       = ; |

|       &n= bsp;            = ;            &n= bsp;            = ;      |

+---------------[ Req/Res Layer API ]----= -----------+ <--

|        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     |

|        &= nbsp;Request/Response Layer (CoAP spec)       = ; |

|        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     |

+----------------------------------------= -----------+

| Message Layer (CoAP spec / alternative tran= sport) |

+----------------------------------------= -----------+

| = ;            &n= bsp;           Transport = Layer (UDP / DTLS / TCP / TLS / SMS)      &nb= sp;            =             |

&= nbsp;

Ciao

Matthi= as

 

> -----Original Message--= ---

> From: Kovatsch Matthias= [mailto:kovatsch@inf.ethz.ch]

> Sent: Thursday, August = 06, 2015 9:47 AM

> To: core WG<= /span>

> Subject: [core] Common = request/response API

>

> Dear list

>

> In Prague, the problem = of a common request/response API for all possible

> transports was raised. = We now have something similar in the Californium

> project, where we want = to improve the error handling for the CoapClient API as

> well as improve the inf= ormation flow between Scandium (DTLS) and Californium

> (or rather the applicat= ion code).

>

> As a start, I collected= possible exceptions that could signal what went wrong.

> While this might be a b= it Java-centric, the intent is universal: have a common set

> of signals to tell the = application above the request/response API what went

> wrong.

>

> Network layer

> - DestinationNotReachab= leException

> - PacketTooBigException=

>

> Transport layer

> - ConnectionRefusedExce= ption

> - AuthenticationExcepti= on

> - TooManyOpenFilesExcep= tion / InsufficientResourcesException (more OS-

> related, but happens at= the socket level)

>

> Application layer<= /o:p>

> - TimeoutException / No= ReplyException

> - InvalidURIException /= InvalidTransportException (alternative transports API)

> - RejectedException (no= t sure if the same as ConnectionRefusedException)

>

> It would be great, if y= ou could have a look, suggest more

> exceptions/signals/erro= r codes, propose thinning/merging, or just comment on

> the direction.

>

> Ciao<= /p>

> Matthias

>

 

--_000_55877B3AFB359744BA0F2140E36F52B54C821E7AMBX110dethzch_-- From nobody Tue Aug 11 10:31:10 2015 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 A625D1ACE08 for ; Tue, 11 Aug 2015 10:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 jrQH3CQSndiz for ; Tue, 11 Aug 2015 10:31:06 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBAD31ACE0B for ; Tue, 11 Aug 2015 10:31:05 -0700 (PDT) Received: by lahi9 with SMTP id i9so44612907lah.2 for ; Tue, 11 Aug 2015 10:31:04 -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=Xrjsl+4Qv+UKRtfYbSBozg6jsTSeC7j9gbWx83bhuwI=; b=vweIheIM/xm9PTXtcQD6uRzFfJ5qABC1RnH4c6eQCyynwT/75nr9SyMuFWN0ugsrZi qsJQhPBnzm2iYHLjdhdTDzIF+1Cx/THEsw8RSKigklor1exNgl6ha94/x167krjWknDG 3fjw9IWyMg7uvGyX9ci0IHvEcC+3VxNNh/PrQ/HWnJ4DCzLJdJG3U7v5U9BCXi2lV1LE lEX2x91Y0vSCT7DlpZ9cgiXoMt2FCamdkCB9EE4kCJ+gSdyMvx2lUoxAL/TFpaPmaXJf E0Bqht60tEb08Z5Tw+4LxZhSHjSk+IJm5qoUh6/PLcJFLzEklNSKOd0qQi08GPOo0UY+ hMXg== MIME-Version: 1.0 X-Received: by 10.112.55.33 with SMTP id o1mr27001361lbp.96.1439314264265; Tue, 11 Aug 2015 10:31:04 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.25.83.65 with HTTP; Tue, 11 Aug 2015 10:31:04 -0700 (PDT) In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54C821E7A@MBX110.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B54C813E91@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22E65A@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C814F8D@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22EFEA@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C815218@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22F1C6@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C821E7A@MBX110.d.ethz.ch> Date: Tue, 11 Aug 2015 18:31:04 +0100 X-Google-Sender-Auth: 6pm9ZDqMhX0-ilFTGV8t8x214-o Message-ID: From: Robert Cragie To: Kovatsch Matthias Content-Type: multipart/alternative; boundary=001a11c3a36c71194a051d0c77cb Archived-At: Cc: "Carey, Timothy \(Timothy\)" , core WG Subject: Re: [core] Common request/response API 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: Tue, 11 Aug 2015 17:31:09 -0000 --001a11c3a36c71194a051d0c77cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I started to put together a strawman document on this topic and would appreciate any comments. https://docs.google.com/document/d/1a8BCVrKcGH0QmKDcV16SaJuD2ai_3v-ds3X7wf_= 32JE/edit?usp=3Dsharing Robert On 11 August 2015 at 13:19, Kovatsch Matthias wrote: > Yes, the application also needs to be informed of failures that are > unrelated to CoAP such as failures at lower layers or the operating syste= m > (I wouldn=E2=80=99t call it =E2=80=9CAbort,=E2=80=9D though, but an excep= tion or error). > > > > How many =E2=80=9Carrows=E2=80=9D you have in the API between Req/Res Lay= er and > Application Layer depends on your implementation. Note that they are > equivalent: > > > > - Downward > > o 1 down: attach all lower-layer-specific information to the request > call (useful if the requirements change for each request) > > o 2 down: have separate calls to configure the lower layers (e.g., > choose the network operator for the cellular modem or relax the requireme= nt > for all requests to NON) > > - Upward > > o 1 up: use a wrapper response struct/object that has either a CoAP > response or an exception/error > > o 2 up: split responses (return value or onSuccess(Response) handler) > and exceptions (e.g., catch blocks or in an onError(Exception) handler). > > > > The question for here is whether we can identify a common set of > Exceptions that is agnostic of specific lower layers. > > > > Regards > > Matthias > > > > > > *From:* Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com= ] > > *Sent:* Freitag, 7. August 2015 18:27 > > *To:* Kovatsch Matthias ; core WG > *Subject:* RE: [core] Common request/response API > > > > Matthias, > > > > So are you suggesting then that the API between the End Application and > the Request Response Layer be: > > > > REQ /\ /\ Application Layer (LWM2M,IPSO) > > | | | > > ------|------|------|------ > > | | > > \/ RESP Abort REQ/RESP Layer > > > > I just wanted to be clear that this is an additional type of interaction. > > > > BR, > > Tim > > > > *From:* Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch > ] > *Sent:* Friday, August 07, 2015 10:12 AM > *To:* Carey, Timothy (Timothy); core WG > *Subject:* RE: [core] Common request/response API > > > > No, response codes reflect success in this context (even 4.xx and 5.xx), > since the request could be delivered and a response was received. > Exceptions are for the things that could go wrong during > transmission/reception. > > > > > > *From:* Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com > ] > *Sent:* Friday, 7 August 2015 16:31 > *To:* Kovatsch Matthias ; core WG > *Subject:* RE: [core] Common request/response API > > > > Matthias, > > > > Then the exceptions you have listed should be reflected in Resp Codes? > > > > BR, > > Tim > > > > *From:* Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch > ] > *Sent:* Friday, August 07, 2015 8:18 AM > *To:* Carey, Timothy (Timothy); core WG > *Subject:* RE: [core] Common request/response API > > > > Hi Tim > > > > > In your view the Application Layer that would receive these indications > is the > > > Request/Response Layer which then you return the appropriate Error code= ? > > > > No, the Request/Response Layer is part of CoAP and defines the methods, > response codes, options, etc. The user application uses an API (=E2=80=9C= Req/Res > Layer API=E2=80=9D) to issue requests and receive responses and will rece= ive these > error codes. The codes need to be transport-agnostic. The transport itsel= f > can be chosen through the scheme used in the URI passed to the Req/Res AP= I. > In Californium, I will probably add additional API calls that only have > effect on some transports (e.g., CON/NON). The user application can call > them depending on what scheme/transport it chose. I tried to depict it: > > > > +---------------------------------------------------+ > > | | > > | Application (custom / LWM2M / IPSO) | > > | | > > +---------------[ Req/Res Layer API ]---------------+ <-- > > | | > > | Request/Response Layer (CoAP spec) | > > | | > > +---------------------------------------------------+ > > | Message Layer (CoAP spec / alternative transport) | > > +---------------------------------------------------+ > > | Transport Layer (UDP / DTLS / TCP / TLS / > SMS) | > > > > Ciao > > Matthias > > > > > -----Original Message----- > > > From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch > ] > > > Sent: Thursday, August 06, 2015 9:47 AM > > > To: core WG > > > Subject: [core] Common request/response API > > > > > > Dear list > > > > > > In Prague, the problem of a common request/response API for all possibl= e > > > transports was raised. We now have something similar in the Californium > > > project, where we want to improve the error handling for the CoapClient > API as > > > well as improve the information flow between Scandium (DTLS) and > Californium > > > (or rather the application code). > > > > > > As a start, I collected possible exceptions that could signal what went > wrong. > > > While this might be a bit Java-centric, the intent is universal: have a > common set > > > of signals to tell the application above the request/response API what > went > > > wrong. > > > > > > Network layer > > > - DestinationNotReachableException > > > - PacketTooBigException > > > > > > Transport layer > > > - ConnectionRefusedException > > > - AuthenticationException > > > - TooManyOpenFilesException / InsufficientResourcesException (more OS- > > > related, but happens at the socket level) > > > > > > Application layer > > > - TimeoutException / NoReplyException > > > - InvalidURIException / InvalidTransportException (alternative > transports API) > > > - RejectedException (not sure if the same as ConnectionRefusedException= ) > > > > > > It would be great, if you could have a look, suggest more > > > exceptions/signals/error codes, propose thinning/merging, or just > comment on > > > the direction. > > > > > > Ciao > > > Matthias > > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --001a11c3a36c71194a051d0c77cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I started to put together a strawman document on this topi= c and would appreciate any comments.


R= obert

= On 11 August 2015 at 13:19, Kovatsch Matthias <kovatsch@inf.ethz.ch> wrote:

Yes, th= e application also needs to be informed of failures that are unrelated to C= oAP such as failures at lower layers or the operating system (I wouldn=E2= =80=99t call it =E2=80=9CAbort,=E2=80=9D though, but an exception or error).

= =C2=A0

How man= y =E2=80=9Carrows=E2=80=9D you have in the API between Req/Res Layer and Ap= plication Layer depends on your implementation. Note that they are equivale= nt:

= =C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Do= wnward

o= =C2=A0=C2=A0 1 = down: attach all lower-layer-specific information to the request call (usef= ul if the requirements change for each request)

o= =C2=A0=C2=A0 2 = down: have separate calls to configure the lower layers (e.g., choose the n= etwork operator for the cellular modem or relax the requirement for all req= uests to NON)

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Up= ward

o= =C2=A0=C2=A0 1 = up: use a wrapper response struct/object that has either a CoAP response or= an exception/error

o= =C2=A0=C2=A0 2 = up: split responses (return value or onSuccess(Response) handler) and excep= tions (e.g., catch blocks or in an onError(Exception) handler).

= =C2=A0

The que= stion for here is whether we can identify a common set of Exceptions that i= s agnostic of specific lower layers.

= =C2=A0

Regards=

Matthia= s

= =C2=A0

= =C2=A0

=C2=A0

Matthias,

=C2=A0

So are you suggesting then that th= e API between the End Application and the Request Response Layer be:=

=C2=A0

=C2=A0=C2=A0 =C2=A0=C2=A0REQ=C2=A0=C2=A0=C2=A0= /\=C2=A0=C2=A0=C2=A0=C2=A0 /\=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0Application La= yer (LWM2M,IPSO)

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

------|------|------|------

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |

=C2=A0 =C2=A0=C2=A0=C2=A0\/=C2=A0=C2=A0=C2=A0 = =C2=A0RESP=C2=A0 Abort=C2=A0=C2=A0=C2=A0 REQ/RESP Layer

=C2=A0

I just wanted to be clear that this is an addi= tional type of interaction.

=C2=A0

BR,

Tim

=C2=A0

From: Ko= vatsch Matthias [= mailto:kovatsch@inf.ethz.ch]
Sent: Friday, August 07, 2015 10:12 AM
To: Carey, Timothy (Timothy); core WG
Subject: RE: [core] Common request/response API=

=C2=A0

No, res= ponse codes reflect success in this context (even 4.xx and 5.xx), since the= request could be delivered and a response was received. Exceptions are for= the things that could go wrong during transmission/reception.

= =C2=A0

= =C2=A0

From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: Friday, 7 August 2015 16:31
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>; core WG <core@ietf.org>
Subject: RE: [core] Common request/response API=

=C2=A0

Matthias,

=C2=A0

Then the exceptions you have liste= d should be reflected in Resp Codes?

=C2=A0

BR,

Tim

=C2=A0

From: Ko= vatsch Matthias [= mailto:kovatsch@inf.ethz.ch]
Sent: Friday, August 07, 2015 8:18 AM
To: Carey, Timothy (Timothy); core WG
Subject: RE: [core] Common request/response API=

=C2=A0

Hi Tim

=C2=A0

> In your view the Application Layer that would = receive these indications is the

> Request/Response Layer which then you return t= he appropriate Error code?

=C2=A0

No, the Request/Response Laye= r is part of CoAP and defines the methods, response codes, options, etc. Th= e user application uses an API (=E2=80=9CReq/Res Layer API=E2=80=9D) to iss= ue requests and receive responses and will receive these error codes. The codes need to be transport-agnosti= c. The transport itself can be chosen through the scheme used in the URI pa= ssed to the Req/Res API. In Californium, I will probably add additional API= calls that only have effect on some transports (e.g., CON/NON). The user application can call them depend= ing on what scheme/transport it chose. I tried to depict it:<= /span>

=C2=A0

+---------------------------------------------------+<= /span>

|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |

| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Application (custom / LW= M2M / IPSO)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |

+---------------[ Req/Res Layer API ]---------------+ <--<= u>

| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0|

| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Request/Response L= ayer (CoAP spec) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|<= /span>

| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0|

+---------------------------------------------------+<= /span>

| Message Layer (CoAP spec / alternative transport) |<= /span>

+---------------------------------------------------+<= /span>

|=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0Transport Layer (UDP / DTLS / TC= P / TLS / SMS)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0

Ciao

Matthias=

=C2=A0

> -----Original Message-----

> From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]

> Sent: Thursday, August 06, 2015 9:47 AM=

> To: core WG

> Subject: [core] Common request/response API=

>

> Dear list

>

> In Prague, the problem of a common request/res= ponse API for all possible

> transports was raised. We now have something s= imilar in the Californium

> project, where we want to improve the error ha= ndling for the CoapClient API as

> well as improve the information flow between S= candium (DTLS) and Californium

> (or rather the application code).

>

> As a start, I collected possible exceptions th= at could signal what went wrong.

> While this might be a bit Java-centric, the in= tent is universal: have a common set

> of signals to tell the application above the r= equest/response API what went

> wrong.

>

> Network layer

> - DestinationNotReachableException

> - PacketTooBigException

>

> Transport layer

> - ConnectionRefusedException

> - AuthenticationException=

> - TooManyOpenFilesException / InsufficientReso= urcesException (more OS-

> related, but happens at the socket level)

>

> Application layer

> - TimeoutException / NoReplyException

> - InvalidURIException / InvalidTransportExcept= ion (alternative transports API)

> - RejectedException (not sure if the same as C= onnectionRefusedException)

>

> It would be great, if you could have a look, s= uggest more

> exceptions/signals/error codes, propose thinni= ng/merging, or just comment on

> the direction.

>

> Ciao

> Matthias

>

=C2=A0


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


--001a11c3a36c71194a051d0c77cb-- From nobody Tue Aug 11 10:41:17 2015 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 7127E1ACE1F for ; Tue, 11 Aug 2015 10:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 aKdlE5dBFJX6 for ; Tue, 11 Aug 2015 10:41:14 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5501A21B2 for ; Tue, 11 Aug 2015 10:41:14 -0700 (PDT) Received: by lahi9 with SMTP id i9so44758607lah.2 for ; Tue, 11 Aug 2015 10:41:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bSf91L0EqyeHDL8NJ10eqHWyIAjRbgny/BByBuzMpeI=; b=OfAi0r93hrOzzzJA/WjvA2ybsuClYtJcUdiHHeQreRzuuQTKfvs1foAE9KLkV7ha58 QxT01ljAActmCMtIbFCVv8I9zBs6wCyXnVxbBdH/6E2bYi0GqLwoCZv4QShYvIwJupwS FPgXN2e0LzLsOXu4x3y/fcnCGxC+GsiUk5Prap2zzO8zpW0IH/fiIlJaQ8j0tAv7T4AL +LMJxpUUNVT92opoIigt4pHFClNsfB3E+rgRdJuaMo5hHksaPkkaq9iiOsgH7k/CUFZ+ EeCsEdbkENMu6FHSw2HL1Sopm5rH/kkzGmFksaXnEGEGC5WeWIUFjO3pyxvzlktLXSRa ysbw== X-Gm-Message-State: ALoCoQlHwJVWs8Lay5bl2FJkfF1Zp0rfIEtCs3AroJh0ZBqNuevt0sjiNdhAVvJMd1emJ6UCPC/D MIME-Version: 1.0 X-Received: by 10.112.154.106 with SMTP id vn10mr17245081lbb.38.1439314872490; Tue, 11 Aug 2015 10:41:12 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 11 Aug 2015 10:41:12 -0700 (PDT) In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54C820DEC@MBX110.d.ethz.ch> References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> <5416B5903CF249719A3299837FF3AC86@WeiGengyuPC> <55877B3AFB359744BA0F2140E36F52B54C813E72@MBX210.d.ethz.ch> <1d4331c57230d49d35bef6df5e5ba4ed@xs4all.nl> <55877B3AFB359744BA0F2140E36F52B54C815017@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B54C820DEC@MBX110.d.ethz.ch> Date: Tue, 11 Aug 2015 10:41:12 -0700 Message-ID: From: Andy Bierman To: Kovatsch Matthias Content-Type: multipart/alternative; boundary=089e0122af2ab1f475051d0c9bea Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Patch idempotent? 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 Aug 2015 17:41:16 -0000 --089e0122af2ab1f475051d0c9bea Content-Type: text/plain; charset=UTF-8 On Tue, Aug 11, 2015 at 5:00 AM, Kovatsch Matthias wrote: > Hi Peter > > > Not sure what your recommendations is > > In my opinion, we should: > > - Keep things simple > - Only have one PATCH method in CoAP > - Design PATCH in such a way that it actually has a benefit over POST, > that is, clear semantics and/or better properties (e.g., idempotency) > > However, I am sure people thought a lot about HTTP PATCH and idempotency > is hard to achieve. Some random thoughts (sorry, I currently cannot work on > this properly...): > > Do we always require "patch documents" (i.e., special media types)? We > could make PATCH with a "normal media type" behave like what was intended > with PUT in RD, that is, adding the entries of the request body to the > resource without replacing the entire resource (which is expected from PUT). > > I am not sure if a MUST for ETags would be a valid approach: > servers/resources supporting PATCH must provide ETags and clients must > include the If-Match option in PATCH requests with. Maybe the latter can be > limited to patch document types, which are hard to make idempotent. > > What is wrong with using ETags and If-Match if the server wants to support this feature? PATCH is very important to CoMI because it maps to a "merge" in YANG. This allows the client to send only the parts of the resource that are changing, instead of the whole thing. This will likely be 20:1 or 100:1 savings every time PATCH is used instead of PUT in CoMI. Regards > Matthias > > Andy > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --089e0122af2ab1f475051d0c9bea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 11, 2015 at 5:00 AM, Kovatsch Matthias &= lt;kovatsch@inf.e= thz.ch> wrote:
Hi Peter

> Not sure what your recommendations is

In my opinion, we should:

- Keep things simple
- Only have one PATCH method in CoAP
- Design PATCH in such a way that it actually has a benefit over POST, that= is, clear semantics and/or better properties (e.g., idempotency)

However, I am sure people thought a lot about HTTP PATCH and idempotency is= hard to achieve. Some random thoughts (sorry, I currently cannot work on t= his properly...):

Do we always require "patch documents" (i.e., special media types= )? We could make PATCH with a "normal media type" behave like wha= t was intended with PUT in RD, that is, adding the entries of the request b= ody to the resource without replacing the entire resource (which is expecte= d from PUT).

I am not sure if a MUST for ETags would be a valid approach: servers/resour= ces supporting PATCH must provide ETags and clients must include the If-Mat= ch option in PATCH requests with. Maybe the latter can be limited to patch = document types, which are hard to make idempotent.



What is wrong with usin= g ETags and If-Match if the server wants to support this feature?
PATCH is very important to CoMI because it maps to a "merge" in = YANG.
This allows the client to send only the parts of the resour= ce that are changing,
instead of the whole thing.=C2=A0 This will= likely be 20:1 or 100:1 savings every time
PATCH is used instead= of PUT in CoMI.


Regards
Matthias


Andy
=C2=A0
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

--089e0122af2ab1f475051d0c9bea-- From nobody Tue Aug 11 10:55:34 2015 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 B5A3D1ACE2A for ; Tue, 11 Aug 2015 10:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 7scMY0en6ilM for ; Tue, 11 Aug 2015 10:55:30 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63991ACE29 for ; Tue, 11 Aug 2015 10:55:29 -0700 (PDT) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 11 Aug 2015 19:55:24 +0200 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.03.0248.002; Tue, 11 Aug 2015 19:55:27 +0200 From: "Kovatsch Matthias" To: Andy Bierman Thread-Topic: [core] Patch idempotent? Thread-Index: AQHQyRnD64vZ1u/NA0WKvHzR1WgUlp3yDH4AgAGC6oCAB33bAIAECxIQgAD93oCAAH7EgIAEIekAgAIMGZCAAEMgAIAAId8g Date: Tue, 11 Aug 2015 17:55:27 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B54C8235DA@MBX110.d.ethz.ch> References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> <5416B5903CF249719A3299837FF3AC86@WeiGengyuPC> <55877B3AFB359744BA0F2140E36F52B54C813E72@MBX210.d.ethz.ch> <1d4331c57230d49d35bef6df5e5ba4ed@xs4all.nl> <55877B3AFB359744BA0F2140E36F52B54C815017@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B54C820DEC@MBX110.d.ethz.ch> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B54C8235DAMBX110dethzch_" MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Patch idempotent? 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 Aug 2015 17:55:32 -0000 --_000_55877B3AFB359744BA0F2140E36F52B54C8235DAMBX110dethzch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KV2hhdCBpcyB3 cm9uZyB3aXRoIHVzaW5nIEVUYWdzIGFuZCBJZi1NYXRjaCBpZiB0aGUgc2VydmVyIHdhbnRzIHRv IHN1cHBvcnQgdGhpcyBmZWF0dXJlPw0KDQpOb3RoaW5nIGlzIHdyb25nIHdpdGggdGhhdC4gSXQg d291bGQganVzdCBiZSBzaW1wbGVyIGFuZCBtb3JlIGVsZWdhbnQgaWYgd2UgY291bGQgZmluZCBh IHdheSB0byBiZSBpZGVtcG90ZW50IHdpdGhvdXQgRVRhZyBjaGVja3MuIE15IG90aGVyIHRob3Vn aHQgd2FzIG1vcmUgb24gZW5mb3JjaW5nIHRoZXNlIGNoZWNrcyBpZiB3ZSBjYW5ub3QgY29tZSB1 cCB3aXRoIHRoZSDigJxlbGVnYW50IHdheS7igJ0gVGhpcyB3YXksIHRoZXJlIHdvdWxkIGJlIGEg bG93ZXIgcHJvYmFiaWxpdHkgdGhhdCBjbGllbnRzIGNvcnJ1cHQgdGhlIHJlc291cmNlIHN0YXRl Lg0KDQpUaGlzIGFsbG93cyB0aGUgY2xpZW50IHRvIHNlbmQgb25seSB0aGUgcGFydHMgb2YgdGhl IHJlc291cmNlIHRoYXQgYXJlIGNoYW5naW5nLA0KaW5zdGVhZCBvZiB0aGUgd2hvbGUgdGhpbmcu ICBUaGlzIHdpbGwgbGlrZWx5IGJlIDIwOjEgb3IgMTAwOjEgc2F2aW5ncyBldmVyeSB0aW1lDQpQ QVRDSCBpcyB1c2VkIGluc3RlYWQgb2YgUFVUIGluIENvTUkuDQoNClllcywgdGhlIHJlcXVpcmVt ZW50IG9mIHNlbmRpbmcgb25seSBkZWx0YXMgaXMgY2xlYXIgdG8gbWUuIEkgYW0ganVzdCBzYXlp bmcgdGhhdCBpdCBjYW4gYWxzbyBiZSBpbXBsZW1lbnRlZCB3aXRoIFBPU1QgaWYgdGhlIFBBVENI IG1ldGhvZCBpdHNlbGYgZG9lcyBub3QgcHJvdmlkZSBkZWZpbmVkIHByb3BlcnRpZXMgdG8gdGhl IGNsaWVudC4gSW4gYm90aCBjYXNlcywgdGhlIGNsaWVudCBvbmx5IGNhbiBob3BlIHRoYXQgdGhl IHNlcnZlciB3aWxsIGRvIHRoZSByaWdodCB0aGluZy4NCg0KUmVnYXJkcw0KTWF0dGhpYXMNCg== --_000_55877B3AFB359744BA0F2140E36F52B54C8235DAMBX110dethzch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJERS1DSCIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV08L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2hhdCBpcyB3cm9uZyB3aXRo IHVzaW5nIEVUYWdzIGFuZCBJZi1NYXRjaCBpZiB0aGUgc2VydmVyIHdhbnRzIHRvIHN1cHBvcnQg dGhpcyBmZWF0dXJlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ob3RoaW5nIGlzIHdyb25nIHdp dGggdGhhdC4gSXQgd291bGQganVzdCBiZSBzaW1wbGVyIGFuZCBtb3JlIGVsZWdhbnQgaWYgd2Ug Y291bGQgZmluZCBhIHdheSB0byBiZSBpZGVtcG90ZW50IHdpdGhvdXQgRVRhZyBjaGVja3MuIE15 IG90aGVyIHRob3VnaHQNCiB3YXMgbW9yZSBvbiBlbmZvcmNpbmcgdGhlc2UgY2hlY2tzIGlmIHdl IGNhbm5vdCBjb21lIHVwIHdpdGggdGhlIOKAnGVsZWdhbnQgd2F5LuKAnSBUaGlzIHdheSwgdGhl cmUgd291bGQgYmUgYSBsb3dlciBwcm9iYWJpbGl0eSB0aGF0IGNsaWVudHMgY29ycnVwdCB0aGUg cmVzb3VyY2Ugc3RhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+VGhpcyBhbGxvd3MgdGhlIGNsaWVudCB0byBzZW5kIG9ubHkgdGhlIHBhcnRzIG9mIHRoZSBy ZXNvdXJjZSB0aGF0IGFyZSBjaGFuZ2luZyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pbnN0ZWFkIG9mIHRoZSB3aG9sZSB0aGluZy4m bmJzcDsgVGhpcyB3aWxsIGxpa2VseSBiZSAyMDoxIG9yIDEwMDoxIHNhdmluZ3MgZXZlcnkgdGlt ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UEFU Q0ggaXMgdXNlZCBpbnN0ZWFkIG9mIFBVVCBpbiBDb01JLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlllcywgdGhlIHJlcXVpcmVtZW50IG9mIHNlbmRpbmcgb25seSBk ZWx0YXMgaXMgY2xlYXIgdG8gbWUuIEkgYW0ganVzdCBzYXlpbmcgdGhhdCBpdCBjYW4gYWxzbyBi ZSBpbXBsZW1lbnRlZCB3aXRoIFBPU1QgaWYgdGhlIFBBVENIIG1ldGhvZCBpdHNlbGYNCiBkb2Vz IG5vdCBwcm92aWRlIGRlZmluZWQgcHJvcGVydGllcyB0byB0aGUgY2xpZW50LiBJbiBib3RoIGNh c2VzLCB0aGUgY2xpZW50IG9ubHkgY2FuIGhvcGUgdGhhdCB0aGUgc2VydmVyIHdpbGwgZG8gdGhl IHJpZ2h0IHRoaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5NYXR0aGlhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_55877B3AFB359744BA0F2140E36F52B54C8235DAMBX110dethzch_-- From nobody Wed Aug 12 05:38:41 2015 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 36D0C1B2D52 for ; Wed, 12 Aug 2015 05:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 kNqyy7NcJ6GU for ; Wed, 12 Aug 2015 05:38:36 -0700 (PDT) Received: from smtp2.ugent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8A21B2D51 for ; Wed, 12 Aug 2015 05:38:35 -0700 (PDT) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp2.ugent.be (Postfix) with ESMTP id 69D5612C2FF; Wed, 12 Aug 2015 14:38:34 +0200 (CEST) X-Virus-Scanned: by UGent DICT Received: from smtp2.ugent.be ([IPv6:::ffff:157.193.49.126]) by localhost (mcheck2.UGent.be [::ffff:157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 92s6L0OYdTdN; Wed, 12 Aug 2015 14:38:33 +0200 (CEST) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp2.ugent.be (Postfix) with ESMTP id CC57612C2E2; Wed, 12 Aug 2015 14:38:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id B64E330; Wed, 12 Aug 2015 14:38:32 +0200 (CEST) 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 E-ybt1OP_wHv; Wed, 12 Aug 2015 14:38:32 +0200 (CEST) Received: from [157.193.135.182] (dhcp-zdpt-182.intec.ugent.be [157.193.135.182]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fvdabeele) by mail2.intec.ugent.be (Postfix) with ESMTPSA id 21E232E; Wed, 12 Aug 2015 14:38:32 +0200 (CEST) Message-ID: <55CB3E46.7060503@intec.ugent.be> Date: Wed, 12 Aug 2015 14:38:30 +0200 From: Floris Van den Abeele User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <55877B3AFB359744BA0F2140E36F52B54C813E91@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22E65A@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C814F8D@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22EFEA@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C815218@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22F1C6@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C821E7A@MBX110.d.ethz.ch> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030500010404040502000901" X-Miltered: at jchkm1 with ID 55CB3E48.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 55CB3E48.000 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 55CB3E48.000 on smtp2.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: "Carey, Timothy \(Timothy\)" , core WG Subject: Re: [core] Common request/response API 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 Aug 2015 12:38:40 -0000 This is a multi-part message in MIME format. --------------030500010404040502000901 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Would such signals also include sanity checks on CoAP requests that are asked by the application? In some implementations the API itself can be designed to prevent constructing invalid CoAP requests. But in our implementation, the interface between the application and the CoAP client (potentially running in a separate process on another machine) is a socket and all the data about the request and the response (or error/warning) is also transferred over this socket. Applications describe their request via CSV strings, and the response is received as a CSV string. This will sometimes lead to invalid requests if the application is oblivious. Our implementation includes sanity checks for some of the MUST (NOT)s in the CoAP spec: * A Non-confirmable message always carries either a request or response and MUST NOT be Empty -> Non messages must not be empty * If a Method or Response Code is not defined to have a payload, then a sender MUST NOT include one, and a recipient MUST ignore it. -> GET requests must not include a payload. Of course one could argue that in our case the logic generating the CSV strings is actually part of the CoAP client library and not the application itself, and that such signals should not be propagated to the application and rather that the logic (i.e API) generating the CSV strings should prevent applications from constructing empty non-messages, GET requests without a payload, etc. BR, Floris On 11-08-15 19:31, Robert Cragie wrote: > I started to put together a strawman document on this topic and would > appreciate any comments. > > https://docs.google.com/document/d/1a8BCVrKcGH0QmKDcV16SaJuD2ai_3v-ds3X7wf_32JE/edit?usp=sharing > > Robert > > On 11 August 2015 at 13:19, Kovatsch Matthias > wrote: > > Yes, the application also needs to be informed of failures that > are unrelated to CoAP such as failures at lower layers or the > operating system (I wouldn鈥檛 call it 鈥淎bort,鈥 though, but an > exception or error). > > > > How many 鈥渁rrows鈥 you have in the API between Req/Res Layer and > Application Layer depends on your implementation. Note that they > are equivalent: > > > > - Downward > > o 1 down: attach all lower-layer-specific information to the > request call (useful if the requirements change for each request) > > o 2 down: have separate calls to configure the lower layers > (e.g., choose the network operator for the cellular modem or relax > the requirement for all requests to NON) > > - Upward > > o 1 up: use a wrapper response struct/object that has either a > CoAP response or an exception/error > > o 2 up: split responses (return value or onSuccess(Response) > handler) and exceptions (e.g., catch blocks or in an > onError(Exception) handler). > > > > The question for here is whether we can identify a common set of > Exceptions that is agnostic of specific lower layers. > > > > Regards > > Matthias > > > > > > *From:*Carey, Timothy (Timothy) > [mailto:timothy.carey@alcatel-lucent.com > ] > *Sent:* Freitag, 7. August 2015 18:27 > > > *To:* Kovatsch Matthias >; core WG > > *Subject:* RE: [core] Common request/response API > > > > Matthias, > > > > So are you suggesting then that the API between the End > Application and the Request Response Layer be: > > > > REQ /\ /\ Application Layer (LWM2M,IPSO) > > | | | > > ------|------|------|------ > > | | > > \/ RESP Abort REQ/RESP Layer > > > > I just wanted to be clear that this is an additional type of > interaction. > > > > BR, > > Tim > > > > *From:*Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] > *Sent:* Friday, August 07, 2015 10:12 AM > *To:* Carey, Timothy (Timothy); core WG > *Subject:* RE: [core] Common request/response API > > > > No, response codes reflect success in this context (even 4.xx and > 5.xx), since the request could be delivered and a response was > received. Exceptions are for the things that could go wrong during > transmission/reception. > > > > > > *From:*Carey, Timothy (Timothy) > [mailto:timothy.carey@alcatel-lucent.com] > *Sent:* Friday, 7 August 2015 16:31 > *To:* Kovatsch Matthias >; core WG > > *Subject:* RE: [core] Common request/response API > > > > Matthias, > > > > Then the exceptions you have listed should be reflected in Resp Codes? > > > > BR, > > Tim > > > > *From:*Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] > *Sent:* Friday, August 07, 2015 8:18 AM > *To:* Carey, Timothy (Timothy); core WG > *Subject:* RE: [core] Common request/response API > > > > Hi Tim > > > > > In your view the Application Layer that would receive these indications is the > > > Request/Response Layer which then you return the appropriate Error code? > > > > No, the Request/Response Layer is part of CoAP and defines the > methods, response codes, options, etc. The user application uses > an API (鈥淩eq/Res Layer API鈥) to issue requests and receive > responses and will receive these error codes. The codes need to be > transport-agnostic. The transport itself can be chosen through the > scheme used in the URI passed to the Req/Res API. In Californium, > I will probably add additional API calls that only have effect on > some transports (e.g., CON/NON). The user application can call > them depending on what scheme/transport it chose. I tried to > depict it: > > > > +---------------------------------------------------+ > > | | > > | Application (custom / LWM2M / IPSO) | > > | | > > +---------------[ Req/Res Layer API ]---------------+ <-- > > | | > > | Request/Response Layer (CoAP spec) | > > | | > > +---------------------------------------------------+ > > | Message Layer (CoAP spec / alternative transport) | > > +---------------------------------------------------+ > > | Transport Layer (UDP / DTLS / TCP / TLS > / SMS) | > > > > Ciao > > Matthias > > > > > -----Original Message----- > > > From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] > > > Sent: Thursday, August 06, 2015 9:47 AM > > > To: core WG > > > Subject: [core] Common request/response API > > > > > > Dear list > > > > > > In Prague, the problem of a common request/response API for all possible > > > transports was raised. We now have something similar in the Californium > > > project, where we want to improve the error handling for the CoapClient API as > > > well as improve the information flow between Scandium (DTLS) and Californium > > > (or rather the application code). > > > > > > As a start, I collected possible exceptions that could signal what went wrong. > > > While this might be a bit Java-centric, the intent is universal: have a common set > > > of signals to tell the application above the request/response API what went > > > wrong. > > > > > > Network layer > > > - DestinationNotReachableException > > > - PacketTooBigException > > > > > > Transport layer > > > - ConnectionRefusedException > > > - AuthenticationException > > > - TooManyOpenFilesException / InsufficientResourcesException (more OS- > > > related, but happens at the socket level) > > > > > > Application layer > > > - TimeoutException / NoReplyException > > > - InvalidURIException / InvalidTransportException (alternative transports API) > > > - RejectedException (not sure if the same as ConnectionRefusedException) > > > > > > It would be great, if you could have a look, suggest more > > > exceptions/signals/error codes, propose thinning/merging, or just > comment on > > > the direction. > > > > > > Ciao > > > Matthias > > > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > > > This body part will be downloaded on demand. --------------030500010404040502000901 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Would such signals also include sanity checks on CoAP requests that are asked by the application? In some implementations the API itself can be designed to prevent constructing invalid CoAP requests. But in our implementation, the interface between the application and the CoAP client (potentially running in a separate process on another machine) is a socket and all the data about the request and the response (or error/warning) is also transferred over this socket. Applications describe their request via CSV strings, and the response is received as a CSV string. This will sometimes lead to invalid requests if the application is oblivious.

Our implementation includes sanity checks for some of the MUST (NOT)s in the CoAP spec:
*聽 A Non-confirmable message always carries either a request or response and MUST NOT be Empty -> Non messages must not be empty
* If a Method or Response Code is not defined to have a payload, then a sender MUST NOT include one, and a recipient MUST ignore it. -> GET requests must not include a payload.

Of course one could argue that in our case the logic generating the CSV strings is actually part of the CoAP client library and not the application itself, and that such signals should not be propagated to the application and rather that the logic (i.e API) generating the CSV strings should prevent applications from constructing empty non-messages, GET requests without a payload, etc.

BR,
Floris

On 11-08-15 19:31, Robert Cragie wrote:
I started to put together a strawman document on this topic and would appreciate any comments.


Robert

On 11 August 2015 at 13:19, Kovatsch Matthias <kovatsch@inf.ethz.ch> wrote:

Yes, the application also needs to be informed of failures that are unrelated to CoAP such as failures at lower layers or the operating system (I wouldn鈥檛 call it 鈥淎bort,鈥 though, but an exception or error).

聽

How many 鈥渁rrows鈥 you have in the API between Req/Res Layer and Application Layer depends on your implementation. Note that they are equivalent:

聽

-聽聽聽聽聽聽聽聽聽 Downward

o聽聽 1 down: attach all lower-layer-specific information to the request call (useful if the requirements change for each request)

o聽聽 2 down: have separate calls to configure the lower layers (e.g., choose the network operator for the cellular modem or relax the requirement for all requests to NON)

-聽聽聽聽聽聽聽聽聽 Upward

o聽聽 1 up: use a wrapper response struct/object that has either a CoAP response or an exception/error

o聽聽 2 up: split responses (return value or onSuccess(Response) handler) and exceptions (e.g., catch blocks or in an onError(Exception) handler).

聽

The question for here is whether we can identify a common set of Exceptions that is agnostic of specific lower layers.

聽

Regards

Matthias

聽

聽

From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: Freitag, 7. August 2015 18:27


To: Kovatsch Matthias <kovatsch@inf.ethz.ch>; core WG <core@ietf.org>
Subject: RE: [core] Common request/response API

聽

Matthias,

聽

So are you suggesting then that the API between the End Application and the Request Response Layer be:

聽

聽聽 聽聽REQ聽聽聽 /\聽聽聽聽 /\聽 聽聽聽聽Application Layer (LWM2M,IPSO)

聽聽 聽聽聽|聽聽聽聽聽 |聽聽聽聽聽 |

------|------|------|------

聽聽 聽聽聽|聽聽聽聽聽 |

聽 聽聽聽\/聽聽聽 聽RESP聽 Abort聽聽聽 REQ/RESP Layer

聽

I just wanted to be clear that this is an additional type of interaction.

聽

BR,

Tim

聽

From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, August 07, 2015 10:12 AM
To: Carey, Timothy (Timothy); core WG
Subject: RE: [core] Common request/response API

聽

No, response codes reflect success in this context (even 4.xx and 5.xx), since the request could be delivered and a response was received. Exceptions are for the things that could go wrong during transmission/reception.

聽

聽

From: Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com]
Sent: Friday, 7 August 2015 16:31
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>; core WG <core@ietf.org>
Subject: RE: [core] Common request/response API

聽

Matthias,

聽

Then the exceptions you have listed should be reflected in Resp Codes?

聽

BR,

Tim

聽

From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]
Sent: Friday, August 07, 2015 8:18 AM
To: Carey, Timothy (Timothy); core WG
Subject: RE: [core] Common request/response API

聽

Hi Tim

聽

> In your view the Application Layer that would receive these indications is the

> Request/Response Layer which then you return the appropriate Error code?

聽

No, the Request/Response Layer is part of CoAP and defines the methods, response codes, options, etc. The user application uses an API (鈥淩eq/Res Layer API鈥) to issue requests and receive responses and will receive these error codes. The codes need to be transport-agnostic. The transport itself can be chosen through the scheme used in the URI passed to the Req/Res API. In Californium, I will probably add additional API calls that only have effect on some transports (e.g., CON/NON). The user application can call them depending on what scheme/transport it chose. I tried to depict it:

聽

+---------------------------------------------------+

|聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽 |

| 聽聽聽聽聽聽聽Application (custom / LWM2M / IPSO)聽聽聽聽聽聽聽 |

|聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽 |

+---------------[ Req/Res Layer API ]---------------+ <--

| 聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽|

| 聽聽聽聽聽聽聽聽Request/Response Layer (CoAP spec) 聽聽聽聽聽聽聽|

| 聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽|

+---------------------------------------------------+

| Message Layer (CoAP spec / alternative transport) |

+---------------------------------------------------+

|聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽 聽聽Transport Layer (UDP / DTLS / TCP / TLS / SMS)聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽 |

聽

Ciao

Matthias

聽

> -----Original Message-----

> From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]

> Sent: Thursday, August 06, 2015 9:47 AM

> To: core WG

> Subject: [core] Common request/response API

>

> Dear list

>

> In Prague, the problem of a common request/response API for all possible

> transports was raised. We now have something similar in the Californium

> project, where we want to improve the error handling for the CoapClient API as

> well as improve the information flow between Scandium (DTLS) and Californium

> (or rather the application code).

>

> As a start, I collected possible exceptions that could signal what went wrong.

> While this might be a bit Java-centric, the intent is universal: have a common set

> of signals to tell the application above the request/response API what went

> wrong.

>

> Network layer

> - DestinationNotReachableException

> - PacketTooBigException

>

> Transport layer

> - ConnectionRefusedException

> - AuthenticationException

> - TooManyOpenFilesException / InsufficientResourcesException (more OS-

> related, but happens at the socket level)

>

> Application layer

> - TimeoutException / NoReplyException

> - InvalidURIException / InvalidTransportException (alternative transports API)

> - RejectedException (not sure if the same as ConnectionRefusedException)

>

> It would be great, if you could have a look, suggest more

> exceptions/signals/error codes, propose thinning/merging, or just comment on

> the direction.

>

> Ciao

> Matthias

>

聽


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




This body part will be downloaded on demand.
--------------030500010404040502000901-- From nobody Wed Aug 12 13:31:27 2015 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 993D61ACD8E for ; Wed, 12 Aug 2015 13:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 3yFW9SyQMt3Q for ; Wed, 12 Aug 2015 13:31:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02DD61ACD81 for ; Wed, 12 Aug 2015 13:31:17 -0700 (PDT) Received: from [192.168.131.134] ([80.92.114.40]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MHoWj-1ZOEZN1Eir-003e17; Wed, 12 Aug 2015 22:31:16 +0200 Message-ID: <55CBACAD.9090401@gmx.net> Date: Wed, 12 Aug 2015 22:29:33 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Simon Lemay , "core@ietf.org WG" References: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> In-Reply-To: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="E2xoXcTuhfkGH6A2UAmQJwcfCJgSsLTcC" X-Provags-ID: V03:K0:umiVI7QOOfQAP6X9UCE2bTpc1+szGTraiYGtrNFmgh0dEUAa8Ht Z41Caf9IdNE7v+v5zRBgGlZfs7w8zGX1dtdDAEgSEMmV79Wm3ZE+wp/VnT3Tt/FZsBHJj/d UZZEy1jmsk8EDjRPEB0pykhcP9iCu0BA5+v4Q8YjRWXbKYT1P0gJA0VZM9UODsAPGlR+hll oUOfLU6rXJtoUvsa2z3cg== X-UI-Out-Filterresults: notjunk:1;V01:K0:AQUQ9RE/N6M=:FGbF2J889YYre7IS8E/V3m Z/dK6oPn6mgEj+OX0qDrt2+PEIK5d2FVCqsUvNlYFY5YVPlgRGmJwHlrcEo7vSjGACVp39pzF NtBSc7telU6ndgeC2jMbuQ0099MrtA8JVPpqHCNrC98SDy4/irfniteGViGpnlAuPCQI0nH45 Tocrfm/9G2tLQcuYJXg/fYFIe2vEYfWwOqW8han6SnZB5eaDjVV3a+ACrO2heAxxTD90/3h68 mYTEfqg0+aovIXSoOHJ67kONBBbSjNm4WdO0MHRC7zD9YkcAVZt+Mg2qvqHgYEu0vldq+PgO+ OEoPrZD73/xmGdhGY7swpNpjMdqA4XbX9mBTmiMLjLlA81EYhTYjo47AzltVa76PoFyrTP4tT pEKEwxbxF9Ga3RyskGC8TtazKW0wssbNJMzNStVx+bfoXgVcmCfgi1cMfLWzBhfuWK+GQ0uUs 7pzFLSdhJsFdlX0BqHHA7bBqRv/+H1Z8wk7+KCPrRHr0XyMi9eI8Iq9IG+imuCToGGr0oe/9c YuEXbsn5V7G0TP1Pmka3nyYSg4xkA8DoDWdmXF0opjklSI3umn8G2CxD01Ug3jia2fS1fkrlZ qU4fUdPa9sNex7+w5jfQ6h6D1UqSo55BPV5evqht2Grz+IdVU3bUJM8ZHfGAtdzyrOb1oRkxf IjC0S5PVOI6eHTOQN37h2LcPy6ANs4nBtegPzMC+Js+3Fypa2BibXKcCnynrPoB9qKI0gMlLU cZeISLQpwCqaj09v Archived-At: Subject: Re: [core] Lenght shim 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 Aug 2015 20:31:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --E2xoXcTuhfkGH6A2UAmQJwcfCJgSsLTcC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Simon, I discussed this with my co-workers and we prefer option A. We like it because of the simpler nature because option B really changes the semantic of the CoAP header. Ciao Hannes On 07/27/2015 04:47 PM, Simon Lemay wrote: > Hi, >=20 > So after the meeting on Friday, a few of up stayed to talk about the di= fferent alternatives on how to represent the length information in CoAP o= ver TCP (reliable transport) >=20 > 2 option came out of the meeting. >=20 > =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97- > Option A > 2 byte shim with new Blocking option for bigger application layer fragm= entation >=20 > This would consists of 2 bytes (16 bits) giving a max length of 64kb. = we would also add a new size option in the block size for FFFF (minus the= header). >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length Shim |Ver| T | TKL | Code | Token (TKL > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | bytes) ... | Options (if any) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1 1 1 1 1 1 1 1| Payload (if any) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > The new blocksize needs to be a clean fraction of the 1024byte block. = This is needed for proxying blocksize across different transport layer. >=20 > Pros: > -easy to manage > -can be remove is faming is not needed > -application layer fragmentation helps with multiplexing request >=20 >=20 >=20 > Cons > -Does not support larger than 16 bits. > -could not do streaming >=20 >=20 > =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97- > Option B > Option like split length with a no length option for reliable transport= that already have a framing >=20 > The initial byte of the frame contains two nibbles, in a similar way t= o the CoAP option encoding (Section 3.1 of [RFC7252]). The first nibble i= s used to indicate the length of the options (including any option delimi= ter), and the payload (if any); it does not include the Code byte or the = Token bytes. The first nibble is interpreted as a 4-bit unsigned integer.= A value between 0 and 12 directly indicates the length of the options/pa= yload, in bytes. The other three values have a special meaning: 13: An 8-= bit unsigned integer follows the initial byte and indicates the length of= options/payload minus 13. 14: A 16-bit unsigned integer in network byte = order follows the initial byte and indicates the length of options/payloa= d minus 269. 15: A 32-bit unsigned integer in network byte order follows = the initial byte and indicates the length of options/payload minus 65805.= 16: no framing. The second nibble of the initial byte indicates the tok= en length. Example: 01 43 7f is a frame just conta ining a 2.03 code with the token 7f. >=20 >=20 >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Len | TKL | Len+ bytes... | Code | TKL bytes ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Options (if any) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1 1 1 1 1 1 1 1| Payload (if any) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > Pros: > -supports larger payload > -flexible (dynamic payload size) > -removed the Message Type field >=20 >=20 > Cons: > -Large message might be difficult to parse or flush for more constraint= node. > -cannot be removed if underlining implementation does not need framing >=20 > Let me know what you guys think, any pro or cons missing and what we sh= ould process to >=20 > Cheers >=20 > Simon >=20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --E2xoXcTuhfkGH6A2UAmQJwcfCJgSsLTcC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVy6ytAAoJEGhJURNOOiAtRS4H+wcG6g7qjePCuk10vixhjgd/ J7vmXz5hFVW5lRGv2xEYWPGmy74rgxP6Bre1vvr4dUIol305btAknyiAHyQ9CzYA duisXg/6nj9twsf29Dm3+h26ADSEGxI3uir8TBY48OrPMZBga7fKsgQOw/QzgrfM X5BhALR12T9EtalMiuYItfyRyhfiZYnTUruPQEl3yAkKp8rtbMWSJZjm5Jr9C728 F+qnKbV2A6pcTcvAEGa2LP6y/rIVzK2aOqQsbajLFdeshknChDwHiIhizncx5MAR PYd5rNsgX4w4Vl17Hsqd7KliLE+WZuJOzMu8ym9KNCRTZAWouikyVGZb0zVflQ4= =t3gH -----END PGP SIGNATURE----- --E2xoXcTuhfkGH6A2UAmQJwcfCJgSsLTcC-- From nobody Wed Aug 12 17:36:49 2015 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 1BF271B2E78 for ; Wed, 12 Aug 2015 17:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 plb78wKjpb7B for ; Wed, 12 Aug 2015 17:36:43 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657801B2E77 for ; Wed, 12 Aug 2015 17:36:42 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 987B2E34BF4D3; Thu, 13 Aug 2015 00:36:36 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t7D0ab09024249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Aug 2015 00:36:37 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Wed, 12 Aug 2015 20:36:36 -0400 From: "Carey, Timothy (Timothy)" To: Floris Van den Abeele , "robert.cragie@gridmerge.com" Thread-Topic: [core] Common request/response API Thread-Index: AQHQ0HpEydKVqprn8kKMXYdIv3GcLQAF2igAACjsw5D///fSAP//1AKwgABMegD/+d9z0J4L6yAAACgS4wAABbnR4A== Date: Thu, 13 Aug 2015 00:36:36 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC2354D1@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <55877B3AFB359744BA0F2140E36F52B54C813E91@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22E65A@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C814F8D@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22EFEA@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C815218@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22F1C6@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C821E7A@MBX110.d.ethz.ch> <55CB3E46.7060503@intec.ugent.be> In-Reply-To: <55CB3E46.7060503@intec.ugent.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC2354D1US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Cc: core WG Subject: Re: [core] Common request/response API 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, 13 Aug 2015 00:36:47 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC2354D1US70UWXCHMBA05z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQpZZXMgSSB0aGluayB0aGlzIG1pZ2h0IHdvcmsuIEEgZ2VuZXJpYyBzZXQgb2Yg cHJpbWl0aXZlcyB3aXRoIHVuaXF1ZSBtZWFuaW5nIGF0IHRoZSBzcGVjaWZpYyBsYXllciBpbnRl cmFjdGlvbi4NCg0KQ291bGQgdGhpcyB0ZWNobmlxdWUgYWxzbyBiZSBleHRlbmRlZCBiZXR3ZWVu IHRoZSBNTCBhbmQgVHJhbnNwb3J0IExheWVycz8NCg0KQlIsDQpUaW0NCg0KRnJvbTogRmxvcmlz IFZhbiBkZW4gQWJlZWxlIFttYWlsdG86ZmxvcmlzLnZhbmRlbmFiZWVsZUBpbnRlYy51Z2VudC5i ZV0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDEyLCAyMDE1IDc6MzkgQU0NClRvOiByb2JlcnQu Y3JhZ2llQGdyaWRtZXJnZS5jb20NCkNjOiBDYXJleSwgVGltb3RoeSAoVGltb3RoeSk7IGNvcmUg V0c7IEtvdmF0c2NoIE1hdHRoaWFzDQpTdWJqZWN0OiBSZTogW2NvcmVdIENvbW1vbiByZXF1ZXN0 L3Jlc3BvbnNlIEFQSQ0KDQpXb3VsZCBzdWNoIHNpZ25hbHMgYWxzbyBpbmNsdWRlIHNhbml0eSBj aGVja3Mgb24gQ29BUCByZXF1ZXN0cyB0aGF0IGFyZSBhc2tlZCBieSB0aGUgYXBwbGljYXRpb24/ IEluIHNvbWUgaW1wbGVtZW50YXRpb25zIHRoZSBBUEkgaXRzZWxmIGNhbiBiZSBkZXNpZ25lZCB0 byBwcmV2ZW50IGNvbnN0cnVjdGluZyBpbnZhbGlkIENvQVAgcmVxdWVzdHMuIEJ1dCBpbiBvdXIg aW1wbGVtZW50YXRpb24sIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgYXBwbGljYXRpb24gYW5k IHRoZSBDb0FQIGNsaWVudCAocG90ZW50aWFsbHkgcnVubmluZyBpbiBhIHNlcGFyYXRlIHByb2Nl c3Mgb24gYW5vdGhlciBtYWNoaW5lKSBpcyBhIHNvY2tldCBhbmQgYWxsIHRoZSBkYXRhIGFib3V0 IHRoZSByZXF1ZXN0IGFuZCB0aGUgcmVzcG9uc2UgKG9yIGVycm9yL3dhcm5pbmcpIGlzIGFsc28g dHJhbnNmZXJyZWQgb3ZlciB0aGlzIHNvY2tldC4gQXBwbGljYXRpb25zIGRlc2NyaWJlIHRoZWly IHJlcXVlc3QgdmlhIENTViBzdHJpbmdzLCBhbmQgdGhlIHJlc3BvbnNlIGlzIHJlY2VpdmVkIGFz IGEgQ1NWIHN0cmluZy4gVGhpcyB3aWxsIHNvbWV0aW1lcyBsZWFkIHRvIGludmFsaWQgcmVxdWVz dHMgaWYgdGhlIGFwcGxpY2F0aW9uIGlzIG9ibGl2aW91cy4NCg0KT3VyIGltcGxlbWVudGF0aW9u IGluY2x1ZGVzIHNhbml0eSBjaGVja3MgZm9yIHNvbWUgb2YgdGhlIE1VU1QgKE5PVClzIGluIHRo ZSBDb0FQIHNwZWM6DQoqICBBIE5vbi1jb25maXJtYWJsZSBtZXNzYWdlIGFsd2F5cyBjYXJyaWVz IGVpdGhlciBhIHJlcXVlc3Qgb3IgcmVzcG9uc2UgYW5kIE1VU1QgTk9UIGJlIEVtcHR5IC0+IE5v biBtZXNzYWdlcyBtdXN0IG5vdCBiZSBlbXB0eQ0KKiBJZiBhIE1ldGhvZCBvciBSZXNwb25zZSBD b2RlIGlzIG5vdCBkZWZpbmVkIHRvIGhhdmUgYSBwYXlsb2FkLCB0aGVuIGEgc2VuZGVyIE1VU1Qg Tk9UIGluY2x1ZGUgb25lLCBhbmQgYSByZWNpcGllbnQgTVVTVCBpZ25vcmUgaXQuIC0+IEdFVCBy ZXF1ZXN0cyBtdXN0IG5vdCBpbmNsdWRlIGEgcGF5bG9hZC4NCg0KT2YgY291cnNlIG9uZSBjb3Vs ZCBhcmd1ZSB0aGF0IGluIG91ciBjYXNlIHRoZSBsb2dpYyBnZW5lcmF0aW5nIHRoZSBDU1Ygc3Ry aW5ncyBpcyBhY3R1YWxseSBwYXJ0IG9mIHRoZSBDb0FQIGNsaWVudCBsaWJyYXJ5IGFuZCBub3Qg dGhlIGFwcGxpY2F0aW9uIGl0c2VsZiwgYW5kIHRoYXQgc3VjaCBzaWduYWxzIHNob3VsZCBub3Qg YmUgcHJvcGFnYXRlZCB0byB0aGUgYXBwbGljYXRpb24gYW5kIHJhdGhlciB0aGF0IHRoZSBsb2dp YyAoaS5lIEFQSSkgZ2VuZXJhdGluZyB0aGUgQ1NWIHN0cmluZ3Mgc2hvdWxkIHByZXZlbnQgYXBw bGljYXRpb25zIGZyb20gY29uc3RydWN0aW5nIGVtcHR5IG5vbi1tZXNzYWdlcywgR0VUIHJlcXVl c3RzIHdpdGhvdXQgYSBwYXlsb2FkLCBldGMuDQoNCkJSLA0KRmxvcmlzDQpPbiAxMS0wOC0xNSAx OTozMSwgUm9iZXJ0IENyYWdpZSB3cm90ZToNCkkgc3RhcnRlZCB0byBwdXQgdG9nZXRoZXIgYSBz dHJhd21hbiBkb2N1bWVudCBvbiB0aGlzIHRvcGljIGFuZCB3b3VsZCBhcHByZWNpYXRlIGFueSBj b21tZW50cy4NCg0KaHR0cHM6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1lbnQvZC8xYThCQ1ZyS2NH SDBRbUtEY1YxNlNhSnVEMmFpXzN2LWRzM1g3d2ZfMzJKRS9lZGl0P3VzcD1zaGFyaW5nDQoNClJv YmVydA0KDQpPbiAxMSBBdWd1c3QgMjAxNSBhdCAxMzoxOSwgS292YXRzY2ggTWF0dGhpYXMgPGtv dmF0c2NoQGluZi5ldGh6LmNoPG1haWx0bzprb3ZhdHNjaEBpbmYuZXRoei5jaD4+IHdyb3RlOg0K WWVzLCB0aGUgYXBwbGljYXRpb24gYWxzbyBuZWVkcyB0byBiZSBpbmZvcm1lZCBvZiBmYWlsdXJl cyB0aGF0IGFyZSB1bnJlbGF0ZWQgdG8gQ29BUCBzdWNoIGFzIGZhaWx1cmVzIGF0IGxvd2VyIGxh eWVycyBvciB0aGUgb3BlcmF0aW5nIHN5c3RlbSAoSSB3b3VsZG7igJl0IGNhbGwgaXQg4oCcQWJv cnQs4oCdIHRob3VnaCwgYnV0IGFuIGV4Y2VwdGlvbiBvciBlcnJvcikuDQoNCkhvdyBtYW55IOKA nGFycm93c+KAnSB5b3UgaGF2ZSBpbiB0aGUgQVBJIGJldHdlZW4gUmVxL1JlcyBMYXllciBhbmQg QXBwbGljYXRpb24gTGF5ZXIgZGVwZW5kcyBvbiB5b3VyIGltcGxlbWVudGF0aW9uLiBOb3RlIHRo YXQgdGhleSBhcmUgZXF1aXZhbGVudDoNCg0KDQotICAgICAgICAgIERvd253YXJkDQoNCm8gICAx IGRvd246IGF0dGFjaCBhbGwgbG93ZXItbGF5ZXItc3BlY2lmaWMgaW5mb3JtYXRpb24gdG8gdGhl IHJlcXVlc3QgY2FsbCAodXNlZnVsIGlmIHRoZSByZXF1aXJlbWVudHMgY2hhbmdlIGZvciBlYWNo IHJlcXVlc3QpDQoNCm8gICAyIGRvd246IGhhdmUgc2VwYXJhdGUgY2FsbHMgdG8gY29uZmlndXJl IHRoZSBsb3dlciBsYXllcnMgKGUuZy4sIGNob29zZSB0aGUgbmV0d29yayBvcGVyYXRvciBmb3Ig dGhlIGNlbGx1bGFyIG1vZGVtIG9yIHJlbGF4IHRoZSByZXF1aXJlbWVudCBmb3IgYWxsIHJlcXVl c3RzIHRvIE5PTikNCg0KLSAgICAgICAgICBVcHdhcmQNCg0KbyAgIDEgdXA6IHVzZSBhIHdyYXBw ZXIgcmVzcG9uc2Ugc3RydWN0L29iamVjdCB0aGF0IGhhcyBlaXRoZXIgYSBDb0FQIHJlc3BvbnNl IG9yIGFuIGV4Y2VwdGlvbi9lcnJvcg0KDQpvICAgMiB1cDogc3BsaXQgcmVzcG9uc2VzIChyZXR1 cm4gdmFsdWUgb3Igb25TdWNjZXNzKFJlc3BvbnNlKSBoYW5kbGVyKSBhbmQgZXhjZXB0aW9ucyAo ZS5nLiwgY2F0Y2ggYmxvY2tzIG9yIGluIGFuIG9uRXJyb3IoRXhjZXB0aW9uKSBoYW5kbGVyKS4N Cg0KVGhlIHF1ZXN0aW9uIGZvciBoZXJlIGlzIHdoZXRoZXIgd2UgY2FuIGlkZW50aWZ5IGEgY29t bW9uIHNldCBvZiBFeGNlcHRpb25zIHRoYXQgaXMgYWdub3N0aWMgb2Ygc3BlY2lmaWMgbG93ZXIg bGF5ZXJzLg0KDQpSZWdhcmRzDQpNYXR0aGlhcw0KDQoNCkZyb206IENhcmV5LCBUaW1vdGh5IChU aW1vdGh5KSBbbWFpbHRvOnRpbW90aHkuY2FyZXlAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzp0 aW1vdGh5LmNhcmV5QGFsY2F0ZWwtbHVjZW50LmNvbT5dDQpTZW50OiBGcmVpdGFnLCA3LiBBdWd1 c3QgMjAxNSAxODoyNw0KDQpUbzogS292YXRzY2ggTWF0dGhpYXMgPGtvdmF0c2NoQGluZi5ldGh6 LmNoPG1haWx0bzprb3ZhdHNjaEBpbmYuZXRoei5jaD4+OyBjb3JlIFdHIDxjb3JlQGlldGYub3Jn PG1haWx0bzpjb3JlQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbY29yZV0gQ29tbW9uIHJlcXVl c3QvcmVzcG9uc2UgQVBJDQoNCk1hdHRoaWFzLA0KDQpTbyBhcmUgeW91IHN1Z2dlc3RpbmcgdGhl biB0aGF0IHRoZSBBUEkgYmV0d2VlbiB0aGUgRW5kIEFwcGxpY2F0aW9uIGFuZCB0aGUgUmVxdWVz dCBSZXNwb25zZSBMYXllciBiZToNCg0KICAgICBSRVEgICAgL1wgICAgIC9cICAgICAgQXBwbGlj YXRpb24gTGF5ZXIgKExXTTJNLElQU08pDQogICAgICB8ICAgICAgfCAgICAgIHwNCi0tLS0tLXwt LS0tLS18LS0tLS0tfC0tLS0tLQ0KICAgICAgfCAgICAgIHwNCiAgICAgXC8gICAgIFJFU1AgIEFi b3J0ICAgIFJFUS9SRVNQIExheWVyDQoNCkkganVzdCB3YW50ZWQgdG8gYmUgY2xlYXIgdGhhdCB0 aGlzIGlzIGFuIGFkZGl0aW9uYWwgdHlwZSBvZiBpbnRlcmFjdGlvbi4NCg0KQlIsDQpUaW0NCg0K RnJvbTogS292YXRzY2ggTWF0dGhpYXMgW21haWx0bzprb3ZhdHNjaEBpbmYuZXRoei5jaF0NClNl bnQ6IEZyaWRheSwgQXVndXN0IDA3LCAyMDE1IDEwOjEyIEFNDQpUbzogQ2FyZXksIFRpbW90aHkg KFRpbW90aHkpOyBjb3JlIFdHDQpTdWJqZWN0OiBSRTogW2NvcmVdIENvbW1vbiByZXF1ZXN0L3Jl c3BvbnNlIEFQSQ0KDQpObywgcmVzcG9uc2UgY29kZXMgcmVmbGVjdCBzdWNjZXNzIGluIHRoaXMg Y29udGV4dCAoZXZlbiA0Lnh4IGFuZCA1Lnh4KSwgc2luY2UgdGhlIHJlcXVlc3QgY291bGQgYmUg ZGVsaXZlcmVkIGFuZCBhIHJlc3BvbnNlIHdhcyByZWNlaXZlZC4gRXhjZXB0aW9ucyBhcmUgZm9y IHRoZSB0aGluZ3MgdGhhdCBjb3VsZCBnbyB3cm9uZyBkdXJpbmcgdHJhbnNtaXNzaW9uL3JlY2Vw dGlvbi4NCg0KDQpGcm9tOiBDYXJleSwgVGltb3RoeSAoVGltb3RoeSkgW21haWx0bzp0aW1vdGh5 LmNhcmV5QGFsY2F0ZWwtbHVjZW50LmNvbV0NClNlbnQ6IEZyaWRheSwgNyBBdWd1c3QgMjAxNSAx NjozMQ0KVG86IEtvdmF0c2NoIE1hdHRoaWFzIDxrb3ZhdHNjaEBpbmYuZXRoei5jaDxtYWlsdG86 a292YXRzY2hAaW5mLmV0aHouY2g+PjsgY29yZSBXRyA8Y29yZUBpZXRmLm9yZzxtYWlsdG86Y29y ZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW2NvcmVdIENvbW1vbiByZXF1ZXN0L3Jlc3BvbnNl IEFQSQ0KDQpNYXR0aGlhcywNCg0KVGhlbiB0aGUgZXhjZXB0aW9ucyB5b3UgaGF2ZSBsaXN0ZWQg c2hvdWxkIGJlIHJlZmxlY3RlZCBpbiBSZXNwIENvZGVzPw0KDQpCUiwNClRpbQ0KDQpGcm9tOiBL b3ZhdHNjaCBNYXR0aGlhcyBbbWFpbHRvOmtvdmF0c2NoQGluZi5ldGh6LmNoXQ0KU2VudDogRnJp ZGF5LCBBdWd1c3QgMDcsIDIwMTUgODoxOCBBTQ0KVG86IENhcmV5LCBUaW1vdGh5IChUaW1vdGh5 KTsgY29yZSBXRw0KU3ViamVjdDogUkU6IFtjb3JlXSBDb21tb24gcmVxdWVzdC9yZXNwb25zZSBB UEkNCg0KDQpIaSBUaW0NCg0KDQoNCj4gSW4geW91ciB2aWV3IHRoZSBBcHBsaWNhdGlvbiBMYXll ciB0aGF0IHdvdWxkIHJlY2VpdmUgdGhlc2UgaW5kaWNhdGlvbnMgaXMgdGhlDQoNCj4gUmVxdWVz dC9SZXNwb25zZSBMYXllciB3aGljaCB0aGVuIHlvdSByZXR1cm4gdGhlIGFwcHJvcHJpYXRlIEVy cm9yIGNvZGU/DQoNCg0KDQpObywgdGhlIFJlcXVlc3QvUmVzcG9uc2UgTGF5ZXIgaXMgcGFydCBv ZiBDb0FQIGFuZCBkZWZpbmVzIHRoZSBtZXRob2RzLCByZXNwb25zZSBjb2Rlcywgb3B0aW9ucywg ZXRjLiBUaGUgdXNlciBhcHBsaWNhdGlvbiB1c2VzIGFuIEFQSSAo4oCcUmVxL1JlcyBMYXllciBB UEnigJ0pIHRvIGlzc3VlIHJlcXVlc3RzIGFuZCByZWNlaXZlIHJlc3BvbnNlcyBhbmQgd2lsbCBy ZWNlaXZlIHRoZXNlIGVycm9yIGNvZGVzLiBUaGUgY29kZXMgbmVlZCB0byBiZSB0cmFuc3BvcnQt YWdub3N0aWMuIFRoZSB0cmFuc3BvcnQgaXRzZWxmIGNhbiBiZSBjaG9zZW4gdGhyb3VnaCB0aGUg c2NoZW1lIHVzZWQgaW4gdGhlIFVSSSBwYXNzZWQgdG8gdGhlIFJlcS9SZXMgQVBJLiBJbiBDYWxp Zm9ybml1bSwgSSB3aWxsIHByb2JhYmx5IGFkZCBhZGRpdGlvbmFsIEFQSSBjYWxscyB0aGF0IG9u bHkgaGF2ZSBlZmZlY3Qgb24gc29tZSB0cmFuc3BvcnRzIChlLmcuLCBDT04vTk9OKS4gVGhlIHVz ZXIgYXBwbGljYXRpb24gY2FuIGNhbGwgdGhlbSBkZXBlbmRpbmcgb24gd2hhdCBzY2hlbWUvdHJh bnNwb3J0IGl0IGNob3NlLiBJIHRyaWVkIHRvIGRlcGljdCBpdDoNCg0KDQoNCistLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCnwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQoNCnwgICAgICAgIEFw cGxpY2F0aW9uIChjdXN0b20gLyBMV00yTSAvIElQU08pICAgICAgICB8DQoNCnwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQoNCistLS0tLS0tLS0t LS0tLS1bIFJlcS9SZXMgTGF5ZXIgQVBJIF0tLS0tLS0tLS0tLS0tLS0rIDwtLQ0KDQp8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQp8ICAgICAg ICAgUmVxdWVzdC9SZXNwb25zZSBMYXllciAoQ29BUCBzcGVjKSAgICAgICAgfA0KDQp8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQorLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQp8IE1lc3Nh Z2UgTGF5ZXIgKENvQVAgc3BlYyAvIGFsdGVybmF0aXZlIHRyYW5zcG9ydCkgfA0KDQorLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQp8ICAgICAg ICAgICAgICAgICAgICAgICAgIFRyYW5zcG9ydCBMYXllciAoVURQIC8gRFRMUyAvIFRDUCAvIFRM UyAvIFNNUykgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQoNCg0KQ2lhbw0KDQpN YXR0aGlhcw0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQo+IEZyb206IEtv dmF0c2NoIE1hdHRoaWFzIFttYWlsdG86a292YXRzY2hAaW5mLmV0aHouY2hdDQoNCj4gU2VudDog VGh1cnNkYXksIEF1Z3VzdCAwNiwgMjAxNSA5OjQ3IEFNDQoNCj4gVG86IGNvcmUgV0cNCg0KPiBT dWJqZWN0OiBbY29yZV0gQ29tbW9uIHJlcXVlc3QvcmVzcG9uc2UgQVBJDQoNCj4NCg0KPiBEZWFy IGxpc3QNCg0KPg0KDQo+IEluIFByYWd1ZSwgdGhlIHByb2JsZW0gb2YgYSBjb21tb24gcmVxdWVz dC9yZXNwb25zZSBBUEkgZm9yIGFsbCBwb3NzaWJsZQ0KDQo+IHRyYW5zcG9ydHMgd2FzIHJhaXNl ZC4gV2Ugbm93IGhhdmUgc29tZXRoaW5nIHNpbWlsYXIgaW4gdGhlIENhbGlmb3JuaXVtDQoNCj4g cHJvamVjdCwgd2hlcmUgd2Ugd2FudCB0byBpbXByb3ZlIHRoZSBlcnJvciBoYW5kbGluZyBmb3Ig dGhlIENvYXBDbGllbnQgQVBJIGFzDQoNCj4gd2VsbCBhcyBpbXByb3ZlIHRoZSBpbmZvcm1hdGlv biBmbG93IGJldHdlZW4gU2NhbmRpdW0gKERUTFMpIGFuZCBDYWxpZm9ybml1bQ0KDQo+IChvciBy YXRoZXIgdGhlIGFwcGxpY2F0aW9uIGNvZGUpLg0KDQo+DQoNCj4gQXMgYSBzdGFydCwgSSBjb2xs ZWN0ZWQgcG9zc2libGUgZXhjZXB0aW9ucyB0aGF0IGNvdWxkIHNpZ25hbCB3aGF0IHdlbnQgd3Jv bmcuDQoNCj4gV2hpbGUgdGhpcyBtaWdodCBiZSBhIGJpdCBKYXZhLWNlbnRyaWMsIHRoZSBpbnRl bnQgaXMgdW5pdmVyc2FsOiBoYXZlIGEgY29tbW9uIHNldA0KDQo+IG9mIHNpZ25hbHMgdG8gdGVs bCB0aGUgYXBwbGljYXRpb24gYWJvdmUgdGhlIHJlcXVlc3QvcmVzcG9uc2UgQVBJIHdoYXQgd2Vu dA0KDQo+IHdyb25nLg0KDQo+DQoNCj4gTmV0d29yayBsYXllcg0KDQo+IC0gRGVzdGluYXRpb25O b3RSZWFjaGFibGVFeGNlcHRpb24NCg0KPiAtIFBhY2tldFRvb0JpZ0V4Y2VwdGlvbg0KDQo+DQoN Cj4gVHJhbnNwb3J0IGxheWVyDQoNCj4gLSBDb25uZWN0aW9uUmVmdXNlZEV4Y2VwdGlvbg0KDQo+ IC0gQXV0aGVudGljYXRpb25FeGNlcHRpb24NCg0KPiAtIFRvb01hbnlPcGVuRmlsZXNFeGNlcHRp b24gLyBJbnN1ZmZpY2llbnRSZXNvdXJjZXNFeGNlcHRpb24gKG1vcmUgT1MtDQoNCj4gcmVsYXRl ZCwgYnV0IGhhcHBlbnMgYXQgdGhlIHNvY2tldCBsZXZlbCkNCg0KPg0KDQo+IEFwcGxpY2F0aW9u IGxheWVyDQoNCj4gLSBUaW1lb3V0RXhjZXB0aW9uIC8gTm9SZXBseUV4Y2VwdGlvbg0KDQo+IC0g SW52YWxpZFVSSUV4Y2VwdGlvbiAvIEludmFsaWRUcmFuc3BvcnRFeGNlcHRpb24gKGFsdGVybmF0 aXZlIHRyYW5zcG9ydHMgQVBJKQ0KDQo+IC0gUmVqZWN0ZWRFeGNlcHRpb24gKG5vdCBzdXJlIGlm IHRoZSBzYW1lIGFzIENvbm5lY3Rpb25SZWZ1c2VkRXhjZXB0aW9uKQ0KDQo+DQoNCj4gSXQgd291 bGQgYmUgZ3JlYXQsIGlmIHlvdSBjb3VsZCBoYXZlIGEgbG9vaywgc3VnZ2VzdCBtb3JlDQoNCj4g ZXhjZXB0aW9ucy9zaWduYWxzL2Vycm9yIGNvZGVzLCBwcm9wb3NlIHRoaW5uaW5nL21lcmdpbmcs IG9yIGp1c3QgY29tbWVudCBvbg0KDQo+IHRoZSBkaXJlY3Rpb24uDQoNCj4NCg0KPiBDaWFvDQoN Cj4gTWF0dGhpYXMNCg0KPg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnPG1haWx0bzpj b3JlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Jl DQoNCg0KDQoNCg0KVGhpcyBib2R5IHBhcnQgd2lsbCBiZSBkb3dubG9hZGVkIG9uIGRlbWFuZC4N Cg== --_000_9966516C6EB5FC4381E05BF80AA55F77DC2354D1US70UWXCHMBA05z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1T IjsNCglwYW5vc2UtMToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IFw7Y29sb3JcOlwjMWY0OTdkIjsNCglw YW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IFw7Y29sb3JcOmJsYWNrIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAg MCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K cHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWls eTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IlRyZWJ1Y2hldCBNUyIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlJvYmVydCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMgSSB0aGluayB0aGlzIG1pZ2h0IHdvcmsu IEEgZ2VuZXJpYyBzZXQgb2YgcHJpbWl0aXZlcyB3aXRoIHVuaXF1ZSBtZWFuaW5nIGF0IHRoZSBz cGVjaWZpYyBsYXllciBpbnRlcmFjdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQg TVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Db3VsZCB0aGlz IHRlY2huaXF1ZSBhbHNvIGJlIGV4dGVuZGVkIGJldHdlZW4gdGhlIE1MIGFuZCBUcmFuc3BvcnQg TGF5ZXJzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRpbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hl dCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRmxvcmlzIFZhbiBkZW4gQWJl ZWxlIFttYWlsdG86ZmxvcmlzLnZhbmRlbmFiZWVsZUBpbnRlYy51Z2VudC5iZV0NCjxicj4NCjxi PlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAxMiwgMjAxNSA3OjM5IEFNPGJyPg0KPGI+VG86 PC9iPiByb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb208YnI+DQo8Yj5DYzo8L2I+IENhcmV5LCBU aW1vdGh5IChUaW1vdGh5KTsgY29yZSBXRzsgS292YXRzY2ggTWF0dGhpYXM8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtjb3JlXSBDb21tb24gcmVxdWVzdC9yZXNwb25zZSBBUEk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPldvdWxkIHN1Y2ggc2lnbmFscyBhbHNvIGluY2x1ZGUgc2FuaXR5IGNoZWNrcyBv biBDb0FQIHJlcXVlc3RzIHRoYXQgYXJlIGFza2VkIGJ5IHRoZSBhcHBsaWNhdGlvbj8gSW4gc29t ZSBpbXBsZW1lbnRhdGlvbnMgdGhlIEFQSSBpdHNlbGYgY2FuIGJlIGRlc2lnbmVkIHRvIHByZXZl bnQgY29uc3RydWN0aW5nIGludmFsaWQgQ29BUCByZXF1ZXN0cy4gQnV0IGluDQogb3VyIGltcGxl bWVudGF0aW9uLCB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIGFwcGxpY2F0aW9uIGFuZCB0aGUg Q29BUCBjbGllbnQgKHBvdGVudGlhbGx5IHJ1bm5pbmcgaW4gYSBzZXBhcmF0ZSBwcm9jZXNzIG9u IGFub3RoZXIgbWFjaGluZSkgaXMgYSBzb2NrZXQgYW5kIGFsbCB0aGUgZGF0YSBhYm91dCB0aGUg cmVxdWVzdCBhbmQgdGhlIHJlc3BvbnNlIChvciBlcnJvci93YXJuaW5nKSBpcyBhbHNvIHRyYW5z ZmVycmVkIG92ZXIgdGhpcyBzb2NrZXQuDQogQXBwbGljYXRpb25zIGRlc2NyaWJlIHRoZWlyIHJl cXVlc3QgdmlhIENTViBzdHJpbmdzLCBhbmQgdGhlIHJlc3BvbnNlIGlzIHJlY2VpdmVkIGFzIGEg Q1NWIHN0cmluZy4gVGhpcyB3aWxsIHNvbWV0aW1lcyBsZWFkIHRvIGludmFsaWQgcmVxdWVzdHMg aWYgdGhlIGFwcGxpY2F0aW9uIGlzIG9ibGl2aW91cy4NCjxicj4NCjxicj4NCk91ciBpbXBsZW1l bnRhdGlvbiBpbmNsdWRlcyBzYW5pdHkgY2hlY2tzIGZvciBzb21lIG9mIHRoZSBNVVNUIChOT1Qp cyBpbiB0aGUgQ29BUCBzcGVjOjxicj4NCiombmJzcDsgQSBOb24tY29uZmlybWFibGUgbWVzc2Fn ZSBhbHdheXMgY2FycmllcyBlaXRoZXIgYSByZXF1ZXN0IG9yIHJlc3BvbnNlIGFuZCBNVVNUIE5P VCBiZSBFbXB0eSAtJmd0OyBOb24gbWVzc2FnZXMgbXVzdCBub3QgYmUgZW1wdHk8YnI+DQoqIElm IGEgTWV0aG9kIG9yIFJlc3BvbnNlIENvZGUgaXMgbm90IGRlZmluZWQgdG8gaGF2ZSBhIHBheWxv YWQsIHRoZW4gYSBzZW5kZXIgTVVTVCBOT1QgaW5jbHVkZSBvbmUsIGFuZCBhIHJlY2lwaWVudCBN VVNUIGlnbm9yZSBpdC4gLSZndDsgR0VUIHJlcXVlc3RzIG11c3Qgbm90IGluY2x1ZGUgYSBwYXls b2FkLjxicj4NCjxicj4NCk9mIGNvdXJzZSBvbmUgY291bGQgYXJndWUgdGhhdCBpbiBvdXIgY2Fz ZSB0aGUgbG9naWMgZ2VuZXJhdGluZyB0aGUgQ1NWIHN0cmluZ3MgaXMgYWN0dWFsbHkgcGFydCBv ZiB0aGUgQ29BUCBjbGllbnQgbGlicmFyeSBhbmQgbm90IHRoZSBhcHBsaWNhdGlvbiBpdHNlbGYs IGFuZCB0aGF0IHN1Y2ggc2lnbmFscyBzaG91bGQgbm90IGJlIHByb3BhZ2F0ZWQgdG8gdGhlIGFw cGxpY2F0aW9uIGFuZCByYXRoZXIgdGhhdCB0aGUgbG9naWMgKGkuZSBBUEkpDQogZ2VuZXJhdGlu ZyB0aGUgQ1NWIHN0cmluZ3Mgc2hvdWxkIHByZXZlbnQgYXBwbGljYXRpb25zIGZyb20gY29uc3Ry dWN0aW5nIGVtcHR5IG5vbi1tZXNzYWdlcywgR0VUIHJlcXVlc3RzIHdpdGhvdXQgYSBwYXlsb2Fk LCBldGMuPGJyPg0KPGJyPg0KQlIsPGJyPg0KRmxvcmlzPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTEtMDgtMTUgMTk6MzEsIFJvYmVydCBDcmFnaWUgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pkkgc3RhcnRlZCB0byBwdXQgdG9nZXRoZXIgYSBzdHJhd21hbiBkb2N1bWVudCBvbiB0aGlzIHRv cGljIGFuZCB3b3VsZCBhcHByZWNpYXRlIGFueSBjb21tZW50cy4NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kb2NzLmdvb2ds ZS5jb20vZG9jdW1lbnQvZC8xYThCQ1ZyS2NHSDBRbUtEY1YxNlNhSnVEMmFpXzN2LWRzM1g3d2Zf MzJKRS9lZGl0P3VzcD1zaGFyaW5nIj5odHRwczovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9k LzFhOEJDVnJLY0dIMFFtS0RjVjE2U2FKdUQyYWlfM3YtZHMzWDd3Zl8zMkpFL2VkaXQ/dXNwPXNo YXJpbmc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJvYmVydDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiAxMSBBdWd1c3QgMjAxNSBhdCAxMzoxOSwgS292YXRzY2ggTWF0dGhpYXMg Jmx0OzxhIGhyZWY9Im1haWx0bzprb3ZhdHNjaEBpbmYuZXRoei5jaCIgdGFyZ2V0PSJfYmxhbmsi PmtvdmF0c2NoQGluZi5ldGh6LmNoPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPlllcywgdGhlIGFwcGxpY2F0aW9uIGFsc28gbmVlZHMgdG8gYmUgaW5mb3JtZWQgb2YgZmFp bHVyZXMgdGhhdCBhcmUgdW5yZWxhdGVkIHRvIENvQVAgc3VjaCBhcyBmYWlsdXJlcyBhdCBsb3dl ciBsYXllcnMgb3IgdGhlIG9wZXJhdGluZyBzeXN0ZW0gKEkgd291bGRu4oCZdA0KIGNhbGwgaXQg 4oCcQWJvcnQs4oCdIHRob3VnaCwgYnV0IGFuIGV4Y2VwdGlvbiBvciBlcnJvcikuPC9zcGFuPjxz cGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhvdyBtYW55IOKAnGFycm93c+KAnSB5b3UgaGF2 ZSBpbiB0aGUgQVBJIGJldHdlZW4gUmVxL1JlcyBMYXllciBhbmQgQXBwbGljYXRpb24gTGF5ZXIg ZGVwZW5kcyBvbiB5b3VyIGltcGxlbWVudGF0aW9uLiBOb3RlIHRoYXQgdGhleSBhcmUgZXF1aXZh bGVudDo8L3NwYW4+PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RG93bndh cmQ8L3NwYW4+PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3IDtjb2xvcjojMWY0OTdkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5vPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4xIGRvd246IGF0dGFjaCBhbGwgbG93ZXItbGF5ZXItc3Bl Y2lmaWMgaW5mb3JtYXRpb24gdG8gdGhlIHJlcXVlc3QgY2FsbCAodXNlZnVsIGlmIHRoZSByZXF1 aXJlbWVudHMgY2hhbmdlIGZvciBlYWNoIHJlcXVlc3QpPC9zcGFuPjxzcGFuIGxhbmc9IkRFLUNI Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6IzFmNDk3ZCZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+bzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+MiBk b3duOiBoYXZlIHNlcGFyYXRlIGNhbGxzIHRvIGNvbmZpZ3VyZSB0aGUgbG93ZXIgbGF5ZXJzIChl LmcuLCBjaG9vc2UgdGhlIG5ldHdvcmsgb3BlcmF0b3IgZm9yIHRoZSBjZWxsdWxhciBtb2RlbSBv ciByZWxheCB0aGUgcmVxdWlyZW1lbnQgZm9yIGFsbCByZXF1ZXN0cyB0byBOT04pPC9zcGFuPjxz cGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5VcHdhcmQ8L3NwYW4+ PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW4tbGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 IDtjb2xvcjojMWY0OTdkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5vPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4xIHVwOiB1c2UgYSB3cmFwcGVyIHJlc3BvbnNlIHN0cnVjdC9vYmplY3Qg dGhhdCBoYXMgZWl0aGVyIGEgQ29BUCByZXNwb25zZSBvciBhbiBleGNlcHRpb24vZXJyb3I8L3Nw YW4+PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3IDtjb2xvcjojMWY0OTdkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5vPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4yIHVwOiBzcGxpdCByZXNwb25zZXMgKHJldHVybiB2YWx1ZSBvciBv blN1Y2Nlc3MoUmVzcG9uc2UpIGhhbmRsZXIpIGFuZCBleGNlcHRpb25zIChlLmcuLCBjYXRjaCBi bG9ja3Mgb3IgaW4gYW4gb25FcnJvcihFeGNlcHRpb24pIGhhbmRsZXIpLjwvc3Bhbj48c3BhbiBs YW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkRF LUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUgcXVlc3Rpb24gZm9yIGhlcmUgaXMgd2hldGhlciB3 ZSBjYW4gaWRlbnRpZnkgYSBjb21tb24gc2V0IG9mIEV4Y2VwdGlvbnMgdGhhdCBpcyBhZ25vc3Rp YyBvZiBzcGVjaWZpYyBsb3dlciBsYXllcnMuPC9zcGFuPjxzcGFuIGxhbmc9IkRFLUNIIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPlJlZ2FyZHM8L3NwYW4+PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi Pk1hdHRoaWFzPC9zcGFuPjxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBDYXJleSwgVGltb3RoeSAoVGltb3RoeSkgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86dGltb3RoeS5jYXJleUBhbGNhdGVsLWx1Y2VudC5jb20iIHRhcmdl dD0iX2JsYW5rIj50aW1vdGh5LmNhcmV5QGFsY2F0ZWwtbHVjZW50LmNvbTwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gRnJlaXRhZywgNy4gQXVndXN0IDIwMTUgMTg6Mjc8c3BhbiBsYW5nPSJERS1D SCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJERS1DSCI+PGJyPg0KPGI+VG86PC9iPiBLb3ZhdHNjaCBNYXR0aGlh cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtvdmF0c2NoQGluZi5ldGh6LmNoIiB0YXJnZXQ9Il9ibGFu ayI+a292YXRzY2hAaW5mLmV0aHouY2g8L2E+Jmd0OzsgY29yZSBXRyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmNvcmVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jb3JlQGlldGYub3JnPC9hPiZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtjb3JlXSBDb21tb24gcmVxdWVzdC9yZXNwb25zZSBB UEk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJERS1DSCI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NYXR0 aGlhcyw8c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TbyBhcmUgeW91IHN1Z2dlc3RpbmcgdGhlbiB0 aGF0IHRoZSBBUEkgYmV0d2VlbiB0aGUgRW5kIEFwcGxpY2F0aW9uIGFuZCB0aGUgUmVxdWVzdCBS ZXNwb25zZSBMYXllciBiZTo8c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJERS1DSCI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOiMxZjQ5N2QmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDtSRVEmbmJzcDsmbmJzcDsmbmJzcDsg L1wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgL1wmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7QXBwbGljYXRpb24gTGF5ZXIgKExXTTJNLElQU08pPC9zcGFuPjxzcGFuIGxhbmc9IkRFLUNI Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6IzFmNDk3ZCZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 PC9zcGFuPjxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyA7Y29sb3I6IzFmNDk3ZCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+LS0tLS0tfC0tLS0tLXwt LS0tLS18LS0tLS0tPC9zcGFuPjxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyA7Y29sb3I6IzFmNDk3ZCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfDwvc3Bhbj48c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcgO2NvbG9yOiMxZjQ5N2QmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDtcLyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtSRVNQJm5ic3A7IEFib3J0 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJFUS9SRVNQIExheWVyPC9zcGFuPjxzcGFuIGxhbmc9IkRFLUNI Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6IzFmNDk3ZCZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6IzFmNDk3ZCZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+SSBqdXN0IHdhbnRlZCB0byBiZSBjbGVhciB0aGF0IHRoaXMgaXMgYW4gYWRkaXRp b25hbCB0eXBlIG9mIGludGVyYWN0aW9uLjwvc3Bhbj48c3BhbiBsYW5nPSJERS1DSCI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOiMxZjQ5N2QmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOiMxZjQ5N2QmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PkJSLDwvc3Bhbj48c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcgO2NvbG9yOiMxZjQ5N2QmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRpbTwvc3Bhbj48 c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IEtvdmF0c2NoIE1hdHRoaWFzIFs8YSBocmVmPSJtYWlsdG86a292 YXRzY2hAaW5mLmV0aHouY2giIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86a292YXRzY2hAaW5mLmV0 aHouY2g8L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXVndXN0IDA3LCAyMDE1IDEw OjEyIEFNPGJyPg0KPGI+VG86PC9iPiBDYXJleSwgVGltb3RoeSAoVGltb3RoeSk7IGNvcmUgV0c8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtjb3JlXSBDb21tb24gcmVxdWVzdC9yZXNwb25zZSBB UEk8L3NwYW4+PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxzcGFuIGxhbmc9IkRFLUNI Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5ObywgcmVzcG9uc2UgY29kZXMgcmVmbGVjdCBzdWNjZXNzIGlu IHRoaXMgY29udGV4dCAoZXZlbiA0Lnh4IGFuZCA1Lnh4KSwgc2luY2UgdGhlIHJlcXVlc3QgY291 bGQgYmUgZGVsaXZlcmVkIGFuZCBhIHJlc3BvbnNlIHdhcyByZWNlaXZlZC4gRXhjZXB0aW9ucw0K IGFyZSBmb3IgdGhlIHRoaW5ncyB0aGF0IGNvdWxkIGdvIHdyb25nIGR1cmluZyB0cmFuc21pc3Np b24vcmVjZXB0aW9uLjwvc3Bhbj48c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gQ2FyZXksIFRpbW90aHkgKFRpbW90aHkpIFs8 YSBocmVmPSJtYWlsdG86dGltb3RoeS5jYXJleUBhbGNhdGVsLWx1Y2VudC5jb20iIHRhcmdldD0i X2JsYW5rIj5tYWlsdG86dGltb3RoeS5jYXJleUBhbGNhdGVsLWx1Y2VudC5jb208L2E+XQ0KPGJy Pg0KPGI+U2VudDo8L2I+IEZyaWRheSwgNyBBdWd1c3QgMjAxNSAxNjozMTxicj4NCjxiPlRvOjwv Yj4gS292YXRzY2ggTWF0dGhpYXMgJmx0OzxhIGhyZWY9Im1haWx0bzprb3ZhdHNjaEBpbmYuZXRo ei5jaCIgdGFyZ2V0PSJfYmxhbmsiPmtvdmF0c2NoQGluZi5ldGh6LmNoPC9hPiZndDs7IGNvcmUg V0cgJmx0OzxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y29y ZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbY29yZV0gQ29tbW9u IHJlcXVlc3QvcmVzcG9uc2UgQVBJPHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxzcGFu IGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk1hdHRoaWFzLDxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZW4gdGhlIGV4Y2VwdGlvbnMg eW91IGhhdmUgbGlzdGVkIHNob3VsZCBiZSByZWZsZWN0ZWQgaW4gUmVzcCBDb2Rlcz88c3BhbiBs YW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5CUiw8c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaW08c3BhbiBsYW5nPSJERS1DSCI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3BhbiBsYW5n PSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEtvdmF0 c2NoIE1hdHRoaWFzIFs8YSBocmVmPSJtYWlsdG86a292YXRzY2hAaW5mLmV0aHouY2giIHRhcmdl dD0iX2JsYW5rIj5tYWlsdG86a292YXRzY2hAaW5mLmV0aHouY2g8L2E+XQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IEZyaWRheSwgQXVndXN0IDA3LCAyMDE1IDg6MTggQU08YnI+DQo8Yj5Ubzo8L2I+IENh cmV5LCBUaW1vdGh5IChUaW1vdGh5KTsgY29yZSBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog W2NvcmVdIENvbW1vbiByZXF1ZXN0L3Jlc3BvbnNlIEFQSTwvc3Bhbj48c3BhbiBsYW5nPSJERS1D SCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPkhpIFRpbTxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJERS1DSCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+Jmd0OyBJbiB5b3VyIHZpZXcgdGhlIEFwcGxpY2F0 aW9uIExheWVyIHRoYXQgd291bGQgcmVjZWl2ZSB0aGVzZSBpbmRpY2F0aW9ucyBpcyB0aGU8c3Bh biBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+Jmd0OyBSZXF1ZXN0L1Jl c3BvbnNlIExheWVyIHdoaWNoIHRoZW4geW91IHJldHVybiB0aGUgYXBwcm9wcmlhdGUgRXJyb3Ig Y29kZT88c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Tm8sIHRoZSBS ZXF1ZXN0L1Jlc3BvbnNlIExheWVyIGlzIHBhcnQgb2YgQ29BUCBhbmQgZGVmaW5lcyB0aGUgbWV0 aG9kcywgcmVzcG9uc2UgY29kZXMsIG9wdGlvbnMsIGV0Yy4gVGhlIHVzZXIgYXBwbGljYXRpb24g dXNlcyBhbiBBUEkgKOKAnFJlcS9SZXMgTGF5ZXIgQVBJ4oCdKSB0byBpc3N1ZSByZXF1ZXN0cyBh bmQgcmVjZWl2ZSByZXNwb25zZXMgYW5kIHdpbGwgcmVjZWl2ZSB0aGVzZSBlcnJvciBjb2Rlcy4N CiBUaGUgY29kZXMgbmVlZCB0byBiZSB0cmFuc3BvcnQtYWdub3N0aWMuIFRoZSB0cmFuc3BvcnQg aXRzZWxmIGNhbiBiZSBjaG9zZW4gdGhyb3VnaCB0aGUgc2NoZW1lIHVzZWQgaW4gdGhlIFVSSSBw YXNzZWQgdG8gdGhlIFJlcS9SZXMgQVBJLiBJbiBDYWxpZm9ybml1bSwgSSB3aWxsIHByb2JhYmx5 IGFkZCBhZGRpdGlvbmFsIEFQSSBjYWxscyB0aGF0IG9ubHkgaGF2ZSBlZmZlY3Qgb24gc29tZSB0 cmFuc3BvcnRzIChlLmcuLCBDT04vTk9OKS4gVGhlDQogdXNlciBhcHBsaWNhdGlvbiBjYW4gY2Fs bCB0aGVtIGRlcGVuZGluZyBvbiB3aGF0IHNjaGVtZS90cmFuc3BvcnQgaXQgY2hvc2UuIEkgdHJp ZWQgdG8gZGVwaWN0IGl0Ojwvc3Bhbj48c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPiYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tJiM0Mzs8L3NwYW4+PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6 YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48 c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+fCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtB cHBsaWNhdGlvbiAoY3VzdG9tIC8gTFdNMk0gLyBJUFNPKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9zcGFuPjxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij58Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHw8L3NwYW4+PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPiYjNDM7LS0tLS0tLS0tLS0tLS0tWyBSZXEvUmVzIExheWVy IEFQSSBdLS0tLS0tLS0tLS0tLS0tJiM0MzsgJmx0Oy0tPC9zcGFuPjxzcGFuIGxhbmc9IkRFLUNI Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij58ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO3w8L3NwYW4+PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29s b3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnwgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UmVxdWVzdC9SZXNwb25zZSBMYXllciAoQ29BUCBz cGVjKSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8PC9zcGFuPjxz cGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij58ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8L3NwYW4+PHNwYW4gbGFuZz0iREUtQ0giPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiYjNDM7LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8L3Nw YW4+PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6YmxhY2smcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPnwgTWVzc2FnZSBMYXllciAoQ29BUCBzcGVjIC8gYWx0ZXJuYXRpdmUg dHJhbnNwb3J0KSB8PC9zcGFuPjxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9y OmJsYWNrJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjxzcGFuIGxhbmc9IkRF LUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7VHJhbnNwb3J0IExheWVyIChVRFAgLyBE VExTIC8gVENQIC8gVExTIC8gU01TKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9zcGFuPjxzcGFuIGxhbmc9IkRFLUNI Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5DaWFvPC9zcGFuPjxzcGFuIGxhbmc9IkRFLUNIIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1hdHRo aWFzPC9zcGFuPjxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4m bmJzcDs8c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+Jmd0OyAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD4mZ3Q7IEZyb206IEtvdmF0c2NoIE1hdHRoaWFzIFs8YSBocmVmPSJtYWls dG86a292YXRzY2hAaW5mLmV0aHouY2giIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOmtvdmF0c2NoQGluZi5l dGh6LmNoPC9zcGFuPjwvYT5dPHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwPiZndDsgU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwNiwgMjAxNSA5OjQ3IEFNPHNwYW4g bGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPiZndDsgVG86IGNvcmUgV0c8 c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+Jmd0OyBTdWJqZWN0 OiBbY29yZV0gQ29tbW9uIHJlcXVlc3QvcmVzcG9uc2UgQVBJPHNwYW4gbGFuZz0iREUtQ0giPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPiZndDsgPHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPiZndDsgRGVhciBsaXN0PHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwPiZndDsgPHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPiZndDsgSW4gUHJhZ3VlLCB0aGUgcHJvYmxlbSBvZiBhIGNvbW1vbiBy ZXF1ZXN0L3Jlc3BvbnNlIEFQSSBmb3IgYWxsIHBvc3NpYmxlPHNwYW4gbGFuZz0iREUtQ0giPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPiZndDsgdHJhbnNwb3J0cyB3YXMgcmFpc2VkLiBXZSBu b3cgaGF2ZSBzb21ldGhpbmcgc2ltaWxhciBpbiB0aGUgQ2FsaWZvcm5pdW08c3BhbiBsYW5nPSJE RS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+Jmd0OyBwcm9qZWN0LCB3aGVyZSB3ZSB3 YW50IHRvIGltcHJvdmUgdGhlIGVycm9yIGhhbmRsaW5nIGZvciB0aGUgQ29hcENsaWVudCBBUEkg YXM8c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+Jmd0OyB3ZWxs IGFzIGltcHJvdmUgdGhlIGluZm9ybWF0aW9uIGZsb3cgYmV0d2VlbiBTY2FuZGl1bSAoRFRMUykg YW5kIENhbGlmb3JuaXVtPHNwYW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPiZndDsgKG9yIHJhdGhlciB0aGUgYXBwbGljYXRpb24gY29kZSkuPHNwYW4gbGFuZz0iREUt Q0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPiZndDsgPHNwYW4gbGFuZz0iREUtQ0giPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPiZndDsgQXMgYSBzdGFydCwgSSBjb2xsZWN0ZWQgcG9z c2libGUgZXhjZXB0aW9ucyB0aGF0IGNvdWxkIHNpZ25hbCB3aGF0IHdlbnQgd3JvbmcuPHNwYW4g bGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPiZndDsgV2hpbGUgdGhpcyBt aWdodCBiZSBhIGJpdCBKYXZhLWNlbnRyaWMsIHRoZSBpbnRlbnQgaXMgdW5pdmVyc2FsOiBoYXZl IGEgY29tbW9uIHNldDxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cD4mZ3Q7IG9mIHNpZ25hbHMgdG8gdGVsbCB0aGUgYXBwbGljYXRpb24gYWJvdmUgdGhlIHJlcXVl c3QvcmVzcG9uc2UgQVBJIHdoYXQgd2VudDxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD4mZ3Q7IHdyb25nLjxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD4mZ3Q7IDxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cD4mZ3Q7IE5ldHdvcmsgbGF5ZXI8c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHA+Jmd0OyAtIERlc3RpbmF0aW9uTm90UmVhY2hhYmxlRXhjZXB0aW9uPHNw YW4gbGFuZz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPiZndDsgLSBQYWNrZXRU b29CaWdFeGNlcHRpb248c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+Jmd0OyA8c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+Jmd0 OyBUcmFuc3BvcnQgbGF5ZXI8c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+Jmd0OyAtIENvbm5lY3Rpb25SZWZ1c2VkRXhjZXB0aW9uPHNwYW4gbGFuZz0iREUtQ0gi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPiZndDsgLSBBdXRoZW50aWNhdGlvbkV4Y2VwdGlv bjxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4mZ3Q7IC0gVG9v TWFueU9wZW5GaWxlc0V4Y2VwdGlvbiAvIEluc3VmZmljaWVudFJlc291cmNlc0V4Y2VwdGlvbiAo bW9yZSBPUy08c3BhbiBsYW5nPSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+Jmd0 OyByZWxhdGVkLCBidXQgaGFwcGVucyBhdCB0aGUgc29ja2V0IGxldmVsKTxzcGFuIGxhbmc9IkRF LUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4mZ3Q7IDxzcGFuIGxhbmc9IkRFLUNIIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4mZ3Q7IEFwcGxpY2F0aW9uIGxheWVyPHNwYW4gbGFu Zz0iREUtQ0giPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPiZndDsgLSBUaW1lb3V0RXhjZXB0 aW9uIC8gTm9SZXBseUV4Y2VwdGlvbjxzcGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD4mZ3Q7IC0gSW52YWxpZFVSSUV4Y2VwdGlvbiAvIEludmFsaWRUcmFuc3BvcnRF eGNlcHRpb24gKGFsdGVybmF0aXZlIHRyYW5zcG9ydHMgQVBJKTxzcGFuIGxhbmc9IkRFLUNIIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4mZ3Q7IC0gUmVqZWN0ZWRFeGNlcHRpb24gKG5vdCBz dXJlIGlmIHRoZSBzYW1lIGFzIENvbm5lY3Rpb25SZWZ1c2VkRXhjZXB0aW9uKTxzcGFuIGxhbmc9 IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4mZ3Q7IDxzcGFuIGxhbmc9IkRFLUNI Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4mZ3Q7IEl0IHdvdWxkIGJlIGdyZWF0LCBpZiB5 b3UgY291bGQgaGF2ZSBhIGxvb2ssIHN1Z2dlc3QgbW9yZTxzcGFuIGxhbmc9IkRFLUNIIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4mZ3Q7IGV4Y2VwdGlvbnMvc2lnbmFscy9lcnJvciBjb2Rl cywgcHJvcG9zZSB0aGlubmluZy9tZXJnaW5nLCBvciBqdXN0IGNvbW1lbnQgb248c3BhbiBsYW5n PSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+Jmd0OyB0aGUgZGlyZWN0aW9uLjxz cGFuIGxhbmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4mZ3Q7IDxzcGFuIGxh bmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4mZ3Q7IENpYW88c3BhbiBsYW5n PSJERS1DSCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+Jmd0OyBNYXR0aGlhczxzcGFuIGxh bmc9IkRFLUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4mZ3Q7IDxzcGFuIGxhbmc9IkRF LUNIIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4mbmJzcDs8c3BhbiBsYW5nPSJERS1DSCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCmNvcmUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0 Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPlRo aXMgYm9keSBwYXJ0IHdpbGwgYmUgZG93bmxvYWRlZCBvbiBkZW1hbmQuPG86cD48L286cD48L3By ZT4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9966516C6EB5FC4381E05BF80AA55F77DC2354D1US70UWXCHMBA05z_-- From nobody Wed Aug 12 19:49:45 2015 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 7DA241B2F59 for ; Wed, 12 Aug 2015 19:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.411 X-Spam-Level: X-Spam-Status: No, score=-98.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 IxPB_WQvN5oZ for ; Wed, 12 Aug 2015 19:49:41 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C8A1B2F4E for ; Wed, 12 Aug 2015 19:49:40 -0700 (PDT) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Aug 2015 11:49:41 +0900 Received: from SMTP1.etri.info ([169.254.1.101]) by SMTP3.etri.info ([10.2.6.32]) with mapi id 14.01.0355.002; Thu, 13 Aug 2015 11:49:36 +0900 From: =?ks_c_5601-1987?B?sO28rrCp?= To: Hannes Tschofenig , Simon Lemay , "core@ietf.org WG" Thread-Topic: [core] Lenght shim Thread-Index: AQHQyHtOn5wwt4OrgUeMYV+4Cm5EGp4IU1uAgAD2FlA= Date: Thu, 13 Aug 2015 02:49:35 +0000 Message-ID: <557A6C8AF976114EBAD8852183CF3F371D7A5A0A@SMTP1.etri.info> References: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> <55CBACAD.9090401@gmx.net> In-Reply-To: <55CBACAD.9090401@gmx.net> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.232.116] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] Lenght shim 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, 13 Aug 2015 02:49:43 -0000 SGVsbG8uIA0KDQpJIHByZWZlciBvcHRpb24gQSwgdG9vLg0KVE8gY292ZXIgT3B0aW9uIEEsIEkg dGhpbmsgd2UgY2FuIGFkZCB0aGUgc2ltaWxhciBtZXRob2Qgb2YgT3B0aW9uIGZvcm1hdCBpbiBD b0FQIHRvIGV4dGVuZCBMZW5ndGggU2hpbSBmaWVsZC4NCg0KMH42NTUzMiBMZW5ndGggc2hpbSwg bm8gZXh0ZW5kZWQgTGVuZ3RoDQo2NTUzMyA0Ynl0ZSBleHRlbmRlZCBMZW5ndGggZmllbGQgKyA2 NTUzMw0KNjU1MzQgOGJ5dGUgZXh0ZW5kZWQgTGVuZ3RoIGZpZWxkICsgNDI5NTAzMjgyOSAoMl4z Mis2NTUzMykNCjY1NTM1IHJlc2VydmVkDQoNCi0gU29mdGdlYXIgS28NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAx MywgMjAxNSA1OjMwIEFNDQpUbzogU2ltb24gTGVtYXkgPHNpbW9uLmxlbWF5QGdtYWlsLmNvbT47 IGNvcmVAaWV0Zi5vcmcgV0cgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIExl bmdodCBzaGltDQoNCkhpIFNpbW9uLA0KDQpJIGRpc2N1c3NlZCB0aGlzIHdpdGggbXkgY28td29y a2VycyBhbmQgd2UgcHJlZmVyIG9wdGlvbiBBLiBXZSBsaWtlIGl0IGJlY2F1c2Ugb2YgdGhlIHNp bXBsZXIgbmF0dXJlIGJlY2F1c2Ugb3B0aW9uIEIgcmVhbGx5IGNoYW5nZXMgdGhlIHNlbWFudGlj IG9mIHRoZSBDb0FQIGhlYWRlci4NCg0KQ2lhbw0KSGFubmVzDQoNCk9uIDA3LzI3LzIwMTUgMDQ6 NDcgUE0sIFNpbW9uIExlbWF5IHdyb3RlOg0KPiBIaSwNCj4gDQo+IFNvIGFmdGVyIHRoZSBtZWV0 aW5nIG9uIEZyaWRheSwgYSBmZXcgb2YgdXAgc3RheWVkIHRvIHRhbGsgYWJvdXQgdGhlIA0KPiBk aWZmZXJlbnQgYWx0ZXJuYXRpdmVzIG9uIGhvdyB0byByZXByZXNlbnQgdGhlIGxlbmd0aCBpbmZv cm1hdGlvbiBpbiANCj4gQ29BUCBvdmVyIFRDUCAocmVsaWFibGUgdHJhbnNwb3J0KQ0KPiANCj4g MiBvcHRpb24gY2FtZSBvdXQgb2YgdGhlIG1lZXRpbmcuDQo+IA0KPiA/Pz8/Pz8/Pz8/Pz8/Pz8/ Pz8tDQo+IE9wdGlvbiBBDQo+IDIgYnl0ZSBzaGltIHdpdGggbmV3IEJsb2NraW5nIG9wdGlvbiBm b3IgYmlnZ2VyIGFwcGxpY2F0aW9uIGxheWVyIA0KPiBmcmFnbWVudGF0aW9uDQo+IA0KPiBUaGlz IHdvdWxkIGNvbnNpc3RzIG9mIDIgYnl0ZXMgKDE2IGJpdHMpIGdpdmluZyBhIG1heCBsZW5ndGgg b2YgNjRrYi4gIHdlIHdvdWxkIGFsc28gYWRkIGEgbmV3IHNpemUgb3B0aW9uIGluIHRoZSBibG9j ayBzaXplIGZvciBGRkZGIChtaW51cyB0aGUgaGVhZGVyKS4NCj4gDQo+ICAgMCAgICAgICAgICAg ICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KPiAgIDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMQ0KPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQo+ICAgfCAgTGVuZ3RoIFNoaW0gIHxWZXJ8IFQgfCAgVEtMICB8 ICAgICAgQ29kZSAgICAgfCAgIFRva2VuIChUS0wNCj4gICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgIHwgICBieXRl cykgLi4uICB8ICBPcHRpb25zIChpZiBhbnkpIC4uLg0KPiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ICAgfDEgMSAx IDEgMSAxIDEgMXwgICAgUGF5bG9hZCAoaWYgYW55KSAuLi4NCj4gICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiANCj4g DQo+IFRoZSBuZXcgYmxvY2tzaXplIG5lZWRzIHRvIGJlIGEgY2xlYW4gZnJhY3Rpb24gb2YgdGhl IDEwMjRieXRlIGJsb2NrLiAgVGhpcyBpcyBuZWVkZWQgZm9yIHByb3h5aW5nIGJsb2Nrc2l6ZSBh Y3Jvc3MgZGlmZmVyZW50IHRyYW5zcG9ydCBsYXllci4NCj4gDQo+IFByb3M6DQo+IC1lYXN5IHRv IG1hbmFnZQ0KPiAtY2FuIGJlIHJlbW92ZSBpcyBmYW1pbmcgaXMgbm90IG5lZWRlZCAtYXBwbGlj YXRpb24gbGF5ZXIgDQo+IGZyYWdtZW50YXRpb24gaGVscHMgd2l0aCBtdWx0aXBsZXhpbmcgcmVx dWVzdA0KPiANCj4gDQo+IA0KPiBDb25zDQo+IC1Eb2VzIG5vdCBzdXBwb3J0IGxhcmdlciB0aGFu IDE2IGJpdHMuDQo+IC1jb3VsZCBub3QgZG8gc3RyZWFtaW5nDQo+IA0KPiANCj4gPz8/Pz8/Pz8/ Pz8/Pz8/Pz8/LQ0KPiBPcHRpb24gQg0KPiBPcHRpb24gbGlrZSBzcGxpdCBsZW5ndGggd2l0aCBh IG5vIGxlbmd0aCBvcHRpb24gZm9yIHJlbGlhYmxlIA0KPiB0cmFuc3BvcnQgdGhhdCBhbHJlYWR5 IGhhdmUgYSBmcmFtaW5nDQo+IA0KPiAgVGhlIGluaXRpYWwgYnl0ZSBvZiB0aGUgZnJhbWUgY29u dGFpbnMgdHdvIG5pYmJsZXMsIGluIGEgc2ltaWxhciB3YXkgDQo+IHRvIHRoZSBDb0FQIG9wdGlv biBlbmNvZGluZyAoU2VjdGlvbiAzLjEgb2YgW1JGQzcyNTJdKS4gVGhlIGZpcnN0IA0KPiBuaWJi bGUgaXMgdXNlZCB0byBpbmRpY2F0ZSB0aGUgbGVuZ3RoIG9mIHRoZSBvcHRpb25zIChpbmNsdWRp bmcgYW55IA0KPiBvcHRpb24gZGVsaW1pdGVyKSwgYW5kIHRoZSBwYXlsb2FkIChpZiBhbnkpOyBp dCBkb2VzIG5vdCBpbmNsdWRlIHRoZSANCj4gQ29kZSBieXRlIG9yIHRoZSBUb2tlbiBieXRlcy4g VGhlIGZpcnN0IG5pYmJsZSBpcyBpbnRlcnByZXRlZCBhcyBhIA0KPiA0LWJpdCB1bnNpZ25lZCBp bnRlZ2VyLiBBIHZhbHVlIGJldHdlZW4gMCBhbmQgMTIgZGlyZWN0bHkgaW5kaWNhdGVzIA0KPiB0 aGUgbGVuZ3RoIG9mIHRoZSBvcHRpb25zL3BheWxvYWQsIGluIGJ5dGVzLiBUaGUgb3RoZXIgdGhy ZWUgdmFsdWVzIA0KPiBoYXZlIGEgc3BlY2lhbCBtZWFuaW5nOiAxMzogQW4gOC1iaXQgdW5zaWdu ZWQgaW50ZWdlciBmb2xsb3dzIHRoZSANCj4gaW5pdGlhbCBieXRlIGFuZCBpbmRpY2F0ZXMgdGhl IGxlbmd0aCBvZiBvcHRpb25zL3BheWxvYWQgbWludXMgMTMuIDE0OiANCj4gQSAxNi1iaXQgdW5z aWduZWQgaW50ZWdlciBpbiBuZXR3b3JrIGJ5dGUgb3JkZXIgZm9sbG93cyB0aGUgaW5pdGlhbCAN Cj4gYnl0ZSBhbmQgaW5kaWNhdGVzIHRoZSBsZW5ndGggb2Ygb3B0aW9ucy9wYXlsb2FkIG1pbnVz IDI2OS4gMTU6IEEgDQo+IDMyLWJpdCB1bnNpZ25lZCBpbnRlZ2VyIGluIG5ldHdvcmsgYnl0ZSBv cmRlciBmb2xsb3dzIHRoZSBpbml0aWFsIGJ5dGUgDQo+IGFuZCBpbmRpY2F0ZXMgdGhlIGxlbmd0 aCBvZiBvcHRpb25zL3BheWxvYWQgbWludXMgNjU4MDUuICAxNjogbm8gDQo+IGZyYW1pbmcuIFRo ZSBzZWNvbmQgbmliYmxlIG9mIHRoZSBpbml0aWFsIGJ5dGUgaW5kaWNhdGVzIHRoZSB0b2tlbiAN Cj4gbGVuZ3RoLiBFeGFtcGxlOiAwMSA0MyA3ZiBpcyBhIGZyYW1lIGp1c3QgY29udGENCmluaW5n IGEgMi4wMyBjb2RlIHdpdGggdGhlIHRva2VuIDdmLg0KPiANCj4gDQo+IA0KPiAgIDAgICAgICAg ICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCj4g ICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDENCj4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgIHwgIExlbiAgfCAgVEtMICB8IExlbisgYnl0ZXMu Li4gfCAgICAgIENvZGUgICAgIHwgVEtMIGJ5dGVzIC4uLg0KPiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ICAgfCAg T3B0aW9ucyAoaWYgYW55KSAuLi4NCj4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgIHwxIDEgMSAxIDEgMSAxIDF8 ICAgIFBheWxvYWQgKGlmIGFueSkgLi4uDQo+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gDQo+IA0KPiBQcm9zOg0K PiAtc3VwcG9ydHMgbGFyZ2VyIHBheWxvYWQNCj4gLWZsZXhpYmxlIChkeW5hbWljIHBheWxvYWQg c2l6ZSkNCj4gLXJlbW92ZWQgdGhlIE1lc3NhZ2UgVHlwZSBmaWVsZA0KPiANCj4gDQo+IENvbnM6 DQo+IC1MYXJnZSBtZXNzYWdlIG1pZ2h0IGJlIGRpZmZpY3VsdCB0byBwYXJzZSBvciBmbHVzaCBm b3IgbW9yZSBjb25zdHJhaW50IG5vZGUuDQo+IC1jYW5ub3QgYmUgcmVtb3ZlZCBpZiB1bmRlcmxp bmluZyBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCBuZWVkIGZyYW1pbmcNCj4gDQo+IExldCBtZSBr bm93IHdoYXQgeW91IGd1eXMgdGhpbmssIGFueSBwcm8gb3IgY29ucyBtaXNzaW5nIGFuZCB3aGF0 IHdlIA0KPiBzaG91bGQgcHJvY2VzcyB0bw0KPiANCj4gQ2hlZXJzDQo+IA0KPiBTaW1vbg0KPiAN Cj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gY29yZSBtYWlsaW5nIGxpc3QNCj4gY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCj4gDQoNCg== From nobody Thu Aug 13 16:09:44 2015 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 B848D1ACEA2 for ; Thu, 13 Aug 2015 16:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 gdcss4nCHkgG for ; Thu, 13 Aug 2015 16:09:40 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6381ACE9C for ; Thu, 13 Aug 2015 16:09:39 -0700 (PDT) Received: by lahi9 with SMTP id i9so34405985lah.2 for ; Thu, 13 Aug 2015 16:09:38 -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=oT5vPbeo2qeH07cRATYo5pZu7HHOkQOYRP71FoaOLfo=; b=cq/RON4vOrtywiuHYvEFhAI3fzjKBNMP2s2oCx2gGWCGJsGo97CokL5ZV9nV/eMony WsdmigYXytKK6T6pLbxNMskWdekhWnbYLdIjUIV/npwlQ1WgI5ZcIbfzmsvnW9ar52BW 67j3tGrCznEeYtwVD9OKsDPHlkmv0t3A0qLKeDm+OrOzSQ6xV9Yaj9izTlPKan4eYSD9 uzKwgXJMsfFtirHQh9P252k2s3xklJPlUhLsWbtZJDULlzljGuzYrvD8gElo3XNavf4S qCWind8swQXSHBpFA5XX1KcbCCs0Z3LIqzvovw1KfyLTWW0j4FpU7JTzPlmuWLAKrwRV iTPg== MIME-Version: 1.0 X-Received: by 10.152.206.41 with SMTP id ll9mr39117728lac.103.1439507378004; Thu, 13 Aug 2015 16:09:38 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.25.83.65 with HTTP; Thu, 13 Aug 2015 16:09:37 -0700 (PDT) In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC2354D1@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <55877B3AFB359744BA0F2140E36F52B54C813E91@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22E65A@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C814F8D@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22EFEA@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C815218@MBX210.d.ethz.ch> <9966516C6EB5FC4381E05BF80AA55F77DC22F1C6@US70UWXCHMBA05.zam.alcatel-lucent.com> <55877B3AFB359744BA0F2140E36F52B54C821E7A@MBX110.d.ethz.ch> <55CB3E46.7060503@intec.ugent.be> <9966516C6EB5FC4381E05BF80AA55F77DC2354D1@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Fri, 14 Aug 2015 00:09:37 +0100 X-Google-Sender-Auth: fy1mH0bHgHVj9eKM5CYv4GNEOME Message-ID: From: Robert Cragie To: "Carey, Timothy (Timothy)" Content-Type: multipart/alternative; boundary=001a1133af6aeaeaad051d396de0 Archived-At: Cc: core WG Subject: Re: [core] Common request/response API 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: Thu, 13 Aug 2015 23:09:43 -0000 --001a1133af6aeaeaad051d396de0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tim, Yes, the intention was to extend it to transport layer as well, probably based on the standard socket API, although this could also be generalised in a primitive-based schema. I stopped short of doing that work as I thought it was complete enough to put forward as a strawman to gauge whether it is worth continuing. If people think it is worth it, I am happy to add more content and open it up as a collaborative document on Google docs. Robert. On 13 August 2015 at 01:36, Carey, Timothy (Timothy) < timothy.carey@alcatel-lucent.com> wrote: > Robert, > > > > Yes I think this might work. A generic set of primitives with unique > meaning at the specific layer interaction. > > > > Could this technique also be extended between the ML and Transport Layers= ? > > > > BR, > > Tim > > > > *From:* Floris Van den Abeele [mailto:floris.vandenabeele@intec.ugent.be] > *Sent:* Wednesday, August 12, 2015 7:39 AM > *To:* robert.cragie@gridmerge.com > *Cc:* Carey, Timothy (Timothy); core WG; Kovatsch Matthias > *Subject:* Re: [core] Common request/response API > > > > Would such signals also include sanity checks on CoAP requests that are > asked by the application? In some implementations the API itself can be > designed to prevent constructing invalid CoAP requests. But in our > implementation, the interface between the application and the CoAP client > (potentially running in a separate process on another machine) is a socke= t > and all the data about the request and the response (or error/warning) is > also transferred over this socket. Applications describe their request vi= a > CSV strings, and the response is received as a CSV string. This will > sometimes lead to invalid requests if the application is oblivious. > > Our implementation includes sanity checks for some of the MUST (NOT)s in > the CoAP spec: > * A Non-confirmable message always carries either a request or response > and MUST NOT be Empty -> Non messages must not be empty > * If a Method or Response Code is not defined to have a payload, then a > sender MUST NOT include one, and a recipient MUST ignore it. -> GET > requests must not include a payload. > > Of course one could argue that in our case the logic generating the CSV > strings is actually part of the CoAP client library and not the applicati= on > itself, and that such signals should not be propagated to the application > and rather that the logic (i.e API) generating the CSV strings should > prevent applications from constructing empty non-messages, GET requests > without a payload, etc. > > BR, > Floris > > On 11-08-15 19:31, Robert Cragie wrote: > > I started to put together a strawman document on this topic and would > appreciate any comments. > > > > > https://docs.google.com/document/d/1a8BCVrKcGH0QmKDcV16SaJuD2ai_3v-ds3X7w= f_32JE/edit?usp=3Dsharing > > > > Robert > > > > On 11 August 2015 at 13:19, Kovatsch Matthias > wrote: > > Yes, the application also needs to be informed of failures that are > unrelated to CoAP such as failures at lower layers or the operating syste= m > (I wouldn=E2=80=99t call it =E2=80=9CAbort,=E2=80=9D though, but an excep= tion or error). > > > > How many =E2=80=9Carrows=E2=80=9D you have in the API between Req/Res Lay= er and > Application Layer depends on your implementation. Note that they are > equivalent: > > > > - Downward > > o 1 down: attach all lower-layer-specific information to the request > call (useful if the requirements change for each request) > > o 2 down: have separate calls to configure the lower layers (e.g., > choose the network operator for the cellular modem or relax the requireme= nt > for all requests to NON) > > - Upward > > o 1 up: use a wrapper response struct/object that has either a CoAP > response or an exception/error > > o 2 up: split responses (return value or onSuccess(Response) handler) > and exceptions (e.g., catch blocks or in an onError(Exception) handler). > > > > The question for here is whether we can identify a common set of > Exceptions that is agnostic of specific lower layers. > > > > Regards > > Matthias > > > > > > *From:* Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com= ] > > *Sent:* Freitag, 7. August 2015 18:27 > > > *To:* Kovatsch Matthias ; core WG > *Subject:* RE: [core] Common request/response API > > > > Matthias, > > > > So are you suggesting then that the API between the End Application and > the Request Response Layer be: > > > > REQ /\ /\ Application Layer (LWM2M,IPSO) > > | | | > > ------|------|------|------ > > | | > > \/ RESP Abort REQ/RESP Layer > > > > I just wanted to be clear that this is an additional type of interaction. > > > > BR, > > Tim > > > > *From:* Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch > ] > *Sent:* Friday, August 07, 2015 10:12 AM > *To:* Carey, Timothy (Timothy); core WG > *Subject:* RE: [core] Common request/response API > > > > No, response codes reflect success in this context (even 4.xx and 5.xx), > since the request could be delivered and a response was received. > Exceptions are for the things that could go wrong during > transmission/reception. > > > > > > *From:* Carey, Timothy (Timothy) [mailto:timothy.carey@alcatel-lucent.com > ] > *Sent:* Friday, 7 August 2015 16:31 > *To:* Kovatsch Matthias ; core WG > *Subject:* RE: [core] Common request/response API > > > > Matthias, > > > > Then the exceptions you have listed should be reflected in Resp Codes? > > > > BR, > > Tim > > > > *From:* Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch > ] > *Sent:* Friday, August 07, 2015 8:18 AM > *To:* Carey, Timothy (Timothy); core WG > *Subject:* RE: [core] Common request/response API > > > > Hi Tim > > > > > In your view the Application Layer that would receive these indications > is the > > > Request/Response Layer which then you return the appropriate Error code= ? > > > > No, the Request/Response Layer is part of CoAP and defines the methods, > response codes, options, etc. The user application uses an API (=E2=80=9C= Req/Res > Layer API=E2=80=9D) to issue requests and receive responses and will rece= ive these > error codes. The codes need to be transport-agnostic. The transport itsel= f > can be chosen through the scheme used in the URI passed to the Req/Res AP= I. > In Californium, I will probably add additional API calls that only have > effect on some transports (e.g., CON/NON). The user application can call > them depending on what scheme/transport it chose. I tried to depict it: > > > > +---------------------------------------------------+ > > | | > > | Application (custom / LWM2M / IPSO) | > > | | > > +---------------[ Req/Res Layer API ]---------------+ <-- > > | | > > | Request/Response Layer (CoAP spec) | > > | | > > +---------------------------------------------------+ > > | Message Layer (CoAP spec / alternative transport) | > > +---------------------------------------------------+ > > | Transport Layer (UDP / DTLS / TCP / TLS / > SMS) | > > > > Ciao > > Matthias > > > > > -----Original Message----- > > > From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch > ] > > > Sent: Thursday, August 06, 2015 9:47 AM > > > To: core WG > > > Subject: [core] Common request/response API > > > > > > Dear list > > > > > > In Prague, the problem of a common request/response API for all possibl= e > > > transports was raised. We now have something similar in the Californium > > > project, where we want to improve the error handling for the CoapClient > API as > > > well as improve the information flow between Scandium (DTLS) and > Californium > > > (or rather the application code). > > > > > > As a start, I collected possible exceptions that could signal what went > wrong. > > > While this might be a bit Java-centric, the intent is universal: have a > common set > > > of signals to tell the application above the request/response API what > went > > > wrong. > > > > > > Network layer > > > - DestinationNotReachableException > > > - PacketTooBigException > > > > > > Transport layer > > > - ConnectionRefusedException > > > - AuthenticationException > > > - TooManyOpenFilesException / InsufficientResourcesException (more OS- > > > related, but happens at the socket level) > > > > > > Application layer > > > - TimeoutException / NoReplyException > > > - InvalidURIException / InvalidTransportException (alternative > transports API) > > > - RejectedException (not sure if the same as ConnectionRefusedException= ) > > > > > > It would be great, if you could have a look, suggest more > > > exceptions/signals/error codes, propose thinning/merging, or just > comment on > > > the direction. > > > > > > Ciao > > > Matthias > > > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > > > > > This body part will be downloaded on demand. > > --001a1133af6aeaeaad051d396de0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tim,

Yes, the intention was to exten= d it to transport layer as well, probably based on the standard socket API,= although this could also be generalised in a primitive-based schema. I sto= pped short of doing that work as I thought it was complete enough to put fo= rward as a strawman to gauge whether it is worth continuing. If people thin= k it is worth it, I am happy to add more content and open it up as a collab= orative document on Google docs.

Robert.

On 13 August 20= 15 at 01:36, Carey, Timothy (Timothy) <timothy.carey@alcate= l-lucent.com> wrote:

Robert,

=C2=A0=

Yes I think this mig= ht work. A generic set of primitives with unique meaning at the specific la= yer interaction.

=C2=A0=

Could this technique= also be extended between the ML and Transport Layers?=

=C2=A0=

BR,

Tim

=C2=A0=

From: Floris V= an den Abeele [mailto:floris.vandenabeele@intec.ugent.be]
Sent: Wednesday, August 12, 2015 7:39 AM
To: robert.cragie@gridmerge.com
Cc: Carey, Timothy (Timothy); core WG; Kovatsch Matthias
Subject: Re: [core] Common request/response API=

=C2=A0

Would such signals al= so include sanity checks on CoAP requests that are asked by the application= ? In some implementations the API itself can be designed to prevent constru= cting invalid CoAP requests. But in our implementation, the interface between the application and the CoAP cli= ent (potentially running in a separate process on another machine) is a soc= ket and all the data about the request and the response (or error/warning) = is also transferred over this socket. Applications describe their request via CSV strings, and the response is r= eceived as a CSV string. This will sometimes lead to invalid requests if th= e application is oblivious.

Our implementation includes sanity checks for some of the MUST (NOT)s in th= e CoAP spec:
*=C2=A0 A Non-confirmable message always carries either a request or respon= se and MUST NOT be Empty -> Non messages must not be empty
* If a Method or Response Code is not defined to have a payload, then a sen= der MUST NOT include one, and a recipient MUST ignore it. -> GET request= s must not include a payload.

Of course one could argue that in our case the logic generating the CSV str= ings is actually part of the CoAP client library and not the application it= self, and that such signals should not be propagated to the application and= rather that the logic (i.e API) generating the CSV strings should prevent applications from constructing e= mpty non-messages, GET requests without a payload, etc.

BR,
Floris

On 11-08-15 19:31, Robert Cragie wrote:

I started to put together a strawman document on thi= s topic and would appreciate any comments.

=C2=A0

=C2=A0

Robert

=C2=A0

On 11 August 2015 at 13:19, Kovatsch Matthias <kovatsch@inf.ethz.c= h> wrote:

Yes, the application a= lso needs to be informed of failures that are unrelated to CoAP such as fai= lures at lower layers or the operating system (I wouldn=E2=80=99t call it =E2=80=9CAbort,=E2=80=9D though, but an exception or error).

=C2=A0

How many =E2=80=9Carro= ws=E2=80=9D you have in the API between Req/Res Layer and Application Layer= depends on your implementation. Note that they are equivalent:

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Downward

o=C2=A0=C2=A0 1 down: attach all lower-layer-specifi= c information to the request call (useful if the requirements change for ea= ch request)

o=C2=A0=C2=A0 2 down: have separate calls to configu= re the lower layers (e.g., choose the network operator for the cellular mod= em or relax the requirement for all requests to NON)

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Upward<= /u>

o=C2=A0=C2=A0 1 up: use a wrapper response struct/ob= ject that has either a CoAP response or an exception/error

o=C2=A0=C2=A0 2 up: split responses (return value or= onSuccess(Response) handler) and exceptions (e.g., catch blocks or in an o= nError(Exception) handler).

=C2=A0

The question for here = is whether we can identify a common set of Exceptions that is agnostic of s= pecific lower layers.

=C2=A0

Regards

Matthias

=C2=A0

=C2=A0

From: Carey, Timothy (Timothy) [mailto:timothy.car= ey@alcatel-lucent.com]
Sent: Freitag, 7. August 2015 18:27


To: Kovatsch Matthias <kovatsch@inf.ethz.ch>; core WG <core@ietf.org>
Subject: RE: [core] Common request/response API=

=C2=A0

Matthias,<= /p>

=C2=A0

So are you suggesting then that the API between the = End Application and the Request Response Layer be:<= /u>

=C2=A0

=C2=A0=C2=A0 =C2=A0=C2=A0REQ=C2=A0=C2=A0= =C2=A0 /\=C2=A0=C2=A0=C2=A0=C2=A0 /\=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0Applicat= ion Layer (LWM2M,IPSO)

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0|=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

------|------|------|------

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0|=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |

=C2=A0 =C2=A0=C2=A0=C2=A0\/=C2=A0=C2=A0=C2= =A0 =C2=A0RESP=C2=A0 Abort=C2=A0=C2=A0=C2=A0 REQ/RESP Layer

=C2=A0<= u>

I just wanted to be clear that this is an = additional type of interaction.

=C2=A0<= u>

BR,<= /u>

Tim<= /u>

=C2=A0

From: Kovatsch= Matthias [mailto= :kovatsch@inf.ethz.ch]
Sent: Friday, August 07, 2015 10:12 AM
To: Carey, Timothy (Timothy); core WG
Subject: RE: [core] Common request/response API

=C2=A0

No, response codes ref= lect success in this context (even 4.xx and 5.xx), since the request could = be delivered and a response was received. Exceptions are for the things that could go wrong during transmission/reception.

=C2=A0

=C2=A0

From: Carey, Timothy (Timothy) [mailto:timothy.car= ey@alcatel-lucent.com]
Sent: Friday, 7 August 2015 16:31
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>; core WG <core@ietf.org>
Subject: RE: [core] Common request/response API=

=C2=A0

Matthias,<= /p>

=C2=A0

Then the exceptions you have listed should be reflec= ted in Resp Codes?

=C2=A0

BR,

Tim

=C2=A0

From: Kovatsch= Matthias [mailto= :kovatsch@inf.ethz.ch]
Sent: Friday, August 07, 2015 8:18 AM
To: Carey, Timothy (Timothy); core WG
Subject: RE: [core] Common request/response API

=C2=A0

Hi Tim

=C2=A0=

> In your view the Application Layer that would receive these indicat= ions is the

> Request/Response Layer which then you return the appropriate Error = code?

=C2=A0=

No, the Request/Response Layer is part of Co= AP and defines the methods, response codes, options, etc. The user applicat= ion uses an API (=E2=80=9CReq/Res Layer API=E2=80=9D) to issue requests and= receive responses and will receive these error codes. The codes need to be transport-agnostic. The transport itself can be chose= n through the scheme used in the URI passed to the Req/Res API. In Californ= ium, I will probably add additional API calls that only have effect on some= transports (e.g., CON/NON). The user application can call them depending on what scheme/transport it chose= . I tried to depict it:

=C2=A0=

+---------------------------------------------------+

|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |

| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Application (custom = / LWM2M / IPSO)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |

+---------------[ Req/Res Layer API ]---------------+ <--

| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0|

| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Request/Respon= se Layer (CoAP spec) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|

| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0|

+---------------------------------------------------+

| Message Layer (CoAP spec / alternative transport) |

+---------------------------------------------------+

|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0Transport Layer (UDP / DTLS / TCP / TLS / SMS)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<= /span>

=C2=A0=

Ciao

Matthias<= u>

=C2=A0

> -----Original Message-----

> From: Kovatsch Matthias [mailt= o:kovatsch@inf.ethz.ch]

> Sent: Thursday, August 06, 2015 9:47 AM=

> To: core WG

> Subject: [core] Common request/response API=

>

> Dear list

>

> In Prague, the problem of a common request/response API for all pos= sible

> transports was raised. We now have something similar in the Califor= nium

> project, where we want to improve the error handling for the CoapCl= ient API as

> well as improve the information flow between Scandium (DTLS) and Ca= lifornium

> (or rather the application code).

>

> As a start, I collected possible exceptions that could signal what = went wrong.

> While this might be a bit Java-centric, the intent is universal: ha= ve a common set

> of signals to tell the application above the request/response API w= hat went

> wrong.

>

> Network layer

> - DestinationNotReachableException

> - PacketTooBigException

>

> Transport layer

> - ConnectionRefusedException

> - AuthenticationException=

> - TooManyOpenFilesException / InsufficientResourcesException (more = OS-

> related, but happens at the socket level)

>

> Application layer

> - TimeoutException / NoReplyException

> - InvalidURIException / InvalidTransportException (alternative tran= sports API)

> - RejectedException (not sure if the same as ConnectionRefusedExcep= tion)

>

> It would be great, if you could have a look, suggest more

> exceptions/signals/error codes, propose thinning/merging, or just c= omment on

> the direction.

>

> Ciao

> Matthias

>

=C2=A0


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

=C2=A0




This body part will be downloaded on demand.

--001a1133af6aeaeaad051d396de0-- From nobody Mon Aug 17 07:09:12 2015 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 1F71C1A03A6 for ; Mon, 17 Aug 2015 07:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6] 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 ny59qZq3YEVD for ; Mon, 17 Aug 2015 07:09:09 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B64E1A03A2 for ; Mon, 17 Aug 2015 07:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t7HE95xo003438 for ; Mon, 17 Aug 2015 16:09:05 +0200 (CEST) Received: from alma.local (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mvy0d5dBfz4vCp; Mon, 17 Aug 2015 16:09:05 +0200 (CEST) Message-ID: <55D1EB00.2050006@tzi.org> Date: Mon, 17 Aug 2015 16:09:04 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.3 (Macintosh/20150805) MIME-Version: 1.0 To: "core@ietf.org WG" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] Publicly accessible Resource Directory? 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, 17 Aug 2015 14:09:11 -0000 Which CoAP resource directories are out there for people to play with? (Sadly, coap.me doesn't have one yet.) Gr眉脽e, Carsten From nobody Wed Aug 19 09:45:27 2015 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 ADBCD1A1A13; Wed, 19 Aug 2015 09:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 eoItztkNnnnQ; Wed, 19 Aug 2015 09:45:24 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57CEC1A1A4B; Wed, 19 Aug 2015 09:45:20 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-03-55d4b29e8679 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A2.5A.05274.E92B4D55; Wed, 19 Aug 2015 18:45:18 +0200 (CEST) Received: from o73.nomadiclab.com (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.210.2; Wed, 19 Aug 2015 18:45:17 +0200 Message-ID: <55D4B29E.7040401@ericsson.com> Date: Wed, 19 Aug 2015 19:45:18 +0300 From: =?windows-1252?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?windows-1252?Q?Christian_Ams=FCss?= References: <20150805185458.GC3989@hephaistos.amsuess.com> In-Reply-To: <20150805185458.GC3989@hephaistos.amsuess.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+Jvje68TVdCDfb807JYfuE5i8W+t+uZ LRZ3TGN0YPbYuv8uk8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJ2XfjKVNAnUfHs1V+2BsYm4S5G Tg4JAROJzvNXWCFsMYkL99azdTFycQgJHGWUeLPqCwuEs45RYuvDNywgVbwC2hLvZl1gBrFZ BFQlbjz7zg5iswk4Stx++BJskqhAisSzJbuZIOoFJU7OfALUy8EhIuApsXmuKkiYWUBY4tXq BWwgtrCAssSJbevAbCEBK4nnCz6A2ZwC1hKvzixhA2llFrCXeLC1DKJVXqJ562xmiHJViav/ XjFOYBSchWTZLISOWUg6FjAyr2IULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIDNqDW36r7mC8 /MbxEKMAB6MSD6/C48uhQqyJZcWVuYcYpTlYlMR5Z2zOCxUSSE8sSc1OTS1ILYovKs1JLT7E yMTBKdXAOLWvh+l0yt51Dup8y1/3/vpzZeoNLuVt8w3UNr4Rml/1sacwVrJOc9r+U9EvbiXX 5nDdqw841/907SeWfWU7rl/NXXfp2bu/xwp/BjwXYi9yqbkq/+Ku7YePJq4zVa49u1FVNmHj UY2G9rqrixfIJ7BFTdgkN3nqXEv5b7cNTEIK45JKCm6tZ1ZiKc5INNRiLipOBADQl3XFOwIA AA== Archived-At: Cc: core@ietf.org Subject: Re: [core] Status of SenML syntax 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, 19 Aug 2015 16:45:25 -0000 Hello Christian, And sorry for the late reply; coming back from vacations and clearing my inbox now. See in-line. On 05/08/15 21:54, Christian Ams黶s wrote: > Hello Ari, hello everybody interested in SenML, > > I've seen the currently pending questions w/rt SenML posed in the IETF93 > slides[1], and the recordings[2] give me the impression that a list > [base dict, values, updating base dict, more values] is the way to go. At the meeting we seemed to have support for this, and no one objecting, but of course we're still looking forward for more feedback on the list. > Would you accept patches to update the sections on JSON and CBOR > serializations and the examples? (If so, which is the master file to > patch, the markdown or the XML?) For sake of discussion (unless it's a typo or other very simple fix), I think it's better if you propose new text here on the list. Currently the XML at the SVN is the latest, but there was discussion that maybe we want to continue with github and/or markdown. No firm decisions yet on this. > Some points have been raised in the discussion I'd like to ask about / > comment on: > > * Concerning "be consistent on being streamable" / order of items inside > an event: Has there been further discussion on this afterwards? I do > see the necessity in certain use cases (think {'sv':'...much > text','n': oh that's where this all should have gone}), even though > I'd figure they are rare; has a suggestion on how to deal with this > been proposed? There hasn't been discussion on this after the meeting except that couple of folks expressed their support for the approach and mentioned that they would go back to home organization and get feedback from their developers. We didn't actually yet think about very long string values. Technically you're right that it could also cause similar issues, but in practice I think it would be a corner case of a corner case and hence I'd rather keep it as such. Would welcome more comments on this though. > Unlike the base value case, this affects the XML representation as > well. Maybe this is another reason for not doing that change. > * "It's usually not gigabytes": Just a side note -- my proxy for sleepy > devices is using SenML for backup and replication purposes. > Extrapolating, the largest SenML involved will hit the gigabyte in a > few months. Interesting. I'd be inclined to say that perhaps SenML is not the right (or at least best) format then, but I'd be interested to hear more why you decided to use SenML for this. > * A google monitoring format has been mentioned that is similar to > SenML; could I have some context on that? I'm not expert on that topic, so I'll leave this for other folks to answer. Cheers, Ari > Best regards > Christian > > > [1] https://www.ietf.org/proceedings/93/slides/slides-93-core-0.pdf > [2] http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF93_CORE_II&chapter=chapter_1 starting at 1:18 > From nobody Wed Aug 19 10:00:47 2015 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 76B381A1B27 for ; Wed, 19 Aug 2015 10:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 sIQvh7OhrAn7 for ; Wed, 19 Aug 2015 10:00:42 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99081A1AA3 for ; Wed, 19 Aug 2015 10:00:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,711,1432591200"; d="scan'208,217";a="143267477" Received: from rosaparks.irisa.fr ([131.254.11.68]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 19 Aug 2015 19:00:28 +0200 Message-ID: <55D4B62C.6020201@irisa.fr> Date: Wed, 19 Aug 2015 19:00:28 +0200 From: =?UTF-8?B?VmlobyBDw6lzYXI=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: core@ietf.org Content-Type: multipart/alternative; boundary="------------040401020805000104060000" Archived-At: Cc: Anthony Baire , Miguel Angel Reina Ortega , William Bertier Subject: [core] New version of IRISA CoAP interop testing tool 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, 19 Aug 2015 17:00:45 -0000 This is a multi-part message in MIME format. --------------040401020805000104060000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello all, I would like to inform you that we (IRISA/TIPI group) have updated our passive interoperability testing tool with the latest version of the CoAP protocol: CORE (RFC7252), BLOCK (draft-ietf-core-block-17) and OBSERVE(draft-ietf-core-observe-16). It implements the test scenarios of the ETSI CoAP Plugtest 2014 in London and also new ETSI tests as well as new tests developed by our IRISA/Tipi group (12 tests for CORE, 2 tests for BLOCK, 3 tests for OBSERVE). It performs a passive analysis on a pcap file and finds automatically maps each CoAP conversation to the relevant test objectives described in the test specification. In other words, all you need to do is to provide a capture file in the pcap format and the tool will provide a detailed analysis of its content. I would like to invite to submit your files to our CoAP testing tool at this address: http://senslab2.irisa.fr/coap/ Please do it as soon as possible, and if possible send us your file to help us fixing bugs that may remain. Any other comments are welcome. Thanks in advance. Regards. __ C茅sar VIHO, Professor IRISA/ISTIC-Universit茅 de Rennes I Campus de Beaulieu, 35042 Rennes cedex, France E-mail : Cesar.Viho@irisa.fr, URL: http://www.irisa.fr T茅l. : +33.2.99.84.74.16, Fax. : +33.2.99.84.71.71 --------------040401020805000104060000 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello all,

I would like to inform you that we (IRISA/TIPI group) have updated our passive interoperability testing tool with the latest version of the CoAP protocol: CORE (RFC7252), BLOCK (draft-ietf-core-block-17) and OBSERVE(draft-ietf-core-observe-16). It implements the test scenarios of the ETSI CoAP Plugtest 2014 in London and also new ETSI tests as well as new tests developed by our IRISA/Tipi group (12 tests for CORE, 2 tests for BLOCK, 3 tests for OBSERVE).

It performs a passive analysis on a pcap file and finds automatically maps each CoAP conversation to the relevant test objectives described in the test specification. In other words, all you need to do is to provide a capture file in the pcap format and the tool will provide a detailed analysis of its content.

I would like to invite to submit your files to our CoAP testing tool at this address: http://senslab2.irisa.fr/coap/

Please do it as soon as possible, and if possible send us your file to help us fixing bugs that may remain.
Any other comments are welcome.

Thanks in advance.
Regards.
__
C茅sar VIHO, Professor
IRISA/ISTIC-Universit茅 de Rennes I
Campus de Beaulieu, 35042 Rennes cedex, France
E-mail : Cesar.Viho@irisa.fr, URL: http://www.irisa.fr
T茅l. : +33.2.99.84.74.16, Fax. : +33.2.99.84.71.71


--------------040401020805000104060000-- From nobody Wed Aug 19 17:26:17 2015 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 3BE4D1A890F for ; Wed, 19 Aug 2015 17:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qw5pgDF2al3h for ; Wed, 19 Aug 2015 17:26:13 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3381A0111 for ; Wed, 19 Aug 2015 17:26:13 -0700 (PDT) Received: by lalv9 with SMTP id v9so13006279lal.0 for ; Wed, 19 Aug 2015 17:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kxADSVhZsqw11RfSAfII84jOHql1kAViZJ3OiV4+nKU=; b=ZP6XTpGD7FQglZ7zTwhNuJ2Q0mVgji+E5zYAz19pZPz7WdrP9XUSoS2MdzduS4Zbqm FXRSx6P4m6woAjLngdiTs36ghqpd2l9s+Xijy0rYtDeVGjKgZeUv9LxZ+ytYRTaLxUz4 ZSf+C8ZEJ6xeaiabey5WRJ9Cp/kKv3t2l2Mb7JMR4ijWsPhNRjgbHvQX+ntYoZnr/eCR r8FtvstzsjTz+KulSArDBKitcvJ3SD13RIRMRM8u2JXiR+pCwVkeeheXzq7TsNp/mbYu 3DKD1tROF62gavCwU4hv472Qluugtyfky70cxAiAfYfMFtRadKj1PLs5KWoTw4yuWA8B zf9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kxADSVhZsqw11RfSAfII84jOHql1kAViZJ3OiV4+nKU=; b=B+8HkDbWGIfP35NzOv5ZLRidyJ1aiiuqeBMIRr37wdAJl1fSpfY8vJlcmh0SK6tNP2 sqO4Nr+EtDqWUFRYcsd7HF+ECaEORxQAE7f+JAS6+u5j7WflfD1JsNpmoLMi/N5bPimK Z2Ar6cX2+6smB5SDW1o/9z63imqBRBVzsg2aj2LP9HCkxtkxdOdteghbK9KyPojEJ4Xk KqapcTa9+mlchm7UHcRBx4WGZmXuZsSxugiJou60/k/s+iz+gNKpOSQLJbLwokEXBbuW i3vlM6addcHJUjewbg7Wws9TmTWQlrldjwCujKqUDcQ54QP2axB/sCVYR77viuYiaKaW kzxg== X-Gm-Message-State: ALoCoQkRnZK3j/qXFMHjeoKmuHTbwDt79q8FDmndmdzRRh+vYZRRAsH7VtqnJNN20dSXOfBTB8ri MIME-Version: 1.0 X-Received: by 10.152.27.10 with SMTP id p10mr253268lag.89.1440030371946; Wed, 19 Aug 2015 17:26:11 -0700 (PDT) Received: by 10.114.79.34 with HTTP; Wed, 19 Aug 2015 17:26:11 -0700 (PDT) In-Reply-To: <20150805185458.GC3989@hephaistos.amsuess.com> References: <20150805185458.GC3989@hephaistos.amsuess.com> Date: Thu, 20 Aug 2015 10:26:11 +1000 Message-ID: From: Andrew Mcgregor To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Content-Type: multipart/alternative; boundary=089e0158c9f8c96bda051db3329c Archived-At: Cc: Core Subject: Re: [core] Status of SenML syntax 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, 20 Aug 2015 00:26:15 -0000 --089e0158c9f8c96bda051db3329c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6 August 2015 at 04:54, Christian Ams=C3=BCss wrote: > Hello Ari, hello everybody interested in SenML, > > > > * "It's usually not gigabytes": Just a side note -- my proxy for sleepy > devices is using SenML for backup and replication purposes. > Extrapolating, the largest SenML involved will hit the gigabyte in a > few months. > > * A google monitoring format has been mentioned that is similar to > SenML; could I have some context on that? > I mentioned that as it has some properties that are relevant, mostly that it can be incrementally parsed and/or streamed. The format itself is not really interesting, and presently unpublished (basically just a key-value list, with optional nested labelset-value dictionaries). And you can probably guess that monitoring things at Google means multi-gigabyte single data scrapes are reasonably common, which makes that property important. Keeping monitoring formats streamable reduces the 'datacenter tax'; turns out, a data center is a constrained environment in some ways, not because you don't have the resources, but because you want to minimise use of them for overhead activities to improve the efficiency of the real work. --089e0158c9f8c96bda051db3329c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 6 August 2015 at 04:54, Christian Ams=C3=BCss <= c.amsues= s@energyharvesting.at> wrote:
Hello Ari, hello everybody interested in SenML,

=C2=A0

* "It's usually not gigabytes": Just a side note -- my proxy = for sleepy
=C2=A0 devices is using SenML for backup and replication purposes.
=C2=A0 Extrapolating, the largest SenML involved will hit the gigabyte in a= =C2=A0 few months.

* A google monitoring format has been mentioned that is similar to
=C2=A0 SenML; could I have some context on that?

<= /div>
I mentioned that as it has some properties that are relevant, mos= tly that it can be incrementally parsed and/or streamed.=C2=A0 The format i= tself is not really interesting, and presently unpublished (basically just = a key-value list, with optional nested labelset-value dictionaries).
<= div>
And you can probably guess that monitoring things at Goo= gle means multi-gigabyte single data scrapes are reasonably common, which m= akes that property important.=C2=A0 Keeping monitoring formats streamable r= educes the 'datacenter tax'; turns out, a data center is a constrai= ned environment in some ways, not because you don't have the resources,= but because you want to minimise use of them for overhead activities to im= prove the efficiency of the real work.
--089e0158c9f8c96bda051db3329c-- From nobody Thu Aug 20 03:25:31 2015 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 0A6141A8A7F for ; Thu, 20 Aug 2015 03:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.528 X-Spam-Level: * X-Spam-Status: No, score=1.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, T_RP_MATCHES_RCVD=-0.01] 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 qd3PkRjsg6pe for ; Thu, 20 Aug 2015 03:25:26 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id EE5821A89AC for ; Thu, 20 Aug 2015 03:25:25 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 7AC5019F806 for ; Thu, 20 Aug 2015 18:25:24 +0800 (HKT) Received: from WeiGengyuPC (unknown [123.113.93.204]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id DD7F619F7C6; Thu, 20 Aug 2015 18:25:23 +0800 (HKT) Message-ID: From: "weigengyu" To: =?UTF-8?B?6rOg7ISd6rCR?= , "Hannes Tschofenig" , "Simon Lemay" References: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> <55CBACAD.9090401@gmx.net> <557A6C8AF976114EBAD8852183CF3F371D7A5A0A@SMTP1.etri.info> In-Reply-To: <557A6C8AF976114EBAD8852183CF3F371D7A5A0A@SMTP1.etri.info> Date: Thu, 20 Aug 2015 18:25:13 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: core@ietf.org Subject: Re: [core] Lenght shim 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, 20 Aug 2015 10:25:29 -0000 Hi all, I have a question on this and a suggestion. If the case of CoAP is only over TCP, option A is OK. But if the usage senario is that there are three nodes; C is a CoAP client, S is a CoAP server, and I is an intermediary. CoAP Client -------------- Intermediary --------------- CoAP Server C I S Suppose, transport layer protocol between C and I is TCP and that beween I and S is UDP. If all the CoAP messages between C and I are NON, which message between I and S shoule be CON? If the intermediary works as a proxy/application gateway, it can make a meassage, but it has not any knowledge about the message type form the received meassage. It is clear that the way of opion A is to add a prefix of CoAP message, this suggestion is to add two more attributes in the prefix. E 2bits and TMB 2bits. E is effective, 1 is effective and 0 is not. TMB is type mask bit, it is use to overload T that the type attribute in CoAP message when E is effective. So, the suggesting message format is the prefix + message format of RFC7252. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ML Message Length | E |TMB| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| T | TKL | Code | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token (if any, TKL bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ And I do not think that the message ID of RFC7252 needs omitting. This is because when running CoAP over TCP, the networks mostly are less-constraint or not constrainted networks. 2Byte (16bits) message ID would not be concerned as overheads. And it brings conveniece for intermediary to do message process. The CoAP client can work as RFC7252 defined. Before delivering to the transport layer, if the underneath layer is TCP, a reliable transport facility, it add the prefix, ML, E=1 and TMB=01; For the Intermediary, if the incoming message is received over TCP, a reliable transport facility, do precessing by the prefix functions. As E=1 and TMB=01, it means NON. If the inermediary is an application proxy or application gateway, for forwarding the message it could delete the prefix, then deliver over UDP. For the server in the constrained networks, do works as RFC7252 defined. Regrads, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----鍘熷閭欢----- From: 瓿犾劃臧 Sent: Thursday, August 13, 2015 10:49 AM To: Hannes Tschofenig ; Simon Lemay ; core@ietf.org WG Subject: Re: [core] Lenght shim Hello. I prefer option A, too. TO cover Option A, I think we can add the similar method of Option format in CoAP to extend Length Shim field. 0~65532 Length shim, no extended Length 65533 4byte extended Length field + 65533 65534 8byte extended Length field + 4295032829 (2^32+65533) 65535 reserved - Softgear Ko -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, August 13, 2015 5:30 AM To: Simon Lemay ; core@ietf.org WG Subject: Re: [core] Lenght shim Hi Simon, I discussed this with my co-workers and we prefer option A. We like it because of the simpler nature because option B really changes the semantic of the CoAP header. Ciao Hannes On 07/27/2015 04:47 PM, Simon Lemay wrote: > Hi, > > So after the meeting on Friday, a few of up stayed to talk about the > different alternatives on how to represent the length information in > CoAP over TCP (reliable transport) > > 2 option came out of the meeting. > > ??????????????????- > Option A > 2 byte shim with new Blocking option for bigger application layer > fragmentation > > This would consists of 2 bytes (16 bits) giving a max length of 64kb. we > would also add a new size option in the block size for FFFF (minus the > header). > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length Shim |Ver| T | TKL | Code | Token (TKL > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | bytes) ... | Options (if any) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1 1 1 1 1 1 1 1| Payload (if any) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The new blocksize needs to be a clean fraction of the 1024byte block. > This is needed for proxying blocksize across different transport layer. > > Pros: > -easy to manage > -can be remove is faming is not needed -application layer > fragmentation helps with multiplexing request > > > > Cons > -Does not support larger than 16 bits. > -could not do streaming > > > ??????????????????- > Option B > Option like split length with a no length option for reliable > transport that already have a framing > > The initial byte of the frame contains two nibbles, in a similar way > to the CoAP option encoding (Section 3.1 of [RFC7252]). The first > nibble is used to indicate the length of the options (including any > option delimiter), and the payload (if any); it does not include the > Code byte or the Token bytes. The first nibble is interpreted as a > 4-bit unsigned integer. A value between 0 and 12 directly indicates > the length of the options/payload, in bytes. The other three values > have a special meaning: 13: An 8-bit unsigned integer follows the > initial byte and indicates the length of options/payload minus 13. 14: > A 16-bit unsigned integer in network byte order follows the initial > byte and indicates the length of options/payload minus 269. 15: A > 32-bit unsigned integer in network byte order follows the initial byte > and indicates the length of options/payload minus 65805. 16: no > framing. The second nibble of the initial byte indicates the token > length. Example: 01 43 7f is a frame just conta ining a 2.03 code with the token 7f. > > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Len | TKL | Len+ bytes... | Code | TKL bytes ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Options (if any) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1 1 1 1 1 1 1 1| Payload (if any) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Pros: > -supports larger payload > -flexible (dynamic payload size) > -removed the Message Type field > > > Cons: > -Large message might be difficult to parse or flush for more constraint > node. > -cannot be removed if underlining implementation does not need framing > > Let me know what you guys think, any pro or cons missing and what we > should process to > > Cheers > > Simon > > > > > _______________________________________________ > 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 Aug 20 06:20:07 2015 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 3062E1ACE52 for ; Thu, 20 Aug 2015 06:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 T6JWA5MQ3_M3 for ; Thu, 20 Aug 2015 06:20:03 -0700 (PDT) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0891ACE51 for ; Thu, 20 Aug 2015 06:20:03 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.216]) by smtp-cloud3.xs4all.net with ESMTP id 71Ky1r00A4fjQrE011KyfY; Thu, 20 Aug 2015 15:20:01 +0200 Received: from [2001:983:a264:1:5c89:1c3c:793f:84f2] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 20 Aug 2015 15:19:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 20 Aug 2015 15:19:58 +0200 From: peter van der Stok To: weigengyu Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> Message-ID: <2816f991f83545899bfd5622e7610f53@xs4all.nl> X-Sender: stokcons@xs4all.nl (C7pB+HSUAHIgnBE/XFXP1gWvFHrOVIv/) User-Agent: XS4ALL Webmail Archived-At: Cc: core@ietf.org Subject: Re: [core] Patch idempotent? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 13:20:06 -0000 Hi all, It seems that people want one coap Patch command, which is preferably idem potent to facilitate application development. On the other hand some people express the wish to have the opportunity to write non idem potent patch services. I propose to change the text in the Coap patch draft to: The Patch method is RECOMMENDED to be idem-potent such that replace, add, and delete operations, as specified in RFC7396, can be executed in an idem-potent fashion with the caveats with respect to add and delete operations as mentioned in RFC 6902 appendices. Any dissatisfaction with this text? Peter weigengyu schreef op 2015-07-29 11:22: > HI Peter, > > It seems not to be a critical issue to be idempotent. > Probably, conditional request can handle this issue. > > In RFC5789, > "PATCH is neither safe nor idempotent as defined by [RFC2616], Section > 9.1." > "A PATCH request can be issued in such a way as to be idempotent, > which also helps prevent bad outcomes from collisions between two > PATCH requests on the same resource in a similar time frame. > Collisions from multiple PATCH requests may be more dangerous than > PUT collisions because some patch formats need to operate from a > known base-point or else they will corrupt the resource. Clients > using this kind of patch application SHOULD use a conditional request > such that the request will fail if the resource has been updated > since the client last accessed the resource. For example, the client > can use a strong ETag [RFC2616] in an If-Match header on the PATCH > request." > > In RFC 6902, it is not mention to be idempotent. > "JavaScript Object Notation (JSON) [RFC4627] is a common format for > the exchange and storage of structured data. HTTP PATCH [RFC5789] > extends the Hypertext Transfer Protocol (HTTP) [RFC2616] with a > method to perform partial modifications to resources." > "JSON Patch is a format (identified by the media type "application/ > json-patch+json") for expressing a sequence of operations to apply to > a target JSON document; it is suitable for use with the HTTP PATCH > method." > > > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----鍘熷閭欢----- From: peter van der Stok > Sent: Tuesday, July 28, 2015 5:42 PM > To: Core > Subject: [core] Patch idempotent? > > Hi all, > > During the CoRE meeting on friday, the suggestion was done that an > idem-potent patch in CoAP should be called iPatch and that Patch itself > is not necessarily idempotent. > > I can identify 2 reasons why patch should not be idempotent: > > 1) the patch adds new sections to a resource and is not idem-potent > when > for example new sections are identified by invocation date and time. > 2) the patch changes the content of the resource as function of the > resource state e.g. incrementing its values > > Other possibilities, not identified by me, may exist. > > 3) An idempotent Patch can be restricted to replacing a subset of the > variables in the resource to the same subset with possibly different > values. > > RF6902 restricts its operations to add, remove, move, copy, replace. > The way the operations add, remove, replace are specified in 6902 > implies their idem-potency; copy and move are not because dependent on > the resource state. > > RFC7396 supports only the operations add, remove and replace, and is > consequently an idem-potent format. > > My proposal is to specify Patch for CoAP to be non-idempotent > conforming > to the http interpretation. > This being said, we can add a new method to CoAP, called "iPatch", > which > is idem-potent and probably fulfils what most applications want Patch > to > do (RFC7396 semantics). > > The Patch command could then also include RPC semantics like toggle, or > INC(x), or actuator settings, currently excluded by an idem-potent PUT > in CoAP. > > Looking forward to other opinions, > > peter From nobody Tue Aug 25 05:51:11 2015 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 4F4B21B2F71 for ; Tue, 25 Aug 2015 05:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 a06Q0nVBHVxO for ; Tue, 25 Aug 2015 05:51:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F2D1B2F67 for ; Tue, 25 Aug 2015 05:51:08 -0700 (PDT) Received: from [192.168.131.139] ([80.92.122.31]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Mfn40-1Z748d2FXg-00NAbH; Tue, 25 Aug 2015 14:50:53 +0200 Message-ID: <55DC64AE.1030105@gmx.net> Date: Tue, 25 Aug 2015 14:50:54 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: weigengyu , =?UTF-8?B?6rOg7ISd6rCR?= , Simon Lemay References: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> <55CBACAD.9090401@gmx.net> <557A6C8AF976114EBAD8852183CF3F371D7A5A0A@SMTP1.etri.info> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="78jbeNQ7Fqvu88cWCWj3dt8bWak76fTtL" X-Provags-ID: V03:K0:EkztyOxaLe+aoWZntVm4HWJk/Ud9jQBfTZYm2o+GBHpt7Kt7G0T MXP9PJEHgbSZxoKRJx2cm3343ryCd6Pbh7FukPT90qLz3uarjRUgifGgvGbfS0SkZpVsMME R7Txp8LKevz/gsY+R0IJo1ag4sVTdphn3QgOrjun+wneF7gTaUWjshdfSwEEZNI2ZyvP8Rc byxuM4KGzrUBLV5QlH6+w== X-UI-Out-Filterresults: notjunk:1;V01:K0:rxHb9a1ZghY=:Xn+OpI0AE1tLN/xh2CnWKT 9r9lHJdKAqfIbVh3D5gVglqgjoZ+Tv6znJ2NXMru1YZ4Xd63hMCUSw+51tapeRdTstpxEXwcO Gp368ezHgUqjpr4Mh/UKlVV6g54NSZUbf6/CYU4t4jQcgsL4Oj/kSZUNHbUag+k48zKoQtqLZ uD259FC3/LhoTeJwHyunwhODW9NH2QUV8kicVtL2RtCyFkfDYgPnB+wl6E0HLxrgWbnf3Br9S +0qF3exlE0t28AtAc47KNS2KbtUDlt7zncUB37d3k50meuFScPNQoK7JqKvCoqZX5iY2Ok0XQ pAdoONt637xg/+ebFzjjQF1ZMW+b3YA+sCcBbkS8IesBKzNcbqSiOH8wbR5bCe7sPt/kRI24h 8gEzgVBDN9qQjq+xd6de+Gc3sMcXPJrrhnRXq8wBcWdrphEi0Bug71ThzWdUpmY5OZVTk6cOx I7xOJC7omStf3O5E+xwiuHKLPpBAGZpCGbqm3yauWgFfa/FmkxJKjr3bp/w0xhqXvt5ozleQW bYnCJymDvroIyqdpX28JZUEEGAKn4fP4ntx/CT4nG1D99EO3KO7XbJUIR24HPxP04rqBGcb55 PkQNTB+sAqpVkfS+O1TvbY11BtTFcBR+SV2mKnf8qDEImXPFebf+cjiy1EB2610Bh4nbMiUKF fFn1pt8Pf2rSaN3r50ISCr/PVJNgmGEwmLlSY3PTwaJ7tv0RnH06k0kWB5pd/PDJId/zJa/XZ U1XttG8145SHCRa4 Archived-At: Cc: core@ietf.org Subject: Re: [core] Lenght shim 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, 25 Aug 2015 12:51:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --78jbeNQ7Fqvu88cWCWj3dt8bWak76fTtL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Gengyu, thanks for your response and the question you raised. Here is my impression about what happens in this case: On 08/20/2015 12:25 PM, weigengyu wrote: > But if the usage senario is that there are three nodes; > C is a CoAP client, S is a CoAP server, and I is an intermediary. > CoAP Client -------------- Intermediary --------------- CoAP Ser= ver > C I S >=20 > Suppose, transport layer protocol between C and I is TCP and that bewee= n > I and S is UDP. > If all the CoAP messages between C and I are NON, > which message between I and S shoule be CON? The CoAP client would use TCP with the gateway and the data transfer would be transmitted reliably due to the nature of TCP (regardless of what CoAP says). Then, when the data is at the gateway a new CoAP over UDP message would be created and sent to the CoAP server. For the CoAP client the interaction with the CoAP server isn't visible since the entire communication terminates at the gateway. As such, the gateway needs to have some application level knowledge to know whether the application demands reliable transport or not. I see two possible approaches: 1) The gateway assumes that the use of TCP between the client and itself is an indication that the client wants reliable data transfer and therefore would replicate this functionality also in the exchange of data between the gateway and the server. It would therefore use CON. 2) The gateway re-uses whatever is conveyed in the CoAP message. For example, if the CoAP message from the client is a CON then it would be a CON also on the other side. Do you believe the draft should recommend one way or should this be left open for deployments to choose? Ciao Hannes --78jbeNQ7Fqvu88cWCWj3dt8bWak76fTtL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV3GSuAAoJEGhJURNOOiAtSrEIAJalVi/tEnMduKsP0sntVaWM s4Zpnw7Crf9OgX6ieFM5JHsM5Ic0ctAF/5/ev6uYiaaptDovCg1AZrl7JovyniW+ +EJ5hrJZGjEHULvyDNinhPtDipGl7RRaWax30c0PtsNXcfnIkyD7J9nUJ09uBmUh Q4kg4Py028DmLswUDEZ6s5n7J10LzHZpV8nAToy1CdLgJYlwRt7SOLCyNcGeWXBb vZaGk5zxylRWklTQLbjcLuwMNo0Nr01sfJMovEDC/Iq5wR2xepSjSvWmRp9dC0By NIMSbQdE6ASPtSusG4PcbPA5hE6CUw8UIC+rKZPNu/TN1SsBsyAZBfq52iG8jrc= =QZCl -----END PGP SIGNATURE----- --78jbeNQ7Fqvu88cWCWj3dt8bWak76fTtL-- From nobody Tue Aug 25 08:21:34 2015 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 B07D41B331E for ; Tue, 25 Aug 2015 08:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.111 X-Spam-Level: X-Spam-Status: No, score=-13.111 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.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 acfyaEG3XguA for ; Tue, 25 Aug 2015 08:21:31 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F071B306C for ; Tue, 25 Aug 2015 08:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3553; q=dns/txt; s=iport; t=1440516091; x=1441725691; h=reply-to:subject:references:to:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=iQotvLYwpFPoTl/o2la4ZbJEY7Poprm7E16NLqn2YiY=; b=jhO2ZVWjQtdd47T3jDsKUvpcoYNIzudbS78HrvARDA2It2oJXZ+Koj0Z NE8hhrZmlb/Zb7pnnnvZG8irvtACjXI6ab9XX76azWpRDR4NJ2ztwTVS6 qWnPNDpRoasTt6HcStLrLUBHGG5qw6sV0GmnJQRkM6tUtVr97JqmC2Hjd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BVBQA3h9xV/4cNJK1TCoMbVIQOwAqCWAKBMjsRAQEBAQEBAYEKhCMBAQEEIw8BBUARCQIRBAEBAQICBRYLAgIJAwIBAgE9CBADCAEBiCqVVp0dhliOPQEBAQEBAQQBAQEBHoEiijWELRRQgmmBQwEElTeMcoFKhDKCeZFfJoIOHIFwIoE5gUYBAQE X-IronPort-AV: E=Sophos;i="5.15,746,1432598400"; d="scan'208";a="21464188" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP; 25 Aug 2015 15:21:30 +0000 Received: from [10.86.254.181] ([10.86.254.181]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t7PFLT32014387 for ; Tue, 25 Aug 2015 15:21:30 GMT References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> To: core@ietf.org From: Paul Duffy Organization: Cisco Systems Message-ID: <55DC87F9.2060901@cisco.com> Date: Tue, 25 Aug 2015 11:21:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] Patch idempotent? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 15:21:32 -0000 Please try to maintain consistency with 5789 PATCH. This to ease translation between HTTP and CoAP. On 7/29/2015 5:22 AM, weigengyu wrote: > HI Peter, > > It seems not to be a critical issue to be idempotent. > Probably, conditional request can handle this issue. > > In RFC5789, > "PATCH is neither safe nor idempotent as defined by [RFC2616], Section > 9.1." > "A PATCH request can be issued in such a way as to be idempotent, > which also helps prevent bad outcomes from collisions between two > PATCH requests on the same resource in a similar time frame. > Collisions from multiple PATCH requests may be more dangerous than > PUT collisions because some patch formats need to operate from a > known base-point or else they will corrupt the resource. Clients > using this kind of patch application SHOULD use a conditional request > such that the request will fail if the resource has been updated > since the client last accessed the resource. For example, the client > can use a strong ETag [RFC2616] in an If-Match header on the PATCH > request." > > In RFC 6902, it is not mention to be idempotent. > "JavaScript Object Notation (JSON) [RFC4627] is a common format for > the exchange and storage of structured data. HTTP PATCH [RFC5789] > extends the Hypertext Transfer Protocol (HTTP) [RFC2616] with a > method to perform partial modifications to resources." > "JSON Patch is a format (identified by the media type "application/ > json-patch+json") for expressing a sequence of operations to apply to > a target JSON document; it is suitable for use with the HTTP PATCH > method." > > > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----鍘熷閭欢----- From: peter van der Stok > Sent: Tuesday, July 28, 2015 5:42 PM > To: Core > Subject: [core] Patch idempotent? > > Hi all, > > During the CoRE meeting on friday, the suggestion was done that an > idem-potent patch in CoAP should be called iPatch and that Patch itself > is not necessarily idempotent. > > I can identify 2 reasons why patch should not be idempotent: > > 1) the patch adds new sections to a resource and is not idem-potent when > for example new sections are identified by invocation date and time. > 2) the patch changes the content of the resource as function of the > resource state e.g. incrementing its values > > Other possibilities, not identified by me, may exist. > > 3) An idempotent Patch can be restricted to replacing a subset of the > variables in the resource to the same subset with possibly different > values. > > RF6902 restricts its operations to add, remove, move, copy, replace. > The way the operations add, remove, replace are specified in 6902 > implies their idem-potency; copy and move are not because dependent on > the resource state. > > RFC7396 supports only the operations add, remove and replace, and is > consequently an idem-potent format. > > My proposal is to specify Patch for CoAP to be non-idempotent conforming > to the http interpretation. > This being said, we can add a new method to CoAP, called "iPatch", which > is idem-potent and probably fulfils what most applications want Patch to > do (RFC7396 semantics). > > The Patch command could then also include RPC semantics like toggle, or > INC(x), or actuator settings, currently excluded by an idem-potent PUT > in CoAP. > > Looking forward to other opinions, > > peter > > > From nobody Tue Aug 25 09:06:58 2015 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 591951B34F5 for ; Tue, 25 Aug 2015 09:06:57 -0700 (PDT) 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] 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 cBYKVmRkkvz3 for ; Tue, 25 Aug 2015 09:06:55 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE821B34D8 for ; Tue, 25 Aug 2015 09:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t7PG6dBf028377; Tue, 25 Aug 2015 18:06:39 +0200 (CEST) Received: from alma.local (p5DC7F76C.dip0.t-ipconnect.de [93.199.247.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3n0wDb1pRWz4vkN; Tue, 25 Aug 2015 18:06:39 +0200 (CEST) Message-ID: <55DC928D.6070604@tzi.org> Date: Tue, 25 Aug 2015 18:06:37 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.3 (Macintosh/20150805) MIME-Version: 1.0 To: consultancy@vanderstok.org References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> <2816f991f83545899bfd5622e7610f53@xs4all.nl> In-Reply-To: <2816f991f83545899bfd5622e7610f53@xs4all.nl> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core@ietf.org Subject: Re: [core] Patch idempotent? 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, 25 Aug 2015 16:06:57 -0000 As Paul said, we need to position ourselves with respect to HTTP's PATCH. Whatever we call PATCH will have to work like HTTP's PATCH. Saying that PATCH is "recommended" to be idempotent is essentially identical to saying it's not -- an implementation will not be able to rely on this behavior if it is just recommended. We might as well mirror HTTP and completely forget about this idempotency simplification. Origin server implementers may still be able to derive idempotency from the properties of the patch media type. However, I don't buy the argument that adding two methods makes things more complex -- nothing is more complex than having to guess what was meant. Saying it in plain language (e.g., spelling out either a PATCH method with no idempotency guarantees or an IPATCH method that does guarantee idempotency) makes the life of the implementer much simpler. (On simple servers, I would actually only implement IPATCH.) Gr眉脽e, Carsten peter van der Stok wrote: > > Hi all, > > It seems that people want one coap Patch command, which is preferably > idem potent to facilitate application development. > On the other hand some people express the wish to have the opportunity > to write non idem potent patch services. > > I propose to change the text in the Coap patch draft to: > > The Patch method is RECOMMENDED to be idem-potent such that replace, > add, and delete operations, as specified in RFC7396, can be executed in > an idem-potent fashion > with the caveats with respect to add and delete operations as mentioned > in RFC 6902 appendices. > > Any dissatisfaction with this text? > > Peter > > > weigengyu schreef op 2015-07-29 11:22: >> HI Peter, >> >> It seems not to be a critical issue to be idempotent. >> Probably, conditional request can handle this issue. >> >> In RFC5789, >> "PATCH is neither safe nor idempotent as defined by [RFC2616], Section >> 9.1." >> "A PATCH request can be issued in such a way as to be idempotent, >> which also helps prevent bad outcomes from collisions between two >> PATCH requests on the same resource in a similar time frame. >> Collisions from multiple PATCH requests may be more dangerous than >> PUT collisions because some patch formats need to operate from a >> known base-point or else they will corrupt the resource. Clients >> using this kind of patch application SHOULD use a conditional request >> such that the request will fail if the resource has been updated >> since the client last accessed the resource. For example, the client >> can use a strong ETag [RFC2616] in an If-Match header on the PATCH >> request." >> >> In RFC 6902, it is not mention to be idempotent. >> "JavaScript Object Notation (JSON) [RFC4627] is a common format for >> the exchange and storage of structured data. HTTP PATCH [RFC5789] >> extends the Hypertext Transfer Protocol (HTTP) [RFC2616] with a >> method to perform partial modifications to resources." >> "JSON Patch is a format (identified by the media type "application/ >> json-patch+json") for expressing a sequence of operations to apply to >> a target JSON document; it is suitable for use with the HTTP PATCH >> method." >> >> >> Regards, >> >> Gengyu WEI >> Network Technology Center >> School of Computer >> Beijing University of Posts and Telecommunications >> -----鍘熷閭欢----- From: peter van der Stok >> Sent: Tuesday, July 28, 2015 5:42 PM >> To: Core >> Subject: [core] Patch idempotent? >> >> Hi all, >> >> During the CoRE meeting on friday, the suggestion was done that an >> idem-potent patch in CoAP should be called iPatch and that Patch itself >> is not necessarily idempotent. >> >> I can identify 2 reasons why patch should not be idempotent: >> >> 1) the patch adds new sections to a resource and is not idem-potent when >> for example new sections are identified by invocation date and time. >> 2) the patch changes the content of the resource as function of the >> resource state e.g. incrementing its values >> >> Other possibilities, not identified by me, may exist. >> >> 3) An idempotent Patch can be restricted to replacing a subset of the >> variables in the resource to the same subset with possibly different >> values. >> >> RF6902 restricts its operations to add, remove, move, copy, replace. >> The way the operations add, remove, replace are specified in 6902 >> implies their idem-potency; copy and move are not because dependent on >> the resource state. >> >> RFC7396 supports only the operations add, remove and replace, and is >> consequently an idem-potent format. >> >> My proposal is to specify Patch for CoAP to be non-idempotent conforming >> to the http interpretation. >> This being said, we can add a new method to CoAP, called "iPatch", which >> is idem-potent and probably fulfils what most applications want Patch to >> do (RFC7396 semantics). >> >> The Patch command could then also include RPC semantics like toggle, or >> INC(x), or actuator settings, currently excluded by an idem-potent PUT >> in CoAP. >> >> Looking forward to other opinions, >> >> peter > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From nobody Wed Aug 26 05:35:49 2015 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 DD6BE1B2C82 for ; Wed, 26 Aug 2015 05:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.412 X-Spam-Level: ** X-Spam-Status: No, score=2.412 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] 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 m4cTS4ITxHgp for ; Wed, 26 Aug 2015 05:35:46 -0700 (PDT) Received: from smtp-in1.interdigital.com (host-64-47-120-121.masergy.com [64.47.120.121]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2FCE1B2C79 for ; Wed, 26 Aug 2015 05:35:45 -0700 (PDT) X-ASG-Debug-ID: 1440592544-06daaa5cf1c0030001-aa7cYp Received: from KYANITE.InterDigital.com (kyanite.interdigital.com [10.1.64.253]) by smtp-in1.interdigital.com with ESMTP id UE1EK3QndVAlXRy0 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Aug 2015 08:35:44 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from KAMACITE.InterDigital.com ([fe80::9d59:a73c:8da:eb0a]) by KYANITE.InterDigital.com ([::1]) with mapi id 14.03.0248.002; Wed, 26 Aug 2015 08:35:43 -0400 From: "Rahman, Akbar" To: "cabo@tzi.org" Thread-Topic: Next steps for HTTP-CoAP Mapping draft? X-ASG-Orig-Subj: Next steps for HTTP-CoAP Mapping draft? Thread-Index: AdDf+pjtB7BqJbGUQsmPDrrFpfrGsA== Date: Wed, 26 Aug 2015 12:35:42 +0000 Message-ID: <36F5869FE31AB24485E5E3222C288E1F347A87BE@KAMACITE.InterDigital.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.2.231] x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd Content-Type: multipart/alternative; boundary="_000_36F5869FE31AB24485E5E3222C288E1F347A87BEKAMACITEInterDi_" MIME-Version: 1.0 X-Barracuda-Connect: kyanite.interdigital.com[10.1.64.253] X-Barracuda-Start-Time: 1440592544 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_MV0713, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.21941 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.50 BSF_SC0_MV0713 Custom rule MV0713 Archived-At: Cc: "core@ietf.org WG" Subject: [core] Next steps for HTTP-CoAP Mapping draft? 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, 26 Aug 2015 12:35:48 -0000 --_000_36F5869FE31AB24485E5E3222C288E1F347A87BEKAMACITEInterDi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Carsten, I hope that you are enjoying the summer. I wanted to ask you what the next= steps are to get to the WGLC of https://tools.ietf.org/html/draft-ietf-cor= e-http-mapping-07 ? We have had quite a few reviews of the document (including your very thorou= gh Chair's review) and I was wondering when we will call the WGLC for the d= raft. Best Regards, Akbar --_000_36F5869FE31AB24485E5E3222C288E1F347A87BEKAMACITEInterDi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Carsten,

 

 

 

I hope that you are enjoying the summer.  I wan= ted to ask you what the next steps are to get to the WGLC of htt= ps://tools.ietf.org/html/draft-ietf-core-http-mapping-07 ?

 

 

We have had quite a few reviews of the document (inc= luding your very thorough Chair’s review) and I was wondering when we= will call the WGLC for the draft.

 

 

Best Regards,

 

 

Akbar

 

 

 

--_000_36F5869FE31AB24485E5E3222C288E1F347A87BEKAMACITEInterDi_-- From nobody Wed Aug 26 08:43:08 2015 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 1CAAE1B379E for ; Thu, 13 Aug 2015 01:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 kLD_DcU7lX0G for ; Thu, 13 Aug 2015 01:57:12 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503E81B3798 for ; Thu, 13 Aug 2015 01:57:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,668,1432591200"; d="scan'208,217";a="173484515" Received: from rosaparks.irisa.fr ([131.254.11.68]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 13 Aug 2015 10:57:10 +0200 Message-ID: <55CC5BE6.9020300@irisa.fr> Date: Thu, 13 Aug 2015 10:57:10 +0200 From: =?UTF-8?B?VmlobyBDw6lzYXI=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: core@ietf.org, IOT_PLUGTESTS@LIST.ETSI.ORG, Laurent Toutain , Baptiste Gaultier , Renzo Navas , archanamcis@gmail.com, UBEDA Stephane , Thomas Watteyne , Frederic Weis , Olivier Barais , Johann Bourcier Content-Type: multipart/alternative; boundary="------------060308000100070705060305" Archived-At: X-Mailman-Approved-At: Wed, 26 Aug 2015 08:43:07 -0700 Cc: Anthony Baire Subject: [core] New version of IRISA CoAP testing tool - (With the good link) 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, 13 Aug 2015 08:57:14 -0000 This is a multi-part message in MIME format. --------------060308000100070705060305 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello all, I would like to inform you that we (IRISA/TIPI group) have updated our passive interoperability testing tool with the latest version of the CoAP protocol: CORE (RFC7252), BLOCK (draft-ietf-core-block-17) and OBSERVE(draft-ietf-core-observe-16). It implements the test scenarios of the ETSI CoAP Plugtest 2014 in London and also new ETSI tests as well as new tests developed by our IRISA/Tipi group (12 tests for CORE, 2 tests for BLOCK, 3 tests for OBSERVE). It performs a passive analysis on a pcap file and finds automatically maps each CoAP conversation to the relevant test objectives described in the test specification. In other words, all you need to do is to provide a capture file in the pcap format and the tool will provide a detailed analysis of its content. I would like to invite to submit your files to our CoAP testing tool at this address: http://senslab2.irisa.fr/coap/ Please do it as soon as possible, and if possible send us your file to help us to fix bugs that may remain. Any other comments are welcome. Thanks in advance. Regards. __ C茅sar VIHO, Professeur IRISA/ISTIC-Universit茅 de Rennes I Campus de Beaulieu, 35042 Rennes cedex, France E-mail : Cesar.Viho@irisa.fr, URL: http://www.irisa.fr T茅l. : +33.2.99.84.74.16, Fax. : +33.2.99.84.71.71 --------------060308000100070705060305 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello all,

I would like to inform you that we (IRISA/TIPI group) have updated our passive interoperability testing tool with the latest version of the CoAP protocol: CORE (RFC7252), BLOCK (draft-ietf-core-block-17) and OBSERVE(draft-ietf-core-observe-16). It implements the test scenarios of the ETSI CoAP Plugtest 2014 in London and also new ETSI tests as well as new tests developed by our IRISA/Tipi group (12 tests for CORE, 2 tests for BLOCK, 3 tests for OBSERVE).

It performs a passive analysis on a pcap file and finds automatically maps each CoAP conversation to the relevant test objectives described in the test specification. In other words, all you need to do is to provide a capture file in the pcap format and the tool will provide a detailed analysis of its content.

I would like to invite to submit your files to our CoAP testing tool at this address: http://senslab2.irisa.fr/coap/

Please do it as soon as possible, and if possible send us your file to help us to fix bugs that may remain.
Any other comments are welcome.

Thanks in advance.
Regards.
__
C茅sar VIHO, Professeur
IRISA/ISTIC-Universit茅 de Rennes I
Campus de Beaulieu, 35042 Rennes cedex, France
E-mail : Cesar.Viho@irisa.fr, URL: http://www.irisa.fr
T茅l. : +33.2.99.84.74.16, Fax. : +33.2.99.84.71.71


--------------060308000100070705060305-- From nobody Thu Aug 27 06:32:25 2015 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 D19AB1A86DF for ; Thu, 27 Aug 2015 06:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_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 aKmK6S5D3HcK for ; Thu, 27 Aug 2015 06:32:21 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::776]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48AC11B38DC for ; Thu, 27 Aug 2015 06:32:15 -0700 (PDT) Received: from AM3PR04CA0037.eurprd04.prod.outlook.com (10.242.16.37) by DB4PR04MB0669.eurprd04.prod.outlook.com (10.141.42.139) with Microsoft SMTP Server (TLS) id 15.1.256.15; Thu, 27 Aug 2015 13:31:56 +0000 Received: from AM1FFO11FD045.protection.gbl (2a01:111:f400:7e00::188) by AM3PR04CA0037.outlook.office365.com (2a01:111:e400:8814::37) with Microsoft SMTP Server (TLS) id 15.1.256.15 via Frontend Transport; Thu, 27 Aug 2015 13:31:56 +0000 Authentication-Results: spf=none (sender IP is 23.103.247.132) smtp.mailfrom=philips.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (23.103.247.132) by AM1FFO11FD045.mail.protection.outlook.com (10.174.65.208) with Microsoft SMTP Server (TLS) id 15.1.256.10 via Frontend Transport; Thu, 27 Aug 2015 13:31:56 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com (141.251.190.18) by HE1PR9001MB0170.MGDPHG.emi.philips.com (141.251.190.18) with Microsoft SMTP Server (TLS) id 15.1.231.21; Thu, 27 Aug 2015 13:31:40 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) by HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) with mapi id 15.01.0231.024; Thu, 27 Aug 2015 13:31:40 +0000 From: "Dijk, Esko" To: "core (core@ietf.org)" Thread-Topic: core-interfaces section 5.2: "toggle" action prescribed for Batch? Thread-Index: AdDgzAhCmRykMa09RDiXE4FX6i+tHA== Date: Thu, 27 Aug 2015 13:31:40 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.109] Content-Type: multipart/alternative; boundary="_000_da51977096684726a6d6944a3facd027HE1PR9001MB0170MGDPHGem_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD045; 1:BU4yfnvkLfwqcOZHgkyqc4JIuTXDLTfyrbHQPc543nkhO96KUp/llfSmi16sNhTj+LkFnBEnKro/UtNigM6H1vz8PA6KZR/09dkWPJX5MX3TM9xuGcZeTa7UTk/12CWc2g1GLeMec+fj+hnkyMHk6g6Dj33hmvEx9oHI6dgk8Bvj+NZkNQlb7nxeEWdn3YKOaHxh6LmHIvclaR3q9erlpUTGRfEICcME63oFBJHISRWNQqW4d+tKVNevT6/xP/E3lmSPPUSpwc39T4cHFEGxhtzJ7rEfKYJ51RH/qRfQGwXdT3WxKY/D6q+/tmfiwHxS X-Forefront-Antispam-Report: CIP:23.103.247.132; CTRY:; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(428002)(189002)(55904004)(85714005)(374574003)(199003)(92566002)(66066001)(110136002)(189998001)(46102003)(101416001)(68736005)(19625215002)(2656002)(106466001)(105586002)(5001920100001)(64706001)(33646002)(84326002)(24736003)(5007970100001)(5003600100002)(77156002)(5004730100002)(16236675004)(16796002)(62966003)(5001960100002)(229853001)(15975445007)(10400500002)(69596002)(102836002)(6806004)(2900100001)(19580395003)(81156007)(108616004)(4001540100001)(5001830100001)(5001860100001)(86362001)(50986999)(512954002)(97736004)(54356999)(19300405004)(87936001)(567094001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR04MB0669; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB4PR04MB0669; 2:ulrApWG3U6Swr7JOVJknuPoR2k2Lp1MK7Q6n7rPb3OKvRNTR2GHbpyeQB+Dfi1vrp0gfWvDPEoaSo4kmN2i1/inY43eX8pNfvo+z6OVnhc0GRCKOcbhcZ3MJV3X8p9eCl17vhBRpXS/jJeleTSz69esKQkc+fW9oqIUqILpVwc4=; 3:nsJaxvKAzvRfAxVBRaIo0lOBpKyqGCVOCEaVf95MhgH440LDx4rrgdth5tShnL2lbp2dX6wVp5QYXw/rt79yU2w0Dn76Dymw1RF++dvjdY5Y+mPNZsoxY68Q5N3IT00Ni7janGTpE8islSRqUlcaYTqZQplK/0gCy2MjlQAVGKcXsqNvVyKdMz82w/mD8fvvHyMaQP8uIycbdTcGGvGVmXn5e6Q1J69fkRiYD249pxg=; 25:ZIuA3vUfIjCAwDQ16EoxDeVgcsdNPAMI8cW3iMuhqrjdoz8nmv1rYVgOhcTUvVHqpl1rB34NVEF2f5TBynxg2izXlkisbiLHdGvX1nC+DzGyFD9owmEsk8WbwHZSfll4kGt3RuOC+D3ioQG4QjQV3LhOo9jwGFT54Az4qalARA1QO4V0AhLUIVQlx/6w8rfxrLjEfSNbtT73wr8+qGx9GDrH/10kDkvB23HK+YbTeEa1xnrRqhrWNrWkTvC5pfIi8yaX1qavg03LBulOaaDl+A== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR04MB0669; X-Microsoft-Exchange-Diagnostics: 1; DB4PR04MB0669; 20:6+Eyl/Gx8xH5F8MNyrByGg+JBz//YJSxf3LpZsnXf/h1uv1gLX4XG4c6WYBbRK+QBRUHWu8PT29U+O825IhScVvlbnmfyy+AWE9rz7oSVKkM5iyVRQSWECEgdg4YRT6oJo9aG39wxWH5MW1zXP2G1RMjQ7MTChSnzzQ4TnLikQfFBw3IKmng0/RwSkB4La0VVyxq+gpX619rQn8hXR/mQTrbTfbmNRetMyFFUCYUYQDa7T5MWO9uHaQutz/u/zLHEznPBAfRge3w4jJsofmUoO3EnFeE8RIZcJt0RpeucDdB+tskdnain6qAJOvmND0W6UdnwRwHi22BXtsmOkkWzaGPlvtEW4KQHu/n7xWPuUYyYbYY3UleX4prepnw0tnwP5ZsG4fPWFW1r1aJC+nCCAIVocuZ7ETb23+GQPg4p+iTfzmz30E8J3m0KNyR+ZBH62Vq2iHD+k/ZTwQ/Ds7mNJlcgcn9Q+def0VeFaqA4XHY3W3JJKZGJP1/r9hVelw0; 4:8xYhIz6bRgF9QOdEjllU9Xa5uyGY2u3FfHPU8VcdlRru/rJZ293uTa08tyn+9WBaHTz5fPcG5K/bQDxuiNGS2kj6MstiLzldLOmesLq56fCa8Q8Q1aZNd/NAqRqKr2d1WPLjplI12WLU/q7fHHYrXOVe34B/oNEpPTXKsQRBaCnJRf5ZDEmVZrLWuPtUAeh5lf+wyje5/0CRxxIjbyGN1waB2VonERD5xEio8e3h83i+NUVpg80GXSlS4F0Qq1NnoYGYIgYNsV/U8yjHKyGcA1eUw2X36e7FfHH7nAYm+Au7FfeStPHgSFtXiqADXN7LwxRqi0I1PssWClIr178GSQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(108003899814671); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:DB4PR04MB0669; BCL:0; PCL:0; RULEID:; SRVR:DB4PR04MB0669; X-Forefront-PRVS: 06818431B9 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB4PR04MB0669; 23:2xxZCF9zOYRl01ohuX8mn4idpjthQCEp8NKevgVSn?= =?us-ascii?Q?W/1iq2JyiQb3SMCmh0qpZAGEb6NF9qIUPrRfbCijhzIUr5uqO23WQznQsYXH?= =?us-ascii?Q?TRPB1rorXAbZsBdENylTw+0T6j/1axNQSRA2PHrYlwarOs3blfzE4bRBSePO?= =?us-ascii?Q?NF/lrEyy1hnQog+CzKJBhCSeXBpte3dFsJiysFH4UK7kSCPJpzP+r0pzSa2n?= =?us-ascii?Q?uUNqXc/DxueNWMPgdMhblk7wFL7HSSMpqShBaUGTV3VbWu2BrvQwFbkIYR4x?= =?us-ascii?Q?KrUqUTJ0atKgJDUDfUb4OeuvilHPDmsQ0pfXYw3ehvMv3rZoVTyalnUW87Mw?= =?us-ascii?Q?+M772pGMBTwXrjwXVtpTRFnTreNo4KAiBkS6ZjhK4tY2sv1b7vLdQlcM/5MJ?= =?us-ascii?Q?zLxrJsL+8xy1bKN7njuZ4rOVFtxx1Vl28Qk6r6UhVNo0pzPRUI1tzxY2Iwxv?= =?us-ascii?Q?4bhcKLqtSqMjXOwh5HGBI8n10JXd1tn0WEZkYJ1skICzn7V8e8b2FXq4rkgO?= =?us-ascii?Q?KhiWSv6Pe7bZAA61iDgnaJfzPPCvK5p0QBegDanOY6GOSEyqkHXE2JaOCYKK?= =?us-ascii?Q?lafoFIvNwmqomYdNplylILlnaCrx8CP8UmHt1rfI8BJwiZlbAJwqCOB0VLLc?= =?us-ascii?Q?oRXwjgIQ7w6WMXSKqzyaMuQFde+ISSKqM5Ze6nm9zx8aRjxuw+wJTRMpbnN1?= =?us-ascii?Q?lmGZLn7yFF+Wg+gzJlRU7C65QDYiOC/U8QbvqJcOhN+GTMlqm0NbWezUJ+JM?= =?us-ascii?Q?93I2av0dcE6kGffP3dWV9yNBnfDpioe0QG99gMpkd8ZVOnKWHK3q0TVsAqsC?= =?us-ascii?Q?CqKB917E04R9gEYv6z3nf6/gzSqq8HesTiICOh3TsPWpfN7lrZjJ7sClbDM3?= =?us-ascii?Q?0s2n6j4prsRywwE8BhTvIHFO/ln5vYDg6tL78CFUuhyg91j36yR1U0mvDfPm?= =?us-ascii?Q?rYafQpREOo25rP14bfws19LrkeVhDJNhB9IyBXzzap/FB7UwlwTL6tnB4xqF?= =?us-ascii?Q?xtDy0RYaqSJUL3c6J0wXBN+L/Hl0oBo0EWDgDYVm08qiwxlJtdGzl962h7M/?= =?us-ascii?Q?Kpa2u+J3A0ftx9T71OJ3DjKE8rlN0G67UEhcxqhhiYxZpYxahZtvv1gpBFqW?= =?us-ascii?Q?vv7a9ls0hYUVi7ikJLTpuWSuEh0hHLL4cky2JEeyt8itPFQPCtbQ4/69MCnh?= =?us-ascii?Q?U+pulqy583DIDcPOCcBVcMUgtrKbhnDQ2/x/kUqwUpUDXu6V4TfIjZocPafx?= =?us-ascii?Q?EAeDYG380v+QPid2CopIE/dg3/sBbQPYOEdFmIl1jHqlE+LsYVbKD8IfzQm8?= =?us-ascii?Q?u8614WqiL3yL+8zAOyCTRPRCgNOkVR+C2eaEKUCnF/OKnWAE6fIjEOCzNqHC?= =?us-ascii?Q?860rNrqEu4xDfZgm9AAAHELHt8Sv+IHb1julAepTqry2j/x5K6EJWA5aW5H4?= =?us-ascii?Q?OMoj7l0NQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB4PR04MB0669; 5:09ZT5aHVRKafB3P2nEPGCDJhIssK7NeQV1VcfF70iJOLbx5BOPoKHSnV8X/4WIyYn0cJu2vKfHnRMVo5KB6N8y3tyjGEz64s5wfRFEtlMAQhn7OjV5jv6l1u0+6QEAGIks0vmfkLvfzBGumF0GIVLw==; 24:vwdSXMG38H7CXWdy2J8QKJuFFQZHt0PCss8Jw13EHyeC8omJns9BN+ZLLKGspX8s0jBR0gN8pDX4LzFsJ03LJ3LsrMallZFjxBbzfwwEwTU=; 20:GwoXkq+A/6UkVGpAlOp10h877MuoEd13rTAoRf471W9rqadA6HATpL3o5lhfohw0TrYTc37QKWsUOLwcYYKNfQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2015 13:31:56.2550 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.132]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR04MB0669 Archived-At: Subject: [core] core-interfaces section 5.2: "toggle" action prescribed for Batch? 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 Aug 2015 13:32:24 -0000 --_000_da51977096684726a6d6944a3facd027HE1PR9001MB0170MGDPHGem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, authors of core-interfaces, I was surprised reading in section 5.2 that a POST on a Batch resource woul= d always be interpreted as a "toggle" action on all its sub-resources. Is t= his intended? Rather I would vote for a POST being translated to the same POST executed o= n all sub-resources that support it - which would for actuator resources tr= anslate into a toggle action. But for other resource types (which may be de= fined in the future, or may be standard-specific, etc.) the POST could take= on a different meaning. I can create a ticket for this. Regards Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_da51977096684726a6d6944a3facd027HE1PR9001MB0170MGDPHGem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all, authors of core-interfaces,

 

I was surprised reading in section 5.2 that a POST o= n a Batch resource would always be interpreted as a “toggle” ac= tion on all its sub-resources. Is this intended?
Rather I would vote for a POST being translated to the same POST executed o= n all sub-resources that support it – which would for actuator resour= ces translate into a toggle action. But for other resource types (which may= be defined in the future, or may be standard-specific, etc.) the POST could take on a different meaning.

 

I can create a ticket for this.

 

Regards

Esko

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_da51977096684726a6d6944a3facd027HE1PR9001MB0170MGDPHGem_-- From nobody Thu Aug 27 06:40:53 2015 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 7ED391B3B4B for ; Thu, 27 Aug 2015 06:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 cv68ouvJnqPZ for ; Thu, 27 Aug 2015 06:40:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D0ED1B3B36 for ; Thu, 27 Aug 2015 06:40:51 -0700 (PDT) Received: from localhost ([::1]:54390 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZUxQ7-00083s-0o; Thu, 27 Aug 2015 06:40:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-interfaces@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Thu, 27 Aug 2015 13:40:46 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/385 Message-ID: <060.f3bac1795bcb1e1dba4d952b89b379eb@trac.tools.ietf.org> X-Trac-Ticket-ID: 385 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-interfaces@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-interfaces@ietf.org Resent-Message-Id: <20150827134051.4D0ED1B3B36@ietfa.amsl.com> Resent-Date: Thu, 27 Aug 2015 06:40:51 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: [core] #385 (interfaces): Use POST in a Batch (sec.5.2) for more than just toggling X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.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: Thu, 27 Aug 2015 13:40:52 -0000 #385: Use POST in a Batch (sec.5.2) for more than just toggling Dear all, authors of core-interfaces, I was surprised reading in section 5.2 that a POST on a Batch resource would always be interpreted as a 鈥渢oggle鈥 action on all its sub-resources. Is this intended? Rather I would vote for a POST being translated to the same POST executed on all sub-resources that support it 鈥 which would for actuator resources translate into a toggle action. But for other resource types (which may be defined in the future, or may be standard-specific, etc.) the POST could take on a different meaning. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | interfaces@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: major | Version: Component: interfaces | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From nobody Thu Aug 27 12:28:32 2015 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 B4A1D1A89C5 for ; Thu, 27 Aug 2015 12:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 gIJ0fKe1rEOC for ; Thu, 27 Aug 2015 12:28:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27171A8755 for ; Thu, 27 Aug 2015 12:28:28 -0700 (PDT) Received: from [192.168.131.140] ([80.92.121.239]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M4Gup-1YdUim0fCt-00rorn for ; Thu, 27 Aug 2015 21:28:27 +0200 Message-ID: <55DF6438.8030508@gmx.net> Date: Thu, 27 Aug 2015 21:25:44 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "core@ietf.org WG" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wf3s5mkSkExIgaC4c0gSx3RutfIa1BOnO" X-Provags-ID: V03:K0:Bv6/wVYse+AUxJgfguRBskvYsYHgaicirl6arpXAcPjwsjHyIj3 zn5J5xGZB4w5ANkoCCGILWzx79oi7KQtVw23osg0PCrUV4riST8xXZ8d7AaoqifncpxZSBp QR1NywLe59CD6175QMR+RWaMvnfgwTGMtBGPERMb+MoXjSHR0Yj62GSjCfHk/vwgck0Wdrx WH9Hg+2gbUG3JuE3rzzeQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:0hsRileDFYI=:X7Qmcas0sGJ8B8iaU2xxyQ gn1iNnMuSi6IlM0Q3+dCf/BoztY1KxxIgK73BQd7k0ByEm8o39/f5520z1AFU3Uajm4iwHk8f QbnfBc2FUcTs2NrmyBywTLR5JIn++ZyTdN3pzDQUqpqN7vcH0ZEOfrg+HvxowbRwQIFGn+ZCu uWlqjgLtMPcOLxt5knjYst7ZkZ4VeXacWqGNU3Co9FlXtMwss9XuvMKjbfOc3iwa25nfWC1dd z0z3A0jGFp16F0xH6qvON127zA5AvJPTKLZItUlyH9hFITRTGDyn1hfcT5ScFQNlrC+FO+uqu dBmr9Lbj2AqekYieu0/+lXayazd/O1UYl4OdWJ7Ald+Jginqh/58m307VMQfiPfHJznLPIexG oLl0Hh7xC1frv9O6iKWJDHW0WHva2lwXnz3bMV1e0mX3xo9WYZ3g3R1uQFe/4zvqT0bRiYQ8H UTB5DnfUvCdKU2Y3tt14G/eswYuBbiBYfajmIgOyCiJsPy+WhhmC1RHdY/ik7AmE14wP26ZKL 9y/yP2ZdLK/zDb2EZzeFIBaTZcgrwg3bfVmH3p0N3p6zLSLphwlSQf+l4+l6WPCZHcAWmHI/B 9R+y6kyRH/AzsY4eLeIg8/h1pOJtO/c4gQT6vvBuKHZIRNCmm9hgzn1pQhJD+RlHt1qqDhWvR rPLecZdjrnxrS55mzq9+Q4PQYm19qpdgV1uBsbsHo3h2/vQzQNqcdMo1W9vpHfuOjgmyDT3++ 8mA6vmcaAA8/5VCy Archived-At: Subject: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" 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 Aug 2015 19:28:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wf3s5mkSkExIgaC4c0gSx3RutfIa1BOnO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, let me start with the request first before I provide a little bit of background. We are trying to figure out what implementations of TLS/DTLS stacks had been doing with regard to RFC 7250. In private conversations I learned that two implementations ran into problems with the encoding of the subjectPublicKeyInfo structure, which is carried inside the Certificate message. Here is the issue: RFC 7250 defines the Certificate structure in the following way: 1 opaque ASN.1Cert<1..2^24-1>; 2 struct { 3 select(certificate_type){ 4 // certificate type defined in this document. 5 case RawPublicKey: 6 opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>; 7 // X.509 certificate defined in RFC 5246 8 case X.509: 9 ASN.1Cert certificate_list<0..2^24-1>; 10 // Additional certificate type based on 11 // "TLS Certificate Types" subregistry 12 }; 13 } Certificate; You may notice the case statement that distinguishes the handling of X.509 certificates and the newly defined raw public key structure. Line 6 does not use the ASN.1Cert type structure, which is defined in line 1. As a concrete example, if your SubjectPublicKey info is 128 bytes, denoted by xx ... xx, then your payload is: 16 03 03 00 86 0b 00 00 83 00 00 80 xx ... xx Here is the breakdown for a payload using TLS 1.2. * record header 16 03 03 00 86 1 byte content type indicating the handshake message (0x16), 2 byte version length field indicating TLS 1.2 (0x03, 0x03), followed by a 2 byte length field (0x00,0x86) indicating 134 bytes. * handshake header 0b 00 00 83 The handshake type (0x0b) is followed by 3 bytes (0x00, 0x00, 0x83) for the length field indicating 131 bytes. * Certificate: 00 00 80 xx ... xx 3 byte length field (0x00, 0x00, 0x80) indicating 128 bytes, followed by the actual SubjectPublicKeyInfo structure -- denoted as xx ... xx. The encoding of the X.509 structure on the other hand is a little different. It contains two length fields in sequence since there might be a list of certificates conveyed in the structure and the definition provides the length of the entire sequence followed by the length of the first certificate, followed by the certificate payload, the length of the second certificate + 2nd certificate and so on. Implementers have interpreted the above definition in such a way that it always contains two length fields, also in the raw public key case. Hence, my question to the folks on the list: Do you have an implementation of RFC 7250 and what you have you implemented. Please drop me/us a message. Ciao Hannes --wf3s5mkSkExIgaC4c0gSx3RutfIa1BOnO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV32Q4AAoJEGhJURNOOiAt5OQH/iBkrumjABNM0QdSdXeK7EWZ 5zhWfcy/Ak4GplSoV3gYgn2tBV05QvL4iA63wDuSsJu1H7DTcIts9XfLibKt1/tQ 3XEtYhh9yIlIFBlFwNKKgwRgh05Ji/hgCQce0Ic+ln84F8cJwoxWFR9FaZmJ5adW kG6ntqFN5cXEVdy/F9JCmyBmCEdSZP184IptTA9S++LIZddyPwyDfGmOh4qkOB2U BFL+3rCAp+rmlXm78f1TZtdkKqve6P9xmcYpSOIVsdM/5NeDMIhH2hFr47eoda5+ N8mLcNZG0bdNzaUEs/0CDCQBjsvIKph1nty3x+/Ey0wf4YoPyfeHgPHYGVFBUE0= =5G1T -----END PGP SIGNATURE----- --wf3s5mkSkExIgaC4c0gSx3RutfIa1BOnO-- From nobody Thu Aug 27 13:09:00 2015 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 0A1391A872D for ; Thu, 27 Aug 2015 13:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 2IssCsxfh4yp for ; Thu, 27 Aug 2015 13:08:53 -0700 (PDT) Received: from hauke-m.de (hauke-m.de [5.39.93.123]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B31C1B2B6A for ; Thu, 27 Aug 2015 13:08:51 -0700 (PDT) Received: from [192.168.178.24] (pD9F60818.dip0.t-ipconnect.de [217.246.8.24]) by hauke-m.de (Postfix) with ESMTPSA id CCD041008DC; Thu, 27 Aug 2015 22:08:49 +0200 (CEST) To: Hannes Tschofenig , "core@ietf.org WG" References: <55DF6438.8030508@gmx.net> From: Hauke Mehrtens Message-ID: <55DF6E51.7000601@hauke-m.de> Date: Thu, 27 Aug 2015 22:08:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55DF6438.8030508@gmx.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" 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 Aug 2015 20:08:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/27/2015 09:25 PM, Hannes Tschofenig wrote: > Hi all, > > let me start with the request first before I provide a little bit > of background. > > We are trying to figure out what implementations of TLS/DTLS stacks > had been doing with regard to RFC 7250. > > In private conversations I learned that two implementations ran > into problems with the encoding of the subjectPublicKeyInfo > structure, which is carried inside the Certificate message. > > Here is the issue: RFC 7250 defines the Certificate structure in > the following way: > > 1 opaque ASN.1Cert<1..2^24-1>; 2 struct { 3 > select(certificate_type){ 4 // certificate type defined in > this document. 5 case RawPublicKey: 6 opaque > ASN.1_subjectPublicKeyInfo<1..2^24-1>; 7 // X.509 > certificate defined in RFC 5246 8 case X.509: 9 > ASN.1Cert certificate_list<0..2^24-1>; 10 // Additional > certificate type based on 11 // "TLS Certificate Types" > subregistry 12 }; 13 } Certificate; > > You may notice the case statement that distinguishes the handling > of X.509 certificates and the newly defined raw public key > structure. Line 6 does not use the ASN.1Cert type structure, which > is defined in line 1. > > As a concrete example, if your SubjectPublicKey info is 128 bytes, > denoted by xx ... xx, then your payload is: 16 03 03 00 86 0b 00 00 > 83 00 00 80 xx ... xx > > Here is the breakdown for a payload using TLS 1.2. > > * record header 16 03 03 00 86 > > 1 byte content type indicating the handshake message (0x16), 2 > byte version length field indicating TLS 1.2 (0x03, 0x03), followed > by a 2 byte length field (0x00,0x86) indicating 134 bytes. > > * handshake header 0b 00 00 83 > > The handshake type (0x0b) is followed by 3 bytes (0x00, 0x00, 0x83) > for the length field indicating 131 bytes. > > * Certificate: 00 00 80 xx ... xx > > 3 byte length field (0x00, 0x00, 0x80) indicating 128 bytes, > followed by the actual SubjectPublicKeyInfo structure -- denoted as > xx ... xx. > > The encoding of the X.509 structure on the other hand is a little > different. It contains two length fields in sequence since there > might be a list of certificates conveyed in the structure and the > definition provides the length of the entire sequence followed by > the length of the first certificate, followed by the certificate > payload, the length of the second certificate + 2nd certificate and > so on. > > Implementers have interpreted the above definition in such a way > that it always contains two length fields, also in the raw public > key case. > > Hence, my question to the folks on the list: Do you have an > implementation of RFC 7250 and what you have you implemented. > Please drop me/us a message. > > Ciao Hannes There are 2 (or 3) DTLS implementations I know of and they are compatible to each other at least they were 1.5 years ago. tinydtls: http://tinydtls.sourceforge.net/ Californium: https://eclipse.org/californium/ wireshark dissector for DTLS and TLS I am not aware of any other publicly available raw public key DTLS or TLS implementations. They are all implementing a 3 bytes certificates length over all certificates, followed by a 3 bytes certificate length over the next certificate. They implemented it in the way it was supposed to be for x509 certificates only and not for raw public keys. I haven't looked at the current code my information is 1.5 years old. Hauke -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJV325MAAoJEIZ0px9YPRMy7OMP/2BydvzNMqLEjBradwxOqOrl U6Gt0kds3BjMxA/3F1ZCzOtUG8NVSVp3ezcTeKvOXN/SaqDm8MEOfa1M5iFA3E+Q AW05WlCxp6R2TDCX0kAqSFTcT49Sbt1edw+BzdmfVbM+sZMirfVMtrgg6WF5/vm8 7r9p0qFh/u7hKY1T+vGRfvC3+nCX9F/xeilhdWZLpXH2L34eodoLpCew7x26cJ9L zoyUrpABlj2IXJ73BUgy61WBJTe84f8x4mOj5KzyGRmuWNCZqp4JRzODuUu/40Qe PffkR+vTqMVhfejromM0/KB94z9Jc4WtYF6LWHM3NemPf32HOSmjsQK/c0MCtfWV 9x/kY+NiR7UyzBijDdYUjTCDCHkJkG9mH/xmqtXBNCRNt5l4u0jSxOXX3JqwcI+3 66BJxjRmUWid2nLEBSMvcc+wCRvCVSCtOyrwq3Y4Xg5h2RryJ4W3nDVZaFrriIyL UDS6S+j8JiK/k5GwU9qH1bPHHDdezzeEUDP/Vyjgnnpsp/w7U7ApU31BvR320SDX OdZ8R6oFnWy4jFbnV6eeB30eUOip7k6RynnRmTN4r/Kh/GYmPXv6vHLQKubV3mJ3 KqWzrQWlpmNtAmB0KINozQdIqHlrMwSJRsp7IT7ezD8ttGaSzOpauyjI+JnSo1rv zky0S1b0lZD6jQqXBBZv =PdnU -----END PGP SIGNATURE----- From nobody Fri Aug 28 19:55:23 2015 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 E13751B3B0F for ; Fri, 28 Aug 2015 19:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.492 X-Spam-Level: * X-Spam-Status: No, score=1.492 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 cK9QdM8KqpAv for ; Fri, 28 Aug 2015 19:55:20 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47BC1B3B11 for ; Fri, 28 Aug 2015 19:55:20 -0700 (PDT) Received: by pacdd16 with SMTP id dd16so80280161pac.2 for ; Fri, 28 Aug 2015 19:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=s9lAkVm3X/HwMPDmYRLhYfhRB5KacR8voDe+kMEH/rA=; b=XsSWUjwbog3uhB7SJy+p2nDZnEMz3Xh5tH5fXNgTKR036YbBWFg4gGJsR5ZLAD7msB yqgjPcUVBZYsP9jNZf4i5e0m4HqXxcj3j8Xvt6sQ+uJSwaj8VEOrztC5w22TIaxtIp2S v2dHlkkPBew9k9ATq1reA8B2kvKZkg4wS/o3hzM1OOP6Dflm3qpfLqOggeZBUW2bWM/6 nJ/bB0zOl4RQFwLsRsUJmhqfMsIAmHYDRr+cdO+29evq8+ufWsuy3qY2EUZpRx7r8thH pdNxBW5/XbCi5kTlWvZlHRk4Oo+Socgnk4IPokAwwzWjZ1nPOSZW1YxtZlR+rhyrye+d 6lJQ== X-Received: by 10.66.136.102 with SMTP id pz6mr20112611pab.52.1440816920286; Fri, 28 Aug 2015 19:55:20 -0700 (PDT) Received: from [10.0.0.15] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id qf7sm7184112pbc.18.2015.08.28.19.55.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Aug 2015 19:55:19 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F6C8762C-BE02-454C-A1EF-104858663FB5" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Koster In-Reply-To: Date: Fri, 28 Aug 2015 15:01:55 -0700 Message-Id: <7B31C315-7B89-4AF4-B708-72B940A7FD62@gmail.com> References: To: "Dijk, Esko" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "core \(core@ietf.org\)" Subject: Re: [core] core-interfaces section 5.2: "toggle" action prescribed for Batch? 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, 29 Aug 2015 02:55:22 -0000 --Apple-Mail=_F6C8762C-BE02-454C-A1EF-104858663FB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes, agreed. POST should be defined as having the expected action on all = resources, and should not be defined as toggle in all cases. Thanks for = making the ticket. Best regards, Michael On Aug 27, 2015, at 6:31 AM, Dijk, Esko wrote: > Dear all, authors of core-interfaces, > =20 > I was surprised reading in section 5.2 that a POST on a Batch resource = would always be interpreted as a =93toggle=94 action on all its = sub-resources. Is this intended? > Rather I would vote for a POST being translated to the same POST = executed on all sub-resources that support it =96 which would for = actuator resources translate into a toggle action. But for other = resource types (which may be defined in the future, or may be = standard-specific, etc.) the POST could take on a different meaning. > =20 > I can create a ticket for this. > =20 > Regards > Esko > =20 >=20 > The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. --Apple-Mail=_F6C8762C-BE02-454C-A1EF-104858663FB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yes, agreed. POST should be = defined as having the expected action on all resources, and should not = be defined as toggle in all cases. Thanks for making the = ticket.

Best = regards,

Michael

On Aug = 27, 2015, at 6:31 AM, Dijk, Esko <esko.dijk@philips.com> = wrote:

Dear all, authors of = core-interfaces,
 
I was = surprised reading in section 5.2 that a POST on a Batch resource would = always be interpreted as a =93toggle=94 action on all its sub-resources. = Is this intended?
Rather I would vote for a POST being translated to = the same POST executed on all sub-resources that support it =96 which = would for actuator resources translate into a toggle action. But for = other resource types (which may be defined in the future, or may be = standard-specific, etc.) the POST could take on a different = meaning.
 
I can = create a ticket for this.
 
Regards
Esko
 

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.

= --Apple-Mail=_F6C8762C-BE02-454C-A1EF-104858663FB5-- From nobody Mon Aug 31 00:06:06 2015 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 8983B1B2A26 for ; Mon, 31 Aug 2015 00:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 aSrmT5fbQELN for ; Mon, 31 Aug 2015 00:06:02 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C451AD2B2 for ; Mon, 31 Aug 2015 00:06:01 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.215]) by smtp-cloud2.xs4all.net with ESMTP id BK5z1r0084eRkWy01K5zJg; Mon, 31 Aug 2015 09:05:59 +0200 Received: from [2001:983:a264:1:384b:339b:7bef:4bd5] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 31 Aug 2015 09:05:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 31 Aug 2015 09:05:59 +0200 From: peter van der Stok To: Michael Koster , Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <25093c7d75ade3f78e471b55816d0bac@xs4all.nl> X-Sender: stokcons@xs4all.nl (3xDQJnjP0bPBIKSed1rSkHFfk8b2BX/v) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] pubsub and sleepy node proxy X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 07:06:04 -0000 Hi Michael, Looking at the pubsub draft and at our sleepy node proxy draft, I come to the conclusion that there are good arguments to maintain both. Following the reasoning of Matthieu Vial, there are already a good arguments for the sleepy node (SN) proxy (aka mirror server) to exist next to the RD. Namely: Where an end-point can delegate its links to the RD for discovery, an end-point can delegate the links AND the associated resource values to the SN-proxy. The SN-proxy resources have the same lifetime as SN resources. The SN-proxy resource values are directly linked to the resources of a given SN. In contrast the pubsub handles anonymous values. The origin can be added but that means adding attributes to the topics. The pubsub handles the more abstract topics, where the SN-proxy is concerned with the resources. The lifetime of the values in the pubsub server is not directly linked to the lifetime of the originating resources. For me these are the arguments that motivate the existence of the pubsub draft next to the sleepy node draft. Looking forward to your reaction. Greetings Teresa and Peter From nobody Mon Aug 31 03:50:54 2015 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 A02261B41D7; Mon, 31 Aug 2015 03:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 rakyOUXih9BP; Mon, 31 Aug 2015 03:50:51 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1F31B41DD; Mon, 31 Aug 2015 03:50:49 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-49-55e43187137b Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C0.FA.17026.78134E55; Mon, 31 Aug 2015 12:50:47 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.14]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Mon, 31 Aug 2015 12:50:47 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org" , "ace@ietf.org" Thread-Topic: COSE requirements from CORE/ACE Thread-Index: AQHQ49rkEpGsSdn1LEmcbWdqGxxzHg== Date: Mon, 31 Aug 2015 10:50:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <69A7C31698E2A847843A5D6FD222271B@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+JvjW674ZNQg6mndS2+f+thttj3dj2z xbStU1kdmD2WLPnJFMAYxWWTkpqTWZZapG+XwJVx/+189oIFEhVLbzWxNjBeEO9i5OSQEDCR 2HxvGjuELSZx4d56ti5GLg4hgaOMEr+27mOGcBYzSiyZ+4cNpIpNwEXiQcMjJhBbRMBJounD brA4s4CyROOGSywgtrCAhsT8aa1QNboSJy/uZIOw9ST2ToCIswioShzYd5AZxOYVsJBYcHMd WJwR6Irvp9YwQcwUl7j1ZD4TxHUCEkv2nGeGsEUlXj7+xwpiiwLNXHm9iQ0iriTRuOQJUJwD qFdTYv0ufYgx1hL7OtugzlSUmNL9kB1iraDEyZlPWCYwis1Csm0WQvcsJN2zkHTPQtK9gJF1 FaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZgVB3c8lt3B+Pq146HGAU4GJV4eBW2Pg4VYk0s K67MPcQozcGiJM7bwvQgVEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj2IJ1TdW3p76zVlOR OKP19M8Zi3MmEizrKn29Jn/5L9xX2W4Z8q7nxGH26umrJCv51gcF7rvrHvrzQoJUyz0vxaSG nBvzmmq0t6oX7TWN2Pvrzs1Wi9BDTw0P+75+dvvggs5O5xkX783Nu7k39Io1g1Qi95Lp16Z9 /Hr18edDW5fOEH2RtVgqTomlOCPRUIu5qDgRAL0fbBeLAgAA Archived-At: Cc: "cose@ietf.org" Subject: [core] COSE requirements from CORE/ACE 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 Aug 2015 10:50:52 -0000 DQpEZWFyIENPUkUgYW5kIEFDRSBtZW1iZXJzLA0KDQoNCkluIHRoZSBDT1NFIFdHIG1lZXRpbmcg aW4gUHJhZ3VlIG9uZSBvZiB0aGUgdG9waWNzIHdhcyByZXF1aXJlbWVudHMgZnJvbSBhDQpjb25z dHJhaW5lZCBub2RlIG5ldHdvcmsgcG9pbnQgb2YgdmlldyBvbiBtZXNzYWdlIGZvcm1hdCwgY3J5 cHRvIHN1aXRlcw0KZXRjLiBTb21lIGlzc3VlcyB3ZXJlIGRpc2N1c3NlZCBpbiB0aGUgbWVldGlu ZyBhbmQgc29tZSBpbiBzbWFsbGVyIGdyb3Vwcw0KYWZ0ZXIgdGhlIG1lZXRpbmcuIEl0IHdvdWxk IGJlIGdvb2QgdG8gY29sbGVjdCB0aGUgdmlld3Mgb2Ygd2hhdCBwZW9wbGUNCnRoaW5rIGFyZSBp bXBvcnRhbnQgcmVxdWlyZW1lbnRzIGZvciBDT1NFIHRvIGNvbnNpZGVyLiBJIGxpc3QgYSBmZXcg aXNzdWVzDQpoZXJlLCBmZWVsIGZyZWUgdG8gYWRkIChhbmQgZW51bWVyYXRlKSBvdGhlcnMgaW4g dGhpcyB0aHJlYWQuDQoNCjEuIE1lc3NhZ2Ugc2l6ZS4gDQoNClRoZXJlIGlzIGEgdHJhZGUtb2Zm IGJldHdlZW4gbWFraW5nIHRoZSBtZXNzYWdlIGZvcm1hdCBhcHBsaWNhYmxlIHRvIG1hbnkNCnNl dHRpbmdzIGFuZCBvcHRpbWl6aW5nIGl0IGZvciBjZXJ0YWluIHNldHRpbmdzLiBEbyB5b3Uga25v dyBvZiBhbg0KaW1wb3J0YW50IGFwcGxpY2F0aW9uIG9yIHNldHRpbmcgd2l0aCBzcGVjaWZpYyBy ZXF1aXJlbWVudHMgb24gdXBwZXIgbGltaXQNCm9mIG1lc3NhZ2Ugc2l6ZT8gT25lIHJlbGV2YW50 IHBhcmFtZXRlciBpcyBpZiB0aGUgYXBwbGljYXRpb24gcmVxdWlyZXMNCnNpZ25lZCBtZXNzYWdl cyAoYXN5bW1ldHJpYyBrZXkpIG9yIGlmIE1BQ3MgKHN5bW1ldHJpYyBrZXkpIGlzIHN1ZmZpY2ll bnQsDQpzaW5jZSB0aGUgc2lnbmF0dXJlIGlzIG11Y2ggbGFyZ2VyIHRoYW4gdGhlIE1BQy4NCg0K T25lIGZpZ3VyZSBtZW50aW9uZWQgaW4gdGhlIG1lZXRpbmcgd2FzIDkwIGJ5dGVzIFVEUCBwYXls b2FkIGluIGEgNnRpc2NoDQpzZXR0aW5nIHdoaWNoIG1heSBuZWVkIHNpZ25lZCBtZXNzYWdlcy4N Cg0KDQoyLiBNQUMtb25seT8NCg0KRG8geW91IGtub3cgb2YgYW4gaW1wb3J0YW50IGFwcGxpY2F0 aW9uIG9yIHNldHRpbmcgd2hpY2ggcmVxdWlyZSB0aGF0DQptZXNzYWdlcyBhcmUgb25seSBwcm90 ZWN0ZWQgYnkgYSBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGNvZGUsIGkuZS4gd2hlcmUNCnRoZSBt ZXNzYWdlIG11c3QgYmUgaW4gcGxhaW4gdGV4dCBhbmQgaW50ZWdyaXR5IHByb3RlY3RlZCB1c2lu ZyBhDQpzeW1tZXRyaWMga2V5IGFsZ29yaXRobT8NCg0KQ2xlYXJseSB0aGVyZSBhcmUgYXBwbGlj YXRpb25zIHdoZXJlIGVuY3J5cHRpb24gYW5kIG1lc3NhZ2UgYXV0aGVudGljYXRpb24NCmJhc2Vk IG9uIHN5bW1ldHJpYyBhbGdvcml0aG1zIChhdXRoZW50aWNhdGVkIGVuY3J5cHRpb24pIGlzIG5l ZWRlZC4gVGhlDQpxdWVzdGlvbiBpcyB3aGF0IGlzIGdhaW5lZCBieSBhbGxvd2luZyBNQUMtb25s eSBhbGdvcml0aG1zLCBzaW5jZSBpbiBvcmRlcg0KdG8gdmVyaWZ5IHRoZSBtZXNzYWdlIHlvdSBh bnl3YXkgbmVlZCB0aGUgc3ltbWV0cmljIGtleS4NCg0KDQozLiBTeW1tZXRyaWMgZW5jcnlwdGlv biArIGRpZ2l0YWwgc2lnbmF0dXJlLg0KDQpGb3IgY2xvc2VkIHN1YnNjcmliZXIgZ3JvdXBzLCB3 aGVyZSB0aGUgZGF0YSBtdXN0IGJlIGVuY3J5cHRlZCBhbmQgd2hlcmUNCmVhY2ggc3Vic2NyaWJl ciBtdXN0IGJlIGFibGUgdG8gdmVyaWZ5IHRoYXQgdGhlIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9t DQp0aGUgcHVibGlzaGVyLCB0aGVyZSBpcyBhIG5lZWQgdG8gY29tYmluZSBzeW1tZXRyaWMgZW5j cnlwdGlvbiB3aXRoDQpkaWdpdGFsIHNpZ25hdHVyZS4gIFRoaXMgY2FuIGJlIGRvbmUgYnkgZmly c3Qgc3ltbWV0cmljIGVuY3J5cHRpb24gYW5kDQp0aGVuIGRpZ2l0YWwgc2lnbmF0dXJlLCBvciBm aXJzdCBkaWdpdGFsIHNpZ25hdHVyZSBhbmQgdGhlbiBzeW1tZXRyaWMNCmVuY3J5cHRpb24uIERv IHlvdSBrbm93IG9mIGFuIGltcG9ydGFudCBhcHBsaWNhdGlvbiBvciBzZXR0aW5nIHRoYXQNCnJl cXVpcmUgYSBjZXJ0YWluIG9yZGVyIG9mIHRoZSBvcGVyYXRpb25zPw0KDQpPbmUgZXhhbXBsZSBp cyB3aGVyZSB0aGUgcHViLXN1YiBicm9rZXIgc2hvdWxkIGJlIGFibGUgdG8gdmVyaWZ5IHRoZQ0K c2lnbmF0dXJlIG9mIHRoZSBtZXNzYWdlIHdpdGhvdXQgZGlzY2xvc2luZyB0aGUgcGxhaW4gdGV4 dCBwdWJsaWNhdGlvbi4NCg0KDQpUaGFua3MsDQpHw7ZyYW4NCg0KDQoNCg== From nobody Mon Aug 31 04:13:17 2015 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 ABCDB1B2F13; Mon, 31 Aug 2015 04:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 mUZGZib7yXZS; Mon, 31 Aug 2015 04:08:55 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBB281B3F61; Mon, 31 Aug 2015 04:08:54 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id t7VB8pUf022413 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 31 Aug 2015 13:08:51 +0200 Received: from DEFTHW99ERNMSX.ww902.siemens.net (defthw99ernmsx.ww902.siemens.net [139.22.70.141]) by mail2.sbs.de (8.15.1/8.15.1) with ESMTPS id t7VB8pIP030838 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Aug 2015 13:08:51 +0200 Received: from DENBGAT9ERGMSX.ww902.siemens.net (139.22.70.137) by DEFTHW99ERNMSX.ww902.siemens.net (139.22.70.141) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 31 Aug 2015 13:08:50 +0200 Received: from DEFTHW99EI4MSX.ww902.siemens.net ([169.254.9.247]) by DENBGAT9ERGMSX.ww902.siemens.net ([139.22.70.137]) with mapi id 14.03.0248.002; Mon, 31 Aug 2015 13:08:50 +0200 From: "Cuellar, Jorge" To: "goran.selander@ericsson.com" , "core@ietf.org" , "ace@ietf.org" Thread-Topic: COSE requirements from CORE/ACE Thread-Index: AQHQ49rkEpGsSdn1LEmcbWdqGxxzHp4l7qQw Date: Mon, 31 Aug 2015 11:08:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.32] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 31 Aug 2015 04:13:16 -0700 Cc: "cose@ietf.org" Subject: Re: [core] COSE requirements from CORE/ACE 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 Aug 2015 11:09:00 -0000 RGVhciBHw7ZyYW4gYW5kIGFsbCwNCg0KPiAyLiBNQUMtb25seT8NCj4gRG8geW91IGtub3cgb2Yg YW4gaW1wb3J0YW50IGFwcGxpY2F0aW9uIG9yIHNldHRpbmcgd2hpY2ggcmVxdWlyZQ0KPiB0aGF0 IG1lc3NhZ2VzIGFyZSBvbmx5IHByb3RlY3RlZCBieSBhIG1lc3NhZ2UgYXV0aGVudGljYXRpb24g Y29kZS4uLg0KDQpJbmRlZWQsIHRoZXJlIGFyZSBzb21lLiAgRm9yIGluc3RhbmNlLCBzb21lIHVz ZSBjYXNlcyBpbiBTbWFydCBDaXRpZXMgKGJ1c2VzIHNjaGVkdWxpbmcvZGVsYXlzIGluZm9ybWF0 aW9uLCBzb21lIGFzcGVjdHMgb2YgZW52aXJvbm1lbnRhbCBtb25pdG9yaW5nLCBnYXJiYWdlIGNv bGxlY3Rpb24gbWFuYWdlbWVudCwgZXRjKSBkbyBub3QgcmVxdWlyZSBjb25maWRlbnRpYWxpdHkg YnV0IGludGVncml0eS4gIEFzIHRvZGF5IGlzIHRoZSBjYXNlLCB0aGUgZ2VuZXJhbCB1c2VyIG1h eSBiZSB1bmFibGUgdG8gdmVyaWZ5IHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGluZm9ybWF0aW9uLCBi dXQgdGhlICJtYWluIHJlY2lwaWVudCIgKHNheSwgdGhlIGNpdHkgY291bmNpbCkgY2FuIHZlcmlm eSBpdC4NCg0KQmVzdCwNCkpvcmdlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBBY2UgW21haWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEfDtnJhbiBT ZWxhbmRlcg0KU2VudDogMzEgQXVndXN0IDIwMTUgMTI6NTENClRvOiBjb3JlQGlldGYub3JnOyBh Y2VAaWV0Zi5vcmcNCkNjOiBjb3NlQGlldGYub3JnDQpTdWJqZWN0OiBbQWNlXSBDT1NFIHJlcXVp cmVtZW50cyBmcm9tIENPUkUvQUNFDQoNCg0KRGVhciBDT1JFIGFuZCBBQ0UgbWVtYmVycywNCg0K DQpJbiB0aGUgQ09TRSBXRyBtZWV0aW5nIGluIFByYWd1ZSBvbmUgb2YgdGhlIHRvcGljcyB3YXMg cmVxdWlyZW1lbnRzIGZyb20gYSBjb25zdHJhaW5lZCBub2RlIG5ldHdvcmsgcG9pbnQgb2Ygdmll dyBvbiBtZXNzYWdlIGZvcm1hdCwgY3J5cHRvIHN1aXRlcyBldGMuIFNvbWUgaXNzdWVzIHdlcmUg ZGlzY3Vzc2VkIGluIHRoZSBtZWV0aW5nIGFuZCBzb21lIGluIHNtYWxsZXIgZ3JvdXBzIGFmdGVy IHRoZSBtZWV0aW5nLiBJdCB3b3VsZCBiZSBnb29kIHRvIGNvbGxlY3QgdGhlIHZpZXdzIG9mIHdo YXQgcGVvcGxlIHRoaW5rIGFyZSBpbXBvcnRhbnQgcmVxdWlyZW1lbnRzIGZvciBDT1NFIHRvIGNv bnNpZGVyLiBJIGxpc3QgYSBmZXcgaXNzdWVzIGhlcmUsIGZlZWwgZnJlZSB0byBhZGQgKGFuZCBl bnVtZXJhdGUpIG90aGVycyBpbiB0aGlzIHRocmVhZC4NCg0KMS4gTWVzc2FnZSBzaXplLiANCg0K VGhlcmUgaXMgYSB0cmFkZS1vZmYgYmV0d2VlbiBtYWtpbmcgdGhlIG1lc3NhZ2UgZm9ybWF0IGFw cGxpY2FibGUgdG8gbWFueSBzZXR0aW5ncyBhbmQgb3B0aW1pemluZyBpdCBmb3IgY2VydGFpbiBz ZXR0aW5ncy4gRG8geW91IGtub3cgb2YgYW4gaW1wb3J0YW50IGFwcGxpY2F0aW9uIG9yIHNldHRp bmcgd2l0aCBzcGVjaWZpYyByZXF1aXJlbWVudHMgb24gdXBwZXIgbGltaXQgb2YgbWVzc2FnZSBz aXplPyBPbmUgcmVsZXZhbnQgcGFyYW1ldGVyIGlzIGlmIHRoZSBhcHBsaWNhdGlvbiByZXF1aXJl cyBzaWduZWQgbWVzc2FnZXMgKGFzeW1tZXRyaWMga2V5KSBvciBpZiBNQUNzIChzeW1tZXRyaWMg a2V5KSBpcyBzdWZmaWNpZW50LCBzaW5jZSB0aGUgc2lnbmF0dXJlIGlzIG11Y2ggbGFyZ2VyIHRo YW4gdGhlIE1BQy4NCg0KT25lIGZpZ3VyZSBtZW50aW9uZWQgaW4gdGhlIG1lZXRpbmcgd2FzIDkw IGJ5dGVzIFVEUCBwYXlsb2FkIGluIGEgNnRpc2NoIHNldHRpbmcgd2hpY2ggbWF5IG5lZWQgc2ln bmVkIG1lc3NhZ2VzLg0KDQoNCjIuIE1BQy1vbmx5Pw0KDQpEbyB5b3Uga25vdyBvZiBhbiBpbXBv cnRhbnQgYXBwbGljYXRpb24gb3Igc2V0dGluZyB3aGljaCByZXF1aXJlIHRoYXQgbWVzc2FnZXMg YXJlIG9ubHkgcHJvdGVjdGVkIGJ5IGEgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlLCBpLmUu IHdoZXJlIHRoZSBtZXNzYWdlIG11c3QgYmUgaW4gcGxhaW4gdGV4dCBhbmQgaW50ZWdyaXR5IHBy b3RlY3RlZCB1c2luZyBhIHN5bW1ldHJpYyBrZXkgYWxnb3JpdGhtPw0KDQpDbGVhcmx5IHRoZXJl IGFyZSBhcHBsaWNhdGlvbnMgd2hlcmUgZW5jcnlwdGlvbiBhbmQgbWVzc2FnZSBhdXRoZW50aWNh dGlvbiBiYXNlZCBvbiBzeW1tZXRyaWMgYWxnb3JpdGhtcyAoYXV0aGVudGljYXRlZCBlbmNyeXB0 aW9uKSBpcyBuZWVkZWQuIFRoZSBxdWVzdGlvbiBpcyB3aGF0IGlzIGdhaW5lZCBieSBhbGxvd2lu ZyBNQUMtb25seSBhbGdvcml0aG1zLCBzaW5jZSBpbiBvcmRlciB0byB2ZXJpZnkgdGhlIG1lc3Nh Z2UgeW91IGFueXdheSBuZWVkIHRoZSBzeW1tZXRyaWMga2V5Lg0KDQoNCjMuIFN5bW1ldHJpYyBl bmNyeXB0aW9uICsgZGlnaXRhbCBzaWduYXR1cmUuDQoNCkZvciBjbG9zZWQgc3Vic2NyaWJlciBn cm91cHMsIHdoZXJlIHRoZSBkYXRhIG11c3QgYmUgZW5jcnlwdGVkIGFuZCB3aGVyZSBlYWNoIHN1 YnNjcmliZXIgbXVzdCBiZSBhYmxlIHRvIHZlcmlmeSB0aGF0IHRoZSBtZXNzYWdlIG9yaWdpbmF0 ZXMgZnJvbSB0aGUgcHVibGlzaGVyLCB0aGVyZSBpcyBhIG5lZWQgdG8gY29tYmluZSBzeW1tZXRy aWMgZW5jcnlwdGlvbiB3aXRoIGRpZ2l0YWwgc2lnbmF0dXJlLiAgVGhpcyBjYW4gYmUgZG9uZSBi eSBmaXJzdCBzeW1tZXRyaWMgZW5jcnlwdGlvbiBhbmQgdGhlbiBkaWdpdGFsIHNpZ25hdHVyZSwg b3IgZmlyc3QgZGlnaXRhbCBzaWduYXR1cmUgYW5kIHRoZW4gc3ltbWV0cmljIGVuY3J5cHRpb24u IERvIHlvdSBrbm93IG9mIGFuIGltcG9ydGFudCBhcHBsaWNhdGlvbiBvciBzZXR0aW5nIHRoYXQg cmVxdWlyZSBhIGNlcnRhaW4gb3JkZXIgb2YgdGhlIG9wZXJhdGlvbnM/DQoNCk9uZSBleGFtcGxl IGlzIHdoZXJlIHRoZSBwdWItc3ViIGJyb2tlciBzaG91bGQgYmUgYWJsZSB0byB2ZXJpZnkgdGhl IHNpZ25hdHVyZSBvZiB0aGUgbWVzc2FnZSB3aXRob3V0IGRpc2Nsb3NpbmcgdGhlIHBsYWluIHRl eHQgcHVibGljYXRpb24uDQoNCg0KVGhhbmtzLA0KR8O2cmFuDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQWNlIG1haWxpbmcgbGlzdA0KQWNl QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0K From nobody Mon Aug 31 05:23:01 2015 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 8323F1B2C7F; Mon, 31 Aug 2015 05:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 q9BAiyJiJt3Y; Mon, 31 Aug 2015 05:22:58 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DC0D1B444E; Mon, 31 Aug 2015 05:22:57 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-5b-55e4471f222d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8F.1D.27359.F1744E55; Mon, 31 Aug 2015 14:22:56 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.14]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0248.002; Mon, 31 Aug 2015 14:22:55 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "Cuellar, Jorge" , "core@ietf.org" , "ace@ietf.org" Thread-Topic: COSE requirements from CORE/ACE Thread-Index: AQHQ49rkEpGsSdn1LEmcbWdqGxxzHp4l7qQwgAAZKoA= Date: Mon, 31 Aug 2015 12:22:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM+Jvja6C+5NQg0cvmS2+f+thttj3dj2z xbStU1ktbp1dxOrA4rFkyU8mj+0nJzEFMEVx2aSk5mSWpRbp2yVwZcy5u5yloEev4vqxT6wN jF90uhg5OSQETCR6X7cxQ9hiEhfurWfrYuTiEBI4yiixZc0/FpCEkMBiRol5a/hAbDYBF4kH DY+YQGwRgSKJxQv/MILYzALKEo0bLoHVCwvoSBzpO8EIUaMrcfLiTjYI20ri0IrZYDaLgKrE k67JYIt5BSwkDh1dyAixuIVRonXrfFaQBKdAmETD8XtgyxiBrvt+ag0TxDJxiVtP5jNBXC0g sWTPeagPRCVePv4H1isqoCex8noTG0RcUWLn2XagGg6gXk2J9bv0IcZYS/Q/bGSDsBUlpnQ/ ZIe4R1Di5MwnLBMYJWYh2TYLoXsWku5ZSLpnIelewMi6ilG0OLU4KTfdyEgvtSgzubg4P08v L7VkEyMwMg9u+W2wg/Hlc8dDjAIcjEo8vApbH4cKsSaWFVfmHmKU5mBREudtZnoQKiSQnliS mp2aWpBaFF9UmpNafIiRiYNTqoExdOXqs5M2SL5wNjNmWW0bxcPRPOXcNbWu7mVyB0QuvZ9w pHuiWa5dblNKxOrFVY4i6e3TrN4Ilimvzj4Rta9LYI5X3tqvXAm6Yq5mR7zW3G1pmqYlbNW3 aX5vudT/M69cfgo8Npq0cBbfTBa1x3XLxX7IsNvM2vn00qz3HSw7HzB3PtTd+zBbiaU4I9FQ i7moOBEARwQ5Vq0CAAA= Archived-At: Cc: "cose@ietf.org" Subject: Re: [core] COSE requirements from CORE/ACE 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 Aug 2015 12:23:00 -0000 RGVhciBKb3JnZSwNCg0KVGhhbmtzIGZvciBxdWljayByZXBseS4NCg0KT25lIHF1ZXN0aW9uIHdl IGdvdCBpbiB0aGlzIGNvbnRleHQgd2FzLCBpZiB0aGVyZSBpcyBhICJtYWluIHJlY2lwaWVudCIg YXMNCnlvdSBjYWxsIGl0LCB3aHkgc2hvdWxkIGFueW9uZSBlbHNlIGJlIGFibGUgdG8gcmVhZCBp dD8gRS5nLiBjb25zaWRlciBJQUINCnN0YXRlbWVudCBvbiBjb25maWRlbnRpYWxpdHkuDQoNCkFu ZCBpZiB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgYW4gaW50ZXJtZWRpYXJ5IHRoYXQgc2hvdWxkIGJl IGFibGUgdG8gcmVhZA0KaW4gb3JkZXIgdG8gcGVyZm9ybSBhbiBhY3Rpb24gYmFzZWQgb24gdGhh dCBpbmZvcm1hdGlvbiwgc2hvdWxkIG5vdCB0aGF0DQplbnRpdHkgYWxzbyBiZSBhYmxlIHRvIHZl cmlmeSB0aGUgZGF0YSBiZWZvcmUgcGVyZm9ybWluZyB0aGUgYWN0aW9uPw0KDQpJZiB0aGUgaW50 ZXJtZWRpYXJ5IG5lZWQgdG8gdmVyaWZ5IHRoZSBkYXRhLCB0aGVuIGVpdGhlcg0KDQpBKSBpdCBp cyB0cnVzdGVkIHdpdGggbm90IGFsdGVyaW5nIHRoZSB2YWx1ZSBhbmQgY291bGQgaGF2ZSBhY2Nl c3MgdG8gdGhlDQpzeW1tZXRyaWMga2V5LiBCdXQgdGhlbiB0aGUgZGF0YSBjb3VsZCBqdXN0IGFz IHdlbGwgYWxzbyBoYXZlIGJlZW4NCmVuY3J5cHRlZCwgb3IgDQoNCkIpIGl0IGlzIG5vdCB0cnVz dGVkIHdpdGggYWx0ZXJpbmcgdGhlIHZhbHVlLCBhbmQgdGhlbiB0aGF0IHdvdWxkIHJlcXVpcmUN CmFzeW1tZXRyaWMga2V5cyAoaS5lLiBzaWduYXR1cmUpLCB3aGljaCBpcyBub3QgdGhlIGNhc2Ug d2UgYXJlIGNvbnNpZGVyaW5nDQpoZXJlLg0KDQpDbGVhcmx5IHdlIG5lZWQgdG8gc3VwcG9ydCBz aWduYXR1cmUtb25seSwgYnV0IGRvIHdlIHJlYWxseSBuZWVkIE1BQy1vbmx5Pw0KDQoNClJlZ2Fy ZHMsDQpHw7ZyYW4NCg0KDQpPbiAyMDE1LTA4LTMxIDEzOjA4LCAiQ3VlbGxhciwgSm9yZ2UiIDxq b3JnZS5jdWVsbGFyQHNpZW1lbnMuY29tPiB3cm90ZToNCg0KPkRlYXIgR8O2cmFuIGFuZCBhbGws DQo+DQo+PiAyLiBNQUMtb25seT8NCj4+IERvIHlvdSBrbm93IG9mIGFuIGltcG9ydGFudCBhcHBs aWNhdGlvbiBvciBzZXR0aW5nIHdoaWNoIHJlcXVpcmUNCj4+IHRoYXQgbWVzc2FnZXMgYXJlIG9u bHkgcHJvdGVjdGVkIGJ5IGEgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlLi4uDQo+DQo+SW5k ZWVkLCB0aGVyZSBhcmUgc29tZS4gIEZvciBpbnN0YW5jZSwgc29tZSB1c2UgY2FzZXMgaW4gU21h cnQgQ2l0aWVzDQo+KGJ1c2VzIHNjaGVkdWxpbmcvZGVsYXlzIGluZm9ybWF0aW9uLCBzb21lIGFz cGVjdHMgb2YgZW52aXJvbm1lbnRhbA0KPm1vbml0b3JpbmcsIGdhcmJhZ2UgY29sbGVjdGlvbiBt YW5hZ2VtZW50LCBldGMpIGRvIG5vdCByZXF1aXJlDQo+Y29uZmlkZW50aWFsaXR5IGJ1dCBpbnRl Z3JpdHkuICBBcyB0b2RheSBpcyB0aGUgY2FzZSwgdGhlIGdlbmVyYWwgdXNlcg0KPm1heSBiZSB1 bmFibGUgdG8gdmVyaWZ5IHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGluZm9ybWF0aW9uLCBidXQgdGhl ICJtYWluDQo+cmVjaXBpZW50IiAoc2F5LCB0aGUgY2l0eSBjb3VuY2lsKSBjYW4gdmVyaWZ5IGl0 Lg0KPg0KPkJlc3QsDQo+Sm9yZ2UNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZy b206IEFjZSBbbWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR8O2cmFu IFNlbGFuZGVyDQo+U2VudDogMzEgQXVndXN0IDIwMTUgMTI6NTENCj5UbzogY29yZUBpZXRmLm9y ZzsgYWNlQGlldGYub3JnDQo+Q2M6IGNvc2VAaWV0Zi5vcmcNCj5TdWJqZWN0OiBbQWNlXSBDT1NF IHJlcXVpcmVtZW50cyBmcm9tIENPUkUvQUNFDQo+DQo+DQo+RGVhciBDT1JFIGFuZCBBQ0UgbWVt YmVycywNCj4NCj4NCj5JbiB0aGUgQ09TRSBXRyBtZWV0aW5nIGluIFByYWd1ZSBvbmUgb2YgdGhl IHRvcGljcyB3YXMgcmVxdWlyZW1lbnRzIGZyb20NCj5hIGNvbnN0cmFpbmVkIG5vZGUgbmV0d29y ayBwb2ludCBvZiB2aWV3IG9uIG1lc3NhZ2UgZm9ybWF0LCBjcnlwdG8gc3VpdGVzDQo+ZXRjLiBT b21lIGlzc3VlcyB3ZXJlIGRpc2N1c3NlZCBpbiB0aGUgbWVldGluZyBhbmQgc29tZSBpbiBzbWFs bGVyIGdyb3Vwcw0KPmFmdGVyIHRoZSBtZWV0aW5nLiBJdCB3b3VsZCBiZSBnb29kIHRvIGNvbGxl Y3QgdGhlIHZpZXdzIG9mIHdoYXQgcGVvcGxlDQo+dGhpbmsgYXJlIGltcG9ydGFudCByZXF1aXJl bWVudHMgZm9yIENPU0UgdG8gY29uc2lkZXIuIEkgbGlzdCBhIGZldw0KPmlzc3VlcyBoZXJlLCBm ZWVsIGZyZWUgdG8gYWRkIChhbmQgZW51bWVyYXRlKSBvdGhlcnMgaW4gdGhpcyB0aHJlYWQuDQo+ DQo+MS4gTWVzc2FnZSBzaXplLiANCj4NCj5UaGVyZSBpcyBhIHRyYWRlLW9mZiBiZXR3ZWVuIG1h a2luZyB0aGUgbWVzc2FnZSBmb3JtYXQgYXBwbGljYWJsZSB0byBtYW55DQo+c2V0dGluZ3MgYW5k IG9wdGltaXppbmcgaXQgZm9yIGNlcnRhaW4gc2V0dGluZ3MuIERvIHlvdSBrbm93IG9mIGFuDQo+ aW1wb3J0YW50IGFwcGxpY2F0aW9uIG9yIHNldHRpbmcgd2l0aCBzcGVjaWZpYyByZXF1aXJlbWVu dHMgb24gdXBwZXINCj5saW1pdCBvZiBtZXNzYWdlIHNpemU/IE9uZSByZWxldmFudCBwYXJhbWV0 ZXIgaXMgaWYgdGhlIGFwcGxpY2F0aW9uDQo+cmVxdWlyZXMgc2lnbmVkIG1lc3NhZ2VzIChhc3lt bWV0cmljIGtleSkgb3IgaWYgTUFDcyAoc3ltbWV0cmljIGtleSkgaXMNCj5zdWZmaWNpZW50LCBz aW5jZSB0aGUgc2lnbmF0dXJlIGlzIG11Y2ggbGFyZ2VyIHRoYW4gdGhlIE1BQy4NCj4NCj5PbmUg ZmlndXJlIG1lbnRpb25lZCBpbiB0aGUgbWVldGluZyB3YXMgOTAgYnl0ZXMgVURQIHBheWxvYWQg aW4gYSA2dGlzY2gNCj5zZXR0aW5nIHdoaWNoIG1heSBuZWVkIHNpZ25lZCBtZXNzYWdlcy4NCj4N Cj4NCj4yLiBNQUMtb25seT8NCj4NCj5EbyB5b3Uga25vdyBvZiBhbiBpbXBvcnRhbnQgYXBwbGlj YXRpb24gb3Igc2V0dGluZyB3aGljaCByZXF1aXJlIHRoYXQNCj5tZXNzYWdlcyBhcmUgb25seSBw cm90ZWN0ZWQgYnkgYSBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGNvZGUsIGkuZS4gd2hlcmUNCj50 aGUgbWVzc2FnZSBtdXN0IGJlIGluIHBsYWluIHRleHQgYW5kIGludGVncml0eSBwcm90ZWN0ZWQg dXNpbmcgYQ0KPnN5bW1ldHJpYyBrZXkgYWxnb3JpdGhtPw0KPg0KPkNsZWFybHkgdGhlcmUgYXJl IGFwcGxpY2F0aW9ucyB3aGVyZSBlbmNyeXB0aW9uIGFuZCBtZXNzYWdlDQo+YXV0aGVudGljYXRp b24gYmFzZWQgb24gc3ltbWV0cmljIGFsZ29yaXRobXMgKGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGlv bikNCj5pcyBuZWVkZWQuIFRoZSBxdWVzdGlvbiBpcyB3aGF0IGlzIGdhaW5lZCBieSBhbGxvd2lu ZyBNQUMtb25seQ0KPmFsZ29yaXRobXMsIHNpbmNlIGluIG9yZGVyIHRvIHZlcmlmeSB0aGUgbWVz c2FnZSB5b3UgYW55d2F5IG5lZWQgdGhlDQo+c3ltbWV0cmljIGtleS4NCj4NCj4NCj4zLiBTeW1t ZXRyaWMgZW5jcnlwdGlvbiArIGRpZ2l0YWwgc2lnbmF0dXJlLg0KPg0KPkZvciBjbG9zZWQgc3Vi c2NyaWJlciBncm91cHMsIHdoZXJlIHRoZSBkYXRhIG11c3QgYmUgZW5jcnlwdGVkIGFuZCB3aGVy ZQ0KPmVhY2ggc3Vic2NyaWJlciBtdXN0IGJlIGFibGUgdG8gdmVyaWZ5IHRoYXQgdGhlIG1lc3Nh Z2Ugb3JpZ2luYXRlcyBmcm9tDQo+dGhlIHB1Ymxpc2hlciwgdGhlcmUgaXMgYSBuZWVkIHRvIGNv bWJpbmUgc3ltbWV0cmljIGVuY3J5cHRpb24gd2l0aA0KPmRpZ2l0YWwgc2lnbmF0dXJlLiAgVGhp cyBjYW4gYmUgZG9uZSBieSBmaXJzdCBzeW1tZXRyaWMgZW5jcnlwdGlvbiBhbmQNCj50aGVuIGRp Z2l0YWwgc2lnbmF0dXJlLCBvciBmaXJzdCBkaWdpdGFsIHNpZ25hdHVyZSBhbmQgdGhlbiBzeW1t ZXRyaWMNCj5lbmNyeXB0aW9uLiBEbyB5b3Uga25vdyBvZiBhbiBpbXBvcnRhbnQgYXBwbGljYXRp b24gb3Igc2V0dGluZyB0aGF0DQo+cmVxdWlyZSBhIGNlcnRhaW4gb3JkZXIgb2YgdGhlIG9wZXJh dGlvbnM/DQo+DQo+T25lIGV4YW1wbGUgaXMgd2hlcmUgdGhlIHB1Yi1zdWIgYnJva2VyIHNob3Vs ZCBiZSBhYmxlIHRvIHZlcmlmeSB0aGUNCj5zaWduYXR1cmUgb2YgdGhlIG1lc3NhZ2Ugd2l0aG91 dCBkaXNjbG9zaW5nIHRoZSBwbGFpbiB0ZXh0IHB1YmxpY2F0aW9uLg0KPg0KPg0KPlRoYW5rcywN Cj5Hw7ZyYW4NCj4NCj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPkFjZSBtYWlsaW5nIGxpc3QNCj5BY2VAaWV0Zi5vcmcNCj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KDQo=