Re: [apps-discuss] AppsDir review of draft-ietf-core-coap-14

Alexey Melnikov <> Sun, 28 April 2013 21:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E79621F8496; Sun, 28 Apr 2013 14:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vyi275RBdwBI; Sun, 28 Apr 2013 14:33:32 -0700 (PDT)
Received: from ( [IPv6:2a00:14f0:e000:7c::2]) by (Postfix) with ESMTP id 1A3BC21F8314; Sun, 28 Apr 2013 14:33:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1367184808;; s=selector;; bh=m9hWLLMyaT4hQn74HjSjpUc5FlPfM/mKuXIJgixu+Jw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Iwr+W8FLb8S0wDmTo8PgqA3lK3qvJlzN409uHaYbEDrnb70mfWk0a10GpQDrjv3jJkYJJN 7F6L7sfVRhTX2up2JsTBuVdKR8NqHvOdAzVBr6u8wgc2vG27+RCaVMQCVHOVoclKlimOxC gCaUBlpj6SGlxN9QxYF9QO9sWM/xIIA=;
Received: from [] ((unknown) []) by (submission channel) via TCP with ESMTPA id <>; Sun, 28 Apr 2013 22:33:28 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <>
Date: Sun, 28 Apr 2013 21:23:56 +0100
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: Carsten Bormann <>
References: <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "HE, XUAN -HCHBJ" <>,,, IETF Apps Discuss <>, The IESG <>
Subject: Re: [apps-discuss] AppsDir review of draft-ietf-core-coap-14
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 28 Apr 2013 21:33:33 -0000

On 04/04/2013 14:57, Carsten Bormann wrote:
> Hi Alexey,
Hi Carsten,
Sorry for the slow response, I was on holidays.
> thank you for this review.
>> In Section 3, version number field: have you thought about backward compatibility rules for future versions (if any) and version negotiation rules?
> I don't think we discussed this in the WG.
> I remember some hallway discussions the gist of which is approximately:
> We don't know yet why we would have a version transition, so it is hard to plan for it.
> Whatever we define now is likely to be wrong when we actually know what we need.
> Anything that is radical enough that we can't express it in an option is likely to change the message layout enough that it's not even clear what kind of error response to send back.
> Sending back something for anything also has its perils.
> So the version number is mainly in there as an insurance against unknown unknowns.
> One other purpose is to allow some multiplexing on the UDP port, including to avoid STUN codepoints.

>> In Section 4.6: is a SHOULD requirement on IP MTU actually valid in this document? IMHO, you can't redefine what relevant RFCs say about that.
> There is no SHOULD on the MTU, but a SHOULD on what CoAP implementations should assume as an MTU.
> Most of our users think in terms of IPv6, so 1280 is a good assumption.
> For IPv4, 1280 is also a good base assumption.  There is an extensive implementation note on that, which qualifies this further.
> The upshot really is that you want to limit the payload size to 1KiB and, if you use all that, be reasonable about the option size; but for constrained applications, these numbers are already high.
I would rather you said just that in the document. But Ok, your 
explanation is sufficient.

>> In 5.10.8, last para: wouldn't it be more correct to say that preconditions must be tested after all other verification is performed? If not, what is the intent of the MAY?
> It gives the server some lenience.  It does allow checking for the preconditions first, and it does allow for checking them last.  (We always try to give the server some lenience to implement things in a way that is best for the specific constrained node.)  In other words, the client cannot rely on, say, a 4.05 indicating that the preconditions did match, or on a 4.12 indicating that the method would have been allowed, but the server is free to check things in either order.
I am not sure this is very interoperable, but maybe this doesn't matter.
>> In 6.4: why is URI's default encoding is UTF-8 and not ASCII? URIs can't contain 8bit data. Or did you mean IRIs? (Hopefully you haven't!)
> We certainly didn't mean IRIs.  Specifying UTF-8 and ASCII should be equivalent here.
> (Either way is likely to confuse a different part of the audience.)

I think you should just say ASCII.