Subject: [core] draft-ietf-core-coap-06 IF-Match Option

From: Cullen Jennings <[email-masked]>
Date: Wed, 4 May 2011 20:49:40 -0600

Imagine a care where you care controlling some actuator and you want to change it's value in a relative way. The typical way to do this is GET the current value, then PUT a new absolute value. However, to do this, you need to know the value did not change in between the GET and PUT. This can be solved by getting and ETag in the GET, then including that ETAG in an If-Match option of the PUT. If, at the time the PUT is received, the current ETAG for the resource does not match the value in the IF-Match option, then the PUT is not performed and returns an error. The client can then retry the GET / PUT pair. You can imagine this case coming up with an example of light dimmer and trying to increase the level of light by say 10%. 

I think this is an important use case that should be supported and we should add an IF-Match option. 

Cullen <in my role as an individual contributor>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 May 2011 21:07:21 +0200

> I think this is an important use case that should be supported and we should add an IF-Match option. 

I just submitted coap-misc-08 with a proposal for that option.

I didn't try to tackle If-None-Match, which (with the ETag functionality we already have) is probably mostly relevant for the single case

       If-None-Match: *

Do you think there are good use cases for this, too?

Gruesse, Carsten

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 7 May 2011 08:35:05 -0700

I read the text you have in the misc draft on if-match and thought it looked just right. As an individual contributor, I would suggest we take this text and move it to CoAP. I don't see a compelling reasons to add the If-None-Match.

> Do you think there are good use cases for this, too?

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 7 May 2011 18:08:35 +0200

> I read the text you have in the misc draft on if-match and thought it looked just right. As an individual contributor, I would suggest we take this text and move it to CoAP. I don't see a compellin…

The only one that sounds useful is "If-None-Match: *", which allows to restrict a PUT to a "Create", similar to the way "If-Match: *" restricts it to a "Replace".  "Create" actually is much more useful than "Replace" -- if you do the latter, you probably know what you are replacing, so you could give the ETag for a full "If-Match: ___".

Just a thought.

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Mon, 9 May 2011 23:12:34 +0300

> I read the text you have in the misc draft on if-match and thought it looked just right. As an individual contributor, I would suggest we take this text and move it to CoAP. I don't see a compellin…

+1

Zach

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
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: Carsten Bormann <[email-masked]>
Date: Tue, 10 May 2011 14:33:00 +0200

> The only one that sounds useful is "If-None-Match: *", which allows to restrict a PUT to a "Create", similar to the way "If-Match: *" restricts it to a "Replace".  "Create" actually is much more us…

Another thought is to not have an option for the * cases, but instead have two new methods:

CREATE 		is like PUT with If-None-Match: * (fails if resource exists)
UPDATE		is like PUT with If-Match: * (fails if resource does not exist).

(and, of course, the PUT that doesn't care whether the resource exists).

This leaves us with a clean If-Match Option for the UPDATE case where we do care about the ETag.

Just a thought, bis.

(Note that none of these need to be in the base spec, by the way.  There is a reason we have moved block and observe to separate documents...)

Gruesse, Carsten

---

From: Paul Duffy <[email-masked]>
Date: Tue, 10 May 2011 11:52:31 -0400

Hi Carsten,

My strong preference is to align options and methods with existing HTTP 
mechanisms.

It goes to the translation issues.  Every step taken away from HTTP 
means more complexity in the translation.

Cheers