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

Carsten Bormann <cabo@tzi.org> Thu, 04 April 2013 13:58 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561C421F8DDD; Thu, 4 Apr 2013 06:58:00 -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 mwy3hFJabD3f; Thu, 4 Apr 2013 06:57:59 -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 5973321F8BBC; Thu, 4 Apr 2013 06:57:59 -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 r34DvmO9020317; Thu, 4 Apr 2013 15:57:49 +0200 (CEST)
Received: from [192.168.217.105] (p54893641.dip.t-dialin.net [84.137.54.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F3C54303D; Thu, 4 Apr 2013 15:57:47 +0200 (CEST)
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: <515D75FE.9070008@isode.com>
Date: Thu, 04 Apr 2013 15:57:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C2FE55F-A4FF-4340-AEBF-C626B42BAA67@tzi.org>
References: <515D75FE.9070008@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: Apple Mail (2.1503)
Cc: "HE, XUAN -HCHBJ" <xhe@hitachi.cn>, core@ietf.org, draft-ietf-core-coap.all@tools.ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [apps-discuss] AppsDir review of draft-ietf-core-coap-14
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2013 13:58:00 -0000

Hi Alexey,

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.

> 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.

> 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.)

> In 6.4: 8/9 - it would be correct to say octet instead of "character" when discussing %-decoding. Unicode characters can be represented as multiple octets in UTF-8, each octet would be %-encoded separately.

We probably just wanted to avoid "octet" because the average age of the authors is low enough that we can say byte :-)  Indeed, each byte is percent-encoded separately, and decoding each percent-triple generates a single byte, the sequences of which are then decoded as UTF-8 characters.

We'll try to find better wording for these two items.

> Nits:
> 
> In 5.4.6: Strange alignment of figure 10. Should it be center aligned?

I don't have a preference either way.  Centered now in SVN [1269].

> In 7.1: the section title is "Service Discovery", but the section is talking about "server discovery". These are used as synonyms, but this might be confusing to non native English speakers.

Well, the usual terminology here *is* confusing.  A CoAP server offers a service.
It's not that interesting to discover the server alone, you want to discover the service on that server. (Actually, the software entity that offers the service might offer it in the form of multiple endpoints at different port numbers, which are by definition different servers, even though we colloquially would rather call it a server with multiple endpoints.)

Let's see if we can untangle the wording a bit here.
But I think we want to stick with the heading "Service Discovery".

> In 12.2 Page82: There is a table below Table 6 and without any number.

Thanks, captioned "CoAP Option Number Registry Policy" now in SVN [1269].

Grüße, Carsten