Subject: [core] coap-04 POST related issues

From: Salvatore Loreto <[email-masked]>
Date: Fri, 28 Jan 2011 18:31:51 +0100

1) CoAP POST is neither safe nor idempotent, but the answer to a CoAP 
POST request both CON and NON
     can be deferred.
     So it is not clear in the spec if the CoAP client that receives an 
empty ACK to a CON CoAP POST can or cannot issue
     a second CoAP POST as there is no warranty about the order how the 
two requests will be served.
     (the Message-ID is not mandate to be sequentially incremental)

2) 200 OK should be allowed for CoAP POST

3) HTTP to CoaP mapping:
    --------------------

- HTTP POST is straightforward translated in CoAP POST

- however the CoAP response to POST at moment can be deferred
    and the defer can lead at the expiration of some timeout in the HTTP 
side
    so that the actual POST answer it will never delivered to the HTTP 
client

- that will lead to the undefined situation where the CoAP POST is 
performed on the CoAP sensor,
   the HTTP/CoAP proxy at some point in time will receive the answer
    but the HTTP client is not sure about the fact that the action it 
has been performed neither about the result.

It is not clear then how the client will be able to retrieve the answer 
from the HTTP/CoAP.
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12 in section 
7.1.4 states

    This means that clients, servers, and proxies MUST be able to recover
    from asynchronous close events.  Client software SHOULD reopen the
    transport connection and retransmit the aborted sequence of requests
    without user interaction so long as the request sequence is
    idempotent (see Section 7.1.2 of [Part2  <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#ref-Part2>]).  Non-idempotent methods or
    sequences MUST NOT be automatically retried, although user agents MAY
    offer a human operator the choice of retrying the request(s).

Is not clear what happen in this situation if the HTTP client decide to 
retry the POST request.
The HTTP/CoAP proxy is unable to distinguish whether or not it is a 
retransmission.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com