Subject: [core] AppsDir review of draft-ietf-core-coap-14

From: Alexey Melnikov <[email-masked]>
Date: Thu, 04 Apr 2013 13:45:50 +0100

I have been selected as the Applications Area Directorate (appsdir) 
reviewer for this draft.  (For background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments 
you may receive.  Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-ietf-core-coap-14
Title: Constrained Application Protocol (CoAP)
Reviewer: Xuan He and Alexey Melnikov
Review Date: April 4, 2013
IETF Last Call Date: 27 March 2013
IESG Telechat Date: not known

Summary: This draft is nearly ready for publication as an Standards 
Track RFC.

Major Issues: none.

Minor:

In Section 3, version number field: have you thought about backward 
compatibility rules for future versions (if any) and version negotiation 
rules?

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.

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?

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

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.

Nits:

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

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.

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 4 Apr 2013 15:57:47 +0200

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.

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 28 Apr 2013 21:23:56 +0100

> Hi Alexey,
Hi Carsten,
Sorry for the slow response, I was on holidays.
> One other purpose is to allow some multiplexing on the UDP port, including to avoid STUN codepoints.
Ok.

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

> 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 thing…
I am not sure this is very interoperable, but maybe this doesn't matter.
> (Either way is likely to confuse a different part of the audience.)

I think you should just say ASCII.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Apr 2013 00:02:35 +0200

Hi Alexey,

> Sorry for the slow response, I was on holidays.

I'll start my vacation (in Russia, by the way) on Friday...
Hope to have a -16 by then.

> I think you should just say ASCII.

This is what the current draft -16pre says:

   2.  Resolve the |url| string using the process of reference
       resolution defined by [RFC3986].  At this stage the URL is in
       ASCII encoding [RFC0020], even though the decoded components will
       be interpreted in UTF-8 [RFC3629] after step 5, 8 and 9.

I think this should be much clearer.

Grüße, Carsten

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 29 Apr 2013 10:33:56 +0100

> I think this should be much clearer.

Yes, this works. Thanks!