Re: [core] Last Call: <draft-ietf-core-coap-14.txt> (Constrained Application Protocol (CoAP)) to Proposed Standard

Carsten Bormann <cabo@tzi.org> Tue, 26 March 2013 23:35 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35ED921F858B for <ietf@ietfa.amsl.com>; Tue, 26 Mar 2013 16:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.008
X-Spam-Level:
X-Spam-Status: No, score=-106.008 tagged_above=-999 required=5 tests=[AWL=0.241, 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 294BXe-97i2Q for <ietf@ietfa.amsl.com>; Tue, 26 Mar 2013 16:35:04 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6D921F854D for <ietf@ietf.org>; Tue, 26 Mar 2013 16:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2QNZ1XK017426; Wed, 27 Mar 2013 00:35:01 +0100 (CET)
Received: from [192.168.217.105] (p54893BDF.dip.t-dialin.net [84.137.59.223]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 752063C4D; Wed, 27 Mar 2013 00:35:00 +0100 (CET)
Subject: Re: [core] Last Call: <draft-ietf-core-coap-14.txt> (Constrained Application Protocol (CoAP)) to Proposed Standard
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset="iso-8859-1"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <5147B789.2070301@tanu.org>
Date: Wed, 27 Mar 2013 00:34:58 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B10CE01-A1BE-4BF2-AA72-A8D2D5FBEBAD@tzi.org>
References: <20130313184125.20160.19265.idtracker@ietfa.amsl.com> <5147B789.2070301@tanu.org>
To: Shoichi Sakane <sakane@tanu.org>
X-Mailer: Apple Mail (2.1503)
Cc: ietf <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2013 23:35:05 -0000

Hi Shoichi,

On Mar 19, 2013, at 01:55, Shoichi Sakane <sakane@tanu.org> wrote:

> And, the length of URI is likely to be bigger than the MTU.
> 
> Do you assume a use case in which the total length of options is going
> to be greater than the MTU ?

CoAP has been designed for constrained devices, and networks built out of these devices (constrained node networks, draft-ietf-lwig-terminology).

In REST, servers can structure their URIs in a way that is appropriate for the intended use.
We would expect constrained node servers to come up with short URIs.
Existing designs based on CoAP (such as OMA lightweight M2M) go to great pains to keep their sizes in check.

So, no, I don't expect a realistic use case where the total length of options (which might be dominated by the URI) is greater than the IP MTU, not even the IFMUALTU (draft-bormann-intarea-alfi).

I should mention that the CoAP approach to slicing a large request/response pair into multiple exchanges is draft-ietf-core-block, which is widely implemented, but the specification text is not yet completed by the WG; if we ever need to address such a use case, we probably should address it there.  (As of today, -block only addresses slicing up the payload.)

Grüße, Carsten