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

[Alexey Melnikov <[e-mail]>]

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

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