Subject: [core] Critical/elective options in CON/NON/ACK/RST

From: Markus Becker <[email-masked]>
Date: Mon, 25 Oct 2010 12:01:32 +0200

Hi,

can it be made explicit in Table 2 (Options headers) of draft-ietf-core-coap 
which option header might appear in which type of transaction message 
(CON/NON/ACK/RST)? Or are all (current) options possible in all transaction 
types?

What happens for critical options in NON/ACK/RST? Section 2.5.1 only specifies 
the behaviour for CON. This is additional to ticket #27.

Best regards,
Markus
------------------------------------------------
| Dipl.-Ing. Markus Becker
| Communication Networks
| Mobile Research Center
| TZI - Center for Computing Technologies
| University Bremen
| Germany
------------------------------------------------
| web: http://www.comnets.uni-bremen.de/~mab/
| mailto: [email-masked]
| telephone: +49 421 218 62379
| building: NW1 room: N2260
------------------------------------------------

---

From: Zach Shelby <[email-masked]>
Date: Mon, 25 Oct 2010 13:04:43 +0300

Markus,

I am working on the coap-03 submission today, and will take a look at this.

> (CON/NON/ACK/RST)? Or are all (current) options possible in all transaction 

Need to take a look if that makes sense.

> 
> What happens for critical options in NON/ACK/RST?

The message must be ignored in that case at the REST layer. At the transaction layer the ACK should still be used to fulfill the CON, and the RST to reset a transaction. 

Zach

> Section 2.5.1 only specifies 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 25 Oct 2010 13:41:53 +0200

On Oct 25, 2010, at 12:04, Zach Shelby wrote:

> The message must be ignored in that case at the REST layer.

(I think you are talking about critical options not understood by the recipient...)
Indeed, NON should be ignored.
For ACK and RST, a response with a critical option that is not understood also causes an error for the outstanding transaction at the REST layer; similar to a situation where an error code 400 had been returned.  In other words, the original request could not be fulfilled without some critical addition to the response, and if the original requester does not understand that critical addition, the response needs to be converted to something like a parameter problem.

> At the transaction layer the ACK should still be used to fulfill the CON, and the RST to reset a transaction. 

Yes.

Gruesse, Carsten