From nobody Tue May 6 02:53:52 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440EE1A0173 for ; Tue, 6 May 2014 02:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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=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 wYV0ubx8ogKW for ; Tue, 6 May 2014 02:53:49 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD151A0043 for ; Tue, 6 May 2014 02:53:48 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id bs8so590315wib.12 for ; Tue, 06 May 2014 02:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=J8jSeiM16MvsbkrxCADWJtQqqAc9+VQU5bgxUF0pAik=; b=ch/OiFJ9ZpHYTuZUlBHQw7gGyC9Guw2GgLcV2Q+bbBBgt50gxG/S7b8YCoiI+tSxWB kmP9dtkvukU3fznKiN4xNlCcm0+7PW/ENiR0Fm4FrZ0omP8HmNJae/gRsC72WakNRqK9 hAAadr+lPfQ1Thxt5EkEXyAlR/qljNtbcU0YHxhS8RIaH8j4bNzkr/S3iNC8vP1ANJtn fzu4hnGoA60UnyNZAvIDiPv/j/vp+ctUDdeALlSMGL4/9xJIXGw4koHz/t2Xlm8a9iCH q0o46QYaHN9cFQDzyA9c4PVtmLuRXrfF/aTm6Tr0XYRL2OYFLrMMMttLF7ybafOkrTay 1eeg== MIME-Version: 1.0 X-Received: by 10.180.90.132 with SMTP id bw4mr1624512wib.43.1399370024941; Tue, 06 May 2014 02:53:44 -0700 (PDT) Received: by 10.216.79.5 with HTTP; Tue, 6 May 2014 02:53:44 -0700 (PDT) Date: Tue, 6 May 2014 15:23:44 +0530 Message-ID: From: Indtiny S To: core@ietf.org, Contiki developer mailing list Content-Type: multipart/alternative; boundary=f46d043c81be3eff9204f8b839ab Archived-At: http://mailarchive.ietf.org/arch/msg/core/HQG_m2iyZldOk7TuKuDdR7aQ6hk Subject: [core] CoRE link format parse 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, 06 May 2014 09:53:50 -0000 --f46d043c81be3eff9204f8b839ab Content-Type: text/plain; charset=UTF-8 Hi, Has anyone tried to parse the response which is in CoRE link format ..? I am trying support the resource discovery in Contiki based device for CoAP. if anyone has done it pls let me know. Rgds Indra --f46d043c81be3eff9204f8b839ab Content-Type: text/html; charset=UTF-8
Hi,
Has anyone tried to parse the response which is in CoRE link format ..?

I am trying support the resource discovery in Contiki based device for CoAP. if anyone has done it pls let me know.


Rgds
Indra
--f46d043c81be3eff9204f8b839ab-- From nobody Tue May 6 03:50:38 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B0A1A07A6 for ; Tue, 6 May 2014 03:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7SmLV9ofdA3U for ; Tue, 6 May 2014 03:50:36 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) by ietfa.amsl.com (Postfix) with ESMTP id 033501A0797 for ; Tue, 6 May 2014 03:50:35 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129201174.i1.akis.net [95.129.201.174]) by prometheus.amsuess.com (Postfix) with ESMTPS id 06391410F5; Tue, 6 May 2014 12:50:30 +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 A39B235; Tue, 6 May 2014 12:50:28 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [192.168.1.1]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2F4CD45C; Tue, 6 May 2014 12:50:28 +0200 (CEST) Received: (nullmailer pid 14984 invoked by uid 1000); Tue, 06 May 2014 10:50:25 -0000 Date: Tue, 6 May 2014 12:50:25 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Indtiny S Message-ID: <20140506105025.GA15052@hephaistos.amsuess.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/core/0b-ieYTCoozGxT_tBCYwH4gBkvs Cc: core@ietf.org Subject: Re: [core] CoRE link format parse 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, 06 May 2014 10:50:37 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Indra, On Tue, May 06, 2014 at 03:23:44PM +0530, Indtiny S wrote: > Has anyone tried to parse the response which is in CoRE link format ..? >=20 > I am trying support the resource discovery in Contiki based device for > CoAP. if anyone has done it pls let me know. The parsing implementations of RFC6690 I've used are: * link header (in Python using regular expressions, https://bitbucket.org/asplake/link_header) * Copper (a Firefox plugin parsing with regular expressions, http://people.inf.ethz.ch/~mkovatsc/, chrome/content/Helpers.js) * h5.linkformat (Javascript, especially for node.js, Copper-based, https://www.npmjs.org/package/h5.linkformat) None of those are written in C, however. Keep your eyes open for RFC5988 parsers as well. If they follow the spec closely, they should be able to deal with RFC6690 too. Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH mailto:c.amsues@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | ATU68476614 --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJTaL5sAAoJEDmNERLTpL3hLqIP/R/x1ePcibqpKSnd56TmoLUn zXx/3p2n/5sAER9Yz8RMgKNyw3nTt4N3UuLcDIUdrwsRbWBgTAcjuhlot46QAfXZ V8cZpd+LR7K5/+T/jvywAGLRWuJQXTokKNznWBwbE3pMYDUdpZ+RL9/Cuq5OvKXH xE1dE7w/FpvmZ8bQDP6JZPnvxV1DOOgGEFIgxCu4kEMTCu4MAlEKzLm1aqKqtzXQ jOTNmonmCKF3ZFx0qdobrYLmmmMQaZ/RxcilJKSDuhXuasdSkMODgzV9UHlZZ9yN gB8ULkhmM1cKKdUSjOL1jMCqZHpt0R7A9zVOXPX4TDVfSLTIjf7dMH89qPKR6WU8 NnVTlOSlSD0smNzDjdNJUezXHVRziqzj9ZyXofqVo/iNLJWn5l2i1be4LdDW+ZSG zeKm0AxiJyj58lSIeWqIknRp07HdX+ot/guIrU8Hxf8SLLvF+pucyj/xKirJ52e0 Tphbg/5rhzST3MGK9hxEq3APFXFViTIVAF8xxDatqK4U3XnkoIpVJ15kx5AzD1tZ QfRukuDbfY/nu54sN1PeOwJ9VPakEnvgnkWDk6j+HZxUkglCUBy4YONInhXT48eK hotXrNozTjZewpqKTMUKRTqeTw/W9Nr9x/B2AHrHVV2I/hQmvGgs3zxHfS6towy1 nBck5dHrJN1Hjz+jl1cb =Junu -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From nobody Thu May 8 01:49:49 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412691A04BC; Thu, 8 May 2014 01:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 bFR5ESpUBSAu; Thu, 8 May 2014 01:49:45 -0700 (PDT) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by ietfa.amsl.com (Postfix) with ESMTP id 972741A04A7; Thu, 8 May 2014 01:49:45 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube7.xs4all.net [194.109.20.205]) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id s488nd8D004927; Thu, 8 May 2014 10:49:40 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 08 May 2014 10:49:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 08 May 2014 10:49:39 +0200 From: peter van der Stok To: Core , coman@ietf.org, opsawg@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <840dfdb4eef3161ac722a6e9c062de53@xs4all.nl> X-Sender: stokcons@xs4all.nl (/n0By8w2v6K2mjGTOA4mIbSLYfnVamY1) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/core/bY17Avjs_hmKTa96zH9W-2j6wKw Subject: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-04.txt 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, 08 May 2014 08:49:48 -0000 Dear all, Bert and I have a submitted version 4 of the comi draft to core. We were encouraged to inform also the opsawg and coman groups because the management subject is linked to these two groups. Changes from version 03 to version 04 are: o Added design considerations section o Extended comparison of management protocols in introduction o Added automatic generation of CBOR tables o Moved lowpan table to Appendix Looking forward to your comments Peter -------- Oorspronkelijke bericht -------- Onderwerp: New Version Notification for draft-vanderstok-core-comi-04.txt Datum: 2014-05-08 10:43 Afzender: internet-drafts@ietf.org Ontvanger: "Peter Van der Stok" , "Bert Greevenbosch" , Bert Greevenbosch , Peter van der Stok A new version of I-D, draft-vanderstok-core-comi-04.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-core-comi Revision: 04 Title: CoAp Management Interfaces Document date: 2014-05-08 Group: Individual Submission Pages: 38 URL: http://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-04.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ Htmlized: http://tools.ietf.org/html/draft-vanderstok-core-comi-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-vanderstok-core-comi-04 Abstract: The draft describes an interface based on CoAP to manage constrained devices via MIBs. The proposed integration of CoAP with SNMP reduces the code- and application development complexity by accessing MIBs via a standard CoAP server. The payload of the MIB request is CBOR based on JSON. The mapping from SMI to CBOR is specified. The introduction motivates the choices of CoMI with respect to utilization of YANG, NETCONF, SMI, CBOR, CoAP, and URI structure. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri May 9 00:26:44 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6761A01F8 for ; Fri, 9 May 2014 00:26:40 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZdFhgmtil7X for ; Fri, 9 May 2014 00:26:38 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0701A0202 for ; Fri, 9 May 2014 00:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s497QVZY029125 for ; Fri, 9 May 2014 09:26:31 +0200 (CEST) Received: from [192.168.217.145] (p5489256C.dip0.t-ipconnect.de [84.137.37.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E528A11F3; Fri, 9 May 2014 09:26:30 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_20DC5663-24D3-4097-8BC1-0905844D057D" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann Date: Fri, 9 May 2014 09:26:28 +0200 X-Mao-Original-Outgoing-Id: 421313188.608633-ad2c7f8a2e82c489ab1bcf8032f68f29 Message-Id: <6DE70DD9-57C0-4263-A256-BA7428926EBC@tzi.org> References: To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/SphyLnP2ZSa_nzyAZ2VtgWUyHmo Subject: [core] Fwd: Coap discovery related questions... 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, 09 May 2014 07:26:40 -0000 --Apple-Mail=_20DC5663-24D3-4097-8BC1-0905844D057D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 [Due to the DMARC disaster, I=92m posting this message manually from my = address for the original author. Those of you who are using Yahoo or AOL accounts for mailing lists, = please consider subscribing from another account.] > From: Sudhir Pendse > Subject: Coap discovery related questions... > Date: 8 May 2014 21:30:32 +0200 >=20 > Hello, >=20 > I am just starting to go through the drafts/rfcs to do a simple coap = server/client > implementation and had a question regarding discovery. >=20 > I understand that one can query an existing coap server's = "/.well-known/core" > to get a list of url's along with weblink info for them, but was = wondering if there > is a way to find out if a particular uri supports = GET/POST/DELETE/PUT.. >=20 > If it is in the list returned, then I would think we could assume that = it supports > GET, but is there any non-destructive way to find out if it supports = POST/DELETE/PUT > (for example sending a request and looking at error codes returned ?) >=20 > Also, if it is not already there, would it be useful to have a = core-link attribute > like method=3Dgpdu to indicate what methods it supports... >=20 > Look forward to hearing your thoughts. Also if this is not the = correct list to > address this issue, please direct me to the right one. >=20 > Thanks, > -Sudhir --Apple-Mail=_20DC5663-24D3-4097-8BC1-0905844D057D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 [Due = to the DMARC disaster, I=92m posting this message manually from my = address for the original author.
Those of you who are using Yahoo or = AOL accounts for mailing lists, please consider subscribing from another = account.]

From: Sudhir Pendse <sudhir_pendse@yahoo.com>
Subject: Coap discovery related = questions...
Date: 8 May 2014 = 21:30:32 = +0200

Hello,

I am just starting to go = through the drafts/rfcs to do a simple coap = server/client
implementation and had a question regarding = discovery.

I understand that one can query an = existing coap server's "/.well-known/core"
to get a list of = url's along with weblink info for them, but was wondering if = there
is a way to find out if a particular uri supports = GET/POST/DELETE/PUT..

If it is in the list = returned, then I would think we could assume that it = supports
GET, but is there any non-destructive way to find out = if it supports POST/DELETE/PUT
(for example sending a request = and looking at error codes returned ?)

Also, if it is not already there, = would it be useful to have a core-link attribute
like method=3Dgpdu to indicate what = methods it supports...

Look = forward to hearing your thoughts.  Also if this is not the correct list to
address = this issue, please direct me to the right one.

Thanks,
-Sudhir
= --Apple-Mail=_20DC5663-24D3-4097-8BC1-0905844D057D-- From nobody Fri May 9 00:42:06 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7221A020F for ; Fri, 9 May 2014 00:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9R9M9Xp6GuGF for ; Fri, 9 May 2014 00:42:02 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 43BD01A020E for ; Fri, 9 May 2014 00:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s497fr0R029530; Fri, 9 May 2014 09:41:53 +0200 (CEST) Received: from [192.168.217.145] (p5489256C.dip0.t-ipconnect.de [84.137.37.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C71A3121C; Fri, 9 May 2014 09:41:52 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <6DE70DD9-57C0-4263-A256-BA7428926EBC@tzi.org> Date: Fri, 9 May 2014 09:41:50 +0200 X-Mao-Original-Outgoing-Id: 421314110.798259-5b66a11d51dd3714acacd9de68599fb3 Content-Transfer-Encoding: quoted-printable Message-Id: <264C4398-4A5A-4819-8DFB-E061FDA3A590@tzi.org> References: <6DE70DD9-57C0-4263-A256-BA7428926EBC@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/xekIStzagDRciuLoNT0fWZTbj-Q Subject: Re: [core] Fwd: Coap discovery related questions... 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, 09 May 2014 07:42:03 -0000 Sudhir Pendse wrote: > a way to find out if a particular uri supports GET/POST/DELETE/PUT There have been a number of proposals to define attributes for = discovering the set of methods applicable to a resource. So far, the sentiment of the WG has been that while this is useful = information to discover, it may not really be sufficient to act on it. Instead, attributes such as =93rt=3D" and =93if=3D" could be used to = provide more specific information that is then directly actionable. Obviously, whether this is the right assessment depends on specific use = cases. (It also depends on a set of resource type/interface description names = to be accepted practice.) Sudhir: Maybe you could describe your use case in more detail so we can = discuss this in more specific terms? Gr=FC=DFe, Carsten From nobody Fri May 9 11:02:14 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7AA1A0061 for ; Fri, 9 May 2014 11:02:11 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaSlR1UUnUlI for ; Fri, 9 May 2014 11:02:09 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D4F1A1A0007 for ; Fri, 9 May 2014 11:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s49I21gI012539 for ; Fri, 9 May 2014 20:02:01 +0200 (CEST) Received: from [192.168.217.145] (p5489256C.dip0.t-ipconnect.de [84.137.37.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C08C91662; Fri, 9 May 2014 20:01:59 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_22F7F88D-04FF-404E-8F3F-74301ACA371E" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann Date: Fri, 9 May 2014 20:01:55 +0200 X-Mao-Original-Outgoing-Id: 421351315.6026-689bb2a951ea551f3b98c2ee32d99143 Message-Id: <9D3C456A-FCC7-4623-BB8D-1DA36A54B227@tzi.org> References: <1399655978.66093.YahooMailNeo@web161206.mail.bf1.yahoo.com> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/JQZ4NBohGl-MN8jVYLC16iSey6U Subject: [core] Fwd: Fwd: Coap discovery related questions... 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, 09 May 2014 18:02:11 -0000 --Apple-Mail=_22F7F88D-04FF-404E-8F3F-74301ACA371E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 [One more mail I'm manually forwarding to work around yahoo=92s DMARC = disaster.] > From: Sudhir Pendse > Subject: Re: [core] Fwd: Coap discovery related questions... > Date: 9 May 2014 19:19:38 +0200 > To: Carsten Bormann , "core@ietf.org WG" > Reply-To: Sudhir Pendse >=20 >=20 > Thanks for your prompt response... >=20 > Yes, rt/if, being opaque strings, will work only if everyone uses a = well=20 > defined set of values in actual practice. >=20 > I reread the "if" attribute description in RFC 6690 and it talks about=20= > "describing the verbs usable on a resource/..REST interface to = interact.."=20 > and this could be viewed to describe the methods applicable on a = resource=20 > like GET/POST/DELETE/PUT.. So that might certainly be a good spot,=20 > although the examples given in that section do not talk about it. =20 >=20 > So a related question would be "what is a good place to specify this=20= > well defined set of values that MAY/SHOULD be used in actual practice = ? >=20 > =3D=3D(use case) >=20 > If we think of the uri's as being manageable objects, then what you = can > do to them like read/write/destroy/create (similar to the ACCESS = clause=20 > in a SNMP MIB) is useful information when building off-the-shelf tools=20= > like a coap-browser or a generic coap management application. =20 >=20 > Adding support for 'ct' attribute (like the SYNTAX clause) in the = draft > helps in this effort and extends the great benefits of "dynamic = discovery",=20 > as it lessens the apriori knowledge needed to interact.. Similarly > information about the methods applicable on a resource will also help. >=20 > So while discovering the methods applicable on a resource might not be=20= > sufficient by itself to act on, it is a start, and in conjunction with=20= > other attributes like 'ct', it helps make the goal of standards based,=20= > off-the-shelf applications more realizable. Otherwise we might be left > with vendor specific applications with pre-known knowledge using > just a standard transport mechanism for management actions other then=20= > viewing.=20 >=20 > One other thing to consider is only providing method information when > requests come over a secure transport (dtls). >=20 > -Sudhir >=20 >=20 > From: Carsten Bormann > To: "core@ietf.org WG" =20 > Cc: Sudhir Pendse =20 > Sent: Friday, May 9, 2014 12:41 AM > Subject: Re: [core] Fwd: Coap discovery related questions... >=20 > Sudhir Pendse wrote: >=20 >=20 > > a way to find out if a particular uri supports GET/POST/DELETE/PUT >=20 >=20 > There have been a number of proposals to define attributes for = discovering the set of methods applicable to a resource. >=20 > So far, the sentiment of the WG has been that while this is useful = information to discover, it may not really be sufficient to act on it. > Instead, attributes such as =93rt=3D" and =93if=3D" could be used to = provide more specific information that is then directly actionable. >=20 > Obviously, whether this is the right assessment depends on specific = use cases. > (It also depends on a set of resource type/interface description names = to be accepted practice.) >=20 > Sudhir: Maybe you could describe your use case in more detail so we = can discuss this in more specific terms? >=20 > Gr=FC=DFe, Carsten >=20 >=20 >=20 --Apple-Mail=_22F7F88D-04FF-404E-8F3F-74301ACA371E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 [One = more mail I'm manually forwarding to work around yahoo=92s DMARC = disaster.]

From: = Sudhir Pendse <sudhir_pendse@yahoo.com>
Subject: = Re: [core] Fwd: = Coap discovery related questions...
Date: 9 May 2014 19:19:38 = +0200
To: = Carsten Bormann = <cabo@tzi.org>, "core@ietf.org WG" <core@ietf.org>
Reply-To: Sudhir Pendse <sudhir_pendse@yahoo.com>


Thanks for your prompt = response...

Yes, rt/if, being opaque strings, = will work only if everyone uses a well
defined = set of values in actual practice.

I reread the "if" attribute description in RFC 6690 and it talks about
"describing the verbs = usable on a resource/..REST interface to interact.."
and this could be viewed to describe the methods applicable = on a resource
like GET/POST/DELETE/PUT.. So = that might certainly be a good spot,
although the examples given in that = section do not talk about it. 

So a related question would be "what is a good = place to specify this
well defined set of = values that MAY/SHOULD be used in actual practice ?

=3D=3D(use case)

If we think of the uri's as being = manageable objects, then what you can
do to = them like read/write/destroy/create (similar to the ACCESS clause
in a SNMP MIB) is useful = information when building off-the-shelf tools
like a coap-browser or a generic coap management = application. 

Adding support for 'ct' attribute (like the SYNTAX clause) in = the draft
helps in this effort and extends the = great benefits of "dynamic discovery",
as it = lessens the apriori knowledge needed to interact.. Similarly
information about the methods applicable on a resource will = also help.

So while = discovering the methods applicable on a resource might not be
sufficient by itself to act on, it is a start, and = in conjunction with
other attributes like = 'ct', it helps make the goal of standards based,
off-the-shelf applications more realizable. Otherwise we might be left
with vendor = specific applications with pre-known knowledge using
just a standard transport mechanism for management actions = other then
viewing.

One other thing to consider is only = providing method information when
requests come = over a secure transport (dtls).

-Sudhir


= From: = Carsten Bormann <cabo@tzi.org>
To: "core@ietf.org WG" <core@ietf.org>
Cc: Sudhir Pendse <sudhir_pendse@yahoo.com> =
Sent: Friday, May 9, 2014 12:41 = AM
Subject: Re: [core] Fwd: Coap = discovery related questions...

Sudhir Pendse = <sudhir_pendse@yahoo.com> = wrote:


> = a way to find out if a particular uri supports = GET/POST/DELETE/PUT


There have been a number of = proposals to define attributes for discovering the set of methods = applicable to a resource.

So far, the sentiment of the WG has = been that while this is useful information to discover, it may not = really be sufficient to act on it.
Instead, attributes such as =93rt=3D" and =93if=3D" could = be used to provide more specific information that is then directly = actionable.

Obviously, whether this is the right = assessment depends on specific use cases.
(It also depends on a set of resource type/interface = description names to be accepted practice.)

Sudhir: Maybe = you could describe your use case in more detail so we can discuss this = in more specific terms?

Gr=FC=DFe, Carsten



=

= --Apple-Mail=_22F7F88D-04FF-404E-8F3F-74301ACA371E-- From nobody Wed May 21 09:05:43 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB771A0840 for ; Wed, 21 May 2014 09:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, MANGLED_WRLDWD=2.3, RP_MATCHES_RCVD=-0.651, 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 agYzWP3LdZd4 for ; Wed, 21 May 2014 09:05:33 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 69C261A0867 for ; Wed, 21 May 2014 09:05:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 5821F1E59CC for ; Wed, 21 May 2014 09:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXucd3TumhOk for ; Wed, 21 May 2014 09:04:53 -0700 (PDT) Received: from [192.168.1.21] (c-69-181-66-243.hsd1.ca.comcast.net [69.181.66.243]) by c8a.amsl.com (Postfix) with ESMTPSA id 39B0D1E59C6 for ; Wed, 21 May 2014 09:04:53 -0700 (PDT) From: Alexa Morris Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <57C5A778-22EE-45E1-9861-25692B6B7DA0@amsl.com> Date: Wed, 21 May 2014 09:05:26 -0700 To: core@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/YsNIA_cS3esfcW_T6jUDAU-LezE Subject: [core] Invitation to Participate in IETF 90 Bits-N-Bites: Internet of Things 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, 21 May 2014 16:05:38 -0000 Bits-N-Bites at IETF 90 in Toronto will focus on the Internet of Things, = and the IETF invites you and your organization to participate! The arrival of Things connected to the Internet in recent years has = given life to new applications in both the consumer and industrial = market segments. We are surrounded by products that utilize connectivity = and a growing enthusiasm suggests imminent and impressive deployments: = billions of new connected devices are expected by year 2020. In the = industrial world, wide spread wireless sensoring devices that collect = data and measurements will move us into the next phase of process = optimization. This will require the combination of the best of = Information Technology (IT) and Operational Technology (OT), forming the = IT/OT convergence. When deploying multi-stage Thing topologies, two trends compete: IP = protocols are enhanced and transformed into less end-to-end protocols = (address translation, header compression, 'mesh under' routing and more) = and, alternatively, existing IP protocols are reduced to their bare = minimum such as to fit in reduced Things (reduced CPU frequency and = number of transistors, dimensions and energy consumption). IETF 90 demonstrations should exhibit recent developments of IP = protocols for IoT networks (6lowpan adaptation layers, MANET and RPL = routing protocols, 6tsch time-constrained communications, CoAP app-layer = protocols) as well as demonstrations of the tendency of bringing the = known IPv6 as close as possible to the Thing - minimum set of unmodified = IPv6, Neighbor Discovery, DHCP, HTTP, IKEv2. Demonstrations of = geo-location uses in and for IP networking and the surrounding privacy = issues are also welcome. Does your organization want to reach 1,200 Internet engineers and = demonstrate your IoT technologies and usage of IETF protocols? This is = your opportunity to show leading industry professionals the latest and = greatest of what you do in a social and interactive setting. Examples of demos include, but are not limited, to: =95 home automation controller using SNMP for HVAC and ambient = temperature, electricity counter; =95 industrial-grade Wireless Sensor Network products; =95 scalable wireless designs and existing deployments; =95 IPv6 end-to-end and backbone interconnection; =95 tablet summarizing status of widespread devices through = heterogeneous link connections; =95 smart belt collecting body information with low-energy communication = protocols; =95 vehicle interior connected designs, vehicle-to-road sensor-based = communications; =95 sensor-assisted autonomous mobile Things (mono-, bi-, quad- wheeled = or propelled devices); =95 vehicular communications (e.g. dead-reckoning enhancements for = enhanced GPS localization, geo-dissemination); =95 smartphone applications relying on geo-localization. There many ways to configure your demo, such as:=20 =95 Things deployed on a table, relying on local connections and = alternatively exhibiting remote access across the Internet; =95 a poster describing a demo; =95 video sequence showing a lab demonstration. For information about IETF 90 Bits-N-Bites, please see = http://www.ietf.org/meeting/90/90-bits-n-bites.html or send email to = bnbsg@ietf.org. Regards, Alexa ---------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From nobody Thu May 22 08:02:27 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EE31A00E2 for ; Wed, 21 May 2014 23:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 lJC2sSnOIgGl for ; Wed, 21 May 2014 23:52:29 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id E20E31A0016 for ; Wed, 21 May 2014 23:52:28 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 21 May 2014 23:52:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,885,1392192000"; d="p7s'?scan'208,217";a="544727810" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by orsmga002.jf.intel.com with ESMTP; 21 May 2014 23:52:27 -0700 Received: from orsmsx154.amr.corp.intel.com (10.22.226.12) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 21 May 2014 23:52:26 -0700 Received: from orsmsx104.amr.corp.intel.com ([169.254.3.166]) by ORSMSX154.amr.corp.intel.com ([169.254.11.72]) with mapi id 14.03.0123.003; Wed, 21 May 2014 23:52:27 -0700 From: "Agrawal, Sachin" To: "core@ietf.org" Thread-Topic: .well-known/core examples Thread-Index: Ac91imIEZ1LOv1mbTte1Bs+0m1q6+A== Date: Thu, 22 May 2014 06:52:25 +0000 Message-ID: <79C6EF6B5F50B3499DC017935C25A5BF2DBCBB4C@ORSMSX104.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0016_01CF754F.B7802AD0" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/core/XJfInqk38vUCa6HAlJUBHTnSGX8 X-Mailman-Approved-At: Thu, 22 May 2014 08:02:22 -0700 Subject: [core] .well-known/core examples 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, 22 May 2014 06:52:30 -0000 ------=_NextPart_000_0016_01CF754F.B7802AD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0017_01CF754F.B7802AD0" ------=_NextPart_001_0017_01CF754F.B7802AD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, I am trying to understand the examples mentioned in RFC 6690 (Section 5). 1) REQ: GET /.well-known/core RES: 2.05 Content ;if="sensor", ;if="sensor" When the client will get this response, since ip_address/hostname and port number is missing from the URI reference, should client assume that the host is the machine sending the response back and port number is the default coap port i.e. 5683? What happens if the client receives this response through a Proxy? 2) Also, another client may send this response to above query too: REQ: GET /.well-known/core RES: 2.05 Content ;if="sensor", ;if="sensor" In above scenario, client will retrieve the hostname and port number from the URI reference provided in the payload of Link Format. Please confirm? Thanks Sachin ------=_NextPart_001_0017_01CF754F.B7802AD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

 

I am trying to understand the examples mentioned in = RFC 6690 (Section 5).

 

1)

REQ: = GET /.well-known/core

 

RES: = 2.05 Content

</sensors/temp>;if=3D"sensor",

</sensors/light>;if=3D"sensor"

 

When the = client will get this response, since ip_address/hostname and port number = is missing from the URI reference, should client assume that the = host  is the machine sending the response back and port number is = the default coap port i.e. 5683?

What happens if the client receives this response = through a Proxy?

 

2)

Also, = another client may send this response to above query = too:

REQ: = GET /.well-known/core

 

RES: = 2.05 Content

<coap://192.168.1.25:9900/sensors/temp>;if=3D&quo= t;sensor",

<coap://192.168.1.25:9901/sensors/light>;if=3D&qu= ot;sensor"

 

In above = scenario, client will retrieve the hostname and port number from the URI = reference provided in the payload of Link Format. Please = confirm?

 

Thanks=

Sachin

 

 

------=_NextPart_001_0017_01CF754F.B7802AD0-- ------=_NextPart_000_0016_01CF754F.B7802AD0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIhJDCCAyAw ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05 ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3 wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1 hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8 7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3 ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4 lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+ iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0 Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69 tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIENjCCAx6gAwIBAgIBATANBgkq hkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsT HUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5h bCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0D GuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6s YapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+7 10LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvd QwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAd BgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMB Af8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEF BQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYT x4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0 hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvCNr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1 n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9 F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQwggTrMIID06ADAgECAhBS6QLKEehE nZRlOC+jGjC7MA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVz dCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFk ZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTMwMzE5MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjB5 MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFDASBgNVBAcTC1NhbnRhIENsYXJhMRowGAYDVQQK ExFJbnRlbCBDb3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWlu ZyBDQSA0QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOCwzICd2ElV+gPbBPo4x92/ hd12vOs9yyyrv+lr4yHb1G8Z6M9qp75fVCkCN7BNc1EUMa34L7T9Gz4Ldbg8AHy3Oh+Xqp8ovuxa z7ExgkeIMA5qtVpE0IDQzV1IG+9Xvf+rH6vlnwg6YvEnGoJciwkae6Yf1etHG4rQb52RXpSggwYd 99kuiht2wHZzRgf75POm8A5WOqJg7Ov0bHzcM0FcKPzN6D67sesus8iKEbpX5FRDWzNP/Ua80Dpc iuFuVZOBBLH1to5QleFvN0CqkXHACiFMcNqvx6B1T22xE66y5hOkUWf/nlpZBlpfprceNhzoDpl9 AUXU0aPbx+8ngaMCAwEAAaOCAXcwggFzMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBQeaSq03Cj+RxhOIQs/vKwRL/CY9TAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/ BAgwBgEB/wIBADA2BgNVHSUELzAtBggrBgEFBQcDBAYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDDAYJ KwYBBAGCNxUFMBcGA1UdIAQQMA4wDAYKKoZIhvhNAQUBaTBJBgNVHR8EQjBAMD6gPKA6hjhodHRw Oi8vY3JsLnRydXN0LXByb3ZpZGVyLmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA6Bggr BgEFBQcBAQQuMCwwKgYIKwYBBQUHMAGGHmh0dHA6Ly9vY3NwLnRydXN0LXByb3ZpZGVyLmNvbTA1 BgNVHR4ELjAsoCowC4EJaW50ZWwuY29tMBugGQYKKwYBBAGCNxQCA6ALDAlpbnRlbC5jb20wDQYJ KoZIhvcNAQEFBQADggEBACnCzaP9kqNSZ6IvBu1uUOhUj6tX5silt7Eg39Wpr8h5IxIHduZ+zCkR xhJkccaM4jyqXJm312FPidIOetJwqOYDxe/Fne2Zs3JgnJtVBRXyMX8OkANfW0aUwvGzDGkkhJfM t/T4MGvhxDZqD2bDOtw3Wes4g5z6nEm3H2LPKnf5uXdtq6V6uSBlVLV+i1+0f4UksP97HwE5wS4I ibYpVcmOzhhpmCggEtiNOIrb0ktVrXnF07fTmQ8jW5ey7Tmwa4DC4WZKSVvqTkfX94eVRtkubipA O04fTQvRKEnHcEAgCMPlFim0kNCLI9lBS+3xyr5qlilUy/fLEc7yN7HjQuAwggWKMIIEcqADAgEC AgphIIpiAAAAAAAIMA0GCSqGSIb3DQEBBQUAMFIxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRl bCBDb3Jwb3JhdGlvbjEnMCUGA1UEAxMeSW50ZWwgRXh0ZXJuYWwgQmFzaWMgUG9saWN5IENBMB4X DTA5MDUxNTE5MjcyNloXDTE1MDUxNTE5MzcyNlowVjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUlu dGVsIENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENB IDNCMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApAQzVaf1NT29z0L79NzsoH56JgSW atwRYTfZZR0e9Yb4hxAdVCyKROYzIoqiM0vDYHmzoh6RzyK8Oj/AJ+NnNf0nJ+0ydz4ACtzSVrzs 6XJvObwr2NcR9MG9OdRIVKIj1lh58hN2JSCqUAW6WMVkQdgpi0u6GtFpymZB8/iZXrc0p1zZtPzT gdF/pim1kVriTpg33jOWsY2sG5BDvhYXPP+MsG6xtSkSSujoy79lgU4VZCtX2UGEX1G6TzI37c3q f19Sj+oGKCIXaQSf3FWHXKSXtIIYvaMFSRfHiqBXbtrpKLyVFF2Csca038dadJaUtdMfmXnvkfgu r77vs4W/fwIDAQABo4ICXDCCAlgwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUDsYq91myCBCQ JW/D3f2KZjEwK8UwCwYDVR0PBAQDAgGGMBIGCSsGAQQBgjcVAQQFAgMBAAEwIwYJKwYBBAGCNxUC BBYEFDmgVjZ6QpD/kq2Kb5V0x5JZvhBZMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1Ud IwQYMBaAFBrGDErER2+o260r8PRWBqPtN1QMMIG9BgNVHR8EgbUwgbIwga+ggayggamGTmh0dHA6 Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUy MFBvbGljeSUyMENBLmNybIZXaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9y eS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3JsMIHjBggrBgEF BQcBAQSB1jCB0zBjBggrBgEFBQcwAoZXaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9j ZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MGwG CCsGAQUFBzAChmBodHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRp ZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3klMjBDQS5jcnQwDQYJKoZI hvcNAQEFBQADggEBALG1AQdyFVCFfKMSq0xVQx7qCSY+whzMfFJ6o1uj12wP7rFtPrklP6hiCkgC 18Sxhd5Qm7VwKGqlvbZTlswDPt5pBxblvN5+59a8DqWDbTjwHyhzMGP+r7k/k2litQ7yM6Y3iNON 8mrcSVnvIVanLusHdWb9o3oBNipZ8xtL/F+H4kLGYfd2uhSYwkjT9pkkewu2NuMWc2wcM2sllfW/ GUzvwtvWGOyRMQ0+aFtVt9OPmL9kaeG/i2YjxBk8I21x6Bcmt+FGXYP1tal1M4+taIsNSrPLVnoo vtNw5L88KXxEcIleQ9q7+2FNAKkigNrb5z7dcD76BFN8BDiy9M7brQ0wggWPMIIEd6ADAgECAgoR zN6TAAEAAIenMA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBD b3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjAe Fw0xMjAxMjUxNDAzNDFaFw0xNTAxMDkxNDAzNDFaMEMxGDAWBgNVBAMTD0FncmF3YWwsIFNhY2hp bjEnMCUGCSqGSIb3DQEJARYYc2FjaGluLmFncmF3YWxAaW50ZWwuY29tMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQChgDxKzx0avb5V86d24U9udKIRiz6yuLarL/3cBROmBHWEjuH9FmD1vIV7 GInXoB7AVO2CX1FPmBC986n9q1jdLcF0/Cam+JVYCXbiJ4H54mGkPW/gjt1hdO+2K/c6pK1B78x0 cPADmoz1+KkrxSgQV2ZVY709NR8BvPWuQd1sUwIDAQABo4IC9DCCAvAwPAYJKwYBBAGCNxUHBC8w LQYlKwYBBAGCNxUIhsOMdYSZ5VGD/YEohY6fU4KRwAlngd69OZXwQwIBZAIBCDAfBgNVHSUEGDAW BggrBgEFBQcDBAYKKwYBBAGCNwoDDDALBgNVHQ8EBAMCB4AwKQYJKwYBBAGCNxUKBBwwGjAKBggr BgEFBQcDBDAMBgorBgEEAYI3CgMMMB0GA1UdDgQWBBTs17ERvljENOCifKjBrxk8sL0drjAfBgNV HSMEGDAWgBQOxir3WbIIEJAlb8Pd/YpmMTArxTCBzwYDVR0fBIHHMIHEMIHBoIG+oIG7hldodHRw Oi8vd3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMl MjBJc3N1aW5nJTIwQ0ElMjAzQigxKS5jcmyGYGh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29t L3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUy MDNCKDEpLmNybDCB9QYIKwYBBQUHAQEEgegwgeUwbAYIKwYBBQUHMAKGYGh0dHA6Ly93d3cuaW50 ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUy MElzc3VpbmclMjBDQSUyMDNCKDEpLmNydDB1BggrBgEFBQcwAoZpaHR0cDovL2NlcnRpZmljYXRl cy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJh c2ljJTIwSXNzdWluZyUyMENBJTIwM0IoMSkuY3J0ME0GA1UdEQRGMESgKAYKKwYBBAGCNxQCA6Aa DBhzYWNoaW4uYWdyYXdhbEBpbnRlbC5jb22BGHNhY2hpbi5hZ3Jhd2FsQGludGVsLmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAfHMiw40/nu5K+w4UT6kWN45C6qhLperJQTl5hhvmdhsIoXDF7+wwiZoZ moDuHfeH89gqxW7Ftc2auCqLSBOLZfCyrIGUYIBP2kCKJ0TqZnRilA72P7p5rn1bMeTxgNaGlGMV JFPnUdQtKs7XUpXexySZS/Z9+eWyGcobtQHzsy5WctynlGZ0Wtv2YWmAOFSfq6RAFyeUgjVu8AY2 AuQkkmyBxO9Q9MIOsSKbFJArHZ9JA5nX/z0O/4rrYpl/se4YIkyvC5T1B02z/ZzHckS5WHUFZRUL mrfuAvM69ZX3ttEtWNUyKwKBz28EBJxvFOu9NS9o44k0SPbsYXAX7H1kaDCCBnEwggVZoAMCAQIC CnRNNvoAAAAAOyowDQYJKoZIhvcNAQEFBQAweTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRQw EgYDVQQHEwtTYW50YSBDbGFyYTEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMT IkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgNEEwHhcNMTMxMTI1MDIzMTA3WhcNMTYx MTA5MDIzMTA3WjBDMRgwFgYDVQQDEw9BZ3Jhd2FsLCBTYWNoaW4xJzAlBgkqhkiG9w0BCQEWGHNh Y2hpbi5hZ3Jhd2FsQGludGVsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOLk qAmyOu2Cvv/ndH7ZFkOxEPgXpfFe9laSPmm5MTYEt6g4go+E0rdM7PAqbNOtINcJWU0wxxJUEBNq Pg4+zK8hVmGugxHw98maL8vm3/Glcc4adjVVhAPeQk5IfQN9fLviv3Jest0epQfQFwB5dYUc3uYR Kd4v8hC4YvgZR5BsqB/7oYJ7ipzfo51ie5++vC5sZTXIZdUPxCas4Uc2IGAmEmW1a277JPC/GcNB rv2WdAguttZiSmMzi95Dbij/wkRH6d7SKWmPhmqRItqsv7Z2C/vJY4ExBNtdf9Z8e9V2Gtl5FwHi +Wf+pY+HQLgcEQSx6Isd9zYPIFnanehl8q8CAwEAAaOCAy8wggMrMAsGA1UdDwQEAwIEMDA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiGw4x1hJnlUYP9gSiFjp9TgpHACWeEudlBh4T/TgIBZAIB DTBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4D AgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFDetOgCrA/wWcJRUIz+haN8D/KCTMB8GA1UdIwQYMBaA FB5pKrTcKP5HGE4hCz+8rBEv8Jj1MIHJBgNVHR8EgcEwgb4wgbuggbiggbWGVGh0dHA6Ly93d3cu aW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3Vp bmclMjBDQSUyMDRBLmNybIZdaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9y eS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENBJTIwNEEuY3JsMIHv BggrBgEFBQcBAQSB4jCB3zBpBggrBgEFBQcwAoZdaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3Np dG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENB JTIwNEEuY3J0MHIGCCsGAQUFBzAChmZodHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNvbS9yZXBv c2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIw Q0ElMjA0QS5jcnQwHwYDVR0lBBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwKQYJKwYBBAGCNxUK BBwwGjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEME0GA1UdEQRGMESgKAYKKwYBBAGCNxQCA6Aa DBhzYWNoaW4uYWdyYXdhbEBpbnRlbC5jb22BGHNhY2hpbi5hZ3Jhd2FsQGludGVsLmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAEi+FRHWtJgJkCQuUEDTYr6py8WSP1a9un1o+rsLvoJUoIW+LMueUGeIv Zznnkpg+QE/cU+pF4L3rFQqXuyfjRZtvAHD9ktf6AP4ER+k0mFAN8inX4oVVQjpS+SPWPaKEZa4c 3/UV6xm4E15YuktZE+r68ZP6oAJOcU5JmaCrDkP1z8JTkaF2QWiNdeFP+ONk8e0O1uBjD3io6ucf JTMQD0fDM+VB5K3LXySg+zN4HRYwrOG/r2SfFBwvYTr1wGBUYU99BfW1ugRqRjPjxz6TnDGhqRtD +S7iV4P7vuydkJkt8ix4FJHkhE+Oasy4bdVn87HlPTrq0ii26MYhb+3AmTGCA1EwggNNAgEBMGQw VjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRl bCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDNCAgoRzN6TAAEAAIenMAkGBSsOAwIaBQCgggJD MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDUyMjA2NTIyNVow IwYJKoZIhvcNAQkEMRYEFG8pcpvPr7No1hnsc85A1+F42Ee8MIGYBgkrBgEEAYI3EAQxgYowgYcw eTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRQwEgYDVQQHEwtTYW50YSBDbGFyYTEaMBgGA1UE ChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3Vp bmcgQ0EgNEECCnRNNvoAAAAAOyowgZoGCyqGSIb3DQEJEAILMYGKoIGHMHkxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJDQTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExGjAYBgNVBAoTEUludGVsIENvcnBv cmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDRBAgp0TTb6 AAAAADsqMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIGAB/2ss7nzCqsolhX+dacsYpkeZAqUsOHTt4euMeRd Dlhb4G2N1doMZzDFe5mExXfUR2AmU8bacj/p4zleJMQV3tiBXn89XRc04cJsgypg4tFACkOaGIym 8l4FyYCDmDIYebp+zAOEf2HzvfUZd9fqO0QgvbkiZpXcpWI4T/PagFoAAAAAAAA= ------=_NextPart_000_0016_01CF754F.B7802AD0-- From nobody Thu May 22 14:49:08 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436041A037E for ; Thu, 22 May 2014 14:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 OS8NcQbDR1jz for ; Thu, 22 May 2014 14:49:04 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7626D1A037F for ; Thu, 22 May 2014 14:49:04 -0700 (PDT) X-ASG-Debug-ID: 1400795342-06daaa09ef1a7890001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id V2rdyUD79F4QbK4S for ; Thu, 22 May 2014 17:49:02 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 May 2014 17:49:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CF7607.A3F18C9B" Date: Thu, 22 May 2014 17:48:58 -0400 X-ASG-Orig-Subj: RE: [core] .well-known/core examples Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: .well-known/core examples Thread-Index: Ac91imIEZ1LOv1mbTte1Bs+0m1q6+AAWOnkw From: "Rahman, Akbar" To: "Agrawal, Sachin" X-OriginalArrivalTime: 22 May 2014 21:49:01.0092 (UTC) FILETIME=[A4550E40:01CF7607] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1400795342 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.6037 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/core/e5eTQWntystfn_dA-PhEP9nHwb0 Cc: core@ietf.org Subject: Re: [core] .well-known/core examples 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, 22 May 2014 21:49:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CF7607.A3F18C9B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sachin, =20 =20 For your question:=20 =20 >When the client will get this response, since ip_address/hostname and port number is missing from the URI reference, should client assume that the host is the machine sending the response back and port number is the default coap port i.e. 5683? =20 =20 You can see part of the answer to your question in the 2nd paragraph of http://tools.ietf.org/html/rfc6690#section-5 which was right before the example 1 that you quoted. Specifically, it says in that paragraph: =20 Note that the default relation type for this link format is "hosts" in links with no rel=3D target attribute. = Thus, the links in this example tell that the Origin server from which /.well-known/core was requested (the context) hosts the resources /sensors/temp and /sensors/light (each a target). =20 In other words, this means that the resources=20 =20 , =20 =20 are located at the "Uri-Host" and the "Uri-Port" that the GET Request was sent to (i.e. Origin Server). These terms are defined in: =20 http://tools.ietf.org/html/draft-ietf-core-coap-18#section-5.10.1=20 =20 also it is instructive to look at: =20 http://tools.ietf.org/html/draft-ietf-core-coap-18#appendix-B =20 =20 =20 =20 Best Regards, =20 =20 Akbar =20 =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Agrawal, Sachin Sent: Thursday, May 22, 2014 2:52 AM To: core@ietf.org Subject: [core] .well-known/core examples =20 Hi All, =20 I am trying to understand the examples mentioned in RFC 6690 (Section 5). =20 1) REQ: GET /.well-known/core =20 RES: 2.05 Content ;if=3D"sensor", ;if=3D"sensor" =20 When the client will get this response, since ip_address/hostname and port number is missing from the URI reference, should client assume that the host is the machine sending the response back and port number is the default coap port i.e. 5683? What happens if the client receives this response through a Proxy? =20 2) Also, another client may send this response to above query too: REQ: GET /.well-known/core =20 RES: 2.05 Content ;if=3D"sensor", ;if=3D"sensor" =20 In above scenario, client will retrieve the hostname and port number from the URI reference provided in the payload of Link Format. Please confirm? =20 Thanks Sachin =20 =20 ------_=_NextPart_001_01CF7607.A3F18C9B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sachin,

 

 

For your question: =

 

>When = the client will get this response, since ip_address/hostname and port = number is missing from the URI reference, should client assume that the = host  is the machine sending the response back and port number is = the default coap port i.e. 5683?

 

 

You can see part of the = answer  to your question in the 2nd paragraph of http://tools.ietf.o= rg/html/rfc6690#section-5 which was right before the example 1 that = you quoted.  Specifically, it says in that = paragraph:

 

   Note = that the default relation type for this

   link = format is "hosts" in links with no rel=3D target = attribute.  Thus,

   the = links in this example tell that the Origin server from = which

   = /.well-known/core was requested (the context) hosts the = resources

   = /sensors/temp and /sensors/light (each a = target).

 

In other words, this = means that the resources

 

</sensors/temp>,

</sensors/light>

 

 

are located at the = “Uri-Host” and the “Uri-Port”  that the GET = Request was sent to (i.e. Origin Server).  These terms are defined = in:

 

http://tools.ietf.org/html/draft-ietf-core-coap-18#section-5.10.1 =

 

also it is instructive = to look at:

 

ht= tp://tools.ietf.org/html/draft-ietf-core-coap-18#appendix-B

 

 

 

 

Best = Regards,

 

 

Akbar

 

 

From:= = core [mailto:core-bounces@ietf.org] On Behalf Of Agrawal, = Sachin
Sent: Thursday, May 22, 2014 2:52 AM
To: = core@ietf.org
Subject: [core] .well-known/core = examples

 

Hi = All,

 

I am trying to understand the examples mentioned in = RFC 6690 (Section 5).

 

1)

REQ: = GET /.well-known/core

 

RES: = 2.05 Content

</sensors/temp>;if=3D"sensor",

</sensors/light>;if=3D"sensor"

 

When the = client will get this response, since ip_address/hostname and port number = is missing from the URI reference, should client assume that the = host  is the machine sending the response back and port number is = the default coap port i.e. 5683?

What happens if the client receives this response = through a Proxy?

 

2)

Also, = another client may send this response to above query = too:

REQ: = GET /.well-known/core

 

RES: = 2.05 Content

<coap://192.168.1.25:9900/sensors/temp>;if=3D&quo= t;sensor",

<coap://192.168.1.25:9901/sensors/light>;if=3D&qu= ot;sensor"

 

In above = scenario, client will retrieve the hostname and port number from the URI = reference provided in the payload of Link Format. Please = confirm?

 

Thanks=

Sachin

 

 

------_=_NextPart_001_01CF7607.A3F18C9B-- From nobody Thu May 22 21:08:41 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7F91A008A for ; Thu, 22 May 2014 21:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 zZVGMz_yyuv3 for ; Thu, 22 May 2014 21:08:35 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 962351A0084 for ; Thu, 22 May 2014 21:08:35 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 22 May 2014 21:08:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,891,1392192000"; d="p7s'?scan'208,217";a="536405623" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by fmsmga001.fm.intel.com with ESMTP; 22 May 2014 21:05:13 -0700 Received: from orsmsx160.amr.corp.intel.com (10.22.226.43) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 22 May 2014 21:05:12 -0700 Received: from orsmsx104.amr.corp.intel.com ([169.254.3.166]) by ORSMSX160.amr.corp.intel.com ([169.254.13.252]) with mapi id 14.03.0123.003; Thu, 22 May 2014 21:05:12 -0700 From: "Agrawal, Sachin" To: "Rahman, Akbar" Thread-Topic: [core] .well-known/core examples Thread-Index: Ac91imIEZ1LOv1mbTte1Bs+0m1q6+AAWOnkwAAzdaHA= Date: Fri, 23 May 2014 04:05:12 +0000 Message-ID: <79C6EF6B5F50B3499DC017935C25A5BF2DBCC2AE@ORSMSX104.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A7_01CF7601.85483320" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/core/PUAHrVo42o8bnORxHo2i_ONFK_0 Cc: "core@ietf.org" Subject: Re: [core] .well-known/core examples 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, 23 May 2014 04:08:37 -0000 ------=_NextPart_000_00A7_01CF7601.85483320 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A8_01CF7601.85483320" ------=_NextPart_001_00A8_01CF7601.85483320 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Akbar, Thanks for responding. For resource discovery, "/.well-known/core" query will be send to default CoAP port i.e 5683. If the server hosts multiple resources on the same machine but at different ports, how will this be conveyed to clients? In short, does CoAP allows absolute URI in well-known responses? REQ: GET /.well-known/core RES: 2.05 Content ;if="sensor", ;if="sensor" The keyword 'relative URI' in line in Section 2.2 of RFC 6690 is creating confusion for me: "The target URI MUST be a relative URI of the context URI for this relation type." Thanks Sachin ------=_NextPart_001_00A8_01CF7601.85483320 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Akbar,

 

Thanks for = responding.

 

For resource discovery, = “/.well-known/core” query will be send to default CoAP port = i.e 5683.

If the server hosts multiple resources on the = same machine but at different ports, how will this be conveyed to = clients?

In short, does CoAP allows absolute URI in = well-known responses?

REQ: = GET /.well-known/core

 

RES: = 2.05 Content

<coap://192.168.1.25:9900/sensors/temp>;if=3D&quo= t;sensor",

<coap://192.168.1.25:9901/sensors/light>;if=3D&qu= ot;sensor"

 

The keyword = ‘relative URI’ in line in Section 2.2 of RFC 6690 is = creating confusion for me:

“=
The target URI MUST be a =
relative URI of the context URI for this relation =
type.”

 

Thanks

Sachin

------=_NextPart_001_00A8_01CF7601.85483320-- ------=_NextPart_000_00A7_01CF7601.85483320 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIhJDCCAyAw ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05 ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3 wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1 hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8 7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3 ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4 lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+ iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0 Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69 tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIENjCCAx6gAwIBAgIBATANBgkq hkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsT HUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5h bCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0D GuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6s YapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+7 10LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvd QwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAd BgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMB Af8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEF BQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYT x4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0 hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvCNr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1 n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9 F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQwggTrMIID06ADAgECAhBS6QLKEehE nZRlOC+jGjC7MA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVz dCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFk ZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTMwMzE5MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjB5 MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFDASBgNVBAcTC1NhbnRhIENsYXJhMRowGAYDVQQK ExFJbnRlbCBDb3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWlu ZyBDQSA0QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOCwzICd2ElV+gPbBPo4x92/ hd12vOs9yyyrv+lr4yHb1G8Z6M9qp75fVCkCN7BNc1EUMa34L7T9Gz4Ldbg8AHy3Oh+Xqp8ovuxa z7ExgkeIMA5qtVpE0IDQzV1IG+9Xvf+rH6vlnwg6YvEnGoJciwkae6Yf1etHG4rQb52RXpSggwYd 99kuiht2wHZzRgf75POm8A5WOqJg7Ov0bHzcM0FcKPzN6D67sesus8iKEbpX5FRDWzNP/Ua80Dpc iuFuVZOBBLH1to5QleFvN0CqkXHACiFMcNqvx6B1T22xE66y5hOkUWf/nlpZBlpfprceNhzoDpl9 AUXU0aPbx+8ngaMCAwEAAaOCAXcwggFzMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBQeaSq03Cj+RxhOIQs/vKwRL/CY9TAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/ BAgwBgEB/wIBADA2BgNVHSUELzAtBggrBgEFBQcDBAYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDDAYJ KwYBBAGCNxUFMBcGA1UdIAQQMA4wDAYKKoZIhvhNAQUBaTBJBgNVHR8EQjBAMD6gPKA6hjhodHRw Oi8vY3JsLnRydXN0LXByb3ZpZGVyLmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA6Bggr BgEFBQcBAQQuMCwwKgYIKwYBBQUHMAGGHmh0dHA6Ly9vY3NwLnRydXN0LXByb3ZpZGVyLmNvbTA1 BgNVHR4ELjAsoCowC4EJaW50ZWwuY29tMBugGQYKKwYBBAGCNxQCA6ALDAlpbnRlbC5jb20wDQYJ KoZIhvcNAQEFBQADggEBACnCzaP9kqNSZ6IvBu1uUOhUj6tX5silt7Eg39Wpr8h5IxIHduZ+zCkR xhJkccaM4jyqXJm312FPidIOetJwqOYDxe/Fne2Zs3JgnJtVBRXyMX8OkANfW0aUwvGzDGkkhJfM t/T4MGvhxDZqD2bDOtw3Wes4g5z6nEm3H2LPKnf5uXdtq6V6uSBlVLV+i1+0f4UksP97HwE5wS4I ibYpVcmOzhhpmCggEtiNOIrb0ktVrXnF07fTmQ8jW5ey7Tmwa4DC4WZKSVvqTkfX94eVRtkubipA O04fTQvRKEnHcEAgCMPlFim0kNCLI9lBS+3xyr5qlilUy/fLEc7yN7HjQuAwggWKMIIEcqADAgEC AgphIIpiAAAAAAAIMA0GCSqGSIb3DQEBBQUAMFIxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRl bCBDb3Jwb3JhdGlvbjEnMCUGA1UEAxMeSW50ZWwgRXh0ZXJuYWwgQmFzaWMgUG9saWN5IENBMB4X DTA5MDUxNTE5MjcyNloXDTE1MDUxNTE5MzcyNlowVjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUlu dGVsIENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENB IDNCMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApAQzVaf1NT29z0L79NzsoH56JgSW atwRYTfZZR0e9Yb4hxAdVCyKROYzIoqiM0vDYHmzoh6RzyK8Oj/AJ+NnNf0nJ+0ydz4ACtzSVrzs 6XJvObwr2NcR9MG9OdRIVKIj1lh58hN2JSCqUAW6WMVkQdgpi0u6GtFpymZB8/iZXrc0p1zZtPzT gdF/pim1kVriTpg33jOWsY2sG5BDvhYXPP+MsG6xtSkSSujoy79lgU4VZCtX2UGEX1G6TzI37c3q f19Sj+oGKCIXaQSf3FWHXKSXtIIYvaMFSRfHiqBXbtrpKLyVFF2Csca038dadJaUtdMfmXnvkfgu r77vs4W/fwIDAQABo4ICXDCCAlgwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUDsYq91myCBCQ JW/D3f2KZjEwK8UwCwYDVR0PBAQDAgGGMBIGCSsGAQQBgjcVAQQFAgMBAAEwIwYJKwYBBAGCNxUC BBYEFDmgVjZ6QpD/kq2Kb5V0x5JZvhBZMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1Ud IwQYMBaAFBrGDErER2+o260r8PRWBqPtN1QMMIG9BgNVHR8EgbUwgbIwga+ggayggamGTmh0dHA6 Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUy MFBvbGljeSUyMENBLmNybIZXaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9y eS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3JsMIHjBggrBgEF BQcBAQSB1jCB0zBjBggrBgEFBQcwAoZXaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9j ZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MGwG CCsGAQUFBzAChmBodHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRp ZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3klMjBDQS5jcnQwDQYJKoZI hvcNAQEFBQADggEBALG1AQdyFVCFfKMSq0xVQx7qCSY+whzMfFJ6o1uj12wP7rFtPrklP6hiCkgC 18Sxhd5Qm7VwKGqlvbZTlswDPt5pBxblvN5+59a8DqWDbTjwHyhzMGP+r7k/k2litQ7yM6Y3iNON 8mrcSVnvIVanLusHdWb9o3oBNipZ8xtL/F+H4kLGYfd2uhSYwkjT9pkkewu2NuMWc2wcM2sllfW/ GUzvwtvWGOyRMQ0+aFtVt9OPmL9kaeG/i2YjxBk8I21x6Bcmt+FGXYP1tal1M4+taIsNSrPLVnoo vtNw5L88KXxEcIleQ9q7+2FNAKkigNrb5z7dcD76BFN8BDiy9M7brQ0wggWPMIIEd6ADAgECAgoR zN6TAAEAAIenMA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBD b3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQjAe Fw0xMjAxMjUxNDAzNDFaFw0xNTAxMDkxNDAzNDFaMEMxGDAWBgNVBAMTD0FncmF3YWwsIFNhY2hp bjEnMCUGCSqGSIb3DQEJARYYc2FjaGluLmFncmF3YWxAaW50ZWwuY29tMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQChgDxKzx0avb5V86d24U9udKIRiz6yuLarL/3cBROmBHWEjuH9FmD1vIV7 GInXoB7AVO2CX1FPmBC986n9q1jdLcF0/Cam+JVYCXbiJ4H54mGkPW/gjt1hdO+2K/c6pK1B78x0 cPADmoz1+KkrxSgQV2ZVY709NR8BvPWuQd1sUwIDAQABo4IC9DCCAvAwPAYJKwYBBAGCNxUHBC8w LQYlKwYBBAGCNxUIhsOMdYSZ5VGD/YEohY6fU4KRwAlngd69OZXwQwIBZAIBCDAfBgNVHSUEGDAW BggrBgEFBQcDBAYKKwYBBAGCNwoDDDALBgNVHQ8EBAMCB4AwKQYJKwYBBAGCNxUKBBwwGjAKBggr BgEFBQcDBDAMBgorBgEEAYI3CgMMMB0GA1UdDgQWBBTs17ERvljENOCifKjBrxk8sL0drjAfBgNV HSMEGDAWgBQOxir3WbIIEJAlb8Pd/YpmMTArxTCBzwYDVR0fBIHHMIHEMIHBoIG+oIG7hldodHRw Oi8vd3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMl MjBJc3N1aW5nJTIwQ0ElMjAzQigxKS5jcmyGYGh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29t L3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUy MDNCKDEpLmNybDCB9QYIKwYBBQUHAQEEgegwgeUwbAYIKwYBBQUHMAKGYGh0dHA6Ly93d3cuaW50 ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUy MElzc3VpbmclMjBDQSUyMDNCKDEpLmNydDB1BggrBgEFBQcwAoZpaHR0cDovL2NlcnRpZmljYXRl cy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJh c2ljJTIwSXNzdWluZyUyMENBJTIwM0IoMSkuY3J0ME0GA1UdEQRGMESgKAYKKwYBBAGCNxQCA6Aa DBhzYWNoaW4uYWdyYXdhbEBpbnRlbC5jb22BGHNhY2hpbi5hZ3Jhd2FsQGludGVsLmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAfHMiw40/nu5K+w4UT6kWN45C6qhLperJQTl5hhvmdhsIoXDF7+wwiZoZ moDuHfeH89gqxW7Ftc2auCqLSBOLZfCyrIGUYIBP2kCKJ0TqZnRilA72P7p5rn1bMeTxgNaGlGMV JFPnUdQtKs7XUpXexySZS/Z9+eWyGcobtQHzsy5WctynlGZ0Wtv2YWmAOFSfq6RAFyeUgjVu8AY2 AuQkkmyBxO9Q9MIOsSKbFJArHZ9JA5nX/z0O/4rrYpl/se4YIkyvC5T1B02z/ZzHckS5WHUFZRUL mrfuAvM69ZX3ttEtWNUyKwKBz28EBJxvFOu9NS9o44k0SPbsYXAX7H1kaDCCBnEwggVZoAMCAQIC CnRNNvoAAAAAOyowDQYJKoZIhvcNAQEFBQAweTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRQw EgYDVQQHEwtTYW50YSBDbGFyYTEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMT IkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgNEEwHhcNMTMxMTI1MDIzMTA3WhcNMTYx MTA5MDIzMTA3WjBDMRgwFgYDVQQDEw9BZ3Jhd2FsLCBTYWNoaW4xJzAlBgkqhkiG9w0BCQEWGHNh Y2hpbi5hZ3Jhd2FsQGludGVsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOLk qAmyOu2Cvv/ndH7ZFkOxEPgXpfFe9laSPmm5MTYEt6g4go+E0rdM7PAqbNOtINcJWU0wxxJUEBNq Pg4+zK8hVmGugxHw98maL8vm3/Glcc4adjVVhAPeQk5IfQN9fLviv3Jest0epQfQFwB5dYUc3uYR Kd4v8hC4YvgZR5BsqB/7oYJ7ipzfo51ie5++vC5sZTXIZdUPxCas4Uc2IGAmEmW1a277JPC/GcNB rv2WdAguttZiSmMzi95Dbij/wkRH6d7SKWmPhmqRItqsv7Z2C/vJY4ExBNtdf9Z8e9V2Gtl5FwHi +Wf+pY+HQLgcEQSx6Isd9zYPIFnanehl8q8CAwEAAaOCAy8wggMrMAsGA1UdDwQEAwIEMDA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiGw4x1hJnlUYP9gSiFjp9TgpHACWeEudlBh4T/TgIBZAIB DTBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4D AgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFDetOgCrA/wWcJRUIz+haN8D/KCTMB8GA1UdIwQYMBaA FB5pKrTcKP5HGE4hCz+8rBEv8Jj1MIHJBgNVHR8EgcEwgb4wgbuggbiggbWGVGh0dHA6Ly93d3cu aW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3Vp bmclMjBDQSUyMDRBLmNybIZdaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9y eS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENBJTIwNEEuY3JsMIHv BggrBgEFBQcBAQSB4jCB3zBpBggrBgEFBQcwAoZdaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3Np dG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENB JTIwNEEuY3J0MHIGCCsGAQUFBzAChmZodHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNvbS9yZXBv c2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIw Q0ElMjA0QS5jcnQwHwYDVR0lBBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwKQYJKwYBBAGCNxUK BBwwGjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEME0GA1UdEQRGMESgKAYKKwYBBAGCNxQCA6Aa DBhzYWNoaW4uYWdyYXdhbEBpbnRlbC5jb22BGHNhY2hpbi5hZ3Jhd2FsQGludGVsLmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAEi+FRHWtJgJkCQuUEDTYr6py8WSP1a9un1o+rsLvoJUoIW+LMueUGeIv Zznnkpg+QE/cU+pF4L3rFQqXuyfjRZtvAHD9ktf6AP4ER+k0mFAN8inX4oVVQjpS+SPWPaKEZa4c 3/UV6xm4E15YuktZE+r68ZP6oAJOcU5JmaCrDkP1z8JTkaF2QWiNdeFP+ONk8e0O1uBjD3io6ucf JTMQD0fDM+VB5K3LXySg+zN4HRYwrOG/r2SfFBwvYTr1wGBUYU99BfW1ugRqRjPjxz6TnDGhqRtD +S7iV4P7vuydkJkt8ix4FJHkhE+Oasy4bdVn87HlPTrq0ii26MYhb+3AmTGCA1EwggNNAgEBMGQw VjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRl bCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDNCAgoRzN6TAAEAAIenMAkGBSsOAwIaBQCgggJD MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDUyMzA0MDUxMlow IwYJKoZIhvcNAQkEMRYEFH6myzOy75kGRbg3ro2jiBUCXE/vMIGYBgkrBgEEAYI3EAQxgYowgYcw eTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRQwEgYDVQQHEwtTYW50YSBDbGFyYTEaMBgGA1UE ChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3Vp bmcgQ0EgNEECCnRNNvoAAAAAOyowgZoGCyqGSIb3DQEJEAILMYGKoIGHMHkxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJDQTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExGjAYBgNVBAoTEUludGVsIENvcnBv cmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDRBAgp0TTb6 AAAAADsqMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIGAfbOGSJGlcRS7PYOhH5dMJyyXDDduSTnXFZM1783i dliniEj6G0rmkjfIGE2BqoXCp0SE1KHOepgQDuK8081Y6MldMlnuDnrf5Fj1RZ8wEDPr17QzZyP6 EBbc6mvV8gxMZPVoqr0jwY0WYAZ2f5Lspipdu4y6Ls7KLLPhv9zB5JQAAAAAAAA= ------=_NextPart_000_00A7_01CF7601.85483320-- From nobody Fri May 23 11:02:46 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7761A0218 for ; Fri, 23 May 2014 11:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 Gb81q2LoBSdS for ; Fri, 23 May 2014 11:02:43 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id E7BD71A01E0 for ; Fri, 23 May 2014 11:02:42 -0700 (PDT) X-ASG-Debug-ID: 1400868159-06daaa09ee1b9360001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id qrPT5rbRJlFDZREv for ; Fri, 23 May 2014 14:02:39 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 May 2014 14:02:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CF76B1.2D83324B" Date: Fri, 23 May 2014 14:02:35 -0400 X-ASG-Orig-Subj: RE: [core] .well-known/core examples Message-ID: In-Reply-To: <79C6EF6B5F50B3499DC017935C25A5BF2DBCC2AE@ORSMSX104.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] .well-known/core examples Thread-Index: Ac91imIEZ1LOv1mbTte1Bs+0m1q6+AAWOnkwAAzdaHAAJd+sYA== References: <79C6EF6B5F50B3499DC017935C25A5BF2DBCC2AE@ORSMSX104.amr.corp.intel.com> From: "Rahman, Akbar" To: "Agrawal, Sachin" X-OriginalArrivalTime: 23 May 2014 18:02:37.0431 (UTC) FILETIME=[2E40A070:01CF76B1] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1400868159 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.6059 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/core/45m1qSwFuPuxbomryBMfKDreUt8 Cc: core@ietf.org Subject: Re: [core] .well-known/core examples 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, 23 May 2014 18:02:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CF76B1.2D83324B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sachin, =20 =20 >In short, does CoAP allows absolute URI in well-known responses? =20 Yes. =20 =20 I also find RFC 6690 terminology a bit dense and hard to follow. But there is a nice example in the RD draft that is similar (but not identical) to the question that you are asking. (The key point to note is that queries to the RD results in a CoAP Response that contains a list of links in Core Link Format). =20 http://tools.ietf.org/html/draft-ietf-core-resource-directory-01#section -7 =20 Req: GET /rd-lookup/ep?et=3Dpower-node =20 Res: 2.05 Content ;ep=3D"node5", ;ep=3D"node7" =20 =20 And of course Zach/Carsten will quickly correct me if I have misinterpreted any of the RFC/drafts! =20 =20 Best Regards, =20 =20 =20 Akbar =20 =20 =20 From: Agrawal, Sachin [mailto:sachin.agrawal@intel.com]=20 Sent: Friday, May 23, 2014 12:05 AM To: Rahman, Akbar Cc: core@ietf.org Subject: RE: [core] .well-known/core examples =20 Hi Akbar, =20 Thanks for responding. =20 For resource discovery, "/.well-known/core" query will be send to default CoAP port i.e 5683. If the server hosts multiple resources on the same machine but at different ports, how will this be conveyed to clients? In short, does CoAP allows absolute URI in well-known responses? REQ: GET /.well-known/core =20 RES: 2.05 Content ;if=3D"sensor", ;if=3D"sensor" =20 The keyword 'relative URI' in line in Section 2.2 of RFC 6690 is creating confusion for me: "The target URI MUST be a relative URI of the context URI for this relation type." =20 Thanks Sachin ------_=_NextPart_001_01CF76B1.2D83324B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sachin,

 

 

>In short, does CoAP = allows absolute URI in well-known responses?

 

Yes.  =

 

I also find RFC 6690 = terminology a bit dense and hard to follow.  But there is a nice = example in the RD draft that is similar (but not identical) to the = question that you are asking.  (The key point to note is that = queries to the RD results in a CoAP Response that contains a list of = links in Core Link Format).

 

http://tools.ietf.org/html/draft-ietf-core-resource-directory-= 01#section-7

 

  Req: GET = /rd-lookup/ep?et=3Dpower-node

 

   Res: 2.05 = Content

   = <coap://{ip:port}>;ep=3D"node5",

   = <coap://{ip:port}>;ep=3D"node7"

 

 

And of course Zach/Carsten = will quickly correct me if I have misinterpreted any of the = RFC/drafts!

 

 

Best = Regards,

 

 

 

Akbar

 

 

 

From:= = Agrawal, Sachin [mailto:sachin.agrawal@intel.com]
Sent: = Friday, May 23, 2014 12:05 AM
To: Rahman, Akbar
Cc: = core@ietf.org
Subject: RE: [core] .well-known/core = examples

 

Hi Akbar,

 

Thanks for = responding.

 

For resource discovery, = “/.well-known/core” query will be send to default CoAP port = i.e 5683.

If the server hosts multiple resources on the = same machine but at different ports, how will this be conveyed to = clients?

In short, does CoAP allows absolute URI in = well-known responses?

REQ: = GET /.well-known/core

 

RES: = 2.05 Content

<coap://192.168.1.25:9900/sensors/temp>;if=3D&quo= t;sensor",

<coap://192.168.1.25:9901/sensors/light>;if=3D&qu= ot;sensor"

 

The keyword = ‘relative URI’ in line in Section 2.2 of RFC 6690 is = creating confusion for me:

“=
The target URI MUST be a =
relative URI of the context URI for this relation =
type.”

 

Thanks

Sachin

------_=_NextPart_001_01CF76B1.2D83324B-- From nobody Sat May 24 12:57:09 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CF31A0234; Sat, 24 May 2014 12:57:03 -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 ioq_rmuxWg2D; Sat, 24 May 2014 12:57:01 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10681A00E9; Sat, 24 May 2014 12:57:01 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id rq2so5697036pbb.31 for ; Sat, 24 May 2014 12:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=9RO++K0OWbFxTiayomoorYxAqk3cil39aDD/GpbnvPE=; b=U/n4YRVmVc7VHCN6pl14GEUAsX/N8G47vMENGKoMoL+G3jUm1GVxo9HeqCJpJZS1OV hvEfFEqCJFdAhtQ8qweKX45OP076yObppu/aeH+xFgqM0RPUIImGThwuqB/N/SY1nTU5 3kdiCjHf1Wgse2JJ2ikT9eZYcoGXmG1veU2siMNgJw1gkjdciqQbgDrUkxNxUX0yijtE QgzuESYf0eLO7h9ie1qAI5AOZ93tfomQ4+7WWNU0LgS3oshYimIp0Lm60SMYYnG10UEA oVVWIqQWdo8WxGgHfbqD/T741U+D61MBa+vLifILDX7sJqELIWpjrCd+oq5G2XVbzBbK DANA== X-Received: by 10.68.178.131 with SMTP id cy3mr16370840pbc.146.1400961419708; Sat, 24 May 2014 12:56:59 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.154.130 with HTTP; Sat, 24 May 2014 12:56:39 -0700 (PDT) In-Reply-To: <1400824911.93819.YahooMailNeo@web120005.mail.ne1.yahoo.com> References: <1399510956.31595.YahooMailNeo@web120001.mail.ne1.yahoo.com> <1400824911.93819.YahooMailNeo@web120005.mail.ne1.yahoo.com> From: Thomas Watteyne Date: Sat, 24 May 2014 12:56:39 -0700 X-Google-Sender-Auth: 4hJ2P7F_czpR3un0sfAyNnN0JF8 Message-ID: To: "6tisch@ietf.org" <6tisch@ietf.org>, core@ietf.org Content-Type: multipart/alternative; boundary=047d7b6735eac4103404fa2abf66 Archived-At: http://mailarchive.ietf.org/arch/msg/core/P37PPHjtp5J5FO1ML5L254bI-hw Subject: Re: [core] [6tisch] How to use Uri-path option while Block option is used? 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, 24 May 2014 19:57:03 -0000 --047d7b6735eac4103404fa2abf66 Content-Type: text/plain; charset=UTF-8 Qin, Correct me if I'm wrong, but you're saying that, in "Figure 7: Simple atomic blockwise PUT" [1], since the PUT operation is atomic, the SERVER will have to keep track of the progress of the exchange, so might as well remember that MID=1234 corresponds to /options, and therefore not include the Uri-path option in each transaction? This is really a question for CORE, I'm CC'ing the CORE ML. Thomas [1] http://tools.ietf.org/html/draft-ietf-core-block-14#page-19 On Thu, May 22, 2014 at 11:01 PM, Qin Wang wrote: > Hi Thomas, > > Please see Figure 7 and Figure 8 in > http://tools.ietf.org/html/draft-ietf-core-block-14. They define "Simple > atomic blockwise PUT" and "Simple stateless blockwise PUT", respectively. I > guess in the first case, it is not necessary to include uri-path option in > each PUT message. > > We really need somebody to confirm it. > > Thanks > Qin > > > On Friday, May 23, 2014 7:40 AM, Thomas Watteyne < > watteyne@eecs.berkeley.edu> wrote: > > > Qin, > > AFAIK, the Uri-path needs to be present in each PUT message to satisfy the > following statements from > http://tools.ietf.org/html/draft-ietf-core-block-14: > > the Block options > enable a server to be truly stateless: the server can handle each > block transfer separately, with no need for a connection setup or > other server-side memory of previous block transfers. > > > The overriding objective is to avoid the need > for creating conversation state at the server for block-wise GET > requests. > > > Any Block option gurus can confirm? Carsten? Zach? > > Thomas > > > On Wed, May 7, 2014 at 6:02 PM, Qin Wang wrote: > > Hi All, > > I have a question about how to use Uri-path option if we use Block option > to do fragmentation. > > Take Figure 7 in draft-ietf-core-block-14 as example. > ============================================= > CLIENT SERVER > | | > | CON [MID=1234], PUT, /options, 1:0/1/128 ------> | > | | > | <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 | > | | > | CON [MID=1235], PUT, /options, 1:1/1/128 ------> | > | | > | <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 | > | | > | CON [MID=1236], PUT, /options, 1:2/0/128 ------> | > | | > | <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 | > > Figure 7: Simple atomic blockwise PUT > > ============================================= > > In my imagination, Uri-path option, which tells SERVER the resource, > will be only in the first PUT message, i.e. CON[MID=1234], and CON > [MID=1235], CON [MID=1235] will not include Uri-path option. Correct? > > Thanks > Qin > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > > > --047d7b6735eac4103404fa2abf66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Qin,

Correct me if I'm wrong,= but you're saying that, in "Figure 7: Simple atomic blockwise PUT= " [1], since the PUT operation is atomic, the SERVER will have to keep= track of the progress of the exchange, so might as well remember that MID= =3D1234 corresponds to /options, and therefore not include the Uri-path opt= ion in each transaction?

This is really a question for CORE, I'm CC'ing the C= ORE ML.

Thomas

[1]=C2=A0<= a href=3D"http://tools.ietf.org/html/draft-ietf-core-block-14#page-19">http= ://tools.ietf.org/html/draft-ietf-core-block-14#page-19


On Thu, May 2= 2, 2014 at 11:01 PM, Qin Wang <qinwang6top@yahoo.com> wr= ote:
Hi Thomas,

Please see Figure 7 and Figure 8 in=C2=A0=C2=A0http://tools.ietf.org/html/draft-ietf-core-block-14= . They define "Simple atomic blockwise PUT" and "S= imple stateless blockwise PUT", respectively. I guess in the first cas= e, it is not necessary to include uri-path option in each PUT message.

We really need somebody to confirm it.

Thanks
Qin


On Friday, May 23, 2014 7:40 AM, T= homas Watteyne <watteyne@eecs.berkeley.edu> wrote:

<= br>
Qin,

AFAIK, th= e Uri-path needs to be present in each PUT message to satisfy the following statements from=C2= =A0http://tools.ietf.org/html/draft-= ietf-core-block-14:

the Blo= ck options
enable a server to be truly st= ateless: the server can handle each
block transfer separately, with no need for a conne= ction setup or
other server-side memory of pr= evious block transfers.

The overriding objective is to avoid = the need
for creating conversation state at the server fo= r block-wise GET
requests.
=
Any Block option gurus can confirm? Carsten? Zach?

Thomas


On Wed, May 7, 2014 at 6:02 PM, Qin Wang <qinwang6top@yahoo.com> wrote:
Hi All,

I have a question about how to use Uri-path option if we use= Block option to do fragmentation.=C2=A0

Take Figure 7 in=C2=A0draft-ietf-core-block-14 as example.
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
CLIENT =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SERVER
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
| CON [MID=3D1234], PUT, /optio= ns, 1:0/1/128 ------> |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
<= div style=3D"background-color:transparent">| <------ ACK [MID=3D1234], 2= .31 Continue, 1:0/1/128 |
= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
| CON [MID=3D1235], PUT, /optio= ns, 1:1/1/128 ------> |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
| <---= --- ACK [MID=3D1235], 2.31 Continue, 1:1/1/128 |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
| CON [MID=3D1236], PUT, /optio= ns, 1:2/0/128 ------> |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
| <------ ACK [MID=3D1236], = 2.04 Changed, 1:2/0/128 |

=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 7: Simple atomic blockwise PUT

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
<= br clear=3D"none">
In my imagination,=C2=A0Uri-path option, whi= ch tells SERVER the resource, will be only=C2=A0in the first PUT message, i.e. CON[MID=3D1234], an= d CON [MID=3D1235],=C2=A0CON [MID=3D1235] = will not include Uri-path option. Correct?

Thanks
Qin

=C2=A0

__________________________= _____________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisc= h


=

=
--047d7b6735eac4103404fa2abf66-- From nobody Sat May 24 13:07:11 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802EC1A0037; Sat, 24 May 2014 13:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE3ULN188uP4; Sat, 24 May 2014 13:07:05 -0700 (PDT) Received: from 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 A5FED1A0029; Sat, 24 May 2014 13:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s4OK6n0j021215; Sat, 24 May 2014 22:06:49 +0200 (CEST) Received: from [192.168.217.148] (p54892C9D.dip0.t-ipconnect.de [84.137.44.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 79EAC1DFD; Sat, 24 May 2014 22:06:48 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Carsten Bormann In-Reply-To: Date: Sat, 24 May 2014 22:06:46 +0200 X-Mao-Original-Outgoing-Id: 422654806.498407-b5cb39b0ae6c44ecbbfcdfef62ed6f0d Content-Transfer-Encoding: quoted-printable Message-Id: <399C3018-4668-4EAE-B8DA-00DF3DA1988A@tzi.org> References: <1399510956.31595.YahooMailNeo@web120001.mail.ne1.yahoo.com> <1400824911.93819.YahooMailNeo@web120005.mail.ne1.yahoo.com> To: Thomas Watteyne X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/core/2lZYEqyor36lmpUGI32EwMKwYFc Cc: "6tisch@ietf.org" <6tisch@ietf.org>, core@ietf.org Subject: Re: [core] [6tisch] How to use Uri-path option while Block option is used? 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, 24 May 2014 20:07:06 -0000 I haven=92t followed the conversation, but I can confirm that all = exchanges that constitute a blockwise transfer need to carry the request = options that indicate what blockwise transfer this is is a part of. So = you do have to repeat the Uri-Path. The message-ID is not useful for linking together the requests of a = blockwise transfer; there is no requirement for these to be sequential = (e.g., you might be interspersing a different request). It is even = possible to have multiple blockwise transfers going on from one client = to one server (I wouldn=92t recommend designing for that, but it might = happen that way e.g. at a proxy). I=92ll try to clarify this some more in the next version of -block. I wonder how -block has become so important for 6tisch. Shouldn=92t the = 6tisch exchanges be rather short? Gr=FC=DFe, Carsten On 24 May 2014, at 21:56, Thomas Watteyne = wrote: > Qin, >=20 > Correct me if I'm wrong, but you're saying that, in "Figure 7: Simple = atomic blockwise PUT" [1], since the PUT operation is atomic, the SERVER = will have to keep track of the progress of the exchange, so might as = well remember that MID=3D1234 corresponds to /options, and therefore not = include the Uri-path option in each transaction? >=20 > This is really a question for CORE, I'm CC'ing the CORE ML. >=20 > Thomas >=20 > [1] http://tools.ietf.org/html/draft-ietf-core-block-14#page-19 >=20 >=20 > On Thu, May 22, 2014 at 11:01 PM, Qin Wang = wrote: > Hi Thomas, >=20 > Please see Figure 7 and Figure 8 in = http://tools.ietf.org/html/draft-ietf-core-block-14. They define "Simple = atomic blockwise PUT" and "Simple stateless blockwise PUT", = respectively. I guess in the first case, it is not necessary to include = uri-path option in each PUT message. >=20 > We really need somebody to confirm it. >=20 > Thanks > Qin >=20 >=20 > On Friday, May 23, 2014 7:40 AM, Thomas Watteyne = wrote: >=20 >=20 > Qin, >=20 > AFAIK, the Uri-path needs to be present in each PUT message to satisfy = the following statements from = http://tools.ietf.org/html/draft-ietf-core-block-14: >=20 > the Block options > enable a server to be truly stateless: the server can handle each > block transfer separately, with no need for a connection setup or > other server-side memory of previous block transfers. >=20 > The overriding objective is to avoid the need > for creating conversation state at the server for block-wise GET > requests. >=20 > Any Block option gurus can confirm? Carsten? Zach? >=20 > Thomas >=20 >=20 > On Wed, May 7, 2014 at 6:02 PM, Qin Wang = wrote: > Hi All, >=20 > I have a question about how to use Uri-path option if we use Block = option to do fragmentation.=20 >=20 > Take Figure 7 in draft-ietf-core-block-14 as example. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > CLIENT SERVER > | = | > | CON [MID=3D1234], PUT, /options, 1:0/1/128 ------> | > | = | > | <------ ACK [MID=3D1234], 2.31 Continue, 1:0/1/128 | > | = | > | CON [MID=3D1235], PUT, /options, 1:1/1/128 ------> | > | = | > | <------ ACK [MID=3D1235], 2.31 Continue, 1:1/1/128 | > | = | > | CON [MID=3D1236], PUT, /options, 1:2/0/128 ------> | > | = | > | <------ ACK [MID=3D1236], 2.04 Changed, 1:2/0/128 | >=20 > Figure 7: Simple atomic blockwise PUT >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > In my imagination, Uri-path option, which tells SERVER the resource, = will be only in the first PUT message, i.e. CON[MID=3D1234], and CON = [MID=3D1235], CON [MID=3D1235] will not include Uri-path option. = Correct? >=20 > Thanks > Qin >=20 > =20 >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sat May 24 13:15:25 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D7D1A0037; Sat, 24 May 2014 13:15:21 -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 9T1DYOi_9s7j; Sat, 24 May 2014 13:15:19 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972421A0029; Sat, 24 May 2014 13:15:19 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id lj1so5646600pab.22 for ; Sat, 24 May 2014 13:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=BOtCOvkw242yW+0a/dFt7fB1oeg5KQKcT7UIe1Z8Nr8=; b=kGh7wX4nyEqwB4rIjNftm37q2JcUjP8aJxZlDr4qTcUv6l/KMk4jLNN+ONHYYWsYG+ /hK6Kt6k5nFD+9R9aT0rMXmr9JlpRl+dCb7/lMXpdx+QmqXZ/TxcBpb+OEk79jnSDoS9 CzjIZz7oDXR9rsN/OuuWVdq3C2euA6mygfBfY4AzvcyqsfJ1/TZetq8zHUvXPRIDyr1X UfFY+pTWpoJbVN6Qe6OwgYhAkrh4XhsGP/ZgSFoDx4Q2RdNw9YdNJdN74IqlMuKzPk/z Vlp7FR2MgBrSCWDXN+LaeFufGVJ0LFPYmc3MLlxIBB5VcPB7FChxv8Z1WkblhtfKD/if rBHQ== X-Received: by 10.68.178.131 with SMTP id cy3mr16451102pbc.146.1400962517476; Sat, 24 May 2014 13:15:17 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.154.130 with HTTP; Sat, 24 May 2014 13:14:57 -0700 (PDT) In-Reply-To: <399C3018-4668-4EAE-B8DA-00DF3DA1988A@tzi.org> References: <1399510956.31595.YahooMailNeo@web120001.mail.ne1.yahoo.com> <1400824911.93819.YahooMailNeo@web120005.mail.ne1.yahoo.com> <399C3018-4668-4EAE-B8DA-00DF3DA1988A@tzi.org> From: Thomas Watteyne Date: Sat, 24 May 2014 13:14:57 -0700 X-Google-Sender-Auth: VnDy8zA2i1Vsr96RZ-fUOpC6S9c Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=047d7b6735ea32ab8304fa2b01fb Archived-At: http://mailarchive.ietf.org/arch/msg/core/Y14X2zHmDoN4QL62ezYkGVkK99Q Cc: "6tisch@ietf.org" <6tisch@ietf.org>, core Subject: Re: [core] [6tisch] How to use Uri-path option while Block option is used? 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, 24 May 2014 20:15:21 -0000 --047d7b6735ea32ab8304fa2b01fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Carsten, Thanks for the quick reply, this is very clear. Qin, can you confirm this answers the question you had? The 6TiSCH WG is exploring the idea of using CoAP for neighbor-to-neighbor communication, to enable distributed management. Ideally, the exchanges involved are very short (and we expect the vast majority to be); in the rare cases they're not, we were looking at Block transfer. Thomas On Sat, May 24, 2014 at 1:06 PM, Carsten Bormann wrote: > I haven=E2=80=99t followed the conversation, but I can confirm that all e= xchanges > that constitute a blockwise transfer need to carry the request options th= at > indicate what blockwise transfer this is is a part of. So you do have to > repeat the Uri-Path. > > The message-ID is not useful for linking together the requests of a > blockwise transfer; there is no requirement for these to be sequential > (e.g., you might be interspersing a different request). It is even > possible to have multiple blockwise transfers going on from one client to > one server (I wouldn=E2=80=99t recommend designing for that, but it might= happen > that way e.g. at a proxy). > > I=E2=80=99ll try to clarify this some more in the next version of -block. > > I wonder how -block has become so important for 6tisch. Shouldn=E2=80=99= t the > 6tisch exchanges be rather short? > > Gr=C3=BC=C3=9Fe, Carsten > > > > On 24 May 2014, at 21:56, Thomas Watteyne > wrote: > > > Qin, > > > > Correct me if I'm wrong, but you're saying that, in "Figure 7: Simple > atomic blockwise PUT" [1], since the PUT operation is atomic, the SERVER > will have to keep track of the progress of the exchange, so might as well > remember that MID=3D1234 corresponds to /options, and therefore not inclu= de > the Uri-path option in each transaction? > > > > This is really a question for CORE, I'm CC'ing the CORE ML. > > > > Thomas > > > > [1] http://tools.ietf.org/html/draft-ietf-core-block-14#page-19 > > > > > > On Thu, May 22, 2014 at 11:01 PM, Qin Wang > wrote: > > Hi Thomas, > > > > Please see Figure 7 and Figure 8 in > http://tools.ietf.org/html/draft-ietf-core-block-14. They define "Simple > atomic blockwise PUT" and "Simple stateless blockwise PUT", respectively.= I > guess in the first case, it is not necessary to include uri-path option i= n > each PUT message. > > > > We really need somebody to confirm it. > > > > Thanks > > Qin > > > > > > On Friday, May 23, 2014 7:40 AM, Thomas Watteyne < > watteyne@eecs.berkeley.edu> wrote: > > > > > > Qin, > > > > AFAIK, the Uri-path needs to be present in each PUT message to satisfy > the following statements from > http://tools.ietf.org/html/draft-ietf-core-block-14: > > > > the Block options > > enable a server to be truly stateless: the server can handle each > > block transfer separately, with no need for a connection setup or > > other server-side memory of previous block transfers. > > > > The overriding objective is to avoid the need > > for creating conversation state at the server for block-wise GET > > requests. > > > > Any Block option gurus can confirm? Carsten? Zach? > > > > Thomas > > > > > > On Wed, May 7, 2014 at 6:02 PM, Qin Wang wrote: > > Hi All, > > > > I have a question about how to use Uri-path option if we use Block > option to do fragmentation. > > > > Take Figure 7 in draft-ietf-core-block-14 as example. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > CLIENT SERVER > > | = | > > | CON [MID=3D1234], PUT, /options, 1:0/1/128 ------> | > > | = | > > | <------ ACK [MID=3D1234], 2.31 Continue, 1:0/1/128 | > > | = | > > | CON [MID=3D1235], PUT, /options, 1:1/1/128 ------> | > > | = | > > | <------ ACK [MID=3D1235], 2.31 Continue, 1:1/1/128 | > > | = | > > | CON [MID=3D1236], PUT, /options, 1:2/0/128 ------> | > > | = | > > | <------ ACK [MID=3D1236], 2.04 Changed, 1:2/0/128 | > > > > Figure 7: Simple atomic blockwise PUT > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > In my imagination, Uri-path option, which tells SERVER the resource, > will be only in the first PUT message, i.e. CON[MID=3D1234], and CON > [MID=3D1235], CON [MID=3D1235] will not include Uri-path option. Correct? > > > > Thanks > > Qin > > > > > > > > _______________________________________________ > > 6tisch mailing list > > 6tisch@ietf.org > > https://www.ietf.org/mailman/listinfo/6tisch > > > > > > > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > --047d7b6735ea32ab8304fa2b01fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carsten,

Thanks for the quick reply, th= is is very clear. Qin, can you confirm this answers the question you had?

The 6TiSCH WG is exploring the idea of using CoAP f= or neighbor-to-neighbor communication, to enable distributed management. Id= eally, the exchanges involved are very short (and we expect the vast majori= ty to be); in the rare cases they're not, we were looking at Block tran= sfer.

Thomas




On Sat, May 24, 2014= at 1:06 PM, Carsten Bormann <cabo@tzi.org> wrote:
I haven=E2=80=99t followed the conversation,= but I can confirm that all exchanges that constitute a blockwise transfer = need to carry the request options that indicate what blockwise transfer thi= s is is a part of. =C2=A0So you do have to repeat the Uri-Path.

The message-ID is not useful for linking together the requests of a blockwi= se transfer; there is no requirement for these to be sequential (e.g., you = might be interspersing a different request). =C2=A0It is even possible to h= ave multiple blockwise transfers going on from one client to one server (I = wouldn=E2=80=99t recommend designing for that, but it might happen that way= e.g. at a proxy).

I=E2=80=99ll try to clarify this some more in the next version of -block.
I wonder how -block has become so important for 6tisch. =C2=A0Shouldn=E2=80= =99t the 6tisch exchanges be rather short?

Gr=C3=BC=C3=9Fe, Carsten



On 24 May 2014, at 21:56, Thomas Watteyne <watteyne@eecs.berkeley.edu> wrote:

> Qin,
>
> Correct me if I'm wrong, but you're saying that, in "Figu= re 7: Simple atomic blockwise PUT" [1], since the PUT operation is ato= mic, the SERVER will have to keep track of the progress of the exchange, so= might as well remember that MID=3D1234 corresponds to /options, and theref= ore not include the Uri-path option in each transaction?
>
> This is really a question for CORE, I'm CC'ing the CORE ML. >
> Thomas
>
> [1] http://tools.ietf.org/html/draft-ietf-core-block-14= #page-19
>
>
> On Thu, May 22, 2014 at 11:01 PM, Qin Wang <qinwang6top@yahoo.com> wrote:
> Hi Thomas,
>
> Please see Figure 7 and Figure 8 in =C2=A0http://tools.ietf.org= /html/draft-ietf-core-block-14. They define "Simple atomic blockwi= se PUT" and "Simple stateless blockwise PUT", respectively. = I guess in the first case, it is not necessary to include uri-path option i= n each PUT message.
>
> We really need somebody to confirm it.
>
> Thanks
> Qin
>
>
> On Friday, May 23, 2014 7:40 AM, Thomas Watteyne <watteyne@eecs.berkeley.edu> wrote:
>
>
> Qin,
>
> AFAIK, the Uri-path needs to be present in each PUT message to satisfy= the following statements from http://tools.ietf.org/html/draft-ietf= -core-block-14:
>
> the Block options
> enable a server to be truly stateless: the server can handle each
> block transfer separately, with no need for a connection setup or
> other server-side memory of previous block transfers.
>
> The overriding objective is to avoid the need
> for creating conversation state at the server for block-wise GET
> requests.
>
> Any Block option gurus can confirm? Carsten? Zach?
>
> Thomas
>
>
> On Wed, May 7, 2014 at 6:02 PM, Qin Wang <qinwang6top@yahoo.com> wrote:
> Hi All,
>
> I have a question about how to use Uri-path option if we use Block opt= ion to do fragmentation.
>
> Take Figure 7 in draft-ietf-core-block-14 as example.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> CLIENT =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SERVER > | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> | CON [MID=3D1234], PUT, /options, 1:0/1/128 ------> |
> | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> | <------ ACK [MID=3D1234], 2.31 Continue, 1:0/1/128 |
> | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> | CON [MID=3D1235], PUT, /options, 1:1/1/128 ------> |
> | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> | <------ ACK [MID=3D1235], 2.31 Continue, 1:1/1/128 |
> | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> | CON [MID=3D1236], PUT, /options, 1:2/0/128 ------> |
> | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> | <------ ACK [MID=3D1236], 2.04 Changed, 1:2/0/128 |
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 7: Simple atomi= c blockwise PUT
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> In my imagination, Uri-path option, which tells SERVER the resource, w= ill be only in the first PUT message, i.e. CON[MID=3D1234], and CON [MID=3D= 1235], CON [MID=3D1235] will not include Uri-path option. Correct?
>
> Thanks
> Qin
>
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


--047d7b6735ea32ab8304fa2b01fb-- From nobody Sun May 25 01:30:18 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E4C1A01A5 for ; Sat, 24 May 2014 18:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 W_2g8drVrQQS for ; Sat, 24 May 2014 18:02:07 -0700 (PDT) Received: from nm28-vm3.bullet.mail.ne1.yahoo.com (nm28-vm3.bullet.mail.ne1.yahoo.com [98.138.91.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A681C1A0194 for ; Sat, 24 May 2014 18:02:07 -0700 (PDT) Received: from [98.138.100.117] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 25 May 2014 01:02:04 -0000 Received: from [98.138.89.162] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 25 May 2014 01:02:04 -0000 Received: from [127.0.0.1] by omp1018.mail.ne1.yahoo.com with NNFMP; 25 May 2014 01:02:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 942091.71348.bm@omp1018.mail.ne1.yahoo.com Received: (qmail 22467 invoked by uid 60001); 25 May 2014 01:02:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1400979724; bh=vIaqBB3SPbRJ1qxOLfYl6zneYC5X3a3S3q2aDr2Yn4g=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lwtOF/w7G+k67+GJBaIRnDKAquJGygiXQnkEFJH+Uph6OGXi/uq8Pu18a9vKMBW5npWLkZrPiT5/47Jb08FW+Y8vq7vQwZF4ojSBhPtUE1oeBwwX3iuaVbRqyDWd+TxBQlIeFTzOxqNZyhPnIMuSYf9mNkOBDEKvUQQLvPwhIPU= X-YMail-OSG: j9pQfP8VM1ndeoS9NbTB0culHZkMt3CEOV67y78j9J9f9_m Ime9TOXqvqJIQDJqsNJD8CXvyTpClQf28A_fnauhMS8igJUhZiBt46JPNhKi Qgry4ZEU8o3MtzX8ajn2N2LXoRagvZafCjyHh2i1oEA_TGNC_WajAhh6QuoJ .ItKhdWFffR9vifKsrW423jjM70OGPia4G1j5K984suaRh3mA2I.cm2sXkJo mETciWzz1swieVsKQ0RL43X.6i2FuAojtBdcjmDSAG4tLCzlKfmPh0T0Kk.h kVP3vldQZsKhx16hMuZat3k9maYf0qnxS1za7NwuptkQVN3XLMde20c7PoG9 cJ7Bpm1sOwypmcDqPMViOZyKJKolaGlXN3vn7EzBedPSFFFh8L1srfeVafHT 10eMLWFqHqfcf9ith92wcvKrPlh7wpF0k037bjDQSZhHq2GAL2NlgelMKbz7 AsC80R9YIlJGLXb0wAmLNrJZoAkggcPyiapXzLhlEVghS69CjYzGSN4uY Received: from [123.124.147.8] by web120004.mail.ne1.yahoo.com via HTTP; Sat, 24 May 2014 18:02:04 PDT X-Rocket-MIMEInfo: 002.001, SGkgQ2Fyc3RlbiBhbmQgVGhvbWFzLAoKSXQgZG9lcyBhbnN3ZXIgbXkgcXVlc3Rpb24uwqBUaGFuayB5b3UgdmVyeSBtdWNoIQoKUWluCgoKT24gU3VuZGF5LCBNYXkgMjUsIDIwMTQgNDoxNSBBTSwgVGhvbWFzIFdhdHRleW5lIDx3YXR0ZXluZUBlZWNzLmJlcmtlbGV5LmVkdT4gd3JvdGU6CiAKCgpDYXJzdGVuLAoKVGhhbmtzIGZvciB0aGUgcXVpY2sgcmVwbHksIHRoaXMgaXMgdmVyeSBjbGVhci4gUWluLCBjYW4geW91IGNvbmZpcm0gdGhpcyBhbnN3ZXJzIHRoZSBxdWVzdGlvbiB5b3UgaGFkPwoKVGhlIDYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <1399510956.31595.YahooMailNeo@web120001.mail.ne1.yahoo.com> <1400824911.93819.YahooMailNeo@web120005.mail.ne1.yahoo.com> <399C3018-4668-4EAE-B8DA-00DF3DA1988A@tzi.org> Message-ID: <1400979724.9677.YahooMailNeo@web120004.mail.ne1.yahoo.com> Date: Sat, 24 May 2014 18:02:04 -0700 (PDT) From: Qin Wang To: Thomas Watteyne , Carsten Bormann In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1265908415-424328365-1400979724=:9677" Archived-At: http://mailarchive.ietf.org/arch/msg/core/_zQYtfsTxbPmwcD1WcGl-NEaQ9A X-Mailman-Approved-At: Sun, 25 May 2014 01:30:14 -0700 Cc: "6tisch@ietf.org" <6tisch@ietf.org>, core Subject: Re: [core] [6tisch] How to use Uri-path option while Block option is used? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Qin Wang List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 01:02:11 -0000 --1265908415-424328365-1400979724=:9677 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten and Thomas,=0A=0AIt does answer my question.=C2=A0Thank you very= much!=0A=0AQin=0A=0A=0AOn Sunday, May 25, 2014 4:15 AM, Thomas Watteyne wrote:=0A =0A=0A=0ACarsten,=0A=0AThanks for the = quick reply, this is very clear. Qin, can you confirm this answers the ques= tion you had?=0A=0AThe 6TiSCH WG is exploring the idea of using CoAP for ne= ighbor-to-neighbor communication, to enable distributed management. Ideally= , the exchanges involved are very short (and we expect the vast majority to= be); in the rare cases they're not, we were looking at Block transfer.=0A= =0AThomas=0A=0A=0A=0A=0A=0AOn Sat, May 24, 2014 at 1:06 PM, Carsten Bormann= wrote:=0A=0AI haven=E2=80=99t followed the conversation, bu= t I can confirm that all exchanges that constitute a blockwise transfer nee= d to carry the request options that indicate what blockwise transfer this i= s is a part of. =C2=A0So you do have to repeat the Uri-Path.=0A>=0A>The mes= sage-ID is not useful for linking together the requests of a blockwise tran= sfer; there is no requirement for these to be sequential (e.g., you might b= e interspersing a different request). =C2=A0It is even possible to have mul= tiple blockwise transfers going on from one client to one server (I wouldn= =E2=80=99t recommend designing for that, but it might happen that way e.g. = at a proxy).=0A>=0A>I=E2=80=99ll try to clarify this some more in the next = version of -block.=0A>=0A>I wonder how -block has become so important for 6= tisch. =C2=A0Shouldn=E2=80=99t the 6tisch exchanges be rather short?=0A>=0A= >Gr=C3=BC=C3=9Fe, Carsten=0A>=0A>=0A>=0A>=0A>On 24 May 2014, at 21:56, Thom= as Watteyne wrote:=0A>=0A>> Qin,=0A>>=0A>> Cor= rect me if I'm wrong, but you're saying that, in "Figure 7: Simple atomic b= lockwise PUT" [1], since the PUT operation is atomic, the SERVER will have = to keep track of the progress of the exchange, so might as well remember th= at MID=3D1234 corresponds to /options, and therefore not include the Uri-pa= th option in each transaction?=0A>>=0A>> This is really a question for CORE= , I'm CC'ing the CORE ML.=0A>>=0A>> Thomas=0A>>=0A>> [1] http://tools.ietf.= org/html/draft-ietf-core-block-14#page-19=0A>>=0A>>=0A>> On Thu, May 22, 20= 14 at 11:01 PM, Qin Wang wrote:=0A>> Hi Thomas,=0A>= >=0A>> Please see Figure 7 and Figure 8 in =C2=A0http://tools.ietf.org/html= /draft-ietf-core-block-14. They define "Simple atomic blockwise PUT" and "S= imple stateless blockwise PUT", respectively. I guess in the first case, it= is not necessary to include uri-path option in each PUT message.=0A>>=0A>>= We really need somebody to confirm it.=0A>>=0A>> Thanks=0A>> Qin=0A>>=0A>>= =0A>> On Friday, May 23, 2014 7:40 AM, Thomas Watteyne wrote:=0A>>=0A>>=0A>> Qin,=0A>>=0A>> AFAIK, the Uri-path needs to = be present in each PUT message to satisfy the following statements from htt= p://tools.ietf.org/html/draft-ietf-core-block-14:=0A>>=0A>> the Block optio= ns=0A>> enable a server to be truly stateless: the server can handle each= =0A>> block transfer separately, with no need for a connection setup or=0A>= > other server-side memory of previous block transfers.=0A>>=0A>> The overr= iding objective is to avoid the need=0A>> for creating conversation state a= t the server for block-wise GET=0A>> requests.=0A>>=0A>> Any Block option g= urus can confirm? Carsten? Zach?=0A>>=0A>> Thomas=0A>>=0A>>=0A>> On Wed, Ma= y 7, 2014 at 6:02 PM, Qin Wang wrote:=0A>> Hi All,= =0A>>=0A>> I have a question about how to use Uri-path option if we use Blo= ck option to do fragmentation.=0A>>=0A>> Take Figure 7 in draft-ietf-core-b= lock-14 as example.=0A>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=0A>> CLIENT =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0SERVER=0A>> | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=0A>> | CON [MID=3D1234], PUT, /= options, 1:0/1/128 ------> |=0A>> | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=0A>> | <-----= - ACK [MID=3D1234], 2.31 Continue, 1:0/1/128 |=0A>> | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=0A>> | CON [MID=3D1235], PUT, /options, 1:1/1/128 ------> |=0A>> | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=0A>> | <------ ACK [MID=3D1235], 2.31 Continue, = 1:1/1/128 |=0A>> | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=0A>> | CON [MID=3D1236], PUT, /= options, 1:2/0/128 ------> |=0A>> | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=0A>> | <-----= - ACK [MID=3D1236], 2.04 Changed, 1:2/0/128 |=0A>>=0A>> =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 7: Simple atomic blockwise PUT=0A>>= =0A>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A>>=0A>= > In my imagination, Uri-path option, which tells SERVER the resource, will= be only in the first PUT message, i.e. CON[MID=3D1234], and CON [MID=3D123= 5], CON [MID=3D1235] will not include Uri-path option. Correct?=0A>>=0A>> T= hanks=0A>> Qin=0A>>=0A>>=0A>>=0A>> ________________________________________= _______=0A>> 6tisch mailing list=0A>> 6tisch@ietf.org=0A>> https://www.ietf= .org/mailman/listinfo/6tisch=0A>>=0A>>=0A>>=0A>>=0A>>=0A>> ________________= _______________________________=0A>> core mailing list=0A>> core@ietf.org= =0A>> https://www.ietf.org/mailman/listinfo/core=0A>=0A>=0A=0A=0A__________= _____________________________________=0A6tisch mailing list=0A6tisch@ietf.o= rg=0Ahttps://www.ietf.org/mailman/listinfo/6tisch --1265908415-424328365-1400979724=:9677 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Carsten and Thom= as,

It does answer my question. = ;Thank you very much!=

= Qin


On Sunday, May 25, 2014 4:15 AM, Thoma= s Watteyne <watteyne@eecs.berkeley.edu> wrote:

Carsten,

Thanks for the quick = reply, this is very clear. Qin, can you confirm this answers the question y= ou had?

The 6TiSCH WG is exploring = the idea of using CoAP for neighbor-to-neighbor communication, to enable di= stributed management. Ideally, the exchanges involved are very short (and w= e expect the vast majority to be); in the rare cases they're not, we were looking at Block t= ransfer.
=0A=0A

Thomas



On Sat, May 24, 2014 at 1:06 PM, Carsten Bormann <cabo@tzi.org= > wrote:
=0A=0A
I haven=E2=80=99t followed the conversation, but I can confirm= that all exchanges that constitute a blockwise transfer need to carry the = request options that indicate what blockwise transfer this is is a part of.=  So you do have to repeat the Uri-Path.
=0A=0A=0A=0AThe message-ID is not useful for linking together the r= equests of a blockwise transfer; there is no requirement for these to be se= quential (e.g., you might be interspersing a different request).  It i= s even possible to have multiple blockwise transfers going on from one clie= nt to one server (I wouldn=E2=80=99t recommend designing for that, but it m= ight happen that way e.g. at a proxy).
=0A=0A=0A
=0AI=E2=80=99ll try to clarify this some more in the next version= of -block.
=0A
=0AI wonder how -block = has become so important for 6tisch.  Shouldn=E2=80=99t the 6tisch exch= anges be rather short?
=0A
=0AGr=C3=BC= =C3=9Fe, Carsten
=0A
<= br clear=3D"none">=0A
=0A
=0AOn 24 May = 2014, at 21:56, Thomas Watteyne <watteyne@eecs.berkeley.edu> wrote:
=0A
=0A> Qin,
=0A>=0A> Correct me if I'm wrong, but you're saying that, i= n "Figure 7: Simple atomic blockwise PUT" [1], since the PUT operation is a= tomic, the SERVER will have to keep track of the progress of the exchange, = so might as well remember that MID=3D1234 corresponds to /options, and ther= efore not include the Uri-path option in each transaction?
=0A=0A=0A>
=0A> This is really a question for COR= E, I'm CC'ing the CORE ML.
=0A>
=0A&= gt; Thomas
=0A>
=0A> [1] http://tools.ietf.org/html/draft-i= etf-core-block-14#page-19
=0A>
= =0A>
=0A> On Thu, May 22, 2014 at 11:01 PM, Qin Wan= g <qinwang6top@= yahoo.com> wrote:
=0A> Hi Thomas,
=0A>
=0A> Please see Figure 7 and Figure 8 in =  http://tools.ietf.org/html/dra= ft-ietf-core-block-14. They define "Simple atomic blockwise PUT" and "S= imple stateless blockwise PUT", respectively. I guess in the first case, it= is not necessary to include uri-path option in each PUT message.
=0A=0A=0A>
=0A> We really need somebody t= o confirm it.
=0A>
=0A> Thanks=0A> Qin
=0A>
=0A= >
=0A> On Friday, May 23, 2014 7:40 AM, Thomas Watt= eyne <watteyne@eecs.berkeley.edu> wrote:
=0A>
=0A>
=0A> Qin,
=0A>= ;
=0A> AFAIK, the Uri-path needs to be present in each= PUT message to satisfy the following statements from http://tools.ietf.org/html/draft-ietf-core-block-14:<= br clear=3D"none">=0A=0A=0A>
=0A> the Block options=
=0A> enable a server to be truly stateless: the serve= r can handle each
=0A> block transfer separately, with= no need for a connection setup or
=0A> other server-s= ide memory of previous block transfers.
=0A>
=0A> The overriding objective is to avoid the need
=0A> for creating conversation state at the server for block-wise= GET
=0A> requests.
=0A>
=0A> Any Block option gurus can confirm? Carsten? Zach?
=0A>
=0A> Thomas
=0A&= gt;
=0A>
=0A> On Wed, May 7, 2014= at 6:02 PM, Qin Wang <qinwang6top@yahoo.com> wrote:
=0A> Hi A= ll,
=0A>
=0A> I have a question a= bout how to use Uri-path option if we use Block option to do fragmentation.=
=0A>
=0A> Take Figure 7 in draft= -ietf-core-block-14 as example.
=0A> =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=0A> CLI= ENT                     &= nbsp;                    =                SERVER
=0A> |                 &nb= sp;                     &= nbsp;                    =           |
=0A> | CON [MID= =3D1234], PUT, /options, 1:0/1/128 ------> |
=0A> |=                     &nbs= p;                     &n= bsp;                     =       |
=0A> | <------ ACK [MID=3D12= 34], 2.31 Continue, 1:0/1/128 |
=0A> |     &= nbsp;                    =                     &nbs= p;                     &n= bsp; |
=0A> | CON [MID=3D1235], PUT, /options, 1:1/1/1= 28 ------> |
=0A> |         &nb= sp;                     &= nbsp;                    =                   |
=0A> | <------ ACK [MID=3D1235], 2.31 Continue, 1:1/1/128 |=
=0A> |             &nbs= p;                     &n= bsp;                     =               |
=0A>= ; | CON [MID=3D1236], PUT, /options, 1:2/0/128 ------> |
=0A> |                  =                     &nbs= p;                     &n= bsp;         |
=0A> | <------ A= CK [MID=3D1236], 2.04 Changed, 1:2/0/128 |
=0A>
=0A>              Figure = 7: Simple atomic blockwise PUT
=0A>
= =0A> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=0A>
=0A> In my imagination, Uri-path = option, which tells SERVER the resource, will be only in the first PUT mess= age, i.e. CON[MID=3D1234], and CON [MID=3D1235], CON [MID=3D1235] will not = include Uri-path option. Correct?
=0A>
=0A> Thanks
=0A> Qin
=0A>=0A>
=0A>
=0A>= ; _______________________________________________
=0A>= 6tisch mailing list
=0A> 6tisch@ietf.org
=0A> https://www.ietf.org/mailman/listinfo/6tisch
=0A>
=0A>
=0A>
=0A>
=0A>
=0A
> _______________________________________________
=0A> core mailing list
=0A> core@ietf.org
=0A> https://www.ietf.org/mailman/listinfo/core
=0A
=0A


__= _____________________________________________
6tisch mail= ing list
6tisch@ietf.org
= https://www.ietf.org/mailman/listinfo/6tisch


--1265908415-424328365-1400979724=:9677--