From cyril.auburtin@gmail.com  Fri Sep 30 10:29:35 2011
Return-Path: <cyril.auburtin@gmail.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020A621F8C06 for <core@ietfa.amsl.com>; Fri, 30 Sep 2011 10:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMgGhVuhBlcj for <core@ietfa.amsl.com>; Fri, 30 Sep 2011 10:29:34 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9DC21F8C04 for <core@ietf.org>; Fri, 30 Sep 2011 10:29:34 -0700 (PDT)
Received: by yic13 with SMTP id 13so2112675yic.31 for <core@ietf.org>; Fri, 30 Sep 2011 10:32:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=KIwQL9gGi9a3y1vkNsVQLQH9YG8WipfUmVoLk4EJ2NY=; b=mkAa4yqT+GzagatKs9fzJKRBKw5mQ6SX9y/H3c9lm764tS3LKxRFo3zFco9fuMB/+R W01SY8zX36H+1aZT5EhF7c4JBNxU1o+UAMoHho7PXTZwtvHLFf8JJ3CIpZxhYqKMeLWM LC3pzJgT8NWyjhHhaKz6f03mP+7r8BwaUBy8A=
MIME-Version: 1.0
Received: by 10.101.175.1 with SMTP id c1mr10382331anp.27.1317403948628; Fri, 30 Sep 2011 10:32:28 -0700 (PDT)
Received: by 10.100.120.2 with HTTP; Fri, 30 Sep 2011 10:32:28 -0700 (PDT)
In-Reply-To: <CAKteAhH6qHu4idSP=MO8y=q-F6xeMFX5ME6=Sp9yq6FaWGXFYA@mail.gmail.com>
References: <CAKteAhH6qHu4idSP=MO8y=q-F6xeMFX5ME6=Sp9yq6FaWGXFYA@mail.gmail.com>
Date: Fri, 30 Sep 2011 19:32:28 +0200
Message-ID: <CAKteAhEvMJ8nnWGivr=1GM88SYrJPsQBcLvGSemZE3DnGihX+w@mail.gmail.com>
From: cyril auburtin <cyril.auburtin@gmail.com>
To: core@ietf.org
Content-Type: multipart/alternative; boundary=001636c5c18c623bef04ae2c02b0
X-Mailman-Approved-At: Sat, 01 Oct 2011 09:59:51 -0700
Subject: Re: [core] Figure 2: Simple blockwise GET
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2011 18:48:27 -0000

--001636c5c18c623bef04ae2c02b0
Content-Type: text/plain; charset=ISO-8859-1

Hello

in  http://tools.ietf.org/html/draft-ietf-core-block-04 Figure 2: Simple
blockwise GET

Why does the server retuns the response in a blockwise way if the client did
not send any Block2 option?

Thanks , sincerely

--001636c5c18c623bef04ae2c02b0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello<div><br><div>in =A0<a href=3D"http://tools.ietf.org/html/draft-ietf-c=
ore-block-04">http://tools.ietf.org/html/draft-ietf-core-block-04</a>=A0Fig=
ure 2: Simple blockwise GET</div><meta http-equiv=3D"content-type" content=
=3D"text/html; charset=3Dutf-8"><div>
<br></div><div>Why does the server retuns the response in a blockwise way i=
f the client did not send any Block2 option?</div><div><br></div><div>Thank=
s , sincerely<br><br></div></div>

--001636c5c18c623bef04ae2c02b0--

From cabo@tzi.org  Sat Oct  1 14:33:09 2011
Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D6521F8F72 for <core@ietfa.amsl.com>; Sat,  1 Oct 2011 14:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta9quAG9K3oN for <core@ietfa.amsl.com>; Sat,  1 Oct 2011 14:33: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 B2D7421F8F71 for <core@ietf.org>; Sat,  1 Oct 2011 14:33: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.3/8.14.3) with ESMTP id p91LZrii002003; Sat, 1 Oct 2011 23:35:53 +0200 (CEST)
Received: from [192.168.217.112] (p54899DBD.dip.t-dialin.net [84.137.157.189]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 45801E35; Sat,  1 Oct 2011 23:35:48 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAKteAhEvMJ8nnWGivr=1GM88SYrJPsQBcLvGSemZE3DnGihX+w@mail.gmail.com>
Date: Sat, 1 Oct 2011 23:35:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <53B23F55-A8B2-424C-9A9C-39D517987B87@tzi.org>
References: <CAKteAhH6qHu4idSP=MO8y=q-F6xeMFX5ME6=Sp9yq6FaWGXFYA@mail.gmail.com> <CAKteAhEvMJ8nnWGivr=1GM88SYrJPsQBcLvGSemZE3DnGihX+w@mail.gmail.com>
To: cyril auburtin <cyril.auburtin@gmail.com>
X-Mailer: Apple Mail (2.1244.3)
Cc: core@ietf.org
Subject: Re: [core] Figure 2: Simple blockwise GET
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Oct 2011 21:33:09 -0000

> in  http://tools.ietf.org/html/draft-ietf-core-block-04 Figure 2: =
Simple blockwise GET
>=20
> Why does the server retuns the response in a blockwise way if the =
client did not send any Block2 option?

Hi Cyril,

in this example, while the server could send the response in one UDP =
datagram, it is configured to send a response of the given size in =
multiple blocks.  One reason for configuring a server that way might be =
that it is on a constrained network that has a bad datagram delivery =
rate for datagrams that need to be excessively L2-fragmented.

Maybe your question was "how does the server dare to use Block if the =
client hasn't indicated Block capability".  When we designed -block, we =
had a choice between avoiding a potential surprise of this kind, but =
then requiring a Block2 option in just about any request that might =
possibly elicit a blockwise answer, and just assuming the majority of =
the clients will be able to handle block options.  We opted for the =
latter.  It's not like we have any backward compatibility issues here =
that would more or less force the first choice.

Gr=FC=DFe, Carsten


From esko.dijk@philips.com  Tue Oct  4 00:54:32 2011
Return-Path: <esko.dijk@philips.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC80F21F8CED for <core@ietfa.amsl.com>; Tue,  4 Oct 2011 00:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.532
X-Spam-Level: 
X-Spam-Status: No, score=-5.532 tagged_above=-999 required=5 tests=[AWL=1.067,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggjLN+OKIIjF for <core@ietfa.amsl.com>; Tue,  4 Oct 2011 00:54:32 -0700 (PDT)
Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 12A7921F8B7D for <core@ietf.org>; Tue,  4 Oct 2011 00:54:31 -0700 (PDT)
Received: from mail137-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.22; Tue, 4 Oct 2011 07:57:36 +0000
Received: from mail137-tx2 (localhost.localdomain [127.0.0.1])	by mail137-tx2-R.bigfish.com (Postfix) with ESMTP id 08B87ED0132; Tue,  4 Oct 2011 07:57:36 +0000 (UTC)
X-SpamScore: -57
X-BigFish: VPS-57(zz217bL15d6O9251J1803M148cM542M1432N98dKzz1202hzz1033IL8275dhz2dh2a8h668h839h)
X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI
X-FB-SS: 13,
Received: from mail137-tx2 (localhost.localdomain [127.0.0.1]) by mail137-tx2 (MessageSwitch) id 1317715055836307_7350; Tue,  4 Oct 2011 07:57:35 +0000 (UTC)
Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.253])	by mail137-tx2.bigfish.com (Postfix) with ESMTP id C46A615D004C; Tue,  4 Oct 2011 07:57:35 +0000 (UTC)
Received: from smtpx.philips.com (168.87.56.20) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 4 Oct 2011 07:57:35 +0000
Received: from NLHILEXH03.connect1.local (172.16.153.78) by connect1.philips.com (172.16.156.160) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 4 Oct 2011 09:57:25 +0200
Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLHILEXH03.connect1.local ([172.16.153.78]) with mapi; Tue, 4 Oct 2011 09:53:13 +0200
From: "Dijk, Esko" <esko.dijk@philips.com>
To: Klaus Hartke <hartke@tzi.org>, "core@ietf.org" <core@ietf.org>
Date: Tue, 4 Oct 2011 09:57:15 +0200
Thread-Topic: [core] Coap-07 deduplication rules - clarification needed?
Thread-Index: Acx5OVFwTWS8nfsZQ5umBJlBwKcdNgJL1v0A
Message-ID: <A337AA36B3B96E4D853E6182B2F27AE2D168F9ED15@NLCLUEXM03.connect1.local>
References: <A337AA36B3B96E4D853E6182B2F27AE2D16726B66A@NLCLUEXM03.connect1.local> <CAB6izETwt2QtzmapqiaoazPB9RR4P8C31=rED_CLV0ywoD80Qw@mail.gmail.com>
In-Reply-To: <CAB6izETwt2QtzmapqiaoazPB9RR4P8C31=rED_CLV0ywoD80Qw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Subject: Re: [core] Coap-07 deduplication rules - clarification needed?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2011 07:54:33 -0000

Dear Klaus,

thanks for responding and clarifying.

> The text is written in the scope of one client communicating with one
> server, i.e. duplicate detection must be performed within the scope of
> the respective client.

I think this scope is not immediately apparent in the current text. Section=
 4.1 as a whole does not have this scope, which I deduce from the text "rel=
ated to a confirmable message by means of a Message ID along with additiona=
l address information of the corresponding end-point". The "additional addr=
ess information of the corresponding end-point" seems to indicate the scope=
 of the section is multi-client. Then we should say it with the same clarit=
y for duplicate detection, e.g. change the text to:

   A recipient MUST be prepared to receive the same confirmable message
   (as indicated by the Message ID and additional address information of th=
e corresponding end-point) multiple times, ...

This is better but it still some information is missing, see below. (PS. I =
interpret the bracketed text as a definition of what the word "same" in the=
 sentence before means.)

> With NoSec, a client is identified by IP source address and UDP source
> port, so this (3.).

Ok it's clear. But this behavior is somehow only specified for Section 5 (r=
equest/response level) and not for Section 4. If implementations are suppos=
ed to do this in uniform fashion, it is best to mention this in Section 4 a=
lso, for use in CON/ACK matching and duplicate detection. And a reference t=
o Section 10 would also be needed to point out that this matching depends o=
n security mode, similar how it's done in Section 5.

Would you agree?

Esko

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kla=
us Hartke
Sent: Thursday 22 September 2011 17:11
To: core@ietf.org
Subject: Re: [core] Coap-07 deduplication rules - clarification needed?

Esko Dijk wrote:
> I noted that section 5.3 has detailed rules for request/response matching
> which include Message ID, IP address and UDP port matching.
>
> For duplicate detection such rules are not specified so well.  The releva=
nt
> text I found is:

The text is written in the scope of one client communicating with one
server, i.e. duplicate detection must be performed within the scope of
the respective client.

> 3. Consider Message ID, IP source address and UDP source port.

With NoSec, a client is identified by IP source address and UDP source
port, so this (3.).

With other security modes, the client may be identified by
certificate, key, dtls session, ... in addition to or instead of IP
source address and UDP source port. But duplicate detection is not
necessary if the security mode prevents replay attacks.


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

The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From hartketzi@googlemail.com  Tue Oct  4 01:38:18 2011
Return-Path: <hartketzi@googlemail.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5926221F8C47 for <core@ietfa.amsl.com>; Tue,  4 Oct 2011 01:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.902
X-Spam-Level: 
X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lvO1jAGyWnu for <core@ietfa.amsl.com>; Tue,  4 Oct 2011 01:38:17 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 751E621F8C46 for <core@ietf.org>; Tue,  4 Oct 2011 01:38:17 -0700 (PDT)
Received: by eye4 with SMTP id 4so248332eye.31 for <core@ietf.org>; Tue, 04 Oct 2011 01:41:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=nIXnCFf5/U7ijPow7Eb1Uo1ssUPfm+fGg3OQHBNmaG8=; b=x88BQ3zmXy07ngQPy+BtvP8svhc7gZLudNt0f0PfcupH+WM02OAPyY5H9s5DxFRpns xtx5Dowjazmpa3+oXbWubL8IMNhMTEO43ewDDFo/WBJZygMG78ifO2TWj4S8r/3HtSRG UTtcEYSaCMdpn+GanK0HiWP4DfmYkSbdRpdZA=
MIME-Version: 1.0
Received: by 10.223.89.91 with SMTP id d27mr1387349fam.55.1317717681401; Tue, 04 Oct 2011 01:41:21 -0700 (PDT)
Sender: hartketzi@googlemail.com
Received: by 10.223.75.207 with HTTP; Tue, 4 Oct 2011 01:41:21 -0700 (PDT)
In-Reply-To: <A337AA36B3B96E4D853E6182B2F27AE2D168F9ED15@NLCLUEXM03.connect1.local>
References: <A337AA36B3B96E4D853E6182B2F27AE2D16726B66A@NLCLUEXM03.connect1.local> <CAB6izETwt2QtzmapqiaoazPB9RR4P8C31=rED_CLV0ywoD80Qw@mail.gmail.com> <A337AA36B3B96E4D853E6182B2F27AE2D168F9ED15@NLCLUEXM03.connect1.local>
Date: Tue, 4 Oct 2011 10:41:21 +0200
X-Google-Sender-Auth: HCz_EQvRdJ786T3FGaraCPs_3t8
Message-ID: <CAB6izERptDTCrO4LWeKBGw_asXx0n0Y-DRm+eDXi_RR=1Z8iCA@mail.gmail.com>
From: Klaus Hartke <hartke@tzi.org>
To: "core@ietf.org" <core@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [core] Coap-07 deduplication rules - clarification needed?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2011 08:38:18 -0000

Esko Dijk wrote:
>> The text is written in the scope of one client communicating with one
>> server, i.e. duplicate detection must be performed within the scope of
>> the respective client.
>
> I think this scope is not immediately apparent in the current text.

You're right; the text used to have this scope until it was "fixed" as
part of ticket #151. This change was obviously not complete; I'll
reopen the ticket.

> (PS. I interpret the bracketed text as a definition of what the word "sam=
e" in the sentence before means.)

Yes.

>> With NoSec, a client is identified by IP source address and UDP source
>> port, so this (3.).
>
> Ok it's clear. But this behavior is somehow only specified for Section 5 =
(request/response level) and not for Section 4. If implementations are supp=
osed to do this in uniform fashion, it is best to mention this in Section 4=
 also, for use in CON/ACK matching and duplicate detection. And a reference=
 to Section 10 would also be needed to point out that this matching depends=
 on security mode, similar how it's done in Section 5.
>
> Would you agree?

Yes. Please create a ticket.

Thanks,
Klaus

From trac+core@trac.tools.ietf.org  Tue Oct  4 01:42:36 2011
Return-Path: <trac+core@trac.tools.ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216BA21F8C6F for <core@ietfa.amsl.com>; Tue,  4 Oct 2011 01:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjCd1s6jmJK4 for <core@ietfa.amsl.com>; Tue,  4 Oct 2011 01:42:35 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A4D7721F8C67 for <core@ietf.org>; Tue,  4 Oct 2011 01:42:35 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from <trac+core@trac.tools.ietf.org>) id 1RB0d0-0008NY-Sn; Tue, 04 Oct 2011 04:45:30 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" <trac+core@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com
X-Trac-Project: core
Date: Tue, 04 Oct 2011 08:45:30 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/151#comment:2
Message-ID: <072.6a5b3024dc90c61827209ef52a00529d@trac.tools.ietf.org>
References: <057.a0dfde1ed2d36d2bf749f251f2a956f4@trac.tools.ietf.org>
X-Trac-Ticket-ID: 151
In-Reply-To: <057.a0dfde1ed2d36d2bf749f251f2a956f4@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] #151: Clarify matching rules for messages and tokens
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2011 08:42:36 -0000

#151: Clarify matching rules for messages and tokens

Changes (by hartke@…):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 There are some left-overs from the previous version which was written in
 the scope of one client communicating with one server; see
 http://www.ietf.org/mail-archive/web/core/current/msg02311.html

-- 
-----------------------------+-----------------------
 Reporter:  zach@…           |       Owner:  cabo@…
     Type:  protocol defect  |      Status:  reopened
 Priority:  minor            |   Milestone:
Component:  coap             |     Version:
 Severity:  -                |  Resolution:
 Keywords:                   |
-----------------------------+-----------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/151#comment:2>
core <http://tools.ietf.org/core/>


From trac+core@trac.tools.ietf.org  Tue Oct  4 03:01:28 2011
Return-Path: <trac+core@trac.tools.ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7BD21F8B4C for <core@ietfa.amsl.com>; Tue,  4 Oct 2011 03:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaogc9f8XpUK for <core@ietfa.amsl.com>; Tue,  4 Oct 2011 03:01:28 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id E00F121F8B4B for <core@ietf.org>; Tue,  4 Oct 2011 03:01:27 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from <trac+core@trac.tools.ietf.org>) id 1RB1rK-0008Gy-BT; Tue, 04 Oct 2011 06:04:22 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" <trac+core@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: hartke@tzi.org, esko.dijk@philips.com
X-Trac-Project: core
Date: Tue, 04 Oct 2011 10:04:22 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/175
Message-ID: <060.944f31d9b293bd1b826f4093572af3a2@trac.tools.ietf.org>
X-Trac-Ticket-ID: 175
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: hartke@tzi.org, esko.dijk@philips.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: [core]  #175: Clarify matching rules for messages, duplicates and relate to security modes
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2011 10:01:28 -0000

#175: Clarify matching rules for messages, duplicates and relate to security
modes

 Section 4 should indicate that MID and additional address information are
 used for CON/ACK matching, CON/RST matching, NON/RST matching, and
 duplicate detection. In addition to ticket #151, Section 4 should state
 that 'additional address information' depends on security mode and make a
 reference to Section 10. Also, the used information in the NoSec mode
 should be specified in Section 4 (or referred to from Section 4) similar
 as it is specified in Section 5. I.e. IP source address and UDP source
 port.

-- 
--------------------------------+----------------------
 Reporter:  esko.dijk@…         |      Owner:  hartke@…
     Type:  protocol defect     |     Status:  new
 Priority:  minor               |  Milestone:
Component:  coap                |    Version:
 Severity:  Active WG Document  |   Keywords:
--------------------------------+----------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/175>
core <http://tools.ietf.org/core/>


From trac+core@trac.tools.ietf.org  Wed Oct  5 03:02:52 2011
Return-Path: <trac+core@trac.tools.ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A182621F8AD3 for <core@ietfa.amsl.com>; Wed,  5 Oct 2011 03:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePXG1hy064dO for <core@ietfa.amsl.com>; Wed,  5 Oct 2011 03:02:52 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5B721F8ACA for <core@ietf.org>; Wed,  5 Oct 2011 03:02:51 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from <trac+core@trac.tools.ietf.org>) id 1RBOMJ-0003O5-RF; Wed, 05 Oct 2011 06:05:51 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" <trac+core@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com, hartke@tzi.org
X-Trac-Project: core
Date: Wed, 05 Oct 2011 10:05:51 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/151#comment:3
Message-ID: <072.0aa569816198153a9c42c75f92bab3f5@trac.tools.ietf.org>
References: <057.a0dfde1ed2d36d2bf749f251f2a956f4@trac.tools.ietf.org>
X-Trac-Ticket-ID: 151
In-Reply-To: <057.a0dfde1ed2d36d2bf749f251f2a956f4@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] #151: Clarify matching rules for messages and tokens
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2011 10:02:52 -0000

#151: Clarify matching rules for messages and tokens

Changes (by hartke@…):

 * owner:  cabo@… => zach@…
 * status:  reopened => new


-- 
-----------------------------+---------------------
 Reporter:  zach@…           |       Owner:  zach@…
     Type:  protocol defect  |      Status:  new
 Priority:  minor            |   Milestone:
Component:  coap             |     Version:
 Severity:  -                |  Resolution:
 Keywords:                   |
-----------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/151#comment:3>
core <http://tools.ietf.org/core/>


From trac+core@trac.tools.ietf.org  Wed Oct  5 03:03:04 2011
Return-Path: <trac+core@trac.tools.ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B385F21F8B6D for <core@ietfa.amsl.com>; Wed,  5 Oct 2011 03:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPFUFqe4CX-S for <core@ietfa.amsl.com>; Wed,  5 Oct 2011 03:03:04 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 565C521F8B2E for <core@ietf.org>; Wed,  5 Oct 2011 03:03:01 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from <trac+core@trac.tools.ietf.org>) id 1RBOMW-0003Of-SL; Wed, 05 Oct 2011 06:06:04 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" <trac+core@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com, hartke@tzi.org
X-Trac-Project: core
Date: Wed, 05 Oct 2011 10:06:04 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/175#comment:1
Message-ID: <075.83e7516cb2a8ea1fbea20feae4f0317a@trac.tools.ietf.org>
References: <060.944f31d9b293bd1b826f4093572af3a2@trac.tools.ietf.org>
X-Trac-Ticket-ID: 175
In-Reply-To: <060.944f31d9b293bd1b826f4093572af3a2@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] #175: Clarify matching rules for messages, duplicates and relate to security modes
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2011 10:03:04 -0000

#175: Clarify matching rules for messages, duplicates and relate to security
modes

Changes (by hartke@…):

 * owner:  hartke@… => zach@…


-- 
--------------------------------+---------------------
 Reporter:  esko.dijk@…         |       Owner:  zach@…
     Type:  protocol defect     |      Status:  new
 Priority:  minor               |   Milestone:
Component:  coap                |     Version:
 Severity:  Active WG Document  |  Resolution:
 Keywords:                      |
--------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/175#comment:1>
core <http://tools.ietf.org/core/>


From esko.dijk@philips.com  Fri Oct  7 07:46:14 2011
Return-Path: <esko.dijk@philips.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8787F21F8BD7 for <core@ietfa.amsl.com>; Fri,  7 Oct 2011 07:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.139
X-Spam-Level: 
X-Spam-Status: No, score=-4.139 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRKOARR2paTf for <core@ietfa.amsl.com>; Fri,  7 Oct 2011 07:46:14 -0700 (PDT)
Received: from VA3EHSOBE010.bigfish.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id C0B0E21F8BD3 for <core@ietf.org>; Fri,  7 Oct 2011 07:46:13 -0700 (PDT)
Received: from mail65-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Fri, 7 Oct 2011 14:49:27 +0000
Received: from mail65-va3 (localhost.localdomain [127.0.0.1])	by mail65-va3-R.bigfish.com (Postfix) with ESMTP id E18A41148132; Fri,  7 Oct 2011 14:49:26 +0000 (UTC)
X-SpamScore: -38
X-BigFish: VPS-38(zz217bL15d6O9251J542Mzz1202hzz1033IL8275dhz2dh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI
X-FB-SS: 13,
Received: from mail65-va3 (localhost.localdomain [127.0.0.1]) by mail65-va3 (MessageSwitch) id 1317998966720828_4179; Fri,  7 Oct 2011 14:49:26 +0000 (UTC)
Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.237])	by mail65-va3.bigfish.com (Postfix) with ESMTP id A0B0A17D0057; Fri,  7 Oct 2011 14:49:26 +0000 (UTC)
Received: from smtpx.philips.com (168.87.56.20) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 7 Oct 2011 14:49:20 +0000
Received: from NLHILEXH02.connect1.local (172.16.153.92) by connect1.philips.com (172.16.156.40) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 7 Oct 2011 16:49:22 +0200
Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLHILEXH02.connect1.local ([172.16.153.92]) with mapi; Fri, 7 Oct 2011 16:45:09 +0200
From: "Dijk, Esko" <esko.dijk@philips.com>
To: Jari Arkko <jari.arkko@piuha.net>, "core@ietf.org" <core@ietf.org>
Date: Fri, 7 Oct 2011 16:49:17 +0200
Thread-Topic: [core] Message ID sliding window
Thread-Index: Acw2tqzAADjOHl4uToStoFMsvrGBkxOPVAHQ
Message-ID: <A337AA36B3B96E4D853E6182B2F27AE2D168F9FC4D@NLCLUEXM03.connect1.local>
References: <4E0BB964.3020806@piuha.net>
In-Reply-To: <4E0BB964.3020806@piuha.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Subject: Re: [core] Message ID sliding window
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2011 14:46:14 -0000

To continue this discussion from a while ago: I agree with Jari on the free=
dom of assigning message IDs.
After a reboot the MID value is likely randomized and receiving CoAP nodes =
have to deal with that. And a sending node may wish to store only one MID c=
ounter for whatever reasons, or generated randomly if storing state is expe=
nsive.

However, it can still be beneficial to suggest (MAY) using sequential MIDs =
(mid++) for the regular operation between reboots. As an advice to be follo=
wed in case no special/random/stateless MID generation is required by a sen=
der. The reason is that this optionally enables to save RAM in receiving Co=
AP nodes that implement an optimized storage for MIDs close together, tradi=
ng higher code complexity for lower RAM use. MIDs are stored then for dedup=
lication purposes.

As Carsten phrased "if you believe supporting this specific optimization is=
 worth it, we could RECOMMEND (i.e., mandate at the SHOULD level) to use me=
ssage-IDs that are close (in modulo arithmetic) to recently used message-ID=
s". I think it is worth it as OPTIONAL/MAY behaviour.
A use case may be a client sending a "toggle light" command to a CoAP (serv=
er) lamp.

best regards,
Esko

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Jar=
i Arkko
Sent: Thursday 30 June 2011 1:47
To: core@ietf.org
Subject: Re: [core] Message ID sliding window

I actually like the freedom to use any approach to assigning message
IDs. I can imagine a few reasons why it might be easier in some cases to
have that freedom. As a hypothetical example, maybe I want to store only
one counter but send messages to multiple other nodes. Also, as Carsten
pointed out, sequential assignment is not as trivial as it sounds. What
do you or the receivers do after a reboot?

That being said, if you want your sender to use sequential message IDs,
it can just go ahead and do it. On the receiver side the issue is more
complex. COAP has acknowledgments to deal with those cases where you
absolutely have to sequence some operations, and relying merely on
sequence numbers would appear to not work in all cases, e.g., when a
message is lost. Given the reboot problem, a simple sliding window
approach might not be sufficient to keep track of which messages you
have received.

As a side note, I scanned the COAP draft today and did not find anything
about the scope of message IDs. Presumably message ID duplicate
detection etc should only apply for a given IP source and destination
pair. Otherwise there will be too many collisions. Is this specified
somewhere?

Jari

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

The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From Akbar.Rahman@InterDigital.com  Wed Oct 12 13:24:27 2011
Return-Path: <Akbar.Rahman@InterDigital.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C735521F8B61 for <core@ietfa.amsl.com>; Wed, 12 Oct 2011 13:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Level: 
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM2ApqX7waAa for <core@ietfa.amsl.com>; Wed, 12 Oct 2011 13:24:27 -0700 (PDT)
Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 34F1821F8B59 for <core@ietf.org>; Wed, 12 Oct 2011 13:24:27 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 12 Oct 2011 16:24:26 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 12 Oct 2011 16:24:26 -0400
Message-ID: <D60519DB022FFA48974A25955FFEC08C04194044@SAM.InterDigital.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: I-D Action: draft-rahman-core-groupcomm-07.txt
Thread-index: AcyJG1ftVH8FQI+qRceh3Omvio1c8gAASmYA
From: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>
To: <core@ietf.org>
X-OriginalArrivalTime: 12 Oct 2011 20:24:26.0734 (UTC) FILETIME=[F01BB8E0:01CC891C]
Subject: [core] FW: I-D Action: draft-rahman-core-groupcomm-07.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Oct 2011 20:24:28 -0000

Hi,


We have updated our CoAP Group Communications I-D as per discussions at
the last IETF in Quebec.   Please review and comment especially on the
detailed use case in section 4.2.


Esko & Akbar

-----Original Message-----
From: i-d-announce-bounces@ietf.org
[mailto:i-d-announce-bounces@ietf.org] On Behalf Of
internet-drafts@ietf.org
Sent: Wednesday, October 12, 2011 4:12 PM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-rahman-core-groupcomm-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Group Communication for CoAP
	Author(s)       : Akbar Rahman
                          Esko Dijk
	Filename        : draft-rahman-core-groupcomm-07.txt
	Pages           : 35
	Date            : 2011-10-12

   This is a working document intended to trigger discussion and develop
   draft text for the CoAP protocol specification in the area of group
   communication.  Engineering tradeoffs become more challenging in
   constrained environments, therefore group communication is considered
   within the context of adjacent topics that may impact or be impacted
   by design choices in the subject area.  A solution based on IP
   multicast is proposed.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rahman-core-groupcomm-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-rahman-core-groupcomm-07.txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From zach@sensinode.com  Mon Oct 17 03:37:37 2011
Return-Path: <zach@sensinode.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB0621F8B3F for <core@ietfa.amsl.com>; Mon, 17 Oct 2011 03:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WKzSzE0peO7 for <core@ietfa.amsl.com>; Mon, 17 Oct 2011 03:37:36 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id CB1DA21F8B0F for <core@ietf.org>; Mon, 17 Oct 2011 03:37:35 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id p9HAbXSI022383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <core@ietf.org>; Mon, 17 Oct 2011 13:37:33 +0300
From: Zach Shelby <zach@sensinode.com>
Content-Type: multipart/signed; boundary=Apple-Mail-10--909246250; protocol="application/pkcs7-signature"; micalg=sha1
Date: Mon, 17 Oct 2011 13:37:33 +0300
Message-Id: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com>
To: core WG <core@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [core] Uri-Path and -Query segmentation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Oct 2011 10:37:37 -0000

--Apple-Mail-10--909246250
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

We have started gaining a good deal of implementation and interop =
experience around the coap-07 specification, and have also seen the =
first multi-vendor implementations of ETSI M2M with the CoAP binding. =
Overall the interoperability has been good, usually just a few issues to =
work out in the beginning. There is however one area of the =
specification I think we need to reconsider as a result of this =
experience - the segmentation of Path and Query URI components.

This segmentation is a neat trick that we felt would make constrained =
implementations easier and smaller. However so far I have not seen that =
benefit, while at the same time it is causing interoperability problems =
and does not save any overhead (replacing a delimiter character for an =
8-bit option header, sometimes 16-bit!). One other problem that has come =
up, is that in some uses of URIs, the max number of CoAP options (15) =
quickly runs out. For example the ETSI M2M standard has some very deep =
(10 or so) resource structures, and may also have query parameters.=20

I would like to propose that we back-track to the simpler solution we =
had in previous versions, just including the whole path or query string =
in the Uri-Path or -Query option, respectively. However, in order to =
overcome the 270 octet limit of a single option, we allow the =
concatenation of these options as is done in the Proxy-Uri option. This =
is a minor change for implementations, as many already just perform =
concatenation when processing these options.=20

Thoughts?

This would require the following technical changes to coap-07:

Section 5.10.2:

-  o  each Uri-Path Option specifies one segment of the absolute path to
-     the resource, and
+  o  the Uri-Path Option contains the absolute path to the resource, =
and

-   o  each Uri-Query Option specifies one argument parameterizing the
-      resource.
+   o  the Uri-Query Option contains the query string of the resource.

Section 6.4:

   8.  If the value of the <path> component of /url/ is empty or
       consists of a single slash character (U+002F SOLIDUS "/"), then
       move to the next step.

 -     Otherwise, for each segment in the <path> component, include a
 -     Uri-Path Option and let that option's value be the segment (not
 -     including the delimiting slash characters) after converting all
 -     percent-encodings ("%" followed by two hexadecimal digits) to the
 -     corresponding characters.

+    Otherwise, the <path> component is included in a Uri-Path option=20
+    after converting all percent-encodings ("%" followed by two =
hexadecimal=20
+    digits) to the corresponding characters. In case the <path> doesn't =
fit=20
+    within a single option, the Uri-Path Option MAY be included =
multiple=20
+    times in a request such that the concatenation of the values =
results in=20
+    the single <path>. All but the last instance of the Uri-Path Option =
MUST=20
+    have a value with a length of 270 bytes, and the last instance MUST =
NOT be empty.

   9. =20
-       If /url/ has a <query> component, then, for each argument in the
-       <query> component, include a Uri-Query Option and let that
-       option's value be the argument (not including the question mark
-       and the delimiting ampersand characters) after converting all
-       percent-encodings to the corresponding characters.

+      If /url/ has a <query> component, then the <query> component is =
included=20
+      in a Uri-Query option after converting all percent-encodings to =
the corresponding=20
+      characters. In case the <query> doesn't fit=20
+      within a single option, the Uri-Query Option MAY be included =
multiple=20
+      times in a request such that the concatenation of the values =
results in=20
+      the single <query>. All but the last instance of the Uri-Query =
Option MUST=20
+      have a value with a length of 270 bytes, and the last instance =
MUST NOT be empty.

Zach

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


--Apple-Mail-10--909246250
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw
ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x
MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT
UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb
+JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH
HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh
5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW
bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud
HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu
ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL
7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb
rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW
YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO
guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn
zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz
MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk
YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg
LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx
jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e
FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT
DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe
vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7
btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB
hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE
JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9
OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD
VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw
QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1
qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS
gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu
EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy
bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW
jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx
HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC
GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEwMTcx
MDM3MzRaMCMGCSqGSIb3DQEJBDEWBBTgUoyWT5MNfhb1KIf28Ge5fUSmIDCCAQMGCSsGAQQBgjcQ
BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp
Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd
uDANBgkqhkiG9w0BAQEFAASCAQBM3F+r/2Cjaum2hWLOU7KkZNO6jbdCWLcQ8QGmcgHq3bWeAZmB
SrqUib2/XhHMYGnyVOLUx4o2vnCSIm1D/NS5RuphLX/6oz4pr9q8SPsLf2Hhi4g99wL+kYeT9jEj
uWWdJ7a1ChtpK0dNIQ/QT4iM/8z7YvsHoh2wMXI9gnJwEyvU2/OEPo5TJgmJJim0WUKnZJzfQZqH
+CAZnG6GfnucZRICoPwDXMhw9WKkoMSH7DqUBl+/anjWScSYb+osBVQAhzxJYtrAPIpvWLgYhwUG
pHbgqNmgzhlZUZuYtryCqk35kH8rBE85CJy9kkY/KnZysAPdHHIcu4Z45MDcL7OhAAAAAAAA

--Apple-Mail-10--909246250--

From zach@sensinode.com  Mon Oct 17 03:46:14 2011
Return-Path: <zach@sensinode.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDD121F877F for <core@ietfa.amsl.com>; Mon, 17 Oct 2011 03:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SBlN617MoTL for <core@ietfa.amsl.com>; Mon, 17 Oct 2011 03:46:13 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 0F94721F848A for <core@ietf.org>; Mon, 17 Oct 2011 03:46:12 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id p9HAkBbP024056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Oct 2011 13:46:11 +0300
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-11--908728396; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby <zach@sensinode.com>
In-Reply-To: <A337AA36B3B96E4D853E6182B2F27AE2D168F9FC4D@NLCLUEXM03.connect1.local>
Date: Mon, 17 Oct 2011 13:46:11 +0300
Message-Id: <EB26BB16-8077-4B91-943A-99D0550E9FC1@sensinode.com>
References: <4E0BB964.3020806@piuha.net> <A337AA36B3B96E4D853E6182B2F27AE2D168F9FC4D@NLCLUEXM03.connect1.local>
To: "Dijk, Esko" <esko.dijk@philips.com>
X-Mailer: Apple Mail (2.1084)
Cc: "core@ietf.org" <core@ietf.org>
Subject: Re: [core] Message ID sliding window
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Oct 2011 10:46:14 -0000

--Apple-Mail-11--908728396
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Esko,

Indeed, I do believe that sequential MIDs are going to be a common =
implementation strategy (of course with a random initial value). This is =
allowed by the current specification. What benefit do you see from =
adding MAY language around something that you may already do?=20

Seems instead we would need to point out to CoAP implementors that =
behavior could be used to optimize the storage of MIDs for duplication =
detection.=20

Now I think the reason why Carsten suggested a SHOULD is that this would =
make the optimization a whole lot more useful as it would encourage the =
majority of implementations to be compatible with this optimization. =
That makes sense.

Zach

On Oct 7, 2011, at 5:49 PM, Dijk, Esko wrote:

> To continue this discussion from a while ago: I agree with Jari on the =
freedom of assigning message IDs.
> After a reboot the MID value is likely randomized and receiving CoAP =
nodes have to deal with that. And a sending node may wish to store only =
one MID counter for whatever reasons, or generated randomly if storing =
state is expensive.
>=20
> However, it can still be beneficial to suggest (MAY) using sequential =
MIDs (mid++) for the regular operation between reboots. As an advice to =
be followed in case no special/random/stateless MID generation is =
required by a sender. The reason is that this optionally enables to save =
RAM in receiving CoAP nodes that implement an optimized storage for MIDs =
close together, trading higher code complexity for lower RAM use. MIDs =
are stored then for deduplication purposes.
>=20
> As Carsten phrased "if you believe supporting this specific =
optimization is worth it, we could RECOMMEND (i.e., mandate at the =
SHOULD level) to use message-IDs that are close (in modulo arithmetic) =
to recently used message-IDs". I think it is worth it as OPTIONAL/MAY =
behaviour.
> A use case may be a client sending a "toggle light" command to a CoAP =
(server) lamp.
>=20
> best regards,
> Esko
>=20
> -----Original Message-----
> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf =
Of Jari Arkko
> Sent: Thursday 30 June 2011 1:47
> To: core@ietf.org
> Subject: Re: [core] Message ID sliding window
>=20
> I actually like the freedom to use any approach to assigning message
> IDs. I can imagine a few reasons why it might be easier in some cases =
to
> have that freedom. As a hypothetical example, maybe I want to store =
only
> one counter but send messages to multiple other nodes. Also, as =
Carsten
> pointed out, sequential assignment is not as trivial as it sounds. =
What
> do you or the receivers do after a reboot?
>=20
> That being said, if you want your sender to use sequential message =
IDs,
> it can just go ahead and do it. On the receiver side the issue is more
> complex. COAP has acknowledgments to deal with those cases where you
> absolutely have to sequence some operations, and relying merely on
> sequence numbers would appear to not work in all cases, e.g., when a
> message is lost. Given the reboot problem, a simple sliding window
> approach might not be sufficient to keep track of which messages you
> have received.
>=20
> As a side note, I scanned the COAP draft today and did not find =
anything
> about the scope of message IDs. Presumably message ID duplicate
> detection etc should only apply for a given IP source and destination
> pair. Otherwise there will be too many collisions. Is this specified
> somewhere?
>=20
> Jari
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>=20
> The information contained in this message may be confidential and =
legally protected under applicable law. The message is intended solely =
for the addressee(s). If you are not the intended recipient, you are =
hereby notified that any use, forwarding, dissemination, or reproduction =
of this message is strictly prohibited and may be unlawful. If you are =
not the intended recipient, please contact the sender by return e-mail =
and destroy all copies of the original message.
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


--Apple-Mail-11--908728396
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw
ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x
MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT
UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb
+JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH
HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh
5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW
bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud
HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu
ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL
7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb
rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW
YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO
guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn
zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz
MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk
YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg
LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx
jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e
FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT
DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe
vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7
btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB
hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE
JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9
OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD
VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw
QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1
qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS
gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu
EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy
bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW
jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx
HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC
GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEwMTcx
MDQ2MTFaMCMGCSqGSIb3DQEJBDEWBBTU7vHmdeQOzs+j5t2CAOcdnL4MnTCCAQMGCSsGAQQBgjcQ
BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp
Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd
uDANBgkqhkiG9w0BAQEFAASCAQAWabmL5e3RrJtf2X0mr+tktCEXNDNTfSFk6qYK7G8VYxcNj+Gy
3fztEnaEHvvaCCdhgHmeHCox2LrRDe2nIUnozgAFgMDo9oW0CAMFRJXhDIlLn5icbh+juM9S+OWY
0wqt8tqLVXeRz/kqS8giCoMKfUyrtPZ3CV1llhp0Qb0yFIx6/7anGUhjF4XHoKbfSk+5xkn0zmA/
cw1N5zX2BIC+olKBW9SEiukH95l0wIr6i7+KSx0UqnyAjfER8lTOLL+xCMpD1AIrJL55X3nSYm4T
lmRmiSt0LgjBBmZ+V4dC92udKq/Aa38RhXmT+JuJqQEm4cUuwhXxvlns9H0649L3AAAAAAAA

--Apple-Mail-11--908728396--

From jari.arkko@piuha.net  Mon Oct 17 04:43:12 2011
Return-Path: <jari.arkko@piuha.net>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4A021F8B3F for <core@ietfa.amsl.com>; Mon, 17 Oct 2011 04:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.38
X-Spam-Level: 
X-Spam-Status: No, score=-102.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7eOTdvZdPUG for <core@ietfa.amsl.com>; Mon, 17 Oct 2011 04:43:12 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id BE7F121F8B24 for <core@ietf.org>; Mon, 17 Oct 2011 04:43:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 263732D42C; Mon, 17 Oct 2011 14:43:11 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rBxa-JYKEjj; Mon, 17 Oct 2011 14:43:09 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D974E2CE32; Mon, 17 Oct 2011 14:43:09 +0300 (EEST)
Message-ID: <4E9C14CD.2010700@piuha.net>
Date: Mon, 17 Oct 2011 13:43:09 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0
MIME-Version: 1.0
To: Zach Shelby <zach@sensinode.com>
References: <4E0BB964.3020806@piuha.net> <A337AA36B3B96E4D853E6182B2F27AE2D168F9FC4D@NLCLUEXM03.connect1.local> <EB26BB16-8077-4B91-943A-99D0550E9FC1@sensinode.com>
In-Reply-To: <EB26BB16-8077-4B91-943A-99D0550E9FC1@sensinode.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "core@ietf.org" <core@ietf.org>
Subject: Re: [core] Message ID sliding window
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Oct 2011 11:43:12 -0000

The original proposal that started this thread was to make some recommendation on using sequential IDs. I am against that (even as a SHOULD), on the grounds that it is unnecessary and any level of mandatory sequencing would break some implementation strategies (such as the one I used on my tiny device). Of course you can use any strategy you want, including sequencing. We should not mandate that in any sense in the spec, however, because otherwise someone will start trusting that all devices behave that way.

Anyway, I had a quick look at -07 and noticed this:

> End-points dealing with large numbers of
> transactions could keep multiple Message ID variables, for example
> per prefix or destination address.  The initial variable value SHOULD
> be randomized.  The same Message ID MUST NOT be re-used within the
> potential retransmission window, calculated as RESPONSE_TIMEOUT *
> RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT - 1) plus the expected
> maximum round trip time.

I think you should change s/window,/window to the same destination address,/ because otherwise those multiple variables are not going to be very useful.

(Or possibly a combination of source/destination address.)

Jari

On 17.10.2011 12:46, Zach Shelby wrote:
> Esko,
>
> Indeed, I do believe that sequential MIDs are going to be a common implementation strategy (of course with a random initial value). This is allowed by the current specification. What benefit do you see from adding MAY language around something that you may already do?
>
> Seems instead we would need to point out to CoAP implementors that behavior could be used to optimize the storage of MIDs for duplication detection.
>
> Now I think the reason why Carsten suggested a SHOULD is that this would make the optimization a whole lot more useful as it would encourage the majority of implementations to be compatible with this optimization. That makes sense.
>
> Zach
>
> On Oct 7, 2011, at 5:49 PM, Dijk, Esko wrote:
>
>> To continue this discussion from a while ago: I agree with Jari on the freedom of assigning message IDs.
>> After a reboot the MID value is likely randomized and receiving CoAP nodes have to deal with that. And a sending node may wish to store only one MID counter for whatever reasons, or generated randomly if storing state is expensive.
>>
>> However, it can still be beneficial to suggest (MAY) using sequential MIDs (mid++) for the regular operation between reboots. As an advice to be followed in case no special/random/stateless MID generation is required by a sender. The reason is that this optionally enables to save RAM in receiving CoAP nodes that implement an optimized storage for MIDs close together, trading higher code complexity for lower RAM use. MIDs are stored then for deduplication purposes.
>>
>> As Carsten phrased "if you believe supporting this specific optimization is worth it, we could RECOMMEND (i.e., mandate at the SHOULD level) to use message-IDs that are close (in modulo arithmetic) to recently used message-IDs". I think it is worth it as OPTIONAL/MAY behaviour.
>> A use case may be a client sending a "toggle light" command to a CoAP (server) lamp.
>>
>> best regards,
>> Esko
>>
>> -----Original Message-----
>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Jari Arkko
>> Sent: Thursday 30 June 2011 1:47
>> To: core@ietf.org
>> Subject: Re: [core] Message ID sliding window
>>
>> I actually like the freedom to use any approach to assigning message
>> IDs. I can imagine a few reasons why it might be easier in some cases to
>> have that freedom. As a hypothetical example, maybe I want to store only
>> one counter but send messages to multiple other nodes. Also, as Carsten
>> pointed out, sequential assignment is not as trivial as it sounds. What
>> do you or the receivers do after a reboot?
>>
>> That being said, if you want your sender to use sequential message IDs,
>> it can just go ahead and do it. On the receiver side the issue is more
>> complex. COAP has acknowledgments to deal with those cases where you
>> absolutely have to sequence some operations, and relying merely on
>> sequence numbers would appear to not work in all cases, e.g., when a
>> message is lost. Given the reboot problem, a simple sliding window
>> approach might not be sufficient to keep track of which messages you
>> have received.
>>
>> As a side note, I scanned the COAP draft today and did not find anything
>> about the scope of message IDs. Presumably message ID duplicate
>> detection etc should only apply for a given IP source and destination
>> pair. Otherwise there will be too many collisions. Is this specified
>> somewhere?
>>
>> Jari
>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>>
>> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core


From bergmann@tzi.org  Mon Oct 17 05:28:50 2011
Return-Path: <bergmann@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838B921F8B63 for <core@ietfa.amsl.com>; Mon, 17 Oct 2011 05:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level: 
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdTYSfmdLa42 for <core@ietfa.amsl.com>; Mon, 17 Oct 2011 05:28:50 -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 BE2B721F8ACE for <core@ietf.org>; Mon, 17 Oct 2011 05:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from aung.tzi.org (robinson.informatik.uni-bremen.de [134.102.218.2]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p9HCSa2s004462; Mon, 17 Oct 2011 14:28:42 +0200 (CEST)
From: Olaf Bergmann <bergmann@tzi.org>
To: Zach Shelby <zach@sensinode.com>
References: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com>
Date: Mon, 17 Oct 2011 14:28:25 +0200
In-Reply-To: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com> (Zach Shelby's message of "Mon, 17 Oct 2011 13:37:33 +0300")
Message-ID: <87lisj245y.fsf@tzi.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: core WG <core@ietf.org>
Subject: Re: [core] Uri-Path and -Query segmentation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Oct 2011 12:28:50 -0000

Zach,


Zach Shelby <zach@sensinode.com> writes:

> There is however one area of the specification I think we need to reconsider as a result of this experience - the segmentation of Path and Query URI components.

from my perspective, the segmentation and normalization of
percent-encodings significantly contribute to the handling of URIs on
the server-side as you can easily walk down on your sequence of path
segments without having to segment the URI yourself, and you can feed it
easily into a hash function to identify resources as it is already
normalized. 

[...]

On the other hand, for URI-Query, I do not see a big advantage of
splitting it, therefore, your proposal sounds good to me.  (The
combination of normalizing percent-encodings with the splitting into 270
bytes chunks is somewhat nasty where a multibyte character is split in
the middle -- this may make.implementation of client and server parsers
a bit more complex).

>    9.  
> -       If /url/ has a <query> component, then, for each argument in the
> -       <query> component, include a Uri-Query Option and let that
> -       option's value be the argument (not including the question mark
> -       and the delimiting ampersand characters) after converting all
> -       percent-encodings to the corresponding characters.
>
> +      If /url/ has a <query> component, then the <query> component is included 
> +      in a Uri-Query option after converting all percent-encodings to the corresponding 
> +      characters. In case the <query> doesn't fit 
> +      within a single option, the Uri-Query Option MAY be included multiple 
> +      times in a request such that the concatenation of the values results in 
> +      the single <query>. All but the last instance of the Uri-Query Option MUST 
> +      have a value with a length of 270 bytes, and the last instance MUST NOT be empty.

Gruesse,
Olaf

From esko.dijk@philips.com  Mon Oct 17 08:01:22 2011
Return-Path: <esko.dijk@philips.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD9721F8BD5 for <core@ietfa.amsl.com>; Mon, 17 Oct 2011 08:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70-SC+lh6Vns for <core@ietfa.amsl.com>; Mon, 17 Oct 2011 08:01:21 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 58A3621F8BCB for <core@ietf.org>; Mon, 17 Oct 2011 08:01:21 -0700 (PDT)
Received: from mail39-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.22; Mon, 17 Oct 2011 15:01:20 +0000
Received: from mail39-ch1 (localhost.localdomain [127.0.0.1])	by mail39-ch1-R.bigfish.com (Postfix) with ESMTP id B957692840C; Mon, 17 Oct 2011 15:01:20 +0000 (UTC)
X-SpamScore: -53
X-BigFish: VPS-53(zz217bL15d6O9371K9251J146fK542M1432N98dKzz1202hzz1033IL8275dhz2dh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI
X-FB-SS: 0,13,
Received: from mail39-ch1 (localhost.localdomain [127.0.0.1]) by mail39-ch1 (MessageSwitch) id 1318863663751889_2439; Mon, 17 Oct 2011 15:01:03 +0000 (UTC)
Received: from CH1EHSMHS010.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254])	by mail39-ch1.bigfish.com (Postfix) with ESMTP id 8E350398052;	Mon, 17 Oct 2011 15:01:03 +0000 (UTC)
Received: from smtpx.philips.com (168.87.56.20) by CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 17 Oct 2011 15:00:55 +0000
Received: from NLAMSEXH04.connect1.local (172.16.153.25) by connect1.philips.com (172.16.156.40) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 17 Oct 2011 17:00:58 +0200
Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLAMSEXH04.connect1.local ([172.16.153.25]) with mapi; Mon, 17 Oct 2011 16:56:25 +0200
From: "Dijk, Esko" <esko.dijk@philips.com>
To: Jari Arkko <jari.arkko@piuha.net>, Zach Shelby <zach@sensinode.com>
Date: Mon, 17 Oct 2011 16:56:23 +0200
Thread-Topic: [core] Message ID sliding window
Thread-Index: AcyMwVWXi/jVEL7VT9KyQC+rENsMWAAAMHdA
Message-ID: <A337AA36B3B96E4D853E6182B2F27AE2D1690AA4A0@NLCLUEXM03.connect1.local>
References: <4E0BB964.3020806@piuha.net> <A337AA36B3B96E4D853E6182B2F27AE2D168F9FC4D@NLCLUEXM03.connect1.local> <EB26BB16-8077-4B91-943A-99D0550E9FC1@sensinode.com> <4E9C14CD.2010700@piuha.net>
In-Reply-To: <4E9C14CD.2010700@piuha.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Cc: "core@ietf.org" <core@ietf.org>
Subject: Re: [core] Message ID sliding window
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Oct 2011 15:01:22 -0000

Hi,

> We should not mandate that in any sense in the spec, however, because oth=
erwise someone will start trusting that all devices behave that way.

this was one of the reasons for me to propose a 'MAY' here. It does not cre=
ate a barrier to interesting strategies e.g. as used in the tiny CoAP senso=
rs. A 'SHOULD' is rather strong here ("but the full implications must be un=
derstood and carefully weighed before choosing a different course", RFC 211=
9).=20

A 'MAY' serves as a note to implementers "you could do it this way, with th=
ese specific benefits" which should be enough push in the right direction i=
n applications where an implementer doesn't really care what MID generation=
 strategy is applied e.g. as in unconstrained nodes.=20
Interestingly a 'MAY' provides a _stronger_ requirement for CoAP nodes to s=
upport non-sequential MIDs from other nodes. Because then, implementers wil=
l not assume that everyone follows the 'SHOULD' from the spec. In fact they=
 MUST NOT assume that the optional feature is there, as RFC 2119 indicates =
for a 'MAY' :)

(Downside is that there is less incentive for implementers to care about op=
timizing MID storage, though.)

regards,
Esko

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@piuha.net]=20
Sent: Monday 17 October 2011 13:43
To: Zach Shelby
Cc: Dijk, Esko; core@ietf.org
Subject: Re: [core] Message ID sliding window


The original proposal that started this thread was to make some recommendat=
ion on using sequential IDs. I am against that (even as a SHOULD), on the g=
rounds that it is unnecessary and any level of mandatory sequencing would b=
reak some implementation strategies (such as the one I used on my tiny devi=
ce). Of course you can use any strategy you want, including sequencing. We =
should not mandate that in any sense in the spec, however, because otherwis=
e someone will start trusting that all devices behave that way.

Anyway, I had a quick look at -07 and noticed this:

> End-points dealing with large numbers of
> transactions could keep multiple Message ID variables, for example
> per prefix or destination address.  The initial variable value SHOULD
> be randomized.  The same Message ID MUST NOT be re-used within the
> potential retransmission window, calculated as RESPONSE_TIMEOUT *
> RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT - 1) plus the expected
> maximum round trip time.

I think you should change s/window,/window to the same destination address,=
/ because otherwise those multiple variables are not going to be very usefu=
l.

(Or possibly a combination of source/destination address.)

Jari

On 17.10.2011 12:46, Zach Shelby wrote:
> Esko,
>
> Indeed, I do believe that sequential MIDs are going to be a common implem=
entation strategy (of course with a random initial value). This is allowed =
by the current specification. What benefit do you see from adding MAY langu=
age around something that you may already do?
>
> Seems instead we would need to point out to CoAP implementors that behavi=
or could be used to optimize the storage of MIDs for duplication detection.
>
> Now I think the reason why Carsten suggested a SHOULD is that this would =
make the optimization a whole lot more useful as it would encourage the maj=
ority of implementations to be compatible with this optimization. That make=
s sense.
>
> Zach
>
> On Oct 7, 2011, at 5:49 PM, Dijk, Esko wrote:
>
>> To continue this discussion from a while ago: I agree with Jari on the f=
reedom of assigning message IDs.
>> After a reboot the MID value is likely randomized and receiving CoAP nod=
es have to deal with that. And a sending node may wish to store only one MI=
D counter for whatever reasons, or generated randomly if storing state is e=
xpensive.
>>
>> However, it can still be beneficial to suggest (MAY) using sequential MI=
Ds (mid++) for the regular operation between reboots. As an advice to be fo=
llowed in case no special/random/stateless MID generation is required by a =
sender. The reason is that this optionally enables to save RAM in receiving=
 CoAP nodes that implement an optimized storage for MIDs close together, tr=
ading higher code complexity for lower RAM use. MIDs are stored then for de=
duplication purposes.
>>
>> As Carsten phrased "if you believe supporting this specific optimization=
 is worth it, we could RECOMMEND (i.e., mandate at the SHOULD level) to use=
 message-IDs that are close (in modulo arithmetic) to recently used message=
-IDs". I think it is worth it as OPTIONAL/MAY behaviour.
>> A use case may be a client sending a "toggle light" command to a CoAP (s=
erver) lamp.
>>
>> best regards,
>> Esko
>>
>> -----Original Message-----
>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of =
Jari Arkko
>> Sent: Thursday 30 June 2011 1:47
>> To: core@ietf.org
>> Subject: Re: [core] Message ID sliding window
>>
>> I actually like the freedom to use any approach to assigning message
>> IDs. I can imagine a few reasons why it might be easier in some cases to
>> have that freedom. As a hypothetical example, maybe I want to store only
>> one counter but send messages to multiple other nodes. Also, as Carsten
>> pointed out, sequential assignment is not as trivial as it sounds. What
>> do you or the receivers do after a reboot?
>>
>> That being said, if you want your sender to use sequential message IDs,
>> it can just go ahead and do it. On the receiver side the issue is more
>> complex. COAP has acknowledgments to deal with those cases where you
>> absolutely have to sequence some operations, and relying merely on
>> sequence numbers would appear to not work in all cases, e.g., when a
>> message is lost. Given the reboot problem, a simple sliding window
>> approach might not be sufficient to keep track of which messages you
>> have received.
>>
>> As a side note, I scanned the COAP draft today and did not find anything
>> about the scope of message IDs. Presumably message ID duplicate
>> detection etc should only apply for a given IP source and destination
>> pair. Otherwise there will be too many collisions. Is this specified
>> somewhere?
>>
>> Jari
>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>>
>> The information contained in this message may be confidential and legall=
y protected under applicable law. The message is intended solely for the ad=
dressee(s). If you are not the intended recipient, you are hereby notified =
that any use, forwarding, dissemination, or reproduction of this message is=
 strictly prohibited and may be unlawful. If you are not the intended recip=
ient, please contact the sender by return e-mail and destroy all copies of =
the original message.
>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core



From Akbar.Rahman@InterDigital.com  Mon Oct 17 08:11:02 2011
Return-Path: <Akbar.Rahman@InterDigital.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B1A21F8509 for <core@ietfa.amsl.com>; Mon, 17 Oct 2011 08:11:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level: 
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7rfgJJGrMzh for <core@ietfa.amsl.com>; Mon, 17 Oct 2011 08:11:01 -0700 (PDT)
Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id E823F21F84D2 for <core@ietf.org>; Mon, 17 Oct 2011 08:10:56 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 17 Oct 2011 11:10:40 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 17 Oct 2011 11:10:40 -0400
Message-ID: <D60519DB022FFA48974A25955FFEC08C042102C3@SAM.InterDigital.com>
In-Reply-To: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: [core] Uri-Path and -Query segmentation
Thread-index: AcyMuMvbnWDOXGa7TtmdvNIGt8x0ywAJBDhQ
References: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com>
From: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>
To: "Zach Shelby" <zach@sensinode.com>
X-OriginalArrivalTime: 17 Oct 2011 15:10:40.0437 (UTC) FILETIME=[EED38650:01CC8CDE]
Cc: core WG <core@ietf.org>
Subject: Re: [core] Uri-Path and -Query segmentation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Oct 2011 15:11:02 -0000

Hi Zach,


With regards to your suggestion:


	"I would like to propose that we back-track to the simpler
solution we had in previous versions, just including the 	whole
path or query string in the Uri-Path or -Query option, respectively.
However, in order to overcome the 270 	octet limit of a single option,
we allow the concatenation of these options as is done in the Proxy-Uri
option. 	This is a minor change for implementations, as many
already just perform concatenation when processing these
options."


I support this change (back to the simpler solution).  In fact, I was
considering the trade-off between complexity and benefit when I was
looking at this issue as part of the HTTP-CoAP Mapping draft, and I
agree with you that the current approach does not offer much benefit.


Akbar


-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of
Zach Shelby
Sent: Monday, October 17, 2011 6:38 AM
To: core WG
Subject: [core] Uri-Path and -Query segmentation

Hi,

We have started gaining a good deal of implementation and interop
experience around the coap-07 specification, and have also seen the
first multi-vendor implementations of ETSI M2M with the CoAP binding.
Overall the interoperability has been good, usually just a few issues to
work out in the beginning. There is however one area of the
specification I think we need to reconsider as a result of this
experience - the segmentation of Path and Query URI components.

This segmentation is a neat trick that we felt would make constrained
implementations easier and smaller. However so far I have not seen that
benefit, while at the same time it is causing interoperability problems
and does not save any overhead (replacing a delimiter character for an
8-bit option header, sometimes 16-bit!). One other problem that has come
up, is that in some uses of URIs, the max number of CoAP options (15)
quickly runs out. For example the ETSI M2M standard has some very deep
(10 or so) resource structures, and may also have query parameters.=20

I would like to propose that we back-track to the simpler solution we
had in previous versions, just including the whole path or query string
in the Uri-Path or -Query option, respectively. However, in order to
overcome the 270 octet limit of a single option, we allow the
concatenation of these options as is done in the Proxy-Uri option. This
is a minor change for implementations, as many already just perform
concatenation when processing these options.=20

Thoughts?

This would require the following technical changes to coap-07:

Section 5.10.2:

-  o  each Uri-Path Option specifies one segment of the absolute path to
-     the resource, and
+  o  the Uri-Path Option contains the absolute path to the resource,
and

-   o  each Uri-Query Option specifies one argument parameterizing the
-      resource.
+   o  the Uri-Query Option contains the query string of the resource.

Section 6.4:

   8.  If the value of the <path> component of /url/ is empty or
       consists of a single slash character (U+002F SOLIDUS "/"), then
       move to the next step.

 -     Otherwise, for each segment in the <path> component, include a
 -     Uri-Path Option and let that option's value be the segment (not
 -     including the delimiting slash characters) after converting all
 -     percent-encodings ("%" followed by two hexadecimal digits) to the
 -     corresponding characters.

+    Otherwise, the <path> component is included in a Uri-Path option=20
+    after converting all percent-encodings ("%" followed by two
hexadecimal=20
+    digits) to the corresponding characters. In case the <path> doesn't
fit=20
+    within a single option, the Uri-Path Option MAY be included
multiple=20
+    times in a request such that the concatenation of the values
results in=20
+    the single <path>. All but the last instance of the Uri-Path Option
MUST=20
+    have a value with a length of 270 bytes, and the last instance MUST
NOT be empty.

   9. =20
-       If /url/ has a <query> component, then, for each argument in the
-       <query> component, include a Uri-Query Option and let that
-       option's value be the argument (not including the question mark
-       and the delimiting ampersand characters) after converting all
-       percent-encodings to the corresponding characters.

+      If /url/ has a <query> component, then the <query> component is
included=20
+      in a Uri-Query option after converting all percent-encodings to
the corresponding=20
+      characters. In case the <query> doesn't fit=20
+      within a single option, the Uri-Query Option MAY be included
multiple=20
+      times in a request such that the concatenation of the values
results in=20
+      the single <query>. All but the last instance of the Uri-Query
Option MUST=20
+      have a value with a length of 270 bytes, and the last instance
MUST NOT be empty.

Zach

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


From likepeng@huawei.com  Tue Oct 18 01:58:20 2011
Return-Path: <likepeng@huawei.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B2021F8C81 for <core@ietfa.amsl.com>; Tue, 18 Oct 2011 01:58:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5icV+YaZWAgX for <core@ietfa.amsl.com>; Tue, 18 Oct 2011 01:58:19 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id BCAB121F8C10 for <core@ietf.org>; Tue, 18 Oct 2011 01:58:15 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT9004L37JP3R@szxga05-in.huawei.com> for core@ietf.org; Tue, 18 Oct 2011 16:57:25 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT900CGP7JOU6@szxga05-in.huawei.com> for core@ietf.org; Tue, 18 Oct 2011 16:57:25 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AEH23182; Tue, 18 Oct 2011 16:56:44 +0800
Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 18 Oct 2011 16:56:39 +0800
Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.181]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0270.001; Tue, 18 Oct 2011 16:56:37 +0800
Date: Tue, 18 Oct 2011 08:56:36 +0000
From: Likepeng <likepeng@huawei.com>
In-reply-to: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com>
X-Originating-IP: [10.70.109.109]
To: Zach Shelby <zach@sensinode.com>, core WG <core@ietf.org>
Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2CF30BA@szxeml525-mbs.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: zh-CN, en-US
Thread-topic: [core] Uri-Path and -Query segmentation
Thread-index: AQHMjLjYkbhVgnuIgEyz/dw8Toh3bZWBvPDg
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com>
Subject: Re: [core] Uri-Path and -Query segmentation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Oct 2011 08:58:20 -0000

> I would like to propose that we back-track to the simpler solution we had in previous versions, just including the whole path or query string in the Uri-Path or -Query option, respectively.

I support this proposal. 

During our implementation, we found out that if multiple URI-Paths are out of order, it will introduce some problems. Also concatenation of URI-Path / URI-Query will introduce some problems.

So I think it is a good idea to have just one URI-Path or URI-Query. It will make easier for the implementation.

Kind Regards
Kepeng
-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zach Shelby
Sent: Monday, October 17, 2011 6:38 PM
To: core WG
Subject: [core] Uri-Path and -Query segmentation

Hi,

We have started gaining a good deal of implementation and interop experience around the coap-07 specification, and have also seen the first multi-vendor implementations of ETSI M2M with the CoAP binding. Overall the interoperability has been good, usually just a few issues to work out in the beginning. There is however one area of the specification I think we need to reconsider as a result of this experience - the segmentation of Path and Query URI components.

This segmentation is a neat trick that we felt would make constrained implementations easier and smaller. However so far I have not seen that benefit, while at the same time it is causing interoperability problems and does not save any overhead (replacing a delimiter character for an 8-bit option header, sometimes 16-bit!). One other problem that has come up, is that in some uses of URIs, the max number of CoAP options (15) quickly runs out. For example the ETSI M2M standard has some very deep (10 or so) resource structures, and may also have query parameters. 

I would like to propose that we back-track to the simpler solution we had in previous versions, just including the whole path or query string in the Uri-Path or -Query option, respectively. However, in order to overcome the 270 octet limit of a single option, we allow the concatenation of these options as is done in the Proxy-Uri option. This is a minor change for implementations, as many already just perform concatenation when processing these options. 

Thoughts?

This would require the following technical changes to coap-07:

Section 5.10.2:

-  o  each Uri-Path Option specifies one segment of the absolute path to
-     the resource, and
+  o  the Uri-Path Option contains the absolute path to the resource, and

-   o  each Uri-Query Option specifies one argument parameterizing the
-      resource.
+   o  the Uri-Query Option contains the query string of the resource.

Section 6.4:

   8.  If the value of the <path> component of /url/ is empty or
       consists of a single slash character (U+002F SOLIDUS "/"), then
       move to the next step.

 -     Otherwise, for each segment in the <path> component, include a
 -     Uri-Path Option and let that option's value be the segment (not
 -     including the delimiting slash characters) after converting all
 -     percent-encodings ("%" followed by two hexadecimal digits) to the
 -     corresponding characters.

+    Otherwise, the <path> component is included in a Uri-Path option 
+    after converting all percent-encodings ("%" followed by two hexadecimal 
+    digits) to the corresponding characters. In case the <path> doesn't fit 
+    within a single option, the Uri-Path Option MAY be included multiple 
+    times in a request such that the concatenation of the values results in 
+    the single <path>. All but the last instance of the Uri-Path Option MUST 
+    have a value with a length of 270 bytes, and the last instance MUST NOT be empty.

   9.  
-       If /url/ has a <query> component, then, for each argument in the
-       <query> component, include a Uri-Query Option and let that
-       option's value be the argument (not including the question mark
-       and the delimiting ampersand characters) after converting all
-       percent-encodings to the corresponding characters.

+      If /url/ has a <query> component, then the <query> component is included 
+      in a Uri-Query option after converting all percent-encodings to the corresponding 
+      characters. In case the <query> doesn't fit 
+      within a single option, the Uri-Query Option MAY be included multiple 
+      times in a request such that the concatenation of the values results in 
+      the single <query>. All but the last instance of the Uri-Query Option MUST 
+      have a value with a length of 270 bytes, and the last instance MUST NOT be empty.

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


From esko.dijk@philips.com  Wed Oct 19 01:01:06 2011
Return-Path: <esko.dijk@philips.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B033F21F8A71 for <core@ietfa.amsl.com>; Wed, 19 Oct 2011 01:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8gYM-ze+6eg for <core@ietfa.amsl.com>; Wed, 19 Oct 2011 01:01:05 -0700 (PDT)
Received: from VA3EHSOBE008.bigfish.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7961C21F8531 for <core@ietf.org>; Wed, 19 Oct 2011 01:01:05 -0700 (PDT)
Received: from mail27-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Wed, 19 Oct 2011 08:01:05 +0000
Received: from mail27-va3 (localhost.localdomain [127.0.0.1])	by mail27-va3-R.bigfish.com (Postfix) with ESMTP id C17B710C03C5; Wed, 19 Oct 2011 08:01:04 +0000 (UTC)
X-SpamScore: -38
X-BigFish: VPS-38(zz217bL15d6O9251J542Mzz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI
Received: from mail27-va3 (localhost.localdomain [127.0.0.1]) by mail27-va3 (MessageSwitch) id 1319011264498409_31047; Wed, 19 Oct 2011 08:01:04 +0000 (UTC)
Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.236])	by mail27-va3.bigfish.com (Postfix) with ESMTP id 66C142C804D; Wed, 19 Oct 2011 08:01:04 +0000 (UTC)
Received: from smtpx.philips.com (168.87.56.20) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 19 Oct 2011 08:00:50 +0000
Received: from NLAMSEXH05.connect1.local (172.16.153.68) by connect1.philips.com (172.16.156.152) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 19 Oct 2011 10:00:49 +0200
Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLAMSEXH05.connect1.local ([172.16.153.68]) with mapi; Wed, 19 Oct 2011 09:56:18 +0200
From: "Dijk, Esko" <esko.dijk@philips.com>
To: Zach Shelby <zach@sensinode.com>, core WG <core@ietf.org>
Date: Wed, 19 Oct 2011 10:00:47 +0200
Thread-Topic: [core] Uri-Path and -Query segmentation
Thread-Index: AcyMuDKy7gqNAYs4Sa66fXGoXtT3TABe6/EQ
Message-ID: <A337AA36B3B96E4D853E6182B2F27AE2D1691222AA@NLCLUEXM03.connect1.local>
References: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com>
In-Reply-To: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Subject: Re: [core] Uri-Path and -Query segmentation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Oct 2011 08:01:06 -0000

Hi Zach,

Agree with the proposed change.

Esko

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zac=
h Shelby
Sent: Monday 17 October 2011 12:38
To: core WG
Subject: [core] Uri-Path and -Query segmentation

Hi,

We have started gaining a good deal of implementation and interop experienc=
e around the coap-07 specification, and have also seen the first multi-vend=
or implementations of ETSI M2M with the CoAP binding. Overall the interoper=
ability has been good, usually just a few issues to work out in the beginni=
ng. There is however one area of the specification I think we need to recon=
sider as a result of this experience - the segmentation of Path and Query U=
RI components.

This segmentation is a neat trick that we felt would make constrained imple=
mentations easier and smaller. However so far I have not seen that benefit,=
 while at the same time it is causing interoperability problems and does no=
t save any overhead (replacing a delimiter character for an 8-bit option he=
ader, sometimes 16-bit!). One other problem that has come up, is that in so=
me uses of URIs, the max number of CoAP options (15) quickly runs out. For =
example the ETSI M2M standard has some very deep (10 or so) resource struct=
ures, and may also have query parameters.

I would like to propose that we back-track to the simpler solution we had i=
n previous versions, just including the whole path or query string in the U=
ri-Path or -Query option, respectively. However, in order to overcome the 2=
70 octet limit of a single option, we allow the concatenation of these opti=
ons as is done in the Proxy-Uri option. This is a minor change for implemen=
tations, as many already just perform concatenation when processing these o=
ptions.

Thoughts?

This would require the following technical changes to coap-07:

Section 5.10.2:

-  o  each Uri-Path Option specifies one segment of the absolute path to
-     the resource, and
+  o  the Uri-Path Option contains the absolute path to the resource, and

-   o  each Uri-Query Option specifies one argument parameterizing the
-      resource.
+   o  the Uri-Query Option contains the query string of the resource.

Section 6.4:

   8.  If the value of the <path> component of /url/ is empty or
       consists of a single slash character (U+002F SOLIDUS "/"), then
       move to the next step.

 -     Otherwise, for each segment in the <path> component, include a
 -     Uri-Path Option and let that option's value be the segment (not
 -     including the delimiting slash characters) after converting all
 -     percent-encodings ("%" followed by two hexadecimal digits) to the
 -     corresponding characters.

+    Otherwise, the <path> component is included in a Uri-Path option
+    after converting all percent-encodings ("%" followed by two hexadecima=
l
+    digits) to the corresponding characters. In case the <path> doesn't fi=
t
+    within a single option, the Uri-Path Option MAY be included multiple
+    times in a request such that the concatenation of the values results i=
n
+    the single <path>. All but the last instance of the Uri-Path Option MU=
ST
+    have a value with a length of 270 bytes, and the last instance MUST NO=
T be empty.

   9.
-       If /url/ has a <query> component, then, for each argument in the
-       <query> component, include a Uri-Query Option and let that
-       option's value be the argument (not including the question mark
-       and the delimiting ampersand characters) after converting all
-       percent-encodings to the corresponding characters.

+      If /url/ has a <query> component, then the <query> component is incl=
uded
+      in a Uri-Query option after converting all percent-encodings to the =
corresponding
+      characters. In case the <query> doesn't fit
+      within a single option, the Uri-Query Option MAY be included multipl=
e
+      times in a request such that the concatenation of the values results=
 in
+      the single <query>. All but the last instance of the Uri-Query Optio=
n MUST
+      have a value with a length of 270 bytes, and the last instance MUST =
NOT be empty.

Zach

--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From zach@sensinode.com  Wed Oct 19 01:37:33 2011
Return-Path: <zach@sensinode.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B46F21F8AFE for <core@ietfa.amsl.com>; Wed, 19 Oct 2011 01:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hictUQBN2D4q for <core@ietfa.amsl.com>; Wed, 19 Oct 2011 01:37:32 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 37AAE21F8B1A for <core@ietf.org>; Wed, 19 Oct 2011 01:37:31 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id p9J8bTcK007186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Oct 2011 11:37:29 +0300
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-186--743651131; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby <zach@sensinode.com>
In-Reply-To: <87lisj245y.fsf@tzi.org>
Date: Wed, 19 Oct 2011 11:37:28 +0300
Message-Id: <0B4C70B5-D29B-468F-8A67-8D5BEB2A5B03@sensinode.com>
References: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com> <87lisj245y.fsf@tzi.org>
To: Olaf Bergmann <bergmann@tzi.org>
X-Mailer: Apple Mail (2.1084)
Cc: core WG <core@ietf.org>
Subject: Re: [core] Uri-Path and -Query segmentation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Oct 2011 08:37:33 -0000

--Apple-Mail-186--743651131
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Olaf,

On Oct 17, 2011, at 3:28 PM, Olaf Bergmann wrote:

>> There is however one area of the specification I think we need to =
reconsider as a result of this experience - the segmentation of Path and =
Query URI components.
>=20
> from my perspective, the segmentation and normalization of
> percent-encodings significantly contribute to the handling of URIs on
> the server-side as you can easily walk down on your sequence of path
> segments without having to segment the URI yourself, and you can feed =
it
> easily into a hash function to identify resources as it is already
> normalized.=20

You bring up two good points.

1. Walking down the sequence of path segments is a nice feature, as long =
as you store your resources like that. What I have noticed is that most =
constrained devices have a small number of resources, so the whole path =
is just stored as a string (not individual segments). You then just do a =
string match or you can match a hash of the whole path.=20

2. You are saying that normalization is somehow tied to segmentation of =
the path. In the proposed update normalization would be performed in =
exactly the same way as it is in -07, but instead of segmentation the =
whole normalized path is just placed in a Uri-Path option. Did I miss =
something here? Yes, you do have the same issue as pointed out below =
with Uri-Query, which means you need to concatenate before parsing.

> [...]
>=20
> On the other hand, for URI-Query, I do not see a big advantage of
> splitting it, therefore, your proposal sounds good to me.  (The
> combination of normalizing percent-encodings with the splitting into =
270
> bytes chunks is somewhat nasty where a multibyte character is split in
> the middle -- this may make.implementation of client and server =
parsers
> a bit more complex).

Yes, but the Uri-Query options would be first concatenated before =
parsing. The same goes for Uri-Path. In that case the multibyte =
characters don't cause a problem.=20

I am not sure that we even really need to support path or query =
components larger than 270 bytes? It makes sense for Proxy-Uri when we =
are dealing with a potentially large absolute URI.=20

Zach=20

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


--Apple-Mail-186--743651131
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw
ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x
MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT
UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb
+JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH
HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh
5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW
bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud
HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu
ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL
7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb
rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW
YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO
guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn
zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz
MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk
YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg
LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx
jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e
FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT
DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe
vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7
btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB
hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE
JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9
OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD
VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw
QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1
qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS
gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu
EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy
bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW
jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx
HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC
GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEwMTkw
ODM3MjlaMCMGCSqGSIb3DQEJBDEWBBQ0768w0zYGySCOtOiBJNUQfIoJPDCCAQMGCSsGAQQBgjcQ
BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp
Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd
uDANBgkqhkiG9w0BAQEFAASCAQAxjioxiOKkbIeXOf0spaYLSodZnkRjFUVAXhvMK4+T214o+GDe
CFS/Gci0wQihi5hXbG8GAwgw5IpahdE02nC63BZ2GsJ60rG1Is0EY5B6qvqOlVx2Z8t2eM5eraRJ
YT7U4w2qMN1oRM9YujAHSVbkR2BVy3MvWJiuf6zSYyUPEBx5mgnoDz5mAwm2AAvV+Xtnbpmd/zft
rxvRdeo9z6KdQ5MbqlYqMhlEywZf0EmpCJs4vX8LsdMXZgQ1Zc1Re4lVwvIIlj6Wmx4BfQYxPyup
s0+68ZT+AhSw/Zubew+ANrl6HntSa/0YCJBjojl5DA8Frqmwq0+fi9VT0oTv1MbsAAAAAAAA

--Apple-Mail-186--743651131--

From zach@sensinode.com  Mon Oct 24 03:24:16 2011
Return-Path: <zach@sensinode.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E56521F8CC8 for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 03:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-MlIE+Z6xn5 for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 03:24:15 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 1505D21F8CBD for <core@ietf.org>; Mon, 24 Oct 2011 03:24:11 -0700 (PDT)
Received: from [192.168.1.51] (a91-156-92-242.elisa-laajakaista.fi [91.156.92.242]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id p9OANsRC012837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Oct 2011 13:23:55 +0300
From: Zach Shelby <zach@sensinode.com>
Content-Type: multipart/signed; boundary=Apple-Mail-72--305265226; protocol="application/pkcs7-signature"; micalg=sha1
Date: Mon, 24 Oct 2011 13:23:54 +0300
Message-Id: <67D760B7-68CD-47E0-BDEC-ABA3C20FBFB2@sensinode.com>
To: core WG <core@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: core issue tracker <trac+core@gamay.tools.ietf.org>
Subject: [core] #165: Add 4.06 error to Accept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 10:24:16 -0000

--Apple-Mail-72--305265226
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I made the relevant changes for this ticket. Added the 4.06 Not =
Acceptable error code and modified the Accept text to return this error. =
I am not 100% sure whether SHOULD is appropriate for both returning the =
preferred types and returning the 4.06, but this is consistent with =
RFC2616 from what I can tell. Here is the new text if anyone has =
comments:

5.10.5.  Accept

   The CoAP Accept option indicates when included one or more times in a
   request, one or more media types, each of which is an acceptable
   media type for the client, in the order of preference.  The
   representation format is given as a numeric media type identifier
   that is defined in the CoAP Media Type registry (Section 11.3).  If
   no Accept options are given, the client does not express a preference
   (thus no default value is assumed).  The client prefers the
   representation returned by the server to be in one of the media types
   indicated.  The server SHOULD return one of the preferred media types
   if available.  If none of the preferred media types can be returned,
   then a 4.06 "Not Acceptable" SHOULD be sent as a response.
   Note that as a server might not support the Accept option (and thus
   would ignore it as it is elective), the client needs to be prepared
   to receive a representation in a different media type.  The client
   can simply discard a representation it can not make use of.

   This option is "elective".  It MAY occur more than once.

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


--Apple-Mail-72--305265226
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw
ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x
MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT
UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb
+JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH
HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh
5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW
bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud
HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu
ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL
7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb
rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW
YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO
guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn
zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz
MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk
YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg
LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx
jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e
FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT
DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe
vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7
btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB
hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE
JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9
OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD
VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw
QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1
qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS
gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu
EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy
bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW
jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx
HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC
GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEwMjQx
MDIzNTVaMCMGCSqGSIb3DQEJBDEWBBQRbIKkeMvAzWNN1z94c29wUVcBiDCCAQMGCSsGAQQBgjcQ
BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp
Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd
uDANBgkqhkiG9w0BAQEFAASCAQAABZe6iicsvAfpRP1bgeZ6A1Bg1wwyJgun0SR0smzs+t5sBvqJ
TeBiFadMt2HypY6CRLp9TGYT90hxwpExDQsHHOds4sjFbmXFdEGCP13M3XnHG3aWJ667cC9uJZ8s
tAX3ScavptAQCO7VA0RYFG5yROPOdtInd15vVrO5r0J9Zo3v/k1fuoyKWGyjKuDlkN/PrFMALY1A
tS72VWrA69oaK5kIrVgZKFh45u7+ysRtHbHKykszdGTH9BlUURcCeGdrwtN0gl0YhvL9XUaGr5fT
rKy8FzrRKj4SGLgXYaa3PfjTzs3U0IPMwcH1ohHORVt8fl97VVMVznUJkug8pnsLAAAAAAAA

--Apple-Mail-72--305265226--

From trac+core@trac.tools.ietf.org  Mon Oct 24 03:28:09 2011
Return-Path: <trac+core@trac.tools.ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0052121F8CD8 for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 03:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzJ0DKzE7RCM for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 03:28:08 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2C70B21F8CD7 for <core@ietf.org>; Mon, 24 Oct 2011 03:28:07 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from <trac+core@trac.tools.ietf.org>) id 1RIHlH-00089k-20; Mon, 24 Oct 2011 06:28:07 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" <trac+core@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Mon, 24 Oct 2011 10:28:07 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/165#comment:1
Message-ID: <072.dc7668a3f5aa1be2c388bb5135713621@trac.tools.ietf.org>
References: <057.af1821fb4e417e5f08d9527476b19890@trac.tools.ietf.org>
X-Trac-Ticket-ID: 165
In-Reply-To: <057.af1821fb4e417e5f08d9527476b19890@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] #165: Add 4.06 error to Accept
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 10:28:09 -0000

#165: Add 4.06 error to Accept

Changes (by zach@…):

 * status:  new => closed
 * resolution:   => fixed


-- 
----------------------------------+---------------------
 Reporter:  zach@…                |       Owner:  zach@…
     Type:  protocol enhancement  |      Status:  closed
 Priority:  minor                 |   Milestone:
Component:  coap                  |     Version:
 Severity:  -                     |  Resolution:  fixed
 Keywords:                        |
----------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/165#comment:1>
core <http://tools.ietf.org/core/>


From trac+core@trac.tools.ietf.org  Mon Oct 24 03:35:49 2011
Return-Path: <trac+core@trac.tools.ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C8221F8888 for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 03:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 206VpusONaE8 for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 03:35:49 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id AB9B521F84BA for <core@ietf.org>; Mon, 24 Oct 2011 03:35:47 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from <trac+core@trac.tools.ietf.org>) id 1RIHsh-0005Me-8m; Mon, 24 Oct 2011 06:35:47 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" <trac+core@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Mon, 24 Oct 2011 10:35:47 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/168#comment:1
Message-ID: <072.89b4a6705e6afe14a021f0de3062c9de@trac.tools.ietf.org>
References: <057.bcc47314d1902f3473bc940901661c07@trac.tools.ietf.org>
X-Trac-Ticket-ID: 168
In-Reply-To: <057.bcc47314d1902f3473bc940901661c07@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] #168: Bug in Section 8.2.2 on Etags
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 10:35:49 -0000

#168: Bug in Section 8.2.2 on Etags

Changes (by zach@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Simply changed to:

 If the CoAP entity has an entity tag, the proxy SHOULD include an ETag
 Option in the response.

-- 
-----------------------+---------------------
 Reporter:  zach@…     |       Owner:  zach@…
     Type:  editorial  |      Status:  closed
 Priority:  trivial    |   Milestone:
Component:  coap       |     Version:
 Severity:  -          |  Resolution:  fixed
 Keywords:             |
-----------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/168#comment:1>
core <http://tools.ietf.org/core/>


From trac+core@trac.tools.ietf.org  Mon Oct 24 03:58:28 2011
Return-Path: <trac+core@trac.tools.ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5AD21F8CD7 for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 03:58:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dyglsva4E83U for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 03:58:27 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2D221F8C0D for <core@ietf.org>; Mon, 24 Oct 2011 03:58:26 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from <trac+core@trac.tools.ietf.org>) id 1RIIES-0007M2-Gu; Mon, 24 Oct 2011 06:58:16 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" <trac+core@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com, hartke@tzi.org
X-Trac-Project: core
Date: Mon, 24 Oct 2011 10:58:16 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/175#comment:2
Message-ID: <075.2a0c2a8b82e1944737f3d4093be86e4e@trac.tools.ietf.org>
References: <060.944f31d9b293bd1b826f4093572af3a2@trac.tools.ietf.org>
X-Trac-Ticket-ID: 175
In-Reply-To: <060.944f31d9b293bd1b826f4093572af3a2@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] #175: Clarify matching rules for messages, duplicates and relate to security modes
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 10:58:28 -0000

#175: Clarify matching rules for messages, duplicates and relate to security
modes

Changes (by zach@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Done.

-- 
--------------------------------+---------------------
 Reporter:  esko.dijk@…         |       Owner:  zach@…
     Type:  protocol defect     |      Status:  closed
 Priority:  minor               |   Milestone:
Component:  coap                |     Version:
 Severity:  Active WG Document  |  Resolution:  fixed
 Keywords:                      |
--------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/175#comment:2>
core <http://tools.ietf.org/core/>


From trac+core@trac.tools.ietf.org  Mon Oct 24 04:03:14 2011
Return-Path: <trac+core@trac.tools.ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6557D21F8CF0 for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 04:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADml0ndavwCx for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 04:03:14 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id E3CCC21F8CEF for <core@ietf.org>; Mon, 24 Oct 2011 04:03:13 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from <trac+core@trac.tools.ietf.org>) id 1RIIJE-0002sH-3y; Mon, 24 Oct 2011 07:03:12 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" <trac+core@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com, hartke@tzi.org
X-Trac-Project: core
Date: Mon, 24 Oct 2011 11:03:12 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/151#comment:4
Message-ID: <072.b640bd5be5d4f94cd1de160a8507a4e9@trac.tools.ietf.org>
References: <057.a0dfde1ed2d36d2bf749f251f2a956f4@trac.tools.ietf.org>
X-Trac-Ticket-ID: 151
In-Reply-To: <057.a0dfde1ed2d36d2bf749f251f2a956f4@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, hartke@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] #151: Clarify matching rules for messages and tokens
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 11:03:14 -0000

#151: Clarify matching rules for messages and tokens

Changes (by zach@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Added a new section on message matching rules, and added references to
 this from Section 4.1.


 4.3.  Message Matching Rules

    The exact rules for matching an ACK or RST to a CON message or a RST
    to a NON message are as follows.  The Message ID of the response MUST
    match that of the original message.  For unicast messages, the source
    of the response MUST match the destination of the original message.
    How this is determined depends on the security mode used (see
    Section 10): With NoSec, the IP address and port number of the
    message destination and response source must match.  With other
    security modes, in addition to the IP address and UDP port matching,
    the request and response MUST have the same security context.

-- 
-----------------------------+---------------------
 Reporter:  zach@…           |       Owner:  zach@…
     Type:  protocol defect  |      Status:  closed
 Priority:  minor            |   Milestone:
Component:  coap             |     Version:
 Severity:  -                |  Resolution:  fixed
 Keywords:                   |
-----------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/151#comment:4>
core <http://tools.ietf.org/core/>


From zach@sensinode.com  Mon Oct 24 04:11:54 2011
Return-Path: <zach@sensinode.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB4521F8C2D for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 04:11:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3y3o2jf-QxS for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 04:11:54 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id B9FCD21F8C13 for <core@ietf.org>; Mon, 24 Oct 2011 04:11:53 -0700 (PDT)
Received: from [192.168.1.51] (a91-156-92-242.elisa-laajakaista.fi [91.156.92.242]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id p9OBBouC022494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Oct 2011 14:11:51 +0300
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-75--302389527; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby <zach@sensinode.com>
In-Reply-To: <4E9C14CD.2010700@piuha.net>
Date: Mon, 24 Oct 2011 14:11:50 +0300
Message-Id: <59ED492B-CF77-4E09-BDDD-0EC3C94E2739@sensinode.com>
References: <4E0BB964.3020806@piuha.net> <A337AA36B3B96E4D853E6182B2F27AE2D168F9FC4D@NLCLUEXM03.connect1.local> <EB26BB16-8077-4B91-943A-99D0550E9FC1@sensinode.com> <4E9C14CD.2010700@piuha.net>
To: Jari Arkko <jari.arkko@piuha.net>
X-Mailer: Apple Mail (2.1084)
Cc: "core@ietf.org" <core@ietf.org>
Subject: Re: [core] Message ID sliding window
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 11:11:55 -0000

--Apple-Mail-75--302389527
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Oct 17, 2011, at 2:43 PM, Jari Arkko wrote:

>> End-points dealing with large numbers of
>> transactions could keep multiple Message ID variables, for example
>> per prefix or destination address.  The initial variable value SHOULD
>> be randomized.  The same Message ID MUST NOT be re-used within the
>> potential retransmission window, calculated as RESPONSE_TIMEOUT *
>> RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT - 1) plus the expected
>> maximum round trip time.
>=20
> I think you should change s/window,/window to the same destination =
address,/ because otherwise those multiple variables are not going to be =
very useful.

Thanks, I fixed this as a nit by=20

s/re-used within/re-used in a variable within

as this sentence refers to both implementations keeping a single Message =
ID variable and those keeping multiple.=20

Zach

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


--Apple-Mail-75--302389527
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw
ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x
MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT
UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb
+JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH
HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh
5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW
bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud
HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu
ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL
7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb
rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW
YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO
guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn
zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz
MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk
YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg
LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx
jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e
FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT
DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe
vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7
btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB
hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE
JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9
OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD
VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw
QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1
qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS
gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu
EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy
bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW
jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx
HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC
GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEwMjQx
MTExNTBaMCMGCSqGSIb3DQEJBDEWBBScR7HqBs/Re8ga/jU2C8RPk6hs/DCCAQMGCSsGAQQBgjcQ
BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp
Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd
uDANBgkqhkiG9w0BAQEFAASCAQAjPLTIHbvv5alP6NJ+w74Kegl8+4sUwNU16d6CVYSV+RY0Mb/z
h4EU3kDAr7yIIz8IUMVRUfbVDVFsI3LpoHk3L9cOVaVVaMPqqeHKRCUfX/P/DVgzVJ3HAhaZcq6k
S99uDixq1DSJbmcwJ5EpM9oqLLuN2if4L7sEzJm75UO7cj2Ecs+uS3vS4rtuPq8LwLoq/rX3MNkx
Rc0glPmRrUlVTQFv8PapZFbNuNgv0/mSu42wUtvlSyWl/B7lNZnbgF2eWH5DlD2BF8LtO+4/dYLa
B70BHN7C3iw/Ug3CuaG8AqeX5uKmrNQYkSwKu3x85CrZOULYH0jgrY1l/JcmNpM5AAAAAAAA

--Apple-Mail-75--302389527--

From zach@sensinode.com  Mon Oct 24 04:24:09 2011
Return-Path: <zach@sensinode.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0BE21F886A for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 04:24:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kybMgXep8sNd for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 04:24:08 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 2086321F8663 for <core@ietf.org>; Mon, 24 Oct 2011 04:24:07 -0700 (PDT)
Received: from [192.168.1.51] (a91-156-92-242.elisa-laajakaista.fi [91.156.92.242]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id p9OBO59l024865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Oct 2011 14:24:06 +0300
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-76--301654449; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby <zach@sensinode.com>
In-Reply-To: <A337AA36B3B96E4D853E6182B2F27AE2D1690AA4A0@NLCLUEXM03.connect1.local>
Date: Mon, 24 Oct 2011 14:24:05 +0300
Message-Id: <84E14610-724C-41CB-8B9D-90146637EFDF@sensinode.com>
References: <4E0BB964.3020806@piuha.net> <A337AA36B3B96E4D853E6182B2F27AE2D168F9FC4D@NLCLUEXM03.connect1.local> <EB26BB16-8077-4B91-943A-99D0550E9FC1@sensinode.com> <4E9C14CD.2010700@piuha.net> <A337AA36B3B96E4D853E6182B2F27AE2D1690AA4A0@NLCLUEXM03.connect1.local>
To: "Dijk, Esko" <esko.dijk@philips.com>
X-Mailer: Apple Mail (2.1084)
Cc: "core@ietf.org" <core@ietf.org>
Subject: Re: [core] Message ID sliding window
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 11:24:09 -0000

--Apple-Mail-76--301654449
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

So to conclude on this thread with a concrete action on the draft (or =
not). The current text says:

"Several implementation strategies can be employed for generating =
Message IDs. In the simplest case a CoAP end-point generates Message IDs =
by keeping a single Message ID variable, which is changed each time a =
new confirmable message is sent regardless of the destination address or =
port."

Esko is suggesting to make it more explicit that this MAY be =
sequentially incremented. There doesn't seem to be push-back on that as =
long is it isn't a SHOULD. Do you have a proposal for the new text that =
you think should be added? So far I haven't been able to come up with =
MAY text that would make much sense here considering the current text.

Zach


On Oct 17, 2011, at 5:56 PM, Dijk, Esko wrote:

> Hi,
>=20
>> We should not mandate that in any sense in the spec, however, because =
otherwise someone will start trusting that all devices behave that way.
>=20
> this was one of the reasons for me to propose a 'MAY' here. It does =
not create a barrier to interesting strategies e.g. as used in the tiny =
CoAP sensors. A 'SHOULD' is rather strong here ("but the full =
implications must be understood and carefully weighed before choosing a =
different course", RFC 2119).=20
>=20
> A 'MAY' serves as a note to implementers "you could do it this way, =
with these specific benefits" which should be enough push in the right =
direction in applications where an implementer doesn't really care what =
MID generation strategy is applied e.g. as in unconstrained nodes.=20
> Interestingly a 'MAY' provides a _stronger_ requirement for CoAP nodes =
to support non-sequential MIDs from other nodes. Because then, =
implementers will not assume that everyone follows the 'SHOULD' from the =
spec. In fact they MUST NOT assume that the optional feature is there, =
as RFC 2119 indicates for a 'MAY' :)
>=20
> (Downside is that there is less incentive for implementers to care =
about optimizing MID storage, though.)
>=20
> regards,
> Esko
>=20
> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]=20
> Sent: Monday 17 October 2011 13:43
> To: Zach Shelby
> Cc: Dijk, Esko; core@ietf.org
> Subject: Re: [core] Message ID sliding window
>=20
>=20
> The original proposal that started this thread was to make some =
recommendation on using sequential IDs. I am against that (even as a =
SHOULD), on the grounds that it is unnecessary and any level of =
mandatory sequencing would break some implementation strategies (such as =
the one I used on my tiny device). Of course you can use any strategy =
you want, including sequencing. We should not mandate that in any sense =
in the spec, however, because otherwise someone will start trusting that =
all devices behave that way.
>=20
> Anyway, I had a quick look at -07 and noticed this:
>=20
>> End-points dealing with large numbers of
>> transactions could keep multiple Message ID variables, for example
>> per prefix or destination address.  The initial variable value SHOULD
>> be randomized.  The same Message ID MUST NOT be re-used within the
>> potential retransmission window, calculated as RESPONSE_TIMEOUT *
>> RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT - 1) plus the expected
>> maximum round trip time.
>=20
> I think you should change s/window,/window to the same destination =
address,/ because otherwise those multiple variables are not going to be =
very useful.
>=20
> (Or possibly a combination of source/destination address.)
>=20
> Jari
>=20
> On 17.10.2011 12:46, Zach Shelby wrote:
>> Esko,
>>=20
>> Indeed, I do believe that sequential MIDs are going to be a common =
implementation strategy (of course with a random initial value). This is =
allowed by the current specification. What benefit do you see from =
adding MAY language around something that you may already do?
>>=20
>> Seems instead we would need to point out to CoAP implementors that =
behavior could be used to optimize the storage of MIDs for duplication =
detection.
>>=20
>> Now I think the reason why Carsten suggested a SHOULD is that this =
would make the optimization a whole lot more useful as it would =
encourage the majority of implementations to be compatible with this =
optimization. That makes sense.
>>=20
>> Zach
>>=20
>> On Oct 7, 2011, at 5:49 PM, Dijk, Esko wrote:
>>=20
>>> To continue this discussion from a while ago: I agree with Jari on =
the freedom of assigning message IDs.
>>> After a reboot the MID value is likely randomized and receiving CoAP =
nodes have to deal with that. And a sending node may wish to store only =
one MID counter for whatever reasons, or generated randomly if storing =
state is expensive.
>>>=20
>>> However, it can still be beneficial to suggest (MAY) using =
sequential MIDs (mid++) for the regular operation between reboots. As an =
advice to be followed in case no special/random/stateless MID generation =
is required by a sender. The reason is that this optionally enables to =
save RAM in receiving CoAP nodes that implement an optimized storage for =
MIDs close together, trading higher code complexity for lower RAM use. =
MIDs are stored then for deduplication purposes.
>>>=20
>>> As Carsten phrased "if you believe supporting this specific =
optimization is worth it, we could RECOMMEND (i.e., mandate at the =
SHOULD level) to use message-IDs that are close (in modulo arithmetic) =
to recently used message-IDs". I think it is worth it as OPTIONAL/MAY =
behaviour.
>>> A use case may be a client sending a "toggle light" command to a =
CoAP (server) lamp.
>>>=20
>>> best regards,
>>> Esko
>>>=20
>>> -----Original Message-----
>>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf =
Of Jari Arkko
>>> Sent: Thursday 30 June 2011 1:47
>>> To: core@ietf.org
>>> Subject: Re: [core] Message ID sliding window
>>>=20
>>> I actually like the freedom to use any approach to assigning message
>>> IDs. I can imagine a few reasons why it might be easier in some =
cases to
>>> have that freedom. As a hypothetical example, maybe I want to store =
only
>>> one counter but send messages to multiple other nodes. Also, as =
Carsten
>>> pointed out, sequential assignment is not as trivial as it sounds. =
What
>>> do you or the receivers do after a reboot?
>>>=20
>>> That being said, if you want your sender to use sequential message =
IDs,
>>> it can just go ahead and do it. On the receiver side the issue is =
more
>>> complex. COAP has acknowledgments to deal with those cases where you
>>> absolutely have to sequence some operations, and relying merely on
>>> sequence numbers would appear to not work in all cases, e.g., when a
>>> message is lost. Given the reboot problem, a simple sliding window
>>> approach might not be sufficient to keep track of which messages you
>>> have received.
>>>=20
>>> As a side note, I scanned the COAP draft today and did not find =
anything
>>> about the scope of message IDs. Presumably message ID duplicate
>>> detection etc should only apply for a given IP source and =
destination
>>> pair. Otherwise there will be too many collisions. Is this specified
>>> somewhere?
>>>=20
>>> Jari
>>>=20
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>>>=20
>>> The information contained in this message may be confidential and =
legally protected under applicable law. The message is intended solely =
for the addressee(s). If you are not the intended recipient, you are =
hereby notified that any use, forwarding, dissemination, or reproduction =
of this message is strictly prohibited and may be unlawful. If you are =
not the intended recipient, please contact the sender by return e-mail =
and destroy all copies of the original message.
>>>=20
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>=20
>=20

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


--Apple-Mail-76--301654449
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw
ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x
MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT
UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb
+JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH
HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh
5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW
bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud
HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu
ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL
7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb
rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW
YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO
guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn
zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz
MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk
YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg
LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx
jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e
FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT
DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe
vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7
btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB
hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE
JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9
OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD
VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw
QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1
qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS
gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu
EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy
bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW
jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx
HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC
GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEwMjQx
MTI0MDVaMCMGCSqGSIb3DQEJBDEWBBRiUrr2TW2hZaWcBdWWc1iVuW6byDCCAQMGCSsGAQQBgjcQ
BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp
Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd
uDANBgkqhkiG9w0BAQEFAASCAQBbCeyZwVgUCGEGldiNwxlzc/ndDuKPo1UcXnok0HnRst9qTZSz
SbGZ5btbyY+/q54MaOOXSfIw4sn+A/2Gkj9ycZPo5IbeVnuS4lstYPi1s9rqsXWOhq8wMhFNtvtc
ztNRPCv3mJwHG8apqSSt9xOLlPJkS7Pj8KrSUA8ztjl+bs5XxI4LNV6TrqVFrvjwrkUh9Q9It1vv
YQa3EfFtg+8iF/SmNe4SDdOfnyFEYEb8iY4Ag+LqJ3K9LvO7u9akUlquGNTa4ayCPMUTuylLF9dp
oOalCWDUSIylMQ/mIrwVFUXB4X75PNaEpXmpercUj/b5SW28PjKHoD02aSJbMqZBAAAAAAAA

--Apple-Mail-76--301654449--

From trac+core@trac.tools.ietf.org  Mon Oct 24 04:42:14 2011
Return-Path: <trac+core@trac.tools.ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14D721F8CC5 for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 04:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level: 
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OMriuWhPSLQ for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 04:42:14 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAAA21F8BB8 for <core@ietf.org>; Mon, 24 Oct 2011 04:42:08 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from <trac+core@trac.tools.ietf.org>) id 1RIIut-00072R-He; Mon, 24 Oct 2011 07:42:07 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" <trac+core@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Mon, 24 Oct 2011 11:42:07 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/166#comment:1
Message-ID: <072.d388c36fab45630d8bd371b32f59633a@trac.tools.ietf.org>
References: <057.11808fbd63fcfaacaafb1d432d39b421@trac.tools.ietf.org>
X-Trac-Ticket-ID: 166
In-Reply-To: <057.11808fbd63fcfaacaafb1d432d39b421@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] #166: Security re-focus on public keys
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 11:42:14 -0000

#166: Security re-focus on public keys

Changes (by zach@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 The following section was added to the draft.

 10.3.4.  IP Address Spoofing Attacks

    Due to the non-reliability of UDP (and to some extent to the
    duplicate message processing strategy), a rogue endpoint which is
    free to read and write messages carried by the constrained network
    (i.e.  NoSec or PreSharedKey deployments with nodes/key ratio > 1:1),
    may easily attack a single endpoint, a group of endpoints, as well as
    the whole network e.g. by:

    1.  spoofing RST in response to a CON message, thus making an
        endpoint "deaf"; or

    2.  spoofing the entire response with forged payload/options (this
        has different levels of impact: from single response disruption,
        to much bolder attacks on the supporting infrastructure, e.g.
        poisoning proxy caches, or tricking validation / lookup
        interfaces in resource directories and, more generally, any
        component that stores global network state and uses CoAP as the
        messaging facility to handle state set/update's is a potential
        target.); or

    3.  spoofing a multicast request for a target node which may result
        in both network congestion/collapse and victim DoS'ing / forced
        wakeup from sleeping; or

    4.  spoofing observe messages, etc.

    In principle, spoofing can be detected by CoAP only in case CON
    semantics is used, because of unexpected ACK/RSTs coming from the
    deceived endpoint.  But this imposes keeping track of the used MIDs
    which is not always possible, and moreover detection becomes
    available usually after the damage is already done.  This kind of
    attack can be prevented using PreSharedKey (with a 1:1 node/key
    ratio) or Certificate security modes.

-- 
----------------------------------+---------------------
 Reporter:  zach@…                |       Owner:  zach@…
     Type:  protocol enhancement  |      Status:  closed
 Priority:  major                 |   Milestone:
Component:  coap                  |     Version:
 Severity:  -                     |  Resolution:  fixed
 Keywords:                        |
----------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/166#comment:1>
core <http://tools.ietf.org/core/>


From trac+core@trac.tools.ietf.org  Mon Oct 24 04:44:34 2011
Return-Path: <trac+core@trac.tools.ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5035821F8D3D for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 04:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level: 
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehq+8rlvtE9N for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 04:44:33 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 63F5021F8D34 for <core@ietf.org>; Mon, 24 Oct 2011 04:44:32 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from <trac+core@trac.tools.ietf.org>) id 1RIIxE-00075O-E8; Mon, 24 Oct 2011 07:44:32 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" <trac+core@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Mon, 24 Oct 2011 11:44:32 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/166#comment:2
Message-ID: <072.f77e3759bc028d51b2f7998d19991488@trac.tools.ietf.org>
References: <057.11808fbd63fcfaacaafb1d432d39b421@trac.tools.ietf.org>
X-Trac-Ticket-ID: 166
In-Reply-To: <057.11808fbd63fcfaacaafb1d432d39b421@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] #166: Security re-focus on public keys
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 11:44:34 -0000

#166: Security re-focus on public keys

Changes (by zach@…):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Wrong ticket, re-opened.

-- 
----------------------------------+-----------------------
 Reporter:  zach@…                |       Owner:  zach@…
     Type:  protocol enhancement  |      Status:  reopened
 Priority:  major                 |   Milestone:
Component:  coap                  |     Version:
 Severity:  -                     |  Resolution:
 Keywords:                        |
----------------------------------+-----------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/166#comment:2>
core <http://tools.ietf.org/core/>


From trac+core@trac.tools.ietf.org  Mon Oct 24 04:44:56 2011
Return-Path: <trac+core@trac.tools.ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA3621F8D36 for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 04:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.249
X-Spam-Level: 
X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVH-AwZAPOjF for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 04:44:55 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id BC4B621F8D34 for <core@ietf.org>; Mon, 24 Oct 2011 04:44:55 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from <trac+core@trac.tools.ietf.org>) id 1RIIxb-00075s-Fg; Mon, 24 Oct 2011 07:44:55 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" <trac+core@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Mon, 24 Oct 2011 11:44:55 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/167#comment:1
Message-ID: <072.64e1026793cf751ae1912aec77af73b5@trac.tools.ietf.org>
References: <057.e5943562b6dfe2827804fe7e0f2dfad3@trac.tools.ietf.org>
X-Trac-Ticket-ID: 167
In-Reply-To: <057.e5943562b6dfe2827804fe7e0f2dfad3@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] #167: IP address spoofing threat analysis
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 11:44:56 -0000

#167: IP address spoofing threat analysis

Changes (by zach@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 The following section was added to the draft.

 10.3.4. IP Address Spoofing Attacks

     Due to the non-reliability of UDP (and to some extent to the
     duplicate message processing strategy), a rogue endpoint which is
     free to read and write messages carried by the constrained network
     (i.e. NoSec? or PreSharedKey? deployments with nodes/key ratio > 1:1),
     may easily attack a single endpoint, a group of endpoints, as well as
     the whole network e.g. by:

     spoofing RST in response to a CON message, thus making an

         endpoint "deaf"; or

     spoofing the entire response with forged payload/options (this

         has different levels of impact: from single response disruption,
         to much bolder attacks on the supporting infrastructure, e.g.
         poisoning proxy caches, or tricking validation / lookup
         interfaces in resource directories and, more generally, any
         component that stores global network state and uses CoAP as the
         messaging facility to handle state set/update's is a potential
         target.); or

     spoofing a multicast request for a target node which may result

         in both network congestion/collapse and victim DoS'ing / forced
         wakeup from sleeping; or

     spoofing observe messages, etc.

     In principle, spoofing can be detected by CoAP only in case CON
     semantics is used, because of unexpected ACK/RSTs coming from the
     deceived endpoint. But this imposes keeping track of the used MIDs
     which is not always possible, and moreover detection becomes
     available usually after the damage is already done. This kind of
     attack can be prevented using PreSharedKey? (with a 1:1 node/key
     ratio) or Certificate security modes.

-- 
--------------------+---------------------
 Reporter:  zach@…  |       Owner:  zach@…
     Type:  task    |      Status:  closed
 Priority:  minor   |   Milestone:
Component:  coap    |     Version:
 Severity:  -       |  Resolution:  fixed
 Keywords:          |
--------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/167#comment:1>
core <http://tools.ietf.org/core/>


From jari.arkko@piuha.net  Mon Oct 24 04:45:10 2011
Return-Path: <jari.arkko@piuha.net>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002BA21F8D46 for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 04:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.588
X-Spam-Level: 
X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWr5fV8aortj for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 04:45:09 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 39BD621F8D34 for <core@ietf.org>; Mon, 24 Oct 2011 04:45:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 635662CC43; Mon, 24 Oct 2011 14:45:07 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHzmrbafgGIc; Mon, 24 Oct 2011 14:45:07 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 04A4E2CC3B; Mon, 24 Oct 2011 14:45:07 +0300 (EEST)
Message-ID: <4EA54FC2.1000705@piuha.net>
Date: Mon, 24 Oct 2011 14:45:06 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0
MIME-Version: 1.0
To: Zach Shelby <zach@sensinode.com>
References: <4E0BB964.3020806@piuha.net> <A337AA36B3B96E4D853E6182B2F27AE2D168F9FC4D@NLCLUEXM03.connect1.local> <EB26BB16-8077-4B91-943A-99D0550E9FC1@sensinode.com> <4E9C14CD.2010700@piuha.net> <A337AA36B3B96E4D853E6182B2F27AE2D1690AA4A0@NLCLUEXM03.connect1.local> <84E14610-724C-41CB-8B9D-90146637EFDF@sensinode.com>
In-Reply-To: <84E14610-724C-41CB-8B9D-90146637EFDF@sensinode.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "core@ietf.org" <core@ietf.org>
Subject: Re: [core] Message ID sliding window
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 11:45:10 -0000

Not sure if this is pushback or not, but we don't normally add RFC 2119 language to implementation strategies.

Jari


From tho@koanlogic.com  Mon Oct 24 11:21:09 2011
Return-Path: <tho@koanlogic.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F0B11E80A6 for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 11:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.505
X-Spam-Level: *
X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmmJymRNmM51 for <core@ietfa.amsl.com>; Mon, 24 Oct 2011 11:21:09 -0700 (PDT)
Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 0600011E809D for <core@ietf.org>; Mon, 24 Oct 2011 11:21:08 -0700 (PDT)
Received: from host105-53-dynamic.52-79-r.retail.telecomitalia.it ([79.52.53.105]:59846 helo=[192.168.1.5]) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1RIP8c-0002q9-O2; Mon, 24 Oct 2011 14:20:53 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Thomas Fossati <tho@koanlogic.com>
In-Reply-To: <072.64e1026793cf751ae1912aec77af73b5@trac.tools.ietf.org>
Date: Mon, 24 Oct 2011 20:20:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <77D5CDDF-EE31-4B02-B4D1-EE366FDBF4D8@koanlogic.com>
References: <057.e5943562b6dfe2827804fe7e0f2dfad3@trac.tools.ietf.org> <072.64e1026793cf751ae1912aec77af73b5@trac.tools.ietf.org>
To: Zach Shelby <zach@sensinode.com>
X-Mailer: Apple Mail (2.1084)
X-SA-Exim-Connect-IP: 79.52.53.105
X-SA-Exim-Mail-From: tho@koanlogic.com
X-Spam-DCC: : 
X-Spam-Pyzor: Reported 0 times.
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com)
Cc: core@ietf.org
Subject: Re: [core] #167: IP address spoofing threat analysis
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 18:21:09 -0000

On Oct 24, 2011, at 1:44 PM, core issue tracker wrote:
> #167: IP address spoofing threat analysis
>=20
> Changes (by zach@=85):
>=20
> * status:  new =3D> closed
> * resolution:   =3D> fixed
>=20
>=20
> Comment:
>=20
> The following section was added to the draft.
>=20
> 10.3.4. IP Address Spoofing Attacks

Thank you Zach, much appreciated.

If you need to refine the text, I'm willing to contribute.=

From esko.dijk@philips.com  Tue Oct 25 00:15:37 2011
Return-Path: <esko.dijk@philips.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB8B21F8562 for <core@ietfa.amsl.com>; Tue, 25 Oct 2011 00:15:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNUsvaU4Yt-H for <core@ietfa.amsl.com>; Tue, 25 Oct 2011 00:15:36 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 17F5F21F8560 for <core@ietf.org>; Tue, 25 Oct 2011 00:15:35 -0700 (PDT)
Received: from mail76-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.22; Tue, 25 Oct 2011 07:15:30 +0000
Received: from mail76-ch1 (localhost.localdomain [127.0.0.1])	by mail76-ch1-R.bigfish.com (Postfix) with ESMTP id CB43B15703D8; Tue, 25 Oct 2011 07:15:32 +0000 (UTC)
X-SpamScore: -38
X-BigFish: VPS-38(zz217bL15d6O9251J542Mzz1202hzz1033IL8275dhz2dh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI
X-FB-SS: 13,
Received: from mail76-ch1 (localhost.localdomain [127.0.0.1]) by mail76-ch1 (MessageSwitch) id 1319526932701033_11042; Tue, 25 Oct 2011 07:15:32 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.243])	by mail76-ch1.bigfish.com (Postfix) with ESMTP id 9FE6C19A0050;	Tue, 25 Oct 2011 07:15:32 +0000 (UTC)
Received: from smtpx.philips.com (168.87.56.20) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 25 Oct 2011 07:15:33 +0000
Received: from NLAMSEXH04.connect1.local (172.16.153.25) by connect1.philips.com (172.16.156.160) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 25 Oct 2011 09:15:06 +0200
Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLAMSEXH04.connect1.local ([172.16.153.25]) with mapi; Tue, 25 Oct 2011 09:10:27 +0200
From: "Dijk, Esko" <esko.dijk@philips.com>
To: Jari Arkko <jari.arkko@piuha.net>, Zach Shelby <zach@sensinode.com>
Date: Tue, 25 Oct 2011 09:15:07 +0200
Thread-Topic: [core] Message ID sliding window
Thread-Index: AcySQbuQxNZPJ2QxQL6R2RdR8434RQAo4ujg
Message-ID: <A337AA36B3B96E4D853E6182B2F27AE2D16ACE95B6@NLCLUEXM03.connect1.local>
References: <4E0BB964.3020806@piuha.net> <A337AA36B3B96E4D853E6182B2F27AE2D168F9FC4D@NLCLUEXM03.connect1.local> <EB26BB16-8077-4B91-943A-99D0550E9FC1@sensinode.com> <4E9C14CD.2010700@piuha.net> <A337AA36B3B96E4D853E6182B2F27AE2D1690AA4A0@NLCLUEXM03.connect1.local> <84E14610-724C-41CB-8B9D-90146637EFDF@sensinode.com> <4EA54FC2.1000705@piuha.net>
In-Reply-To: <4EA54FC2.1000705@piuha.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Cc: "core@ietf.org" <core@ietf.org>
Subject: Re: [core] Message ID sliding window
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2011 07:15:37 -0000

If it's an implementation strategy indeed not, but my proposal was to inclu=
de it as an optional protocol feature instead for the reasons mentioned bef=
ore. (Where the optional feature allows multiple implementation strategies =
e.g. various ways of efficient MID sequences storage, or no special MID sto=
rage.)

Esko

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@piuha.net]
Sent: Monday 24 October 2011 13:45
To: Zach Shelby
Cc: Dijk, Esko; core@ietf.org
Subject: Re: [core] Message ID sliding window

Not sure if this is pushback or not, but we don't normally add RFC 2119 lan=
guage to implementation strategies.

Jari


The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From esko.dijk@philips.com  Tue Oct 25 00:46:01 2011
Return-Path: <esko.dijk@philips.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B44D21F8A70 for <core@ietfa.amsl.com>; Tue, 25 Oct 2011 00:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSwRefPOTCmO for <core@ietfa.amsl.com>; Tue, 25 Oct 2011 00:46:00 -0700 (PDT)
Received: from AM1EHSOBE005.bigfish.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 6B38621F877F for <core@ietf.org>; Tue, 25 Oct 2011 00:45:59 -0700 (PDT)
Received: from mail4-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.22; Tue, 25 Oct 2011 07:45:54 +0000
Received: from mail4-am1 (localhost.localdomain [127.0.0.1])	by mail4-am1-R.bigfish.com (Postfix) with ESMTP id F3CBA188835A; Tue, 25 Oct 2011 07:45:55 +0000 (UTC)
X-SpamScore: -53
X-BigFish: VPS-53(zz217bL15d6O9371K9251J146fK542M1432N98dKzz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h944h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI
Received: from mail4-am1 (localhost.localdomain [127.0.0.1]) by mail4-am1 (MessageSwitch) id 1319528755208019_12369; Tue, 25 Oct 2011 07:45:55 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.245])	by mail4-am1.bigfish.com (Postfix) with ESMTP id 1E11A1B90046; Tue, 25 Oct 2011 07:45:55 +0000 (UTC)
Received: from smtpx.philips.com (168.87.56.20) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 25 Oct 2011 07:45:52 +0000
Received: from NLAMSEXH05.connect1.local (172.16.153.68) by connect1.philips.com (172.16.156.40) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 25 Oct 2011 09:45:51 +0200
Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLAMSEXH05.connect1.local ([172.16.153.68]) with mapi; Tue, 25 Oct 2011 09:41:13 +0200
From: "Dijk, Esko" <esko.dijk@philips.com>
To: Zach Shelby <zach@sensinode.com>
Date: Tue, 25 Oct 2011 09:45:53 +0200
Thread-Topic: [core] Message ID sliding window
Thread-Index: AcySPs1fMIoXMmmfQL2aZphhnV3ETAAqUrOA
Message-ID: <A337AA36B3B96E4D853E6182B2F27AE2D16ACE95DA@NLCLUEXM03.connect1.local>
References: <4E0BB964.3020806@piuha.net> <A337AA36B3B96E4D853E6182B2F27AE2D168F9FC4D@NLCLUEXM03.connect1.local> <EB26BB16-8077-4B91-943A-99D0550E9FC1@sensinode.com> <4E9C14CD.2010700@piuha.net> <A337AA36B3B96E4D853E6182B2F27AE2D1690AA4A0@NLCLUEXM03.connect1.local> <84E14610-724C-41CB-8B9D-90146637EFDF@sensinode.com>
In-Reply-To: <84E14610-724C-41CB-8B9D-90146637EFDF@sensinode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Cc: "core@ietf.org" <core@ietf.org>
Subject: Re: [core] Message ID sliding window
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2011 07:46:01 -0000

Here is a proposal that can be added at the end of the paragraph
   "Several implementation strategies can be employed for generating Messag=
e IDs .....
   ........ RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT - 1) plus the expe=
cted
   maximum round trip time."

[proposal:]
   To support efficient Message ID storage implementations for duplicate me=
ssage=20
   detection (which is detailed below), an end-point MAY generate sequentia=
l=20
   Message IDs by increasing a Message ID variable by 1 each time a=20
   new message is sent.=20

This does not prescribe one or multiple MID variables, this is left to impl=
ementation strategies as stated in the current paragraph already.
Specific implementation strategies are mentioned as a motivation for this o=
ptional behaviour. The wrapping of value from highest to 0 is not explicitl=
y mentioned but could be added.

Esko

-----Original Message-----
From: Zach Shelby [mailto:zach@sensinode.com]=20
Sent: Monday 24 October 2011 13:24
To: Dijk, Esko
Cc: Jari Arkko; core@ietf.org
Subject: Re: [core] Message ID sliding window

So to conclude on this thread with a concrete action on the draft (or not).=
 The current text says:

"Several implementation strategies can be employed for generating Message I=
Ds. In the simplest case a CoAP end-point generates Message IDs by keeping =
a single Message ID variable, which is changed each time a new confirmable =
message is sent regardless of the destination address or port."

Esko is suggesting to make it more explicit that this MAY be sequentially i=
ncremented. There doesn't seem to be push-back on that as long is it isn't =
a SHOULD. Do you have a proposal for the new text that you think should be =
added? So far I haven't been able to come up with MAY text that would make =
much sense here considering the current text.

Zach


On Oct 17, 2011, at 5:56 PM, Dijk, Esko wrote:

> Hi,
>=20
>> We should not mandate that in any sense in the spec, however, because ot=
herwise someone will start trusting that all devices behave that way.
>=20
> this was one of the reasons for me to propose a 'MAY' here. It does not c=
reate a barrier to interesting strategies e.g. as used in the tiny CoAP sen=
sors. A 'SHOULD' is rather strong here ("but the full implications must be =
understood and carefully weighed before choosing a different course", RFC 2=
119).=20
>=20
> A 'MAY' serves as a note to implementers "you could do it this way, with =
these specific benefits" which should be enough push in the right direction=
 in applications where an implementer doesn't really care what MID generati=
on strategy is applied e.g. as in unconstrained nodes.=20
> Interestingly a 'MAY' provides a _stronger_ requirement for CoAP nodes to=
 support non-sequential MIDs from other nodes. Because then, implementers w=
ill not assume that everyone follows the 'SHOULD' from the spec. In fact th=
ey MUST NOT assume that the optional feature is there, as RFC 2119 indicate=
s for a 'MAY' :)
>=20
> (Downside is that there is less incentive for implementers to care about =
optimizing MID storage, though.)
>=20
> regards,
> Esko
>=20
> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]=20
> Sent: Monday 17 October 2011 13:43
> To: Zach Shelby
> Cc: Dijk, Esko; core@ietf.org
> Subject: Re: [core] Message ID sliding window
>=20
>=20
> The original proposal that started this thread was to make some recommend=
ation on using sequential IDs. I am against that (even as a SHOULD), on the=
 grounds that it is unnecessary and any level of mandatory sequencing would=
 break some implementation strategies (such as the one I used on my tiny de=
vice). Of course you can use any strategy you want, including sequencing. W=
e should not mandate that in any sense in the spec, however, because otherw=
ise someone will start trusting that all devices behave that way.
>=20
> Anyway, I had a quick look at -07 and noticed this:
>=20
>> End-points dealing with large numbers of
>> transactions could keep multiple Message ID variables, for example
>> per prefix or destination address.  The initial variable value SHOULD
>> be randomized.  The same Message ID MUST NOT be re-used within the
>> potential retransmission window, calculated as RESPONSE_TIMEOUT *
>> RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT - 1) plus the expected
>> maximum round trip time.
>=20
> I think you should change s/window,/window to the same destination addres=
s,/ because otherwise those multiple variables are not going to be very use=
ful.
>=20
> (Or possibly a combination of source/destination address.)
>=20
> Jari
>=20
> On 17.10.2011 12:46, Zach Shelby wrote:
>> Esko,
>>=20
>> Indeed, I do believe that sequential MIDs are going to be a common imple=
mentation strategy (of course with a random initial value). This is allowed=
 by the current specification. What benefit do you see from adding MAY lang=
uage around something that you may already do?
>>=20
>> Seems instead we would need to point out to CoAP implementors that behav=
ior could be used to optimize the storage of MIDs for duplication detection=
.
>>=20
>> Now I think the reason why Carsten suggested a SHOULD is that this would=
 make the optimization a whole lot more useful as it would encourage the ma=
jority of implementations to be compatible with this optimization. That mak=
es sense.
>>=20
>> Zach
>>=20
>> On Oct 7, 2011, at 5:49 PM, Dijk, Esko wrote:
>>=20
>>> To continue this discussion from a while ago: I agree with Jari on the =
freedom of assigning message IDs.
>>> After a reboot the MID value is likely randomized and receiving CoAP no=
des have to deal with that. And a sending node may wish to store only one M=
ID counter for whatever reasons, or generated randomly if storing state is =
expensive.
>>>=20
>>> However, it can still be beneficial to suggest (MAY) using sequential M=
IDs (mid++) for the regular operation between reboots. As an advice to be f=
ollowed in case no special/random/stateless MID generation is required by a=
 sender. The reason is that this optionally enables to save RAM in receivin=
g CoAP nodes that implement an optimized storage for MIDs close together, t=
rading higher code complexity for lower RAM use. MIDs are stored then for d=
eduplication purposes.
>>>=20
>>> As Carsten phrased "if you believe supporting this specific optimizatio=
n is worth it, we could RECOMMEND (i.e., mandate at the SHOULD level) to us=
e message-IDs that are close (in modulo arithmetic) to recently used messag=
e-IDs". I think it is worth it as OPTIONAL/MAY behaviour.
>>> A use case may be a client sending a "toggle light" command to a CoAP (=
server) lamp.
>>>=20
>>> best regards,
>>> Esko
>>>=20
>>> -----Original Message-----
>>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of=
 Jari Arkko
>>> Sent: Thursday 30 June 2011 1:47
>>> To: core@ietf.org
>>> Subject: Re: [core] Message ID sliding window
>>>=20
>>> I actually like the freedom to use any approach to assigning message
>>> IDs. I can imagine a few reasons why it might be easier in some cases t=
o
>>> have that freedom. As a hypothetical example, maybe I want to store onl=
y
>>> one counter but send messages to multiple other nodes. Also, as Carsten
>>> pointed out, sequential assignment is not as trivial as it sounds. What
>>> do you or the receivers do after a reboot?
>>>=20
>>> That being said, if you want your sender to use sequential message IDs,
>>> it can just go ahead and do it. On the receiver side the issue is more
>>> complex. COAP has acknowledgments to deal with those cases where you
>>> absolutely have to sequence some operations, and relying merely on
>>> sequence numbers would appear to not work in all cases, e.g., when a
>>> message is lost. Given the reboot problem, a simple sliding window
>>> approach might not be sufficient to keep track of which messages you
>>> have received.
>>>=20
>>> As a side note, I scanned the COAP draft today and did not find anythin=
g
>>> about the scope of message IDs. Presumably message ID duplicate
>>> detection etc should only apply for a given IP source and destination
>>> pair. Otherwise there will be too many collisions. Is this specified
>>> somewhere?
>>>=20
>>> Jari
>>>=20
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>>>=20
>>> The information contained in this message may be confidential and legal=
ly protected under applicable law. The message is intended solely for the a=
ddressee(s). If you are not the intended recipient, you are hereby notified=
 that any use, forwarding, dissemination, or reproduction of this message i=
s strictly prohibited and may be unlawful. If you are not the intended reci=
pient, please contact the sender by return e-mail and destroy all copies of=
 the original message.
>>>=20
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>=20
>=20

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297



From kovatsch@inf.ethz.ch  Tue Oct 25 04:00:43 2011
Return-Path: <kovatsch@inf.ethz.ch>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724AC21F8B1C for <core@ietfa.amsl.com>; Tue, 25 Oct 2011 04:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.11
X-Spam-Level: 
X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ffmc1Nsx4DI for <core@ietfa.amsl.com>; Tue, 25 Oct 2011 04:00:43 -0700 (PDT)
Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id AC5A521F8B1A for <core@ietf.org>; Tue, 25 Oct 2011 04:00:42 -0700 (PDT)
Received: from CAS10.d.ethz.ch (172.31.38.210) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 25 Oct 2011 13:00:17 +0200
Received: from MBX10.d.ethz.ch ([169.254.1.192]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.01.0339.001; Tue, 25 Oct 2011 13:00:19 +0200
From: "Kovatsch  Matthias" <kovatsch@inf.ethz.ch>
To: Carsten Bormann <cabo@tzi.org>, "core@ietf.org" <core@ietf.org>
Thread-Topic: Status of Blockwise Transfers
Thread-Index: AcyTA1LLgF2apeWtTByzRREkH8/syg==
Date: Tue, 25 Oct 2011 11:00:18 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B51382ED5E@MBX10.d.ethz.ch>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [129.132.130.253]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [core] Status of Blockwise Transfers
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2011 11:00:43 -0000

Dear Carsten

I would like to ask about the current status of blockwise transfers:

- Concurrent usage of Block1 and Block2 in a single operation
  core-block-04 mentions it once, but does not specify how to handle it or =
give an example (I guess, a POST request keeps the Block1 option with M=3D0=
 and no payload until all Block2 blocks were requested?).

- Using Status codes before an atomic Block1 transfer is complete
  A POST could result in different actions, thus the server cannot provide =
it before the last Block1 request. Shouldn't the status be empty  when M=3D=
0 in a Block1 response?

Thanks a lot
Matthias

From matthieu.vial@non.schneider-electric.com  Tue Oct 25 09:08:19 2011
Return-Path: <matthieu.vial@non.schneider-electric.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5F921F8BE8 for <core@ietfa.amsl.com>; Tue, 25 Oct 2011 09:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJaOWtwmEL5w for <core@ietfa.amsl.com>; Tue, 25 Oct 2011 09:08:19 -0700 (PDT)
Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by ietfa.amsl.com (Postfix) with ESMTP id EB72321F8B8C for <core@ietf.org>; Tue, 25 Oct 2011 09:08:18 -0700 (PDT)
Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX02.eud.schneider-electric.com with ESMTP id 2011102517485761-241911 ; Tue, 25 Oct 2011 17:48:57 +0200 
To: core@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
From: matthieu.vial@non.schneider-electric.com
Message-ID: <OFD738EFDB.A5B4D10F-ONC1257934.00504867-C1257934.0058A53A@Schneider-Electric.com>
Date: Tue, 25 Oct 2011 18:08:14 +0200
X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 25/10/2011 18:08:13, Serialize complete at 25/10/2011 18:08:13, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 25/10/2011 17:48:57, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 25/10/2011 17:48:59, Serialize complete at 25/10/2011 17:48:59
Content-Type: text/plain; charset="US-ASCII"
Subject: [core] Multicast and error codes
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2011 16:08:19 -0000

Hi all,

In section 4.1 multicast of coap 03 there is a proposition to eliminate 
responses with an error code

This text has been removed in 07 and the text "SHOULD be a Non-confirmable 
request" is now a "MUST be Non-confirmable request".
But as I understand coap 07 it is possible to send a response with an 
error code to a NON request as a NON response.
So I think the text in coap 03 is now missing to avoid response floods.
What do you think?

Matthieu

From trac+core@trac.tools.ietf.org  Thu Oct 27 22:37:57 2011
Return-Path: <trac+core@trac.tools.ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D2621F852E for <core@ietfa.amsl.com>; Thu, 27 Oct 2011 22:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.513
X-Spam-Level: 
X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+G1Xpem2nle for <core@ietfa.amsl.com>; Thu, 27 Oct 2011 22:37:57 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id EB63521F851F for <core@ietf.org>; Thu, 27 Oct 2011 22:37:56 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from <trac+core@trac.tools.ietf.org>) id 1RJf8d-0007Hf-9Z; Fri, 28 Oct 2011 01:37:55 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" <trac+core@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: hartke@tzi.org
X-Trac-Project: core
Date: Fri, 28 Oct 2011 05:37:54 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/core/trac/ticket/173#comment:1
Message-ID: <072.78b61815d16f07c3ef88d304ff33e1ed@trac.tools.ietf.org>
References: <057.36634ad92e5cec195bb77f53e566188d@trac.tools.ietf.org>
X-Trac-Ticket-ID: 173
In-Reply-To: <057.36634ad92e5cec195bb77f53e566188d@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] #173: Advanced examples
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2011 05:37:57 -0000

#173: Advanced examples

Changes (by hartke@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Done in observe-03.

-- 
---------------------+-----------------------
 Reporter:  zach@…   |       Owner:  hartke@…
     Type:  task     |      Status:  closed
 Priority:  minor    |   Milestone:
Component:  observe  |     Version:
 Severity:  -        |  Resolution:  fixed
 Keywords:           |
---------------------+-----------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/core/trac/ticket/173#comment:1>
core <http://tools.ietf.org/core/>


From trac+core@trac.tools.ietf.org  Thu Oct 27 23:12:04 2011
Return-Path: <trac+core@trac.tools.ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DBA21F8AB9 for <core@ietfa.amsl.com>; Thu, 27 Oct 2011 23:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level: 
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF64+iGPP88n for <core@ietfa.amsl.com>; Thu, 27 Oct 2011 23:12:03 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 196CD21F87C5 for <core@ietf.org>; Thu, 27 Oct 2011 23:12:01 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from <trac+core@trac.tools.ietf.org>) id 1RJffc-0004pz-Sm; Fri, 28 Oct 2011 02:12:00 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" <trac+core@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: hartke@tzi.org
X-Trac-Project: core
Date: Fri, 28 Oct 2011 06:12:00 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/174#comment:1
Message-ID: <068.a2e4531d010c0288929fada8734aaf01@trac.tools.ietf.org>
References: <053.70316ef76a2aab1204bc99bad86807ea@trac.tools.ietf.org>
X-Trac-Ticket-ID: 174
In-Reply-To: <053.70316ef76a2aab1204bc99bad86807ea@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] #174: Robust observation relationships
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2011 06:12:04 -0000

#174: Robust observation relationships

Changes (by hartke@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Clear rules for what to do when a client does not receive a notification
 for some time, or a server does not receive an acknowledgement, have been
 added in observe-03. The time to wait is determined by Max-Age and a new
 option called Max-OFE ("optimistic freshness extension").

-- 
-----------------------------------+-----------------------
 Reporter:  hartke@…               |       Owner:  hartke@…
     Type:  protocol defect        |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  observe                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+-----------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/174#comment:1>
core <http://tools.ietf.org/core/>


From trac+core@trac.tools.ietf.org  Fri Oct 28 03:48:45 2011
Return-Path: <trac+core@trac.tools.ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6858521F8B07 for <core@ietfa.amsl.com>; Fri, 28 Oct 2011 03:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.532
X-Spam-Level: 
X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Kyeql1vgYwL for <core@ietfa.amsl.com>; Fri, 28 Oct 2011 03:48:45 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id E803C21F8B02 for <core@ietf.org>; Fri, 28 Oct 2011 03:48:44 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from <trac+core@trac.tools.ietf.org>) id 1RJjzP-0006rR-VX; Fri, 28 Oct 2011 06:48:44 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" <trac+core@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: hartke@tzi.org
X-Trac-Project: core
Date: Fri, 28 Oct 2011 10:48:43 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/172#comment:1
Message-ID: <072.2bc11f1a133f7ffbaa25eb8259a65703@trac.tools.ietf.org>
References: <057.680fef4adc297d24c3063e01849787fc@trac.tools.ietf.org>
X-Trac-Ticket-ID: 172
In-Reply-To: <057.680fef4adc297d24c3063e01849787fc@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: hartke@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: Re: [core] #172: Improve observer + block text
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2011 10:48:45 -0000

#172: Improve observer + block text

Changes (by hartke@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Done in observe-03.

-- 
-----------------------+-----------------------
 Reporter:  zach@…     |       Owner:  hartke@…
     Type:  editorial  |      Status:  closed
 Priority:  minor      |   Milestone:
Component:  observe    |     Version:
 Severity:  -          |  Resolution:  fixed
 Keywords:             |
-----------------------+-----------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/172#comment:1>
core <http://tools.ietf.org/core/>


From trac+core@trac.tools.ietf.org  Fri Oct 28 06:35:41 2011
Return-Path: <trac+core@trac.tools.ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710A121F8B5B for <core@ietfa.amsl.com>; Fri, 28 Oct 2011 06:35:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level: 
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8djoXnnHJ1US for <core@ietfa.amsl.com>; Fri, 28 Oct 2011 06:35:40 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B0FAA21F84FC for <core@ietf.org>; Fri, 28 Oct 2011 06:35:40 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from <trac+core@trac.tools.ietf.org>) id 1RJmav-0002rl-IO; Fri, 28 Oct 2011 09:35:37 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" <trac+core@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Fri, 28 Oct 2011 13:35:37 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/176
Message-ID: <057.1e9c9b555be0e4f1e7b8069f00a990a7@trac.tools.ietf.org>
X-Trac-Ticket-ID: 176
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: [core]  #176: Uri-Path and Uri-Query
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2011 13:35:41 -0000

#176: Uri-Path and Uri-Query

 This ticket is to move to a non-segmented Uri-Path and Uri-Query solution
 (as was in previous versions), just normalizing and then including the
 whole path or query string in the Uri-Path or -Query option, respectively.
 However, in order to overcome the 270 octet limit of a single option, we
 allow the concatenation of these options as is done in the Proxy-Uri
 option. This is a minor change for implementations, as many already just
 perform concatenation when processing these options.

 The ticket is in response to implementor feedback where interoperability
 problems have been common regarding segmentation, and the ETSI M2M
 standardization effort where a CoAP binding has been defined and the
 segmented model casuses problems with the ETSI standard as deep path
 structures together with query parameters are required.

 This would require the following technical changes to coap-07:

 Section 5.10.2:

 -  o  each Uri-Path Option specifies one segment of the absolute path to
 -     the resource, and
 +  o  the Uri-Path Option contains the absolute path to the resource, and

 -   o  each Uri-Query Option specifies one argument parameterizing the
 -      resource.
 +   o  the Uri-Query Option contains the query string of the resource.

 Section 6.4:

   8.  If the value of the <path> component of /url/ is empty or
       consists of a single slash character (U+002F SOLIDUS "/"), then
       move to the next step.

 -     Otherwise, for each segment in the <path> component, include a
 -     Uri-Path Option and let that option's value be the segment (not
 -     including the delimiting slash characters) after converting all
 -     percent-encodings ("%" followed by two hexadecimal digits) to the
 -     corresponding characters.

 +    Otherwise, the <path> component is included in a Uri-Path option
 +    after converting all percent-encodings ("%" followed by two
 hexadecimal
 +    digits) to the corresponding characters. In case the <path> doesn't
 fit
 +    within a single option, the Uri-Path Option MAY be included multiple
 +    times in a request such that the concatenation of the values results
 in
 +    the single <path>. All but the last instance of the Uri-Path Option
 MUST
 +    have a value with a length of 270 bytes, and the last instance MUST
 NOT be empty.

   9.
 -       If /url/ has a <query> component, then, for each argument in the
 -       <query> component, include a Uri-Query Option and let that
 -       option's value be the argument (not including the question mark
 -       and the delimiting ampersand characters) after converting all
 -       percent-encodings to the corresponding characters.

 +      If /url/ has a <query> component, then the <query> component is
 included
 +      in a Uri-Query option after converting all percent-encodings to the
 corresponding
 +      characters. In case the <query> doesn't fit
 +      within a single option, the Uri-Query Option MAY be included
 multiple
 +      times in a request such that the concatenation of the values
 results in
 +      the single <query>. All but the last instance of the Uri-Query
 Option MUST
 +      have a value with a length of 270 bytes, and the last instance MUST
 NOT be empty.

 Section 6.5:

      6.  Let /resource name/ be the empty string.
 - For each Uri-Path
 + For the first Uri-Path

      Option in the request, append a single character U+002F SOLIDUS
     (/) followed by the option's value to /resource name/

 + For any additional Uri-Path options, concatenate the value to /resource
 name/.

 -        Then converting any character that is not either in the
 -    "unreserved" set, "sub-delims" set, a U+003A COLON (:) or U+0040 -
 COMMERCIAL AT (@) character, to its percent-encoded form.


    8.
 -        For each
 +        For the first

 Uri-Query Option in the request, append a single
         character U+003F QUESTION MARK (?) (first option) or U+0026
         AMPERSAND (&) (subsequent options) followed by the option's
         value to /resource name/.

 + For any additional Uri-Query options, concatenate the value to /resource
 name/.


 +  New step 8a.

 + Then convert any character in /resource name/ that is not either in the
 + "unreserved" set, "sub-delims" set, a U+003A COLON (:) or U+0040 +
 COMMERCIAL AT (@) character, to its percent-encoded form.

-- 
----------------------------------+--------------------
 Reporter:  zach@…                |      Owner:  zach@…
     Type:  protocol enhancement  |     Status:  new
 Priority:  minor                 |  Milestone:
Component:  coap                  |    Version:
 Severity:  -                     |   Keywords:
----------------------------------+--------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/176>
core <http://tools.ietf.org/core/>


From zach@sensinode.com  Fri Oct 28 06:44:19 2011
Return-Path: <zach@sensinode.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C079F21F8B8C for <core@ietfa.amsl.com>; Fri, 28 Oct 2011 06:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oS42JwOZLNWq for <core@ietfa.amsl.com>; Fri, 28 Oct 2011 06:44:19 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6E11421F8A91 for <core@ietf.org>; Fri, 28 Oct 2011 06:44:18 -0700 (PDT)
Received: from [10.10.21.243] (nblzone-225-1.nblnetworks.fi [83.145.225.1]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id p9SDhkOv002391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Oct 2011 16:43:56 +0300
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-362-52324732; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby <zach@sensinode.com>
In-Reply-To: <057.1e9c9b555be0e4f1e7b8069f00a990a7@trac.tools.ietf.org>
Date: Fri, 28 Oct 2011 16:43:44 +0300
Message-Id: <54B5D1FD-D904-41FD-9AEE-D5E3639A82C5@sensinode.com>
References: <057.1e9c9b555be0e4f1e7b8069f00a990a7@trac.tools.ietf.org>
To: trac+core@gamay.tools.ietf.org
X-Mailer: Apple Mail (2.1084)
Cc: core@ietf.org
Subject: Re: [core] #176: Uri-Path and Uri-Query
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2011 13:44:19 -0000

--Apple-Mail-362-52324732
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi,

I entered this as a ticket not to lose track of the changes needed. This =
text now includes all the changes I think would be necessary for this =
update. Please take a look if you can spot bugs or have improvement =
suggestions.

We should hear some more feedback on making this change before =
implementing it. So far I have heard decent support on the mailing list. =
Olaf brought up a possible normalization issue with Uri-Path, but I =
think that was a misunderstanding. I am just returning from the an ETSI =
M2M meeting and can confirm that the current -07 model is a broken for =
them, and the general expectation is that we will fix this.=20

Please let us know your thoughts by Monday.

Thanks,
Zach=20

On Oct 28, 2011, at 4:35 PM, core issue tracker wrote:

> #176: Uri-Path and Uri-Query
>=20
> This ticket is to move to a non-segmented Uri-Path and Uri-Query =
solution
> (as was in previous versions), just normalizing and then including the
> whole path or query string in the Uri-Path or -Query option, =
respectively.
> However, in order to overcome the 270 octet limit of a single option, =
we
> allow the concatenation of these options as is done in the Proxy-Uri
> option. This is a minor change for implementations, as many already =
just
> perform concatenation when processing these options.
>=20
> The ticket is in response to implementor feedback where =
interoperability
> problems have been common regarding segmentation, and the ETSI M2M
> standardization effort where a CoAP binding has been defined and the
> segmented model casuses problems with the ETSI standard as deep path
> structures together with query parameters are required.
>=20
> This would require the following technical changes to coap-07:
>=20
> Section 5.10.2:
>=20
> -  o  each Uri-Path Option specifies one segment of the absolute path =
to
> -     the resource, and
> +  o  the Uri-Path Option contains the absolute path to the resource, =
and
>=20
> -   o  each Uri-Query Option specifies one argument parameterizing the
> -      resource.
> +   o  the Uri-Query Option contains the query string of the resource.
>=20
> Section 6.4:
>=20
>   8.  If the value of the <path> component of /url/ is empty or
>       consists of a single slash character (U+002F SOLIDUS "/"), then
>       move to the next step.
>=20
> -     Otherwise, for each segment in the <path> component, include a
> -     Uri-Path Option and let that option's value be the segment (not
> -     including the delimiting slash characters) after converting all
> -     percent-encodings ("%" followed by two hexadecimal digits) to =
the
> -     corresponding characters.
>=20
> +    Otherwise, the <path> component is included in a Uri-Path option
> +    after converting all percent-encodings ("%" followed by two
> hexadecimal
> +    digits) to the corresponding characters. In case the <path> =
doesn't
> fit
> +    within a single option, the Uri-Path Option MAY be included =
multiple
> +    times in a request such that the concatenation of the values =
results
> in
> +    the single <path>. All but the last instance of the Uri-Path =
Option
> MUST
> +    have a value with a length of 270 bytes, and the last instance =
MUST
> NOT be empty.
>=20
>   9.
> -       If /url/ has a <query> component, then, for each argument in =
the
> -       <query> component, include a Uri-Query Option and let that
> -       option's value be the argument (not including the question =
mark
> -       and the delimiting ampersand characters) after converting all
> -       percent-encodings to the corresponding characters.
>=20
> +      If /url/ has a <query> component, then the <query> component is
> included
> +      in a Uri-Query option after converting all percent-encodings to =
the
> corresponding
> +      characters. In case the <query> doesn't fit
> +      within a single option, the Uri-Query Option MAY be included
> multiple
> +      times in a request such that the concatenation of the values
> results in
> +      the single <query>. All but the last instance of the Uri-Query
> Option MUST
> +      have a value with a length of 270 bytes, and the last instance =
MUST
> NOT be empty.
>=20
> Section 6.5:
>=20
>      6.  Let /resource name/ be the empty string.
> - For each Uri-Path
> + For the first Uri-Path
>=20
>      Option in the request, append a single character U+002F SOLIDUS
>     (/) followed by the option's value to /resource name/
>=20
> + For any additional Uri-Path options, concatenate the value to =
/resource
> name/.
>=20
> -        Then converting any character that is not either in the
> -    "unreserved" set, "sub-delims" set, a U+003A COLON (:) or U+0040 =
-
> COMMERCIAL AT (@) character, to its percent-encoded form.
>=20
>=20
>    8.
> -        For each
> +        For the first
>=20
> Uri-Query Option in the request, append a single
>         character U+003F QUESTION MARK (?) (first option) or U+0026
>         AMPERSAND (&) (subsequent options) followed by the option's
>         value to /resource name/.
>=20
> + For any additional Uri-Query options, concatenate the value to =
/resource
> name/.
>=20
>=20
> +  New step 8a.
>=20
> + Then convert any character in /resource name/ that is not either in =
the
> + "unreserved" set, "sub-delims" set, a U+003A COLON (:) or U+0040 +
> COMMERCIAL AT (@) character, to its percent-encoded form.
>=20
> --=20
> ----------------------------------+--------------------
> Reporter:  zach@=85                |      Owner:  zach@=85
>     Type:  protocol enhancement  |     Status:  new
> Priority:  minor                 |  Milestone:
> Component:  coap                  |    Version:
> Severity:  -                     |   Keywords:
> ----------------------------------+--------------------
>=20
> Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/176>
> core <http://tools.ietf.org/core/>
>=20

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


--Apple-Mail-362-52324732
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw
ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x
MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT
UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb
+JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH
HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh
5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW
bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud
HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu
ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL
7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb
rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW
YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO
guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn
zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz
MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk
YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg
LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx
jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e
FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT
DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe
vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7
btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB
hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE
JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9
OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD
VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw
QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1
qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS
gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu
EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy
bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW
jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx
HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC
GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEwMjgx
MzQzNDVaMCMGCSqGSIb3DQEJBDEWBBTKY+admNTlTqI8l3LfB57c0nI0QDCCAQMGCSsGAQQBgjcQ
BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp
Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd
uDANBgkqhkiG9w0BAQEFAASCAQDFTC0t01qUycxUZzoFaAOW9WEG6qwAM/YuU6afL3vUQUl+esII
nTqryJeMOxOsRH0otAzWnMQOxRCGr3CtoNFjM4GNc9aArGU7Vcyq67fhjQgzUrfeyo3+6Q4lbu9g
ygR0D+afXavB2RBEbD9IHeNia2GkNB8YasQujzt02Y1m16+XaQnLbZPoBZpXcYTuuytKfrPfp9iz
skipnaBufSQbALcMIXs9qBOQO6NU66QHDhiQFEJyBlvHGoOsZOGViBPT2tju462MWuYtWwqVGXyG
zQldhHzYuCDiJrEg7vNjd3Hfs4pmO/aMZV20Lfi6gOAaqNMSUrcKLOG4sO4bKRtPAAAAAAAA

--Apple-Mail-362-52324732--

From peter.van.der.stok@philips.com  Mon Oct 31 01:08:25 2011
Return-Path: <peter.van.der.stok@philips.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40FD21F8CFF for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 01:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgFj3ScR1TeS for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 01:08:25 -0700 (PDT)
Received: from AM1EHSOBE005.bigfish.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 8641221F8CFE for <core@ietf.org>; Mon, 31 Oct 2011 01:08:24 -0700 (PDT)
Received: from mail13-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.22; Mon, 31 Oct 2011 08:08:10 +0000
Received: from mail13-am1 (localhost.localdomain [127.0.0.1])	by mail13-am1-R.bigfish.com (Postfix) with ESMTP id 472F8550227	for <core@ietf.org>; Mon, 31 Oct 2011 08:08:17 +0000 (UTC)
X-SpamScore: -36
X-BigFish: VPS-36(zz217bL15d6O9251J936eKc85fhzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPVD:NLI; H:mail.philips.com; RD:none; EFVD:NLI
Received: from mail13-am1 (localhost.localdomain [127.0.0.1]) by mail13-am1 (MessageSwitch) id 1320048496971325_932; Mon, 31 Oct 2011 08:08:16 +0000 (UTC)
Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.241])	by mail13-am1.bigfish.com (Postfix) with ESMTP id DFCEA18F8052	for <core@ietf.org>; Mon, 31 Oct 2011 08:08:16 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS018.bigfish.com (10.3.206.21) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 31 Oct 2011 08:08:09 +0000
Received: from 011-DB3MPN1-062.MGDPHG.emi.philips.com ([169.254.2.186]) by 011-DB3MMR1-001.MGDPHG.emi.philips.com ([10.128.28.51]) with mapi id 14.01.0339.002; Mon, 31 Oct 2011 08:08:21 +0000
From: "Stok, Peter van der" <peter.van.der.stok@philips.com>
To: core WG <core@ietf.org>
Thread-Topic: new bc draft
Thread-Index: AcyXpEDGxMf6Cdb2TT2cDHIcxkfedw==
Date: Mon, 31 Oct 2011 08:08:20 +0000
Message-ID: <A31CB84F6F0BFC449C6807DF752A715B8EC8@011-DB3MPN1-062.MGDPHG.emi.philips.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [194.171.252.100]
Content-Type: multipart/alternative; boundary="_000_A31CB84F6F0BFC449C6807DF752A715B8EC8011DB3MPN1062MGDPHG_"
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Subject: [core] new bc draft
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 08:08:26 -0000

--_000_A31CB84F6F0BFC449C6807DF752A715B8EC8011DB3MPN1062MGDPHG_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

A new version of I-D, draft-vanderstok-core-bc-05.txt has been successfully=
 submitted by Peter Stok and posted to the IETF repository.



Filename:   draft-vanderstok-core-bc

Revision:   05

Title:            CoAP Utilization for Building Control

Creation date:    2011-10-30

WG ID:            Individual Submission

Number of pages: 32



url: draft-vanderstok-core-bc-05<https://datatracker.ietf.org/doc/draft-van=
derstok-core-bc/>


Changes from bc-04 to bc-05
- extended and corrected examples for multi-function devices
- syntax more compatible with other resource discovery I-Ds
- abstract adapted
- more stringent use of the words server, end point, service and

devices





Abstract:

   This draft describes an example use of the RESTful CoAP protocol for

   building automation and control (BAC) applications such as HVAC and

   lighting.  A few basic design assumptions are stated first, then URI

   structure is utilized to define group as well as unicast scope for

   RESTful operations.



   This proposal supports the view that 1) service discovery is

   complementary to resource discovery and facilitates control network

   scaling, and 2) building control is likely to move in steps toward

   all-IP control networks based on the legacy efforts provided by DALI,

   LON, BACnet, ZigBee, and other standards.



   The authority portion of the URI is used to identify a device (group)

   and the resulting DNS name is bound to a unicast (multicast) address.

   Group addressing has consequence for the naming convention of the

   resources of a device.  Naming of URI is building or organization

   dependent, must be flexible, and SHOULD conform to some local

   convention.  Naming of resources MUST be standardized preferably by

   a building control related organization.



   It is shown that DNS-based service discovery can be used to locate

   URIs on the scale necessary in large commercial BAC deployments.  The

   relation of DNS-SD and a Resource Directory is discussed.  Finally, a

   method is proposed for mapping URIs onto legacy BAC resources, e.g.,

   to discover application-layer gateways, proxies, and their dependent

   services.




Peter van der Stok
Philips Research Laboratories Eindhoven
High Tech Campus                                                          H=
TC 34 (WB) 1-067
5656 AA Eindhoven                                                      The =
Netherlands
phone +31 40 2749657                                                Fax: + =
31 40 2746321
mailto: Peter.van.der.Stok@philips.com


________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.

--_000_A31CB84F6F0BFC449C6807DF752A715B8EC8011DB3MPN1062MGDPHG_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<style>
<!--
@font-face
	{font-family:Courier}
@font-face
	{font-family:Courier}
@font-face
	{font-family:Cambria}
@font-face
	{font-family:Calibri}
@font-face
	{font-family:Consolas}
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif"}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas}
span.EmailStyle17
	{font-family:"Calibri","sans-serif";
	color:windowtext}
span.PlainTextChar
	{font-family:Consolas}
.MsoChpDefault
	{}
@page WordSection1
	{margin:72.0pt 72.0pt 72.0pt 72.0pt}
div.WordSection1
	{}
-->
</style>
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">A new version of I-D, draft-vanderstok-core-bc-05=
.txt has been successfully submitted by Peter Stok and posted to the IETF r=
epository.</p>
<p class=3D"MsoPlainText">&nbsp;</p>
<p class=3D"MsoPlainText">Filename:&nbsp;&nbsp; draft-vanderstok-core-bc</p=
>
<p class=3D"MsoPlainText">Revision:&nbsp;&nbsp; 05</p>
<p class=3D"MsoPlainText">Title:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; CoAP Utilization for Building Control</p>
<p class=3D"MsoPlainText">Creation date:&nbsp;&nbsp;&nbsp; 2011-10-30</p>
<p class=3D"MsoPlainText">WG ID:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; Individual Submission</p>
<p class=3D"MsoPlainText">Number of pages: 32</p>
<p class=3D"MsoPlainText">&nbsp;</p>
<p class=3D"MsoPlainText"><span lang=3D"NL">url:</span><span lang=3D"NL" st=
yle=3D"font-size:10.0pt; font-family:&quot;Arial&quot;,&quot;sans-serif&quo=
t;">
</span><span style=3D"font-size:10.0pt; font-family:&quot;Arial&quot;,&quot=
;sans-serif&quot;"><a href=3D"https://datatracker.ietf.org/doc/draft-vander=
stok-core-bc/"><span lang=3D"NL">draft-vanderstok-core-bc-05</span></a></sp=
an><span style=3D"font-size:10.0pt; font-family:&quot;Arial&quot;,&quot;san=
s-serif&quot;">
<span lang=3D"NL"></span></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none">&nbsp;</p>
<p class=3D"MsoNormal" style=3D"text-autospace:none">&nbsp;</p>
<p class=3D"MsoNormal" style=3D"text-autospace:none">Changes <span style=3D=
"font-size:12.0pt; font-family:Courier">
from bc-04 to bc-05</span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:12.0pt; font-family:Courier">- extended and corrected examples for multi=
-function devices</span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:12.0pt; font-family:Courier">- syntax more compatible with other resourc=
e discovery I-Ds</span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:12.0pt; font-family:Courier">- abstract adapted</span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:12.0pt; font-family:Courier">- more stringent use of the words server, e=
nd point, service and</span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:12.0pt; font-family:Cour=
ier">devices</span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:12.0pt; font-family:Cour=
ier">&nbsp;</span></p>
<p class=3D"MsoPlainText"><span lang=3D"NL">&nbsp;</span></p>
<p class=3D"MsoPlainText">Abstract:</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; This draft describes an example use =
of the RESTful CoAP protocol for</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; building automation and control (BAC=
) applications such as HVAC and</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; lighting.&nbsp; A few basic design a=
ssumptions are stated first, then URI</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; structure is utilized to define grou=
p as well as unicast scope for</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; RESTful operations.</p>
<p class=3D"MsoPlainText">&nbsp;</p>
<p class=3D"MsoPlainText">&nbsp; &nbsp;This proposal supports the view that=
 1) service discovery is</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; complementary to resource discovery =
and facilitates control network</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; scaling, and 2) building control is =
likely to move in steps toward</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; all-IP control networks based on the=
 legacy efforts provided by DALI,</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; LON, BACnet, ZigBee, and other stand=
ards.</p>
<p class=3D"MsoPlainText">&nbsp;</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; The authority portion of the URI is =
used to identify a device (group)</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; and the resulting DNS name is bound =
to a unicast (multicast) address.</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; Group addressing has consequence for=
 the naming convention of the</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; resources of a device.&nbsp; Naming =
of URI is building or organization</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; dependent, must be flexible, and SHO=
ULD conform to some local</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; convention.&nbsp; Naming of resource=
s MUST be standardized preferably by</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; a building control related organizat=
ion.</p>
<p class=3D"MsoPlainText">&nbsp;</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; It is shown that DNS-based service d=
iscovery can be used to locate</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; URIs on the scale necessary in large=
 commercial BAC deployments.&nbsp; The</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; relation of DNS-SD and a Resource Di=
rectory is discussed.&nbsp; Finally, a</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; method is proposed for mapping URIs =
onto legacy BAC resources, e.g.,</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; to discover application-layer gatewa=
ys, proxies, and their dependent</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; services.</p>
<p class=3D"MsoPlainText">&nbsp;</p>
<p class=3D"MsoNormal">&nbsp;</p>
<p class=3D"MsoNormal">&nbsp;</p>
<p class=3D"MsoNormal">Peter van der Stok</p>
<p class=3D"MsoNormal">Philips Research Laboratories Eindhoven</p>
<p class=3D"MsoNormal">High Tech Campus<span style=3D"font-family:&quot;Cam=
bria&quot;,&quot;serif&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HT=
C 34 (WB) 1-067</span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Cambria&quot;,&quot=
;serif&quot;">5656 AA Eindhoven&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Netherlands</span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Cambria&quot;,&quot=
;serif&quot;">phone &#43;31 40 2749657&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; Fax: &#43; 31 40 2746321</span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Cambria&quot;,&quot=
;serif&quot;">mailto: Peter.van.der.Stok@philips.com</span></p>
<p class=3D"MsoNormal">&nbsp;</p>
</div>
<br>
<hr>
<font face=3D"Arial" color=3D"Gray" size=3D"1">The information contained in=
 this message may be confidential and legally protected under applicable la=
w. The message is intended solely for the addressee(s). If you are not the =
intended recipient, you are hereby notified
 that any use, forwarding, dissemination, or reproduction of this message i=
s strictly prohibited and may be unlawful. If you are not the intended reci=
pient, please contact the sender by return e-mail and destroy all copies of=
 the original message.<br>
</font>
</body>
</html>

--_000_A31CB84F6F0BFC449C6807DF752A715B8EC8011DB3MPN1062MGDPHG_--

From esko.dijk@philips.com  Mon Oct 31 04:07:48 2011
Return-Path: <esko.dijk@philips.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAFB21F8DA8 for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 04:07:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4+Von9wfWsX for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 04:07:48 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 3E86221F8D3F for <core@ietf.org>; Mon, 31 Oct 2011 04:07:48 -0700 (PDT)
Received: from mail26-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.22; Mon, 31 Oct 2011 11:07:35 +0000
Received: from mail26-ch1 (localhost.localdomain [127.0.0.1])	by mail26-ch1-R.bigfish.com (Postfix) with ESMTP id B3E4E57845D; Mon, 31 Oct 2011 11:07:41 +0000 (UTC)
X-SpamScore: -43
X-BigFish: VPS-43(zz217bL15d6O9251J119bM542Mzz1202hzz1033IL8275dhz2dh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPVD:NLI; H:mail.philips.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail26-ch1 (localhost.localdomain [127.0.0.1]) by mail26-ch1 (MessageSwitch) id 1320059261517814_1217; Mon, 31 Oct 2011 11:07:41 +0000 (UTC)
Received: from CH1EHSMHS019.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244])	by mail26-ch1.bigfish.com (Postfix) with ESMTP id 1BBE9218051;	Mon, 31 Oct 2011 11:07:41 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 31 Oct 2011 11:07:46 +0000
Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.171]) by 011-DB3MMR1-006.MGDPHG.emi.philips.com ([10.128.28.56]) with mapi id 14.01.0339.002; Mon, 31 Oct 2011 11:07:44 +0000
From: "Dijk, Esko" <esko.dijk@philips.com>
To: "Kovatsch  Matthias" <kovatsch@inf.ethz.ch>, "core@ietf.org" <core@ietf.org>
Thread-Topic: Status of Blockwise Transfers
Thread-Index: AcyTA1LLgF2apeWtTByzRREkH8/sygEtchlQ
Date: Mon, 31 Oct 2011 11:07:43 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED618D50B@011-DB3MPN1-013.MGDPHG.emi.philips.com>
References: <55877B3AFB359744BA0F2140E36F52B51382ED5E@MBX10.d.ethz.ch>
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B51382ED5E@MBX10.d.ethz.ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [86.94.216.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Subject: Re: [core] Status of Blockwise Transfers
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 11:07:49 -0000

Dear Matthias,

I agree with your second point that a server can't in general select a stat=
us code to a blockwise POST. It could be either 2.01, 2.02 or 2.04, or one =
of the error codes, but this depends on the entire payload being POSTed whi=
ch is only known after the last block (Block1). Perhaps the server could se=
nd a "most likely to happen" response code. This is okay since only the fin=
al response status code (where M bit 0 in the Block1 option) actually carri=
es the result of the REST operation  - see string "final response" in the t=
ext.

The current spec seems to already take this "most likely to happen" meaning=
 for the status code in the examples, e.g. blockwise PUT returns 2.04 each =
time but if a block is missing the final result could still be 2.04 or 4.00=
 or 4.08. POST could do the same?

On your first point, concurrent Block1/Block2 usage, that seems only applic=
able to POST or doesn't it? It seems logical to me that the server can only=
 start sending a blockwise response back (using Block2) when the full paylo=
ad to POST has been received from the client (who uses Block1 and simultane=
ously empty Block2 to indicate size) and processed. For this text and/or ex=
amples are needed in my view.

regards,
Esko

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kov=
atsch Matthias
Sent: Tuesday 25 October 2011 13:00
To: Carsten Bormann; core@ietf.org
Subject: [core] Status of Blockwise Transfers

Dear Carsten

I would like to ask about the current status of blockwise transfers:

- Concurrent usage of Block1 and Block2 in a single operation
  core-block-04 mentions it once, but does not specify how to handle it or =
give an example (I guess, a POST request keeps the Block1 option with M=3D0=
 and no payload until all Block2 blocks were requested?).

- Using Status codes before an atomic Block1 transfer is complete
  A POST could result in different actions, thus the server cannot provide =
it before the last Block1 request. Shouldn't the status be empty  when M=3D=
0 in a Block1 response?

Thanks a lot
Matthias
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From internet-drafts@ietf.org  Mon Oct 31 04:37:19 2011
Return-Path: <internet-drafts@ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7835221F8DC0; Mon, 31 Oct 2011 04:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.562
X-Spam-Level: 
X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HikFi6x4m0mp; Mon, 31 Oct 2011 04:37:19 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C1821F8DB8; Mon, 31 Oct 2011 04:37:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.62
Message-ID: <20111031113719.3103.79998.idtracker@ietfa.amsl.com>
Date: Mon, 31 Oct 2011 04:37:19 -0700
Cc: core@ietf.org
Subject: [core] I-D Action: draft-ietf-core-observe-03.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 11:37:19 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Constrained RESTful Environments Work=
ing Group of the IETF.

	Title           : Observing Resources in CoAP
	Author(s)       : Klaus Hartke
                          Zach Shelby
	Filename        : draft-ietf-core-observe-03.txt
	Pages           : 27
	Date            : 2011-10-31

   CoAP is a RESTful application protocol for constrained nodes and
   networks.  The state of a resource on a CoAP server can change over
   time.  This document specifies a simple protocol extension for CoAP
   that gives clients the ability to observe such changes.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-core-observe-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-observe-03.txt

From cabo@tzi.org  Mon Oct 31 05:40:53 2011
Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F0C21F8D58 for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 05:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-NDSKPlkRK3 for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 05:40:53 -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 DAFF321F8DBC for <core@ietf.org>; Mon, 31 Oct 2011 05:40:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p9VCei4t027643; Mon, 31 Oct 2011 13:40:44 +0100 (CET)
Received: from [192.168.217.112] (p5B3E6CBA.dip.t-dialin.net [91.62.108.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 49019704; Mon, 31 Oct 2011 13:40:44 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com>
Date: Mon, 31 Oct 2011 13:40:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <230F2748-EEAF-4FC7-83E6-BDB43E29D5F3@tzi.org>
References: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com>
To: Zach Shelby <zach@sensinode.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: core WG <core@ietf.org>
Subject: Re: [core] Uri-Path and -Query segmentation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 12:40:53 -0000

Zach,

coap-07 is fully consistent, as it sends fully parsed CoAP URLs only.
Apart from taking away any need for a CoAP server to do any parsing,
this particularly means coap-07 has full data transparency, e.g. you
could use a binary number as a path component.  For Uri-path, falling
back to coap-03 would take back that ability, as bytes of the value
0x2F are suddenly special again.  Similarly, Uri-query components
suddenly couldn't use 0x25 bytes any more.  There is no percent
encoding any more to work around this.

I believe support for binary values in URIs is important for CoAP.

The 15 option limit may indeed hurt more complex applications; maybe
we need to do something about that, but preferably not by futzing
around with every single repeatable option.

Gr=FC=DFe, Carsten


From sye.loong.keoh@philips.com  Mon Oct 31 06:56:41 2011
Return-Path: <sye.loong.keoh@philips.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34F521F8CEC for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 06:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOepLSRntmwO for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 06:56:40 -0700 (PDT)
Received: from VA3EHSOBE003.bigfish.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 85B1121F8CCA for <core@ietf.org>; Mon, 31 Oct 2011 06:56:39 -0700 (PDT)
Received: from mail89-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.22; Mon, 31 Oct 2011 13:56:26 +0000
Received: from mail89-va3 (localhost [127.0.0.1])	by mail89-va3-R.bigfish.com (Postfix) with ESMTP id C9F044C0138	for <core@ietf.org>; Mon, 31 Oct 2011 13:56:07 +0000 (UTC)
X-SpamScore: -36
X-BigFish: VPS-36(zz217bL15d6O9251J936eKc85fhzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPV:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI
X-FB-SS: 0,0,
Received: from mail89-va3 (localhost.localdomain [127.0.0.1]) by mail89-va3 (MessageSwitch) id 1320069346300531_7698; Mon, 31 Oct 2011 13:55:46 +0000 (UTC)
Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.254])	by mail89-va3.bigfish.com (Postfix) with ESMTP id 3F7A0540046	for <core@ietf.org>; Mon, 31 Oct 2011 13:55:46 +0000 (UTC)
Received: from smtpx.philips.com (168.87.56.20) by VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 31 Oct 2011 13:56:03 +0000
Received: from nlamsexh01.connect1.local (172.16.153.11) by connect1.philips.com (172.16.156.152) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 31 Oct 2011 14:56:11 +0100
Received: from NLCLUEXM05.connect1.local ([172.16.153.54]) by nlamsexh01.connect1.local ([172.16.153.11]) with mapi; Mon, 31 Oct 2011 14:51:19 +0100
From: "Keoh, Sye Loong" <sye.loong.keoh@philips.com>
To: core WG <core@ietf.org>
Date: Mon, 31 Oct 2011 14:56:09 +0100
Thread-Topic: Updates to I-D draft-garcia-core-security
Thread-Index: AcyXpEDGxMf6Cdb2TT2cDHIcxkfedwAL/zLA
Message-ID: <004986BCB690A646B9E3F3789E9F4B8CC9F781525E@NLCLUEXM05.connect1.local>
References: <A31CB84F6F0BFC449C6807DF752A715B8EC8@011-DB3MPN1-062.MGDPHG.emi.philips.com>
In-Reply-To: <A31CB84F6F0BFC449C6807DF752A715B8EC8@011-DB3MPN1-062.MGDPHG.emi.philips.com>
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, nl-NL
Content-Type: multipart/alternative; boundary="_000_004986BCB690A646B9E3F3789E9F4B8CC9F781525ENLCLUEXM05con_"
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Subject: [core] Updates to I-D draft-garcia-core-security
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 13:56:41 -0000

--_000_004986BCB690A646B9E3F3789E9F4B8CC9F781525ENLCLUEXM05con_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

A new version of I-D, draft-garcia-core-security-03.txt has been successful=
ly submitted by Sye Loong Keoh and posted to the IETF repository.



Filename:   draft-garcia-core-security

Revision:   03

Title:            Security Considerations in the IP-based Internet of Thing=
s

Creation date:    2011-10-31

WG ID:            Individual Submission

Number of pages: 44



Changes:

Added section 3.1 to discuss various security threats and potential vulnera=
bilities in the context of IoTs.



URL: draft-garcia-core-security-03<https://datatracker.ietf.org/doc/draft-g=
arcia-core-security/>



Abstract:

   A direct interpretation of the Internet of Things concept refers to

   the usage of standard Internet protocols to allow for human-to-thing

   or thing-to-thing communication.  Although the security needs are

   well-recognized, it is still not fully clear how existing IP-based

   security protocols can be applied to this new setting.  This

   Internet-Draft first provides an overview of security architecture,

   its deployment model and general security needs in the context of the

   lifecycle of a thing.  Then, it presents challenges and requirements

   for the successful roll-out of new applications and usage of standard

   IP-based security protocols when applied to get a functional Internet

   of Things.



Cheers

Sye Loong





________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.

--_000_004986BCB690A646B9E3F3789E9F4B8CC9F781525ENLCLUEXM05con_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.emailstyle17
	{mso-style-name:emailstyle17;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.plaintextchar0
	{mso-style-name:plaintextchar;
	font-family:Consolas;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.apple-style-span
	{mso-style-name:apple-style-span;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">A new version of I-D, draft-garcia-core-security-=
03.txt has been successfully submitted by Sye Loong Keoh and posted to the =
IETF repository.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Filename:&nbsp;&nbsp; draft-garcia-core-security<=
o:p></o:p></p>
<p class=3D"MsoPlainText">Revision:&nbsp;&nbsp; 03<o:p></o:p></p>
<p class=3D"MsoPlainText">Title:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; Security Considerations in the IP-based Internet of=
 Things<o:p></o:p></p>
<p class=3D"MsoPlainText">Creation date:&nbsp;&nbsp;&nbsp; 2011-10-31<o:p><=
/o:p></p>
<p class=3D"MsoPlainText">WG ID:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; Individual Submission<o:p></o:p></p>
<p class=3D"MsoPlainText">Number of pages: 44<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Changes:<o:p></o:p></p>
<p class=3D"MsoPlainText">Added section 3.1 to discuss various security thr=
eats and potential vulnerabilities in the context of IoTs.
<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">URL: <span class=3D"apple-style-span"><span style=
=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black;backgr=
ound:white"><a href=3D"https://datatracker.ietf.org/doc/draft-garcia-core-s=
ecurity/">draft-garcia-core-security-03</a></span></span><o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Abstract:<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; A direct interpretation of the Inter=
net of Things concept refers to<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; the usage of standard Internet proto=
cols to allow for human-to-thing<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; or thing-to-thing communication.&nbs=
p; Although the security needs are<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; well-recognized, it is still not ful=
ly clear how existing IP-based<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; security protocols can be applied to=
 this new setting.&nbsp; This<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; Internet-Draft first provides an ove=
rview of security architecture,<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; its deployment model and general sec=
urity needs in the context of the<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; lifecycle of a thing.&nbsp; Then, it=
 presents challenges and requirements<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; for the successful roll-out of new a=
pplications and usage of standard<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; IP-based security protocols when app=
lied to get a functional Internet<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; of Things.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Cheers<o:p></o:p></p>
<p class=3D"MsoPlainText">Sye Loong<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
</div>
<br>
<hr>
<font face=3D"Arial" color=3D"Gray" size=3D"1">The information contained in=
 this message may be confidential and legally protected under applicable la=
w. The message is intended solely for the addressee(s). If you are not the =
intended recipient, you are hereby notified
 that any use, forwarding, dissemination, or reproduction of this message i=
s strictly prohibited and may be unlawful. If you are not the intended reci=
pient, please contact the sender by return e-mail and destroy all copies of=
 the original message.<br>
</font>
</body>
</html>

--_000_004986BCB690A646B9E3F3789E9F4B8CC9F781525ENLCLUEXM05con_--

From zach@sensinode.com  Mon Oct 31 07:36:49 2011
Return-Path: <zach@sensinode.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA44621F8CCB for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 07:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J39gl3RsNwjD for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 07:36:48 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5099B21F8B89 for <core@ietf.org>; Mon, 31 Oct 2011 07:36:47 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id p9VEah5Z000323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 Oct 2011 16:36:43 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-437-314703339; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby <zach@sensinode.com>
In-Reply-To: <230F2748-EEAF-4FC7-83E6-BDB43E29D5F3@tzi.org>
Date: Mon, 31 Oct 2011 16:36:43 +0200
Message-Id: <E11B69C9-4655-4E9F-828F-3E418D3A6D82@sensinode.com>
References: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com> <230F2748-EEAF-4FC7-83E6-BDB43E29D5F3@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.1084)
Cc: core WG <core@ietf.org>
Subject: Re: [core] Uri-Path and -Query segmentation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 14:36:50 -0000

--Apple-Mail-437-314703339
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On Oct 31, 2011, at 2:40 PM, Carsten Bormann wrote:

> Zach,
>=20
> coap-07 is fully consistent, as it sends fully parsed CoAP URLs only.
> Apart from taking away any need for a CoAP server to do any parsing,

Yes, this has been pointed out clearly in the draft. I think it makes =
sense for servers that actually do parse the path into segments for =
comparison with its resources. What I have noticed is that most =
implementations seem to be happy comparing the whole path as many store =
it that way anyways. Parsing to find / is not much more difficult than =
parsing option headers, so although this is a nice feature, it is a =
marginal benefit only when parsing is actually needed.=20

> this particularly means coap-07 has full data transparency, e.g. you
> could use a binary number as a path component. =20

Ah, so that is the issue. I checked through the draft and we aren't =
really clear about this feature at all. It was only alluded at in one =
small piece of text that arbitrary information can be placed in a =
segment.=20

> For Uri-path, falling
> back to coap-03 would take back that ability, as bytes of the value
> 0x2F are suddenly special again. =20

Hmm... how does that actually work? Section 6.4 prescribes these steps:

1. CoAP client gets request URI from upper layer application
2. As per 6.4 the request URI is split into CoAP options
3. In order to split the <path> component into segments the following =
step is used:

"Otherwise, for each segment in the <path> component, include a
       Uri-Path Option and let that option's value be the segment (not
       including the delimiting slash characters) after converting all
       percent-encodings ("%" followed by two hexadecimal digits) to the
       corresponding characters."

0x2F is special here as well, as any path that had arbitrary binary =
content would be split by 0x2F if it shows up in the octet sequence. Is =
the use of 0x2F inside of a path segment even legal as per RFC3986? All =
CoAP client APIs I have seen so far just accept the request URI path as =
an octet sequence, and they actually use the Section 6.4 process to =
produce Uri-Path options.

Although placing arbitrary binary could be made to work by not following =
section 6.4 and just manually placing that content into each Uri-Path =
option, this is not at all obvious from the draft that we have this =
feature (and why) or from Section 6. Also what does this mean on the =
server side? How does it know this is binary content and not a path =
segment? What happens when it combines the options back into a complete =
path?

> Similarly, Uri-query components
> suddenly couldn't use 0x25 bytes any more.  There is no percent
> encoding any more to work around this.
>=20
> I believe support for binary values in URIs is important for CoAP.

I think this needs some more discussion.=20

> The 15 option limit may indeed hurt more complex applications; maybe
> we need to do something about that, but preferably not by futzing
> around with every single repeatable option.

=46rom what I can tell we will run across this issue with REST designs =
that need to work on both HTTP and CoAP as in the ETSI M2M case. All you =
need is a 6-8 segment path, with 3-4 query parameters and some common =
CoAP options and you hit the limit. Of course if you make the REST =
design specifically to reduce path depth with CoAP in mind you can avoid =
that, but this is not really practical in all cases.=20

Changing the 15 option limit would involve modifying that base CoAP =
header - I would really rather not do that. Or what did you have in =
mind?

Zach

>=20
> Gr=FC=DFe, Carsten
>=20

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


--Apple-Mail-437-314703339
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw
ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x
MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT
UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb
+JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH
HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh
5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW
bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud
HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu
ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL
7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb
rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW
YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO
guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn
zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz
MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk
YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg
LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx
jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e
FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT
DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe
vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7
btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB
hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE
JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9
OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD
VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw
QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1
qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS
gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu
EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy
bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW
jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx
HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC
GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEwMzEx
NDM2NDNaMCMGCSqGSIb3DQEJBDEWBBRfe210LNngF/G1+1MtOR4wWI3BjzCCAQMGCSsGAQQBgjcQ
BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp
Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd
uDANBgkqhkiG9w0BAQEFAASCAQA9irk1+jXFy8XIe9K7+RieiXq3NnQqBe+49HYdfLtLSaJpGgo+
oavHz7eOMZaYOzac/SCo7EdVJwtPkG83sTCMvKzEwflUM48r/bAAfJl0OXug5Q1EkhAzHQDfyAgt
R5JG+EvYY9PNfNVjrBW0aNgT7zUZOi45tALjpEdEFsULl8D+JQAh69No8gXhzGuBm3rnGMOx8dJV
VGprwDvn/8OTC1oN1Tz6JdKNb+rcP9qr6yoBl8iuaTC6zWrlBm3aHAfaXLMlPkD2tJWezb1Z006i
BIemNMiP6lnJej9jRj1/uThv/GW1vgVROOV55xkPw7aHI50uLj0RzBatqDSMGiwfAAAAAAAA

--Apple-Mail-437-314703339--

From cabo@tzi.org  Mon Oct 31 08:04:10 2011
Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B3721F8DC9 for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 08:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2RmLhSBW2zr for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 08:04: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 4145D21F8DBE for <core@ietf.org>; Mon, 31 Oct 2011 08:04:09 -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.3/8.14.3) with ESMTP id p9VF40Jb003247; Mon, 31 Oct 2011 16:04:00 +0100 (CET)
Received: from [192.168.217.110] (p5B3E6CBA.dip.t-dialin.net [91.62.108.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 022BB838; Mon, 31 Oct 2011 16:03:59 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <E11B69C9-4655-4E9F-828F-3E418D3A6D82@sensinode.com>
Date: Mon, 31 Oct 2011 16:03:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A287D49C-3051-4EF1-9686-3521C917390A@tzi.org>
References: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com> <230F2748-EEAF-4FC7-83E6-BDB43E29D5F3@tzi.org> <E11B69C9-4655-4E9F-828F-3E418D3A6D82@sensinode.com>
To: Zach Shelby <zach@sensinode.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: core WG <core@ietf.org>
Subject: Re: [core] Uri-Path and -Query segmentation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 15:04:10 -0000

Zach,

I think a good intro to the usual use of percent-encoding is in

	http://en.wikipedia.org/wiki/Percent-encoding

This specifically addresses the use of %2F in paths, which by the way is =
rather common in the HTTP space as in

http://www.example.com/myniceproxy/http%3A%2F%2Fwww.ietf.org/

> "Otherwise, for each segment in the <path> component, include a
>       Uri-Path Option and let that option's value be the segment (not
>       including the delimiting slash characters) after converting all
>       percent-encodings ("%" followed by two hexadecimal digits) to =
the
>       corresponding characters."
>=20
> 0x2F is special here as well, as any path that had arbitrary binary =
content would be split by 0x2F if it shows up in the octet sequence.

No, that's not what it says.  Percent decoding is after segment (what =
should be called "path component", i.e. the things between the slashes) =
splitting.

> Although placing arbitrary binary could be made to work by not =
following section 6.4 and just manually placing that content into each =
Uri-Path option, this is not at all obvious from the draft that we have =
this feature (and why) or from Section 6.

One of the problems of a spec like CoAP is that we inherit the world =
opened up by the referenced specs.
URIs have had the ability to encode binary data from the point where =
percent-encoding was introduced.
So the text of CoAP doesn't mention this, as it is not anything special.
What *is* special, is that these binary data are actually encoded in raw =
form in the protocol, and this point maybe needs to be spoken to =
explicitly.

> Also what does this mean on the server side? How does it know this is =
binary content and not a path segment?

There is no difference.  All path segments are sequences of (binary) =
bytes.
It is up to the server to structure its URI space, and if it does this =
by assigning semantics to the path segments that are based on binary =
arithmetic, more power to it.

> What happens when it combines the options back into a complete path?

It has to do the percent encoding to preserve those bytes that are not =
unreserved (section 2.3) in 3986.

I'm painfully aware that many HTTP users (read: many of my students :-) =
are not aware of the complexity of URI encoding.  This complexity is =
there, we can't reduce it, we just can try to isolate the CoAP protocol =
as much as possible from it.  I think that coap-07 succeeds rather well =
in this.  (What remains of the complexity is mostly in the HTTP mappers =
-- that's maybe why the authors of these perceive CoAP to be complex; =
when in reality it is HTTP and its URIs that are complex.)

> [=85]
> 6-8 segment path,

YMBK :-)

> Changing the 15 option limit would involve modifying that base CoAP =
header - I would really rather not do that. Or what did you have in =
mind?

See the upcoming coap-misc-09 for a strawman.  Not sure I like what I'm =
writing there, though.

Gr=FC=DFe, Carsten


From likepeng@huawei.com  Mon Oct 31 11:18:13 2011
Return-Path: <likepeng@huawei.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7F21F0CAD for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 11:18:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.997
X-Spam-Level: 
X-Spam-Status: No, score=-3.997 tagged_above=-999 required=5 tests=[AWL=-1.601, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWrwsItv5Dv3 for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 11:18:12 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 67AB21F0CA8 for <core@ietf.org>; Mon, 31 Oct 2011 11:18:12 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTY00I2Z065A6@szxga05-in.huawei.com> for core@ietf.org; Tue, 01 Nov 2011 02:18:05 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTY0069H064LB@szxga05-in.huawei.com> for core@ietf.org; Tue, 01 Nov 2011 02:18:05 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AEQ63490; Tue, 01 Nov 2011 02:18:03 +0800
Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 01 Nov 2011 02:18:00 +0800
Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.181]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0270.001; Tue, 01 Nov 2011 02:17:55 +0800
Date: Mon, 31 Oct 2011 18:17:54 +0000
From: Likepeng <likepeng@huawei.com>
In-reply-to: <031DD135F9160444ABBE3B0C36CED618D50B@011-DB3MPN1-013.MGDPHG.emi.philips.com>
X-Originating-IP: [172.24.2.40]
To: "Dijk, Esko" <esko.dijk@philips.com>, Kovatsch Matthias <kovatsch@inf.ethz.ch>, "core@ietf.org" <core@ietf.org>
Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2CF8815@szxeml525-mbs.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: [core] Status of Blockwise Transfers
Thread-index: AcyTA1LLgF2apeWtTByzRREkH8/sygEtchlQAA/NDpQ=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <55877B3AFB359744BA0F2140E36F52B51382ED5E@MBX10.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618D50B@011-DB3MPN1-013.MGDPHG.emi.philips.com>
Subject: Re: [core] Status of Blockwise Transfers
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 18:18:13 -0000

PiBPbiB5b3VyIGZpcnN0IHBvaW50LCBjb25jdXJyZW50IEJsb2NrMS9CbG9jazIgdXNhZ2UsIHRo
YXQgc2VlbXMgb25seSBhcHBsaWNhYmxlIHRvIFBPU1Qgb3IgZG9lc24ndCBpdD8NCg0KRnJvbSB0
aGUgc3BlYywgb25seSBjb25jdXJyZW50IFBPU1QgaXMgbWVudGlvbmVkLiBJbiB0aGUgU2l6ZSBl
eHRlbnNpb24gZHJhZnQsIEkgcHJvcG9zZWQgdG8gZ2V0IHRoZSByZXNvdXJjZSBzaXplIGJ5IHRo
ZSBTaXplIG9wdGlvbiwgYW5kIHVzZSBjb25jdXJyZW50IEdFVCBmb3IgYmxvY2tzLg0KaHR0cDov
L3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1saS1jb3JlLWNvYXAtc2l6ZS1vcHRpb24tMDIudHh0DQoN
CkFuZCBhbHNvIEkgcHJvcG9zZWQgdG8gbWVyZ2UgdGhlIFNpemUgZHJhZnQgYW5kIEJsb2NrIGRy
YWZ0IHRvIGFsbG93IHRoaXMsIGFuZCBhbHNvIG90aGVyIGZlYXR1cmVzLg0KDQpLaW5kIFJlZ2Fy
ZHMNCktlcGVuZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8
/sjLOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW2NvcmUtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBE
aWprLCBFc2tvIFtlc2tvLmRpamtAcGhpbGlwcy5jb21dDQq3osvNyrG85DogMjAxMcTqMTDUwjMx
yNUgMTk6MDcNCrW9OiBLb3ZhdHNjaCBNYXR0aGlhczsgY29yZUBpZXRmLm9yZw0K1vfM4jogUmU6
IFtjb3JlXSBTdGF0dXMgb2YgQmxvY2t3aXNlIFRyYW5zZmVycw0KDQpEZWFyIE1hdHRoaWFzLA0K
DQpJIGFncmVlIHdpdGggeW91ciBzZWNvbmQgcG9pbnQgdGhhdCBhIHNlcnZlciBjYW4ndCBpbiBn
ZW5lcmFsIHNlbGVjdCBhIHN0YXR1cyBjb2RlIHRvIGEgYmxvY2t3aXNlIFBPU1QuIEl0IGNvdWxk
IGJlIGVpdGhlciAyLjAxLCAyLjAyIG9yIDIuMDQsIG9yIG9uZSBvZiB0aGUgZXJyb3IgY29kZXMs
IGJ1dCB0aGlzIGRlcGVuZHMgb24gdGhlIGVudGlyZSBwYXlsb2FkIGJlaW5nIFBPU1RlZCB3aGlj
aCBpcyBvbmx5IGtub3duIGFmdGVyIHRoZSBsYXN0IGJsb2NrIChCbG9jazEpLiBQZXJoYXBzIHRo
ZSBzZXJ2ZXIgY291bGQgc2VuZCBhICJtb3N0IGxpa2VseSB0byBoYXBwZW4iIHJlc3BvbnNlIGNv
ZGUuIFRoaXMgaXMgb2theSBzaW5jZSBvbmx5IHRoZSBmaW5hbCByZXNwb25zZSBzdGF0dXMgY29k
ZSAod2hlcmUgTSBiaXQgMCBpbiB0aGUgQmxvY2sxIG9wdGlvbikgYWN0dWFsbHkgY2FycmllcyB0
aGUgcmVzdWx0IG9mIHRoZSBSRVNUIG9wZXJhdGlvbiAgLSBzZWUgc3RyaW5nICJmaW5hbCByZXNw
b25zZSIgaW4gdGhlIHRleHQuDQoNClRoZSBjdXJyZW50IHNwZWMgc2VlbXMgdG8gYWxyZWFkeSB0
YWtlIHRoaXMgIm1vc3QgbGlrZWx5IHRvIGhhcHBlbiIgbWVhbmluZyBmb3IgdGhlIHN0YXR1cyBj
b2RlIGluIHRoZSBleGFtcGxlcywgZS5nLiBibG9ja3dpc2UgUFVUIHJldHVybnMgMi4wNCBlYWNo
IHRpbWUgYnV0IGlmIGEgYmxvY2sgaXMgbWlzc2luZyB0aGUgZmluYWwgcmVzdWx0IGNvdWxkIHN0
aWxsIGJlIDIuMDQgb3IgNC4wMCBvciA0LjA4LiBQT1NUIGNvdWxkIGRvIHRoZSBzYW1lPw0KDQpP
biB5b3VyIGZpcnN0IHBvaW50LCBjb25jdXJyZW50IEJsb2NrMS9CbG9jazIgdXNhZ2UsIHRoYXQg
c2VlbXMgb25seSBhcHBsaWNhYmxlIHRvIFBPU1Qgb3IgZG9lc24ndCBpdD8gSXQgc2VlbXMgbG9n
aWNhbCB0byBtZSB0aGF0IHRoZSBzZXJ2ZXIgY2FuIG9ubHkgc3RhcnQgc2VuZGluZyBhIGJsb2Nr
d2lzZSByZXNwb25zZSBiYWNrICh1c2luZyBCbG9jazIpIHdoZW4gdGhlIGZ1bGwgcGF5bG9hZCB0
byBQT1NUIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gdGhlIGNsaWVudCAod2hvIHVzZXMgQmxvY2sx
IGFuZCBzaW11bHRhbmVvdXNseSBlbXB0eSBCbG9jazIgdG8gaW5kaWNhdGUgc2l6ZSkgYW5kIHBy
b2Nlc3NlZC4gRm9yIHRoaXMgdGV4dCBhbmQvb3IgZXhhbXBsZXMgYXJlIG5lZWRlZCBpbiBteSB2
aWV3Lg0KDQpyZWdhcmRzLA0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv
bTogY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBP
biBCZWhhbGYgT2YgS292YXRzY2ggTWF0dGhpYXMNClNlbnQ6IFR1ZXNkYXkgMjUgT2N0b2JlciAy
MDExIDEzOjAwDQpUbzogQ2Fyc3RlbiBCb3JtYW5uOyBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBb
Y29yZV0gU3RhdHVzIG9mIEJsb2Nrd2lzZSBUcmFuc2ZlcnMNCg0KRGVhciBDYXJzdGVuDQoNCkkg
d291bGQgbGlrZSB0byBhc2sgYWJvdXQgdGhlIGN1cnJlbnQgc3RhdHVzIG9mIGJsb2Nrd2lzZSB0
cmFuc2ZlcnM6DQoNCi0gQ29uY3VycmVudCB1c2FnZSBvZiBCbG9jazEgYW5kIEJsb2NrMiBpbiBh
IHNpbmdsZSBvcGVyYXRpb24NCiAgY29yZS1ibG9jay0wNCBtZW50aW9ucyBpdCBvbmNlLCBidXQg
ZG9lcyBub3Qgc3BlY2lmeSBob3cgdG8gaGFuZGxlIGl0IG9yIGdpdmUgYW4gZXhhbXBsZSAoSSBn
dWVzcywgYSBQT1NUIHJlcXVlc3Qga2VlcHMgdGhlIEJsb2NrMSBvcHRpb24gd2l0aCBNPTAgYW5k
IG5vIHBheWxvYWQgdW50aWwgYWxsIEJsb2NrMiBibG9ja3Mgd2VyZSByZXF1ZXN0ZWQ/KS4NCg0K
LSBVc2luZyBTdGF0dXMgY29kZXMgYmVmb3JlIGFuIGF0b21pYyBCbG9jazEgdHJhbnNmZXIgaXMg
Y29tcGxldGUNCiAgQSBQT1NUIGNvdWxkIHJlc3VsdCBpbiBkaWZmZXJlbnQgYWN0aW9ucywgdGh1
cyB0aGUgc2VydmVyIGNhbm5vdCBwcm92aWRlIGl0IGJlZm9yZSB0aGUgbGFzdCBCbG9jazEgcmVx
dWVzdC4gU2hvdWxkbid0IHRoZSBzdGF0dXMgYmUgZW1wdHkgIHdoZW4gTT0wIGluIGEgQmxvY2sx
IHJlc3BvbnNlPw0KDQpUaGFua3MgYSBsb3QNCk1hdHRoaWFzDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0
Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp
biB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQg
dW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3Ig
dGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg
eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1p
bmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hp
Yml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl
Y2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBk
ZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0K
Y29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Jl

From kovatsch@inf.ethz.ch  Mon Oct 31 11:19:57 2011
Return-Path: <kovatsch@inf.ethz.ch>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8F621F8C11 for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 11:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6zkyFMkSfXd for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 11:19:56 -0700 (PDT)
Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 48BA221F8BD7 for <core@ietf.org>; Mon, 31 Oct 2011 11:19:54 -0700 (PDT)
Received: from CAS21.d.ethz.ch (172.31.51.111) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 31 Oct 2011 19:19:31 +0100
Received: from MBX10.d.ethz.ch ([169.254.1.192]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.01.0339.001; Mon, 31 Oct 2011 19:19:31 +0100
From: "Kovatsch  Matthias" <kovatsch@inf.ethz.ch>
To: Zach Shelby <zach@sensinode.com>
Thread-Topic: [core] Uri-Path and -Query segmentation
Thread-Index: AQHMjLjS/ofJNSdxiUOxYl1BuGovnpWAd43fgALCJQCAE5jGQA==
Date: Mon, 31 Oct 2011 18:19:31 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B513832FCF@MBX10.d.ethz.ch>
References: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com> <87lisj245y.fsf@tzi.org> <0B4C70B5-D29B-468F-8A67-8D5BEB2A5B03@sensinode.com>
In-Reply-To: <0B4C70B5-D29B-468F-8A67-8D5BEB2A5B03@sensinode.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [70.102.96.7]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: core WG <core@ietf.org>
Subject: Re: [core] Uri-Path and -Query segmentation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 18:19:57 -0000

Hi

What about introducing the general rule that when all bits of a length/coun=
t field are ones, another byte is following, whose value is added (so there=
 might be multiple bytes following, allowing sizes > 270).
No memmove for concatenation would be required. Also, we would not have any=
 length limitations, which almost always turned out bad for other systems i=
n the past.
For the option count, we now saw that 15 might be too low. Even when URI-Pa=
th and -Query become singletons again, we might have something similar to t=
he HTTP X-headers in the future. Hopefully, the unlikeliness of 15 options =
so far does not break compatibility with the current base CoAP header (Cars=
ten, I could not find coap-misc-09 to see what is said in there...).
Maybe the additional OC bytes should come after the 4 bytes base header, as=
 many might use the constant length 4 in their implementations...

I think length the limitations are bad if we want CoAP to be future proof.

Best regards
Matthias

From kovatsch@inf.ethz.ch  Mon Oct 31 12:24:33 2011
Return-Path: <kovatsch@inf.ethz.ch>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD9511E80CB for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 12:24:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZbcpi3hsHrD for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 12:24:33 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7963811E80BD for <core@ietf.org>; Mon, 31 Oct 2011 12:24:31 -0700 (PDT)
Received: from CAS12.d.ethz.ch (172.31.38.212) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 31 Oct 2011 20:24:29 +0100
Received: from MBX10.d.ethz.ch ([169.254.1.192]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.01.0339.001; Mon, 31 Oct 2011 20:24:30 +0100
From: "Kovatsch  Matthias" <kovatsch@inf.ethz.ch>
To: Likepeng <likepeng@huawei.com>, "Dijk, Esko" <esko.dijk@philips.com>, "core@ietf.org" <core@ietf.org>
Thread-Topic: [core] Status of Blockwise Transfers
Thread-Index: AcyTA1LLgF2apeWtTByzRREkH8/sygEtchlQAA/NDpQAAOAYEA==
Date: Mon, 31 Oct 2011 19:24:29 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B513833019@MBX10.d.ethz.ch>
References: <55877B3AFB359744BA0F2140E36F52B51382ED5E@MBX10.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618D50B@011-DB3MPN1-013.MGDPHG.emi.philips.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2CF8815@szxeml525-mbs.china.huawei.com>
In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F2CF8815@szxeml525-mbs.china.huawei.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [70.102.96.7]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [core] Status of Blockwise Transfers
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 19:24:33 -0000

Thanks for the responses!

> > The current spec seems to already take this "most likely to happen" mea=
ning
> > for the status code in the examples, e.g. blockwise PUT returns 2.04 ea=
ch
> > time but if a block is missing the final result could still be 2.04 or =
4.00 or 4.08.
> > POST could do the same?

But what is most likely to happen?
The author of the server implementations will just arbitrarily pick a statu=
s code, which still has no meaning.
A badly written client then might misinterpret that intermediate status. I =
think, it only creates a source of errors.

> > On your first point, concurrent Block1/Block2 usage, that seems only ap=
plicable to POST or doesn't it?
> From the spec, only concurrent POST is mentioned.

Yes, that is how I understand it as well. A successful PUT would always res=
ults in resource state, i.e., no payload in the response.

> In the Size extension draft, I proposed to get the resource size by the S=
ize option, and use concurrent GET for blocks.
> http://www.ietf.org/id/draft-li-core-coap-size-option-02.txt

I would say an upper bound (sz attribute) is enough. Embedded devices usual=
ly avoid dynamic memory allocation and those which use it probably have ple=
nty of memory from a CoRE point of view.
For the concurrent GETs, one should be careful not to re-invent/implement T=
CP (sliding window for messages in flight), I guess. If it is required, the=
 devices should rather switch to another protocol, shouldn't they?
I also saw that even for the server it can be hard to know the exact size i=
n advance. With content-negotiation, the representation is created on-the-f=
ly from some variables. When including on-demand sensor readings, the serve=
r cannot even do a "dry run" to pre-cache the sizes for each content-type.

Best regards
Matthias


From Akbar.Rahman@InterDigital.com  Mon Oct 31 12:25:44 2011
Return-Path: <Akbar.Rahman@InterDigital.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342AA11E80CB for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 12:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level: 
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcs2xrdBakUF for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 12:25:43 -0700 (PDT)
Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9223411E80BD for <core@ietf.org>; Mon, 31 Oct 2011 12:25:43 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 31 Oct 2011 15:25:42 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 31 Oct 2011 15:25:40 -0400
Message-ID: <D60519DB022FFA48974A25955FFEC08C04282D4E@SAM.InterDigital.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: I-D Action: draft-castellani-core-http-mapping-02.txt
Thread-index: AcyXxcCkFmyKarotTIq10gJ7M+7/kQAOHrAg
From: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>
To: <core@ietf.org>
X-OriginalArrivalTime: 31 Oct 2011 19:25:42.0739 (UTC) FILETIME=[E17E0230:01CC9802]
Subject: [core] FW: I-D Action: draft-castellani-core-http-mapping-02.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 19:25:44 -0000

Hi,


We have done an update of our I-D to cover:

- HTTP to CoAP mapping details for the following features:
	- Cache Refresh via Observe
	- Use of CoAP blockwise transfer
	- Multicast response caching

- New section on CoAP to HTTP mapping


We would appreciate if the WG could review and provide us any feedback.


Sincerely,


Akbar


-----Original Message-----
From: i-d-announce-bounces@ietf.org
[mailto:i-d-announce-bounces@ietf.org] On Behalf Of
internet-drafts@ietf.org
Sent: Monday, October 31, 2011 8:08 AM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-castellani-core-http-mapping-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Best practices for HTTP-CoAP mapping
implementation
	Author(s)       : Angelo P. Castellani
                          Salvatore Loreto
                          Akbar Rahman
                          Thomas Fossati
                          Esko Dijk
	Filename        : draft-castellani-core-http-mapping-02.txt
	Pages           : 34
	Date            : 2011-10-31

   This draft aims at being a base reference documentation for HTTP-CoAP
   proxy implementors.  It details deployment options, discusses
   possible approaches for URI mapping, and provides useful
   considerations related to protocol translation.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-castellani-core-http-mapping-0
2.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-castellani-core-http-mapping-02
.txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From sarikaya2012@gmail.com  Mon Oct 31 12:26:39 2011
Return-Path: <sarikaya2012@gmail.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C5311E8154 for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 12:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.428
X-Spam-Level: 
X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.170,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moeH1exNGS8N for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 12:26:39 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 241AA11E8157 for <core@ietf.org>; Mon, 31 Oct 2011 12:26:39 -0700 (PDT)
Received: by ywt2 with SMTP id 2so7466108ywt.31 for <core@ietf.org>; Mon, 31 Oct 2011 12:26:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=WMv2pq73Ph3WaNvP1/S/msvbCjCqHbdYRF82oAT/SFs=; b=qu4W2IvEcZ9h5vbA/UorlnIElRtSjW0uh9gZ4qeWKwrNBn10q61p6+TBjggtYoOKT8 inX+ABBebfwjt0yBZRMnPzxJ13qILLeppSQSf4QHBaYhbaHEihypefIKLLQq0GcdbXDg aVeMKpD5J+HeSkUkgApCMZFyZHjyZf0qHOdxk=
MIME-Version: 1.0
Received: by 10.236.76.136 with SMTP id b8mr19200875yhe.9.1320089198723; Mon, 31 Oct 2011 12:26:38 -0700 (PDT)
Received: by 10.236.110.39 with HTTP; Mon, 31 Oct 2011 12:26:38 -0700 (PDT)
In-Reply-To: <20111031192458.20468.45270.idtracker@ietfa.amsl.com>
References: <20111031192458.20468.45270.idtracker@ietfa.amsl.com>
Date: Mon, 31 Oct 2011 14:26:38 -0500
Message-ID: <CAC8QAce5BewdfWWUr5v0WFwN5-dozXVhC4t7mYvqaF4SitdnvQ@mail.gmail.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: core@ietf.org
Content-Type: multipart/alternative; boundary=20cf300fad0fc300e704b09d37bb
Subject: [core] Fwd: New Version Notification for draft-sarikaya-core-sbootstrapping-03.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 19:26:39 -0000

--20cf300fad0fc300e704b09d37bb
Content-Type: text/plain; charset=ISO-8859-1

A new version of I-D, draft-sarikaya-core-sbootstrapping-03.txt has been
successfully submitted by Behcet Sarikaya and posted to the IETF repository.

Filename:        draft-sarikaya-core-sbootstrapping
Revision:        03
Title:           Security Bootstrapping of Resource-Constrained Devices
Creation date:   2011-10-31
WG ID:           Individual Submission
Number of pages: 27

Abstract:
  This document describes how to initially configure the network of
  resource constrained nodes securely, a.k.a., security bootstrapping.
  Bootstrapping architecture, communication channel and bootstrap
  security methods are described.  System level objectives for security
  bootstrapping are stated followed by the protocols that can be used.
  Requirements on these protocols to be used as security bootstrapping
  protocols are identified.




The IETF Secretariat

--20cf300fad0fc300e704b09d37bb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote"><br>A new version of I-D, draft-sarikaya=
-core-sbootstrapping-03.txt has been successfully submitted by Behcet Sarik=
aya and posted to the IETF repository.<br>
<br>
Filename: =A0 =A0 =A0 =A0draft-sarikaya-core-sbootstrapping<br>
Revision: =A0 =A0 =A0 =A003<br>
Title: =A0 =A0 =A0 =A0 =A0 Security Bootstrapping of Resource-Constrained D=
evices<br>
Creation date: =A0 2011-10-31<br>
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission<br>
Number of pages: 27<br>
<br>
Abstract:<br>
 =A0 This document describes how to initially configure the network of<br>
 =A0 resource constrained nodes securely, a.k.a., security bootstrapping.<b=
r>
 =A0 Bootstrapping architecture, communication channel and bootstrap<br>
 =A0 security methods are described. =A0System level objectives for securit=
y<br>
 =A0 bootstrapping are stated followed by the protocols that can be used.<b=
r>
 =A0 Requirements on these protocols to be used as security bootstrapping<b=
r>
 =A0 protocols are identified.<br>
<br>
<br>
<br>
<br>
The IETF Secretariat<br>
</div><br>

--20cf300fad0fc300e704b09d37bb--

From zach@sensinode.com  Mon Oct 31 13:46:33 2011
Return-Path: <zach@sensinode.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD8511E8215 for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 13:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bzv1zzi2JKqq for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 13:46:33 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9348D1F0C8B for <core@ietf.org>; Mon, 31 Oct 2011 13:46:20 -0700 (PDT)
Received: from [192.168.1.102] (178-55-45-148.bb.dnainternet.fi [178.55.45.148]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id p9VKkEKq002645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 Oct 2011 22:46:15 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-480-336873982; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby <zach@sensinode.com>
In-Reply-To: <A287D49C-3051-4EF1-9686-3521C917390A@tzi.org>
Date: Mon, 31 Oct 2011 22:46:13 +0200
Message-Id: <6F095FCB-09CE-4D8D-B65D-1353F0F4F917@sensinode.com>
References: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com> <230F2748-EEAF-4FC7-83E6-BDB43E29D5F3@tzi.org> <E11B69C9-4655-4E9F-828F-3E418D3A6D82@sensinode.com> <A287D49C-3051-4EF1-9686-3521C917390A@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.1084)
Cc: core WG <core@ietf.org>
Subject: Re: [core] Uri-Path and -Query segmentation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 20:46:34 -0000

--Apple-Mail-480-336873982
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Carsten,

Thanks, that helped clarify the issue. Now even RPL doesn't seem all =
that complicated :-) I was confused by the term "binary data", and you =
meant percent-encoded data. I suggest we let this ticket rest for now, =
and do some more homework in Taipei.=20

Just a few more questions on this for now:=20

- It seems to me that UTF-8 is what is causing the need for splitting =
the segments. If the percent encoding would stay un-touched we would be =
fine, or does that move the normalization problem to the server? Of =
course percent-encoding is less efficient over the air than UTF-8.

- If "/" is the only character that is a problem in the Uri-Path, =
couldn't we just keep representing that as %2F?=20

- As we are defining the coap(s):// scheme, couldn't we have done =
anything more to limit our exposure to this problem?

Zach


On Oct 31, 2011, at 5:03 PM, Carsten Bormann wrote:

> Zach,
>=20
> I think a good intro to the usual use of percent-encoding is in
>=20
> 	http://en.wikipedia.org/wiki/Percent-encoding
>=20
> This specifically addresses the use of %2F in paths, which by the way =
is rather common in the HTTP space as in
>=20
> http://www.example.com/myniceproxy/http%3A%2F%2Fwww.ietf.org/
>=20
>> "Otherwise, for each segment in the <path> component, include a
>>      Uri-Path Option and let that option's value be the segment (not
>>      including the delimiting slash characters) after converting all
>>      percent-encodings ("%" followed by two hexadecimal digits) to =
the
>>      corresponding characters."
>>=20
>> 0x2F is special here as well, as any path that had arbitrary binary =
content would be split by 0x2F if it shows up in the octet sequence.
>=20
> No, that's not what it says.  Percent decoding is after segment (what =
should be called "path component", i.e. the things between the slashes) =
splitting.
>=20
>> Although placing arbitrary binary could be made to work by not =
following section 6.4 and just manually placing that content into each =
Uri-Path option, this is not at all obvious from the draft that we have =
this feature (and why) or from Section 6.
>=20
> One of the problems of a spec like CoAP is that we inherit the world =
opened up by the referenced specs.
> URIs have had the ability to encode binary data from the point where =
percent-encoding was introduced.
> So the text of CoAP doesn't mention this, as it is not anything =
special.
> What *is* special, is that these binary data are actually encoded in =
raw form in the protocol, and this point maybe needs to be spoken to =
explicitly.
>=20
>> Also what does this mean on the server side? How does it know this is =
binary content and not a path segment?
>=20
> There is no difference.  All path segments are sequences of (binary) =
bytes.
> It is up to the server to structure its URI space, and if it does this =
by assigning semantics to the path segments that are based on binary =
arithmetic, more power to it.
>=20
>> What happens when it combines the options back into a complete path?
>=20
> It has to do the percent encoding to preserve those bytes that are not =
unreserved (section 2.3) in 3986.
>=20
> I'm painfully aware that many HTTP users (read: many of my students =
:-) are not aware of the complexity of URI encoding.  This complexity is =
there, we can't reduce it, we just can try to isolate the CoAP protocol =
as much as possible from it.  I think that coap-07 succeeds rather well =
in this.  (What remains of the complexity is mostly in the HTTP mappers =
-- that's maybe why the authors of these perceive CoAP to be complex; =
when in reality it is HTTP and its URIs that are complex.)
>=20
>> [=85]
>> 6-8 segment path,
>=20
> YMBK :-)
>=20
>> Changing the 15 option limit would involve modifying that base CoAP =
header - I would really rather not do that. Or what did you have in =
mind?
>=20
> See the upcoming coap-misc-09 for a strawman.  Not sure I like what =
I'm writing there, though.
>=20
> Gr=FC=DFe, Carsten
>=20

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


--Apple-Mail-480-336873982
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw
ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x
MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT
UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb
+JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH
HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh
5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW
bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud
HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu
ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL
7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb
rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW
YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO
guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn
zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz
MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk
YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg
LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx
jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e
FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT
DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe
vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7
btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB
hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE
JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9
OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD
VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw
QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1
qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS
gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu
EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy
bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW
jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx
HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC
GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEwMzEy
MDQ2MTRaMCMGCSqGSIb3DQEJBDEWBBTyfXR/4C9PB0nhZerRy/kEyV9rmDCCAQMGCSsGAQQBgjcQ
BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp
Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd
uDANBgkqhkiG9w0BAQEFAASCAQCSD58Pm7Md1GUAaRdJkEqUFn1tYa6Tu/Q9FpU6KPiUEJ7qXR2Z
7S0KMB3v8RJfpEelAXMVYnTRw3dBz2USUU4ewKSrR7ySyx2/kW/H7LkZxOekUq5pRsdYDTKh8Y+F
VihFNWVz5voMCOhHfDyvLe9MNg0I2DlDoJeswOiy3njDP8R5+x0c47h81Dygt6Yf1hDxTFxIn/LF
XWFjCc7PFflp5vq9TwLqSuAkTbGGGkLpsfmpWNGxxMcO9ObatmqxRmEZzKgk1EXkJBXgdppo3kTN
Vpt8VQg1Ma59AmtVSWJKPh57QMvamCYS1Y7XzTtmrglfJkU8q1od0evgd68p4QnSAAAAAAAA

--Apple-Mail-480-336873982--

From internet-drafts@ietf.org  Mon Oct 31 15:12:35 2011
Return-Path: <internet-drafts@ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22221F0C9E; Mon, 31 Oct 2011 15:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Level: 
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcwHB4KWCbey; Mon, 31 Oct 2011 15:12:35 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FCE1F0C3D; Mon, 31 Oct 2011 15:12:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.62
Message-ID: <20111031221235.31139.82654.idtracker@ietfa.amsl.com>
Date: Mon, 31 Oct 2011 15:12:35 -0700
Cc: core@ietf.org
Subject: [core] I-D Action: draft-ietf-core-coap-08.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 22:12:36 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Constrained RESTful Environments Work=
ing Group of the IETF.

	Title           : Constrained Application Protocol (CoAP)
	Author(s)       : Zach Shelby
                          Klaus Hartke
                          Carsten Bormann
                          Brian Frank
	Filename        : draft-ietf-core-coap-08.txt
	Pages           : 88
	Date            : 2011-10-31

   This document specifies the Constrained Application Protocol (CoAP),
   a specialized web transfer protocol for use with constrained networks
   and nodes for machine-to-machine applications such as smart energy
   and building automation.  These constrained nodes often have 8-bit
   microcontrollers with small amounts of ROM and RAM, while networks
   such as 6LoWPAN often have high packet error rates and a typical
   throughput of 10s of kbit/s.  CoAP provides a method/response
   interaction model between application end-points, supports built-in
   resource discovery, and includes key web concepts such as URIs and
   content-types.  CoAP easily translates to HTTP for integration with
   the web while meeting specialized requirements such as multicast
   support, very low overhead and simplicity for constrained
   environments.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-core-coap-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-coap-08.txt

From cabo@tzi.org  Mon Oct 31 15:22:24 2011
Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E681F0D11 for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 15:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.099
X-Spam-Level: 
X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwOknOYGABm9 for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 15:22:23 -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 BFAA51F0D05 for <core@ietf.org>; Mon, 31 Oct 2011 15:22:22 -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.3/8.14.3) with ESMTP id p9VMMEXZ016775; Mon, 31 Oct 2011 23:22:14 +0100 (CET)
Received: from [192.168.217.110] (p54899E2D.dip.t-dialin.net [84.137.158.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 19A93A05; Mon, 31 Oct 2011 23:22:14 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B513832FCF@MBX10.d.ethz.ch>
Date: Mon, 31 Oct 2011 23:22:13 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4717BEE9-6A0B-4488-BA81-E4875372CEF9@tzi.org>
References: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com> <87lisj245y.fsf@tzi.org> <0B4C70B5-D29B-468F-8A67-8D5BEB2A5B03@sensinode.com> <55877B3AFB359744BA0F2140E36F52B513832FCF@MBX10.d.ethz.ch>
To: "Kovatsch  Matthias" <kovatsch@inf.ethz.ch>
X-Mailer: Apple Mail (2.1251.1)
Cc: core WG <core@ietf.org>
Subject: Re: [core] Uri-Path and -Query segmentation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 22:22:24 -0000

On Oct 31, 2011, at 19:19, Kovatsch Matthias wrote:

> (Carsten, I could not find coap-misc-09 to see what is said in =
there...).

Fixed:

	http://tools.ietf.org/html/draft-bormann-coap-misc-09#section-2

Gr=FC=DFe, Carsten


From zach@sensinode.com  Mon Oct 31 15:54:00 2011
Return-Path: <zach@sensinode.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FC511E8348 for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 15:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fttfTu-ESPya for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 15:53:59 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 44C4111E8341 for <core@ietf.org>; Mon, 31 Oct 2011 15:53:59 -0700 (PDT)
Received: from [192.168.1.102] (178-55-45-148.bb.dnainternet.fi [178.55.45.148]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id p9VMruN1009868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <core@ietf.org>; Tue, 1 Nov 2011 00:53:57 +0200
From: Zach Shelby <zach@sensinode.com>
Content-Type: multipart/signed; boundary=Apple-Mail-491-344535551; protocol="application/pkcs7-signature"; micalg=sha1
Date: Tue, 1 Nov 2011 00:53:55 +0200
References: <20111031225230.14976.90114.idtracker@ietfa.amsl.com>
To: core WG <core@ietf.org>
Message-Id: <237C5236-C5E4-44B1-845B-DD8346564855@sensinode.com>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [core] Fwd: New Version Notification for draft-shelby-core-resource-directory-02.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 22:54:00 -0000

--Apple-Mail-491-344535551
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

A new version of the Resource Directory draft is now available:

http://www.ietf.org/id/draft-shelby-core-resource-directory-02.txt

   Changes from -01 to -02:

      o Added a terminology section.

      o Changed the inclusing of an Etag in registration or update to a
      MAY.

      o Added the concept of an RD domain and a registration parameter
      for it.

      o Recommended the Location returned from a registration to be
      stable, allowing for end-point and domain information to be
      changed during updates.

      o Changed the lookup interface to accept end-point and domain as
      query string parameters to control the scope of a lookup.

Zach

Begin forwarded message:

> From: internet-drafts@ietf.org
> Date: November 1, 2011 12:52:30 AM GMT+02:00
> To: zach@sensinode.com
> Cc: srdjan.krco@ericsson.com, zach@sensinode.com
> Subject: New Version Notification for =
draft-shelby-core-resource-directory-02.txt
>=20
> A new version of I-D, draft-shelby-core-resource-directory-02.txt has =
been successfully submitted by Zach Shelby and posted to the IETF =
repository.
>=20
> Filename:	 draft-shelby-core-resource-directory
> Revision:	 02
> Title:		 CoRE Resource Directory
> Creation date:	 2011-11-01
> WG ID:		 Individual Submission
> Number of pages: 19
>=20
> Abstract:
>   In many M2M scenarios, direct discovery of resources is not =
practical
>   due to sleeping nodes, disperse networks, or networks where =
multicast
>   traffic is inefficient.  These problems can be solved by employing =
an
>   entity called a Resource Directory (RD), which hosts descriptions of
>   resources held on other servers, allowing lookups to be performed =
for
>   those resources.  This document specifies the web interfaces that a
>   Resource Directory supports in order for web servers to discover the
>   RD and to registrer, maintain, lookup and remove resources
>   descriptions.  Furthermore, new link attributes useful in =
conjunction
>   with an RD are defined.
>=20
>=20
>=20
>=20
> The IETF Secretariat

--=20
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297


--Apple-Mail-491-344535551
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCBWMw
ggRLoAMCAQICEHOCkw2jxZ3D/33R5ncHHbgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTAwMDAwMDBaFw0x
MjEwMDkyMzU5NTlaMIIBEDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRQwEgYDVQQDFAtaYWNoIFNoZWxieTEhMB8GCSqGSIb3DQEJARYSemFjaEBzZW5zaW5vZGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzhUEvdReCaejkXy7oHgfRykbzYKT
UVdKPk27VuoqRENDsQvOx+7PedUCyaXF1CUyzY5/QI+8lRyPEdyctsqAKTb1Pp0Bx0zgpsSHrFVb
+JTLLEI4rKJ2KogmzXar3FQow+819WT0tIC7QIwma6m6N2MpxVGXd6VGTidqshi7ZfvyDwUh1BuH
HYgn8/fgTAvCFJoLD6asYUZ/AKreqDD7lwyjPZG5AfoaXPilBzuVIGArLCcYvaWSlMpntokmU5oh
5AjZX8Wmg32rxYnCy6NCGyoQHq1iQTnleH0eUcbvG5fTGDnOs1scoHHKeZ6meyFFDAc/d2KJJ8zW
bEKU2MalcQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAGA1Ud
HwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0lu
ZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATFvGnK8aGE+tObyxTKI5EzlL
7RKS5iH7fQ0DIdLXNTph4XZL1kLxp3LIwsm2+UsptMhtk7nXT8sWgiH8pugbYUZQl/pZZeTbcqGb
rPpWTQg1jqXNo0nZJG1jvgGyuA4ozmSiD6frU/s58cUCwNdmPK41lunpS4KyLbgw7vQZCwrb0RGW
YkCrVds9CtncAlcHROFAuuNsgrN6GX+VEsfqw+u+eOVIMaAVKfXqfquuLp/p41HgkDC6onA2biaO
guxLuH/fAhIwSNe8TBS/bYMTF8yROSxn0mnNryhMOZTsqt4R0XEgXxyNpPIgRmrg3DgnqldFWDPn
zHHOQRx73R3fXTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw
gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQz
MDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk
YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg
LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mx
jUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+e
FBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAAT
DdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRe
vsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7
btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgB
hvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYj
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG
AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE
JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9
OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD
VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUw
QwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1
qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HS
gZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWu
EnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yy
bUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUW
jMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx
HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcduDAJBgUrDgMC
GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEwMzEy
MjUzNTVaMCMGCSqGSIb3DQEJBDEWBBSUKKfmYwYt4KIS7iGko7YH42mdajCCAQMGCSsGAQQBgjcQ
BDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt
IEczAhBzgpMNo8Wdw/990eZ3Bx24MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYT
AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNp
Z24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQc4KTDaPFncP/fdHmdwcd
uDANBgkqhkiG9w0BAQEFAASCAQC8i4L0q0q3Q5AfUzyW59bG5UNPTxyJFH92rutZp2jgk0Q3TeAX
8srWMlB5mzftFvdgLB+fzIH1+wPc02G91uKIRDom5aalDxVHEqiNWdAE1kVimtqB5qHGTAGCWttm
Vq3M++wh9XrEwV1m+BQegYs0XPe59G2OWGM1ToxBAgN8JdFD8XaIAA2CU/l97qY6sp9e2i8kRo4X
yQfKpyAfjI/VQL0ddl4inPLo0PZTJWDrBn0J3uuOTKi8f74JqJa0mP5wqBuH1Adyt6yV5r8GFwsI
sQqaycGtFIKjYp/3yVgM+nkTdmdoYugvdK6UoZiH0tIYf1H10yZf2Rd5ogOevP7YAAAAAAAA

--Apple-Mail-491-344535551--

From kovatsch@inf.ethz.ch  Mon Oct 31 18:28:30 2011
Return-Path: <kovatsch@inf.ethz.ch>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4987C1F0C48 for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 18:28:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClBOKNfV8jGH for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 18:28:29 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 832271F0C3B for <core@ietf.org>; Mon, 31 Oct 2011 18:28:28 -0700 (PDT)
Received: from CAS22.d.ethz.ch (172.31.51.112) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 1 Nov 2011 02:28:25 +0100
Received: from MBX10.d.ethz.ch ([169.254.1.192]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.01.0339.001; Tue, 1 Nov 2011 02:28:26 +0100
From: "Kovatsch  Matthias" <kovatsch@inf.ethz.ch>
To: Carsten Bormann <cabo@tzi.org>
Thread-Topic: [core] Uri-Path and -Query segmentation
Thread-Index: AQHMjLjS/ofJNSdxiUOxYl1BuGovnpWAd43fgALCJQCAE5jGQIAAOmaAgABAa/A=
Date: Tue, 1 Nov 2011 01:28:25 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B51383317B@MBX10.d.ethz.ch>
References: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com> <87lisj245y.fsf@tzi.org> <0B4C70B5-D29B-468F-8A67-8D5BEB2A5B03@sensinode.com> <55877B3AFB359744BA0F2140E36F52B513832FCF@MBX10.d.ethz.ch> <4717BEE9-6A0B-4488-BA81-E4875372CEF9@tzi.org>
In-Reply-To: <4717BEE9-6A0B-4488-BA81-E4875372CEF9@tzi.org>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [70.102.96.7]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: core WG <core@ietf.org>
Subject: Re: [core] Uri-Path and -Query segmentation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Nov 2011 01:28:30 -0000

> Fixed:
> 	http://tools.ietf.org/html/draft-bormann-coap-misc-09#section-2

Thanks!

> See the upcoming coap-misc-09 for a strawman.  Not sure I like what I'm w=
riting there, though.

I definitely like the opinion on the artificial limitations :)
I would, however, vote for a consistent rule, as described in my previous m=
ail: "all ones -> additional length/count byte following" (with arbitrarily=
 many additional length/count bytes). Also in preference over the more effi=
cient 2-byte solution of Figure 5.

Best regards
Matthias

From cabo@tzi.org  Mon Oct 31 22:47:30 2011
Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DEE11E812F for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 22:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.149
X-Spam-Level: 
X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7J-ufWaod+h for <core@ietfa.amsl.com>; Mon, 31 Oct 2011 22:47:30 -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 E051611E8098 for <core@ietf.org>; Mon, 31 Oct 2011 22:47:29 -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.3/8.14.3) with ESMTP id pA15lLVZ009533; Tue, 1 Nov 2011 06:47:21 +0100 (CET)
Received: from [192.168.217.112] (p54899E2D.dip.t-dialin.net [84.137.158.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E7007A37; Tue,  1 Nov 2011 06:47:20 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B51383317B@MBX10.d.ethz.ch>
Date: Tue, 1 Nov 2011 06:47:19 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D52C7D9-8C05-4A31-BE27-B490575E514A@tzi.org>
References: <DC8A2BB3-BB27-4E78-860C-69DB93AC5A22@sensinode.com> <87lisj245y.fsf@tzi.org> <0B4C70B5-D29B-468F-8A67-8D5BEB2A5B03@sensinode.com> <55877B3AFB359744BA0F2140E36F52B513832FCF@MBX10.d.ethz.ch> <4717BEE9-6A0B-4488-BA81-E4875372CEF9@tzi.org> <55877B3AFB359744BA0F2140E36F52B51383317B@MBX10.d.ethz.ch>
To: "Kovatsch  Matthias" <kovatsch@inf.ethz.ch>
X-Mailer: Apple Mail (2.1251.1)
Cc: core WG <core@ietf.org>
Subject: Re: [core] Uri-Path and -Query segmentation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Nov 2011 05:47:30 -0000

> I definitely like the opinion on the artificial limitations :)

Indeed, this should now be common knowledge about system (and protocol) =
design.
The interesting question is where the "painless" threshold is.

> I would, however, vote for a consistent rule, as described in my =
previous mail: "all ones -> additional length/count byte following" =
(with arbitrarily many additional length/count bytes). Also in =
preference over the more efficient 2-byte solution of Figure 5.

Ah, you are a fan of unary encoding (base 255) :-)

Re the number of options, I now have yet another proposal (too late for =
the draft deadline):

2.1.4.  Alternative: Going to a delimiter model

   Another alternative is to spend the additional byte not as an
   extended count, but as an option terminator.

   In this proposal setting OC to 15 means that the number of options is
   no longer given explicitly.  Instead, the sequence of options is
   terminated by a byte with a special interpretation, 0xF0.  (Note that
   the option _delta_ of 15 is made special, not any specific option
   number.)  The next byte is then the first byte of the payload.

     0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver| T |  15   |      Code     |          Message ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 0 0 0 0|   Payload (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 5: Option Terminator for CoAP Messages with 15+ options

   (It is to be decided whether 0xF0 is made special only for OC=3D15,
   i.e. if it retains its meaning of (option delta =3D 15, option length =
=3D
   0) for other values of OC.)


Of the alternatives, I hate this one the least so far.

Gr=FC=DFe, Carsten