Subject: [core] Tightening up unknown status code semantics

From: Adam Roach <[email-masked]>
Date: Tue, 09 Nov 2010 14:01:23 +0800

CoAP borrows its status code structure (after a fashion) from HTTP. But, 
in reading through the current document, there's an important aspect of 
HTTP status codes that is missing, and that I suspect we want to adopt. 
The language in RFC 2616 in question is:

    HTTP status codes are extensible. HTTP applications are not required
    to understand the meaning of all registered status codes, though such
    understanding is obviously desirable. However, applications MUST
    understand the class of any status code, as indicated by the first
    digit, and treat any unrecognized response as being equivalent to the
    x00 status code of that class, with the exception that an
    unrecognized response MUST NOT be cached. For example, if an
    unrecognized status code of 431 is received by the client, it can
    safely assume that there was something wrong with its request and
    treat the response as if it had received a 400 status code.

To maintain reasonable behavior as we introduce new status codes in 
CoAP, I think we want to have similar language in the base CoAP spec.

But this raises another question about how to handle the new 240 - 255 
class of CoAP-specific error codes. Certainly we don't want to treat all 
unknown CoAP errors as "240 Token Required."

Finally, on the topic of response codes: we might benefit from some 
explicit language about how HTTP/CoAP proxies deal with mapping these 
CoAP-specific codes into HTTP responses. Presumably, if the proxy can 
recover (e.g., on receipt of a 240), it will do so. But you can also 
envision circumstances -- like 241 -- that the server won't be able to 
recover from. Perhaps we don't need to specify how the proxy translates 
these into HTTP; but it might be nice to be unambiguous in the 
specification (possibly something like calling out that an HTTP 502 
response would be a reasonable response if it receives a CoAP-specific 
response it can't automatically recover from).

(As an aside, I note that you could have 39 different CoAP codes if you 
put them in the 1-39 range, rather than the 15 codes afforded by the 240 
- 255 range).

/a

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Nov 2010 14:15:53 +0800

Very good point, Adam.

CoAP uses a base-10-4 number representation, which I will use here (the second in the three digits only goes from 0 to 3, so we can encode the whole thing in a byte).

Instead of using 6xx codes (240 base 10-10) for CoAP-specific applications, we might reserve x3x.
So the set of CoAP-specific 400-kind codes would be 430, 431, etc.

Still works with the HTTP assignments so far:

	http://www.iana.org/assignments/http-status-codes

If somebody really comes up with an HTTP 43x and we want to use that, we can map it to a CoAP status code.

(And we can still use 6xx for something completely foreign to the HTTP classes, if we want to, or as an extension to the crowded 4xx field.)

Gruesse, Carsten

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Nov 2010 09:45:58 +0800

> (And we can still use 6xx for something completely foreign to the HTTP classes, if we want to, or as an extension to the crowded 4xx field.)

An alternative that might make sense -- again, taking advantage of what 
would be the nonsensical "0xx" status code range in HTTP -- would be 
something like:

1 - 9 : CoAP-specific 2xx-class responses
10 - 19: CoAP-specific 3xx-class responses
20 - 29: CoAP-specific 4xx-class responses
30 - 39: CoAP-specific 5xx-class responses

Alternately, as it seems unlikely that CoAP-specific responses are 
unlikely to ever be in the 2xx or 3xx class, we could give ourselves 
more headroom by defining them as:

1 - 19: CoAP-specific 4xx-class responses
20 - 39 : CoAP-specific 5xx-class responses

Thoughts?

/a

---

From: Robert Quattlebaum <[email-masked]>
Date: Tue, 9 Nov 2010 21:38:07 -0800

I may be misunderstanding, but wouldn't this then conflict with method codes?

On Nov 9, 2010, at 5:45 PM, Adam Roach <[email-masked]> wrote:

> An alternative that might make sense -- again, taking advantage of what would be the nonsensical "0xx" status code range in HTTP -- would be something like:
> 
> Alternately, as it seems unlikely that CoAP-specific responses are unlikely to ever be in the 2xx or 3xx class, we could give ourselves more headroom by defining them as:
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Nov 2010 14:10:44 +0800

> I may be misunderstanding, but wouldn't this then conflict with method codes?

Yes, it would.

We may not need to reserve all 40 values allocated for methode codes now, though.

(I'd rather use this as extension space if the 43x codes run out.  
But we have to decide that now.
So how about using 03x as an extension space to 43x?  
More complexity.  Hmm.)

Gruesse, Carsten

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Nov 2010 22:59:59 +0800

Gack. You're right. I forgot to look before I proposed this, and for 
some reason I had it in my head that this field was set to 0 for requests.

Okay, so we're back into the 6xx range (or taking over the upper end of 
the normal 4xx and 5xx ranges). That is, unless, we want to limit 
ourselves to a maximum of 20 methods, and take 20-29 for 4xx-like codes 
and 30-39 for 5xx-like codes.

/a

On 11/10/10 1:38 PM, Robert Quattlebaum wrote:
> On Nov 9, 2010, at 5:45 PM, Adam Roach<[email-masked]>  wrote:
>