Subject: [core] WG: Mail regarding draft-ietf-core-coap

From: "Doran Hans (donn)" <[email-masked]>
Date: Mon, 10 Oct 2016 09:49:07 +0000

Hi,

I've been teaching CoAP in an IoT class which led me to read the RFC 7252.

The standard could do with a revision in writing - one example is here:

5.2.3.  Non-confirmable

   If the request message is Non-confirmable, then the response SHOULD
   be returned in a Non-confirmable message as well.  However, an
   endpoint MUST be prepared to receive a Non-confirmable response
   (preceded or followed by an Empty Acknowledgement message) in reply
   to a Confirmable request, or a Confirmable response in reply to a
   Non-confirmable request. 

This sentence links Non-confirmable message behaviour with Confirmable message behaviour through the word "However" despite it being abundantly clear that the two have nothing to do with each other.

The paragraph SHOULD read:

5.2.3.  Non-confirmable
 
  If the request message is Non-confirmable, then the response SHOULD
   be returned in a Non-confirmable message as well.  However an
   endpoint MUST be prepared to receive a Confirmable response in reply to a
   Non-confirmable request.

So far so good: However we have an implementation based on python libraries running where the default response to a NON message is an ACK. It is not possible to determine from the standard whether this is incorrect behaviour or not.    

I don't know how the RFC system works with regard to revisions - if I had read the earlier versions of the document I would have done some re-writing at the time - but if it is to be revised  then maybe you could let me know. 

Best regards

ZHAW Zurich University of Applied Sciences 
Institute of Embedded Systems (InES) 
Prof. Hans Dermot Doran Head of Secure and Dependable Systems 
Technikumstrasse 9, Postfach, CH-8401 Winterthur 
T +41-58-934-7676   | M +41-79-636-8133 
http://ines.zhaw.ch | [email-masked]

---

From: "Dijk, Esko" <[email-masked]>
Date: Sun, 16 Oct 2016 20:41:02 +0000

Hello Doran,

errata can be reported via this page: https://www.rfc-editor.org/errata.php (section "Report new errata").
In my reading of the text it is clear that a NON should never trigger an ACK, but of course these sentences could be interpreted in various ways.

best regards
Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Doran Hans (donn)
Sent: Monday, October 10, 2016 11:49
To: [email-masked]
Subject: [core] WG: Mail regarding draft-ietf-core-coap

Hi,

5.2.3.  Non-confirmable

5.2.3.  Non-confirmable

Best regards

ZHAW Zurich University of Applied Sciences Institute of Embedded Systems (InES) Prof. Hans Dermot Doran Head of Secure and Dependable Systems Technikumstrasse 9, Postfach, CH-8401 Winterthur T +41-58-934-7676   | M +41-79-636-8133 http://ines.zhaw.ch | [email-masked]

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 17 Oct 2016 01:55:06 +0200

On 13 October 2016 at 09:48:49, Doran Hans (donn) ([email-masked]) wrote:

we have an implementation based on python libraries running where the default response to a NON message is an ACK.
ACK messages are acknowledging CON messages.  ACK messages sent in response to NON messages are wrong.

Right there in 1.2:

   Acknowledgement Message

      An Acknowledgement message acknowledges that a specific

      Confirmable message arrived.  By itself, an Acknowledgement

      message does not indicate success or failure of any request

      encapsulated in the Confirmable message, but the Acknowledgement

      message may also carry a Piggybacked Response (see below).

Please note that 4.2 says:

   Rejecting an
   Acknowledgement or Reset message (including the case where the
   Acknowledgement carries a request or a code with a reserved class, or
   the Reset message is not Empty) is effected by silently ignoring it.
   More generally, recipients of Acknowledgement and Reset messages MUST
   NOT respond with either Acknowledgement or Reset messages.

So the bad python library is interoperable (the bad ACK will be silently ignored*), but still wrong.
The text you are citing is answering a different question: If the request was in a NON, does the server respond with a NON or with a CON?  (The latter would imply that the client sends an ACK for that.)  The text that you want to delete describes that a separate response to a CON message (which needs an empty ACK do indicate a separate response will be sent later) MAY be responded to in a NON message.  (See also the penultimate paragraph of 4.2…)

Grüße, Carsten

*) Well, unless the client manages to reuse the NON message-ID for a CON before the ACK arrives.  Should not really happen, because of EXCHANGE_LIFETIME.