Subject: [core] coap #52 (new): How strict to make POST definition?

From: "core issue tracker" <[email-masked]>
Date: Sat, 06 Nov 2010 11:30:05 -0000

#52: How strict to make POST definition?

 In coap-03 a change was made to the POST definition (suggested by Kerry)
 to make it slightly more REST oriented compared to RFC2616. This ticket is
 to decide whether to:

 1. Keep the coap-02 definition that was closer to RFC2616 allowing POST to
 be used for other things than creating sub-resources.

 or

 2. Keep the coap-03 definition which includes only the REST usage of POST.

-- 
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:     
     Type:  enhancement         |      Status:  new
 Priority:  minor               |   Milestone:     
Component:  coap                |     Version:     
 Severity:  -                   |    Keywords:     
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/52>
core <http://tools.ietf.org/core/>

---

From: Kerry Lynn <[email-masked]>
Date: Sat, 6 Nov 2010 08:54:17 -0400

To be clear, I only suggested the addition of two words, "subordinate"
and "parent", to clarify the text that was already there.  I don't think this
substantially changed the meaning of the text between versions 2 & 3.
The section we're talking about is 2.3.2:
http://tools.ietf.org/wg/core/draft-ietf-core-coap/draft-ietf-core-coap-03-from-02.diff.html

Now compare this to RFC 2616, section 9.5:

"9.5 POST

The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line. POST is designed
to allow a uniform method to cover the following functions:

      - Annotation of existing resources;

      - Posting a message to a bulletin board, newsgroup, mailing list,
        or similar group of articles;

      - Providing a block of data, such as the result of submitting a
        form, to a data-handling process;

      - Extending a database through an append operation.

The actual function performed by the POST method is determined by
the server and is usually dependent on the Request-URI. The posted
entity is subordinate to that URI in the same way that a file is subordinate
to a directory containing it, a news article is subordinate to a newsgroup
to which it is posted, or a record is subordinate to a database.

The action performed by the POST method might not result in a resource
that can be identified by a URI. In this case, either 200 (OK) or 204 (No
Content) is the appropriate response status, depending on whether or
not the response includes an entity that describes the result.

If a resource has been created on the origin server, the response
SHOULD be 201 (Created) and contain an entity which describes the
status of the request and refers to the new resource, and a Location
header (see section 14.30).

Responses to this method are not cacheable, unless the response
includes appropriate Cache-Control or Expires header fields. However,
the 303 (See Other) response can be used to direct the user agent to
retrieve a cacheable resource.

POST requests MUST obey the message transmission requirements
set out in section 8.2.

See section 15.1.3 for security considerations."

If we want coap POST to be more like 2616, then I think language like
"The actual function performed by the POST method is determined by
the server and is usually dependent on the Request-URI" needs to be
*added*.  This will provide the backdoor RPC capability that many so-
called RESTful designs depend on (IOW, using POST more like "invoke"
than "append").

Now one thing I belive *is* a problem, and needs a new ticket, is the
inability of the underlying transaction model to treat POST in a non-
idempotent fashion.  Figure 8 in draft-ietf-core-coap-03 shows the
client retying a GET in the case where the ACK is lost. How the server
treats this in the case of POST is unspecified.  I believe this may result
in the creation of *multiple* resources at the server.

Need a new ticket: "CoAP MUST support At Most Once transactions"

Regards, -K-

On Sat, Nov 6, 2010 at 7:30 AM, core issue tracker <[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 7 Nov 2010 00:53:10 +0800

> in the creation of *multiple* resources at the server.

Maybe I don't understand your concern correctly.
Figure 8 shows how a lost ACK is handled by the transaction layer.
The mechanism shown also works for POST.
A server that wants to offer at-most-once POST can use the transaction ID to differentiate a retransmission from a new request.
How it does this is indeed unspecified, but we rarely specify implementation details.
The semantics of a POST are defined by the resource/the server.
Requiring the server to offer at-most-once POSTs would be an onus for those applications that don't need that.

We could go ahead and specify
-- requirements on the time that must elapse before TID reuse by a client (to avoid false positives)
-- requirements on the time TID state is kept at a server (to avoid false negatives)

Do we need to?
(Not a rhetorical question.)

My ceterum censeo: Please talk about the use case you have in mind.
(E.g., I have one use case for POST where the at-most-once semantics are important enough to be realized in the application, so I wouldn't even care if the server does them right or not.)

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Sun, 7 Nov 2010 22:18:16 +0800

Hi Kerry,

> called RESTful designs depend on (IOW, using POST more like "invoke"

You are right, I agree the original comment that started this thread really doesn't have to do with your added words (my mistake). But you do bring up a good point here. I think it would be a good idea to add that sentence in order to bring this in line with the RFC2616 definition. Will be proposed in tomorrow's CoAP WG slides. 

Zach

-- 
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: Kerry Lynn <[email-masked]>
Date: Sun, 7 Nov 2010 21:32:04 -0500

> Maybe I don't understand your concern correctly.

I guess I didn't fully understand the *lack* of concern until now, so
either I'm slow or the spec could use more explanation on this point
(or both :)  Hence the suggestion that we raise this to an issue that
should be discussed and tracked by the WG.

> The mechanism shown also works for POST.

The client cannot know whether the CON or ACK has been lost.  All
it can do in this situation is retry the CON and that's where the problem
may arise.

This is not an issue with HTTP servers because TCP provides reliable
transport and duplicate client requests do not occur as a result of the
protocol.

> A server that wants to offer at-most-once POST can use the transaction
> ID to differentiate a retransmission from a new request.

If the server receives a duplicate CON+POST, a naive implementation
may treat this as a new indication and duplicate the function at the server.
What the server *should* do in the case of POST is to cache the response
and return that to the client upon receipt of a duplicate CON, without
offering the equivalent of a duplicate indication to the application.  This
would normally be the responsibility of the transaction layer; the desire
for AMO behavior would be signaled by the client and implemented by
the server.

> Requiring the server to offer at-most-once POSTs would be an onus for those applications that don't need that.

HTTP is pretty clear on this point; POST does not have the idempotent
property.  Section 2.3 says coap methods have the same properties as
their HTTP equivalents.  If all coap implementations don't treat POST the
same way, then how can we call it a uniform method?

> -- requirements on the time that must elapse before TID reuse by a client (to avoid false positives)

Done.  See section 2.2.5.

> -- requirements on the time TID state is kept at a server (to avoid false negatives)

RFC 955 talks about retaining state until a new TID is received, but this
doesn't allow for parallel requests.  Some transaction protocols have a
"release" message to signal the server that the response has been received.
I'm sure there are other equally valid approaches.

> (E.g., I have one use case for POST where the at-most-once semantics are
> important enough to be realized in the application, so I wouldn't even care
> if the server does them right or not.)

I guess that may depend on the outcome of the issue #52 discussion.
If the consensus is to allow POST to act as "invoke" as well as
"append" (and I suspect this will be the case), then basically any
situation that can result in duplicate indications would be a use case.
For example, I wouldn't want my energy controller to receive duplicate
load shed invocations.

Regards, -K-

---

From: Robert Cragie <[email-masked]>
Date: Mon, 08 Nov 2010 07:23:13 +0000

I think the language of CON+ACK processing at the end-point as a server 
needs to be tightened up. The transaction handler should not be 
submitting multiple CONs with the same tid for further processing. In 
that case it then just becomes a reliable delivery mechanism and POST 
does not have to be idempotent. However, I think the idea of caching the 
response makes sense if you apply a lifetime to it.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

On 08/11/2010 2:32 AM, Kerry Lynn wrote:
> On Sat, Nov 6, 2010 at 12:53 PM, Carsten Bormann<[email-masked]>  wrote:

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Nov 2010 08:21:10 +0800

On Nov 8, 2010, at 15:23, Robert Cragie wrote:

> However, I think the idea of caching the response makes sense if you apply a lifetime to it.

Sure, in particular if we don't try to prevent a server from setting that lifetime to zero.

I agree that the current text (2.2.5) is a bit implicit about the meaning of transaction-IDs.
What it should say is at least:

-- a client SHOULD send retransmissions with the same TID it sent the original message with
-- a server SHOULD use TIDs for duplicate detection (lost ACKs) and act on duplicate messages in a way that is appropriate  (e.g. it could minimize its work by caching a response for a while, and it SHOULD use TIDs to implement at-most-once semantics for non-idempotent operations where that is desired).

The language need not be fuzzy to grant the server some leeway; it could quite explicitly say that a server may choose not to to duplicate detection IF that is appropriate (i.e., for idempotent operations, as well as for POST (non-idempotent operations) IF the resource semantics do not require at-most-once operation).

Gruesse, Carsten

---

From: [email-masked]
Date: Tue, 9 Nov 2010 09:54:52 +0100

Hi Carsten,

>-- a server SHOULD use TIDs for duplicate detection (lost ACKs) and act on
duplicate messages in a way that is appropriate  (e.g. it could minimize
>its work by caching a response for a while, and it SHOULD use TIDs to
implement at-most-once semantics for non-idempotent operations where that
is >desired).

May be the following questions could be clarified too:
- how long the server should keep the state ?
- what information should be used to detect duplication: (TID) or (TID, src
address)? Do you think that the initial random TID of each client would
suffice to prevent false duplicate detection if we only use (TID)? (TID,
src address) seems more robust.

Regards,
Matthieu

             Carsten Bormann                                               
             <[email-masked]>                                                
             Envoyé par :                                                A 
             core-bounces@ietf         [email-masked]         
             .org                                                       cc 
                                       core <[email-masked]>                
                                                                     Objet 
             09/11/2010 01:21          Re: [core] coap #52 (new): How      
                                       strict to make POST definition?     

                                                                           

> However, I think the idea of caching the response makes sense if you
apply a lifetime to it.

Sure, in particular if we don't try to prevent a server from setting that
lifetime to zero.

I agree that the current text (2.2.5) is a bit implicit about the meaning
of transaction-IDs.
What it should say is at least:

-- a client SHOULD send retransmissions with the same TID it sent the
original message with
-- a server SHOULD use TIDs for duplicate detection (lost ACKs) and act on
duplicate messages in a way that is appropriate  (e.g. it could minimize
its work by caching a response for a while, and it SHOULD use TIDs to
implement at-most-once semantics for non-idempotent operations where that
is desired).

The language need not be fuzzy to grant the server some leeway; it could
quite explicitly say that a server may choose not to to duplicate detection
IF that is appropriate (i.e., for idempotent operations, as well as for
POST (non-idempotent operations) IF the resource semantics do not require
at-most-once operation).

Gruesse, Carsten

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________