Subject: [core] draft-ietf-core-coap-09 - Additional response codes

From: Klaus Hartke <[email-masked]>
Date: Mon, 16 Apr 2012 17:34:43 +0200

draft-nottingham-http-new-status [1] defines a few new HTTP status
codes. They look useful to have in CoAP as well.

- 428 Precondition Required

     The 428 status code indicates that the origin
     server requires the request to be conditional.

- 429 Too Many Requests

     The 429 status code indicates that the user
     has sent too many requests in a given amount
     of time ("rate limiting").

- 431 Request Header Fields Too Large

     The 431 status code indicates that the server
     is unwilling to process the request because its
     header fields are too large. The request MAY
     be resubmitted after reducing the size of the
     request header fields.

- 511 Network Authentication Required

     The 511 status code indicates that the client
     needs to authenticate to gain network access.

I think it would also be useful to have an equivalent of the HTTP 202
status code [2] in CoAP.

- 202 Accepted

     The request has been accepted for processing,
     but the processing has not been completed. ...

     The 202 response is intentionally non-committal.
     Its purpose is to allow a server to accept a request
     for some other process (perhaps a batch-oriented
     process that is only run once per day) without
     requiring that the user agent's connection to the
     server persist until the process is completed.

Klaus

[1] http://tools.ietf.org/html/draft-nottingham-http-new-status-04
[2] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-7.2.3

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Apr 2012 19:13:14 +0200

>     needs to authenticate to gain network access.

This is the status code informally known as "greedy hotel detected".
It is meant to be returned by captive portals that redirect all requests to a payment site until payment is received.
This is a well-understood and widely deployed scenario for HTTP; 511 solves the problem that is created when captive portals respond with 200 and cause automatic processes to believe the portal page is indeed the desired page.
I'm not so sure that we'll have exactly the same (or even a comparable) scenario in CoAP.

Grüße, Carsten