Subject: Re: [core] core-coap RFC status

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 3 Jan 2014 17:23:47 +0000

Dear CoRE list

Happy new year!

> > The CoAP document will go through a final edit phase (called "AUTH48")
> > once the missing references are cleared (and I'm working with Sean,
> > the responsible AD for the two TLS documents in question, to get that
> > to happen as soon as possible).  Significant changes to the document
> > are not allowed in AUTH48 state, but:

I just found a small contradiction in coap-18:

Section 4.2 says on page 21: "including the case where the Acknowledgement carries a request"

While this is technically possible, Table 1 "Usage of message types" indicates that requests can only be carried in CON and NON messages.

I would suggest to simply remove the parenthetic clause in Section 4.2, which also makes the important statement much clearer. A question remains whether we already have or should have a clear "MUST NOT" for carrying requests in Acknowledgements. (Or even explicitly allow it?)

Ciao
Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Jan 2014 20:13:48 +0100

Hi Matthias,

thanks for reading this again closely.

On 03 Jan 2014, at 18:23, Kovatsch Matthias <[email-masked]> wrote:

> Section 4.2 says on page 21: "including the case where the Acknowledgement carries a request”

… and goes on to list other error cases: "or a code with a reserved class, or the Reset
   message is not Empty”
This is in the paragraph that among other things defines how “rejecting a message” (that is malformed) means.

> While this is technically possible, Table 1 "Usage of message types" indicates that requests can only be carried in CON and NON messages.

Indeed, and that’s why they need to be rejected when in an ACK or RST.

Quoting the entire text should make clearer that this is not a contradiction at all:

   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 point is that even if you receive a request in an ACK (which makes it unprocessable), an unprocessable ACK is never responded to; you just silently ignore it.

(We had some last-call comments that the term “rejecting a message” may be confusing when it is effected by ignoring the message — some people think that term implies actively sending a message indicating rejection.  We didn’t find better terminology, unfortunately.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Jan 2014 20:15:53 +0100

> This is in the paragraph that among other things defines how “rejecting a message” (that is malformed) means.

*This is in the paragraph that among other things defines how “rejecting a message” (that is malformed) is achieved.

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 3 Jan 2014 20:05:41 +0000

> > While this is technically possible, Table 1 "Usage of message types"
> indicates that requests can only be carried in CON and NON messages.
> 
> Indeed, and that's why they need to be rejected when in an ACK or RST.

Okay, got it :)
I was currently on the general topic of rejecting messages for any possible reason and read "including the [perfectly normal] case where the Acknowledgement carries a request." Table 1 is explicit enough, though.

Thanks for the quick response
Matthias

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 3 Jan 2014 23:14:01 +0000

Hi

Found something else: Section 5.10 ends with
   (The
   present specification does not define any NoCacheKey options, but the
   format of the table is intended to be useful for additional
   specifications.)
But we now have Size1 in Table 4, which is marked N=NoCacheKey.

Ciao
Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 4 Jan 2014 13:21:41 +0100

On 04 Jan 2014, at 00:14, Kovatsch Matthias <[email-masked]> wrote:

> Found something else

Good catch!

This is rather typical of the kind of bugs we tend to fix in AUTH48.

I have added a milestone AUTH48 to the tracker.

	http://tools.ietf.org/wg/core/trac/report/10

This is now #362.

Grüße, Carsten