Subject: [core] Fwd: New Version Notification for draft-vanderstok-core-patch-01.txt

From: peter van der Stok <[email-masked]>
Date: Mon, 06 Jul 2015 11:48:40 +0200

Hi all,

We submitted a new version of the patch draft.

Example has been added, content formats have been specified (needs more 
work), caching has been reviewed.
error handling is improved.
Discussion on idem potency and atomicity is still needed.

Peter

A new version of I-D, draft-vanderstok-core-patch-01.txt
has been successfully submitted by Peter van der Stok and posted to the
IETF repository.

Name:		draft-vanderstok-core-patch
Revision:	01
Title:		Patch Method for Constrained Application Protocol (CoAP)
Document date:	2015-07-06
Group:		Individual Submission
Pages:		8
URL:            
https://www.ietf.org/internet-drafts/draft-vanderstok-core-patch-01.txt
Status:         
https://datatracker.ietf.org/doc/draft-vanderstok-core-patch/
Htmlized:       
https://tools.ietf.org/html/draft-vanderstok-core-patch-01
Diff:           
https://www.ietf.org/rfcdiff?url2=draft-vanderstok-core-patch-01

Abstract:
    The existing Constrained Application Protocol (CoAP) PUT method only
    allows a complete replacement of a resource.  This does not permit
    applications to perform partial resource modifications.  In case of
    resources with larger or complex data, or in situations where a
    resource continuity is required, replacing a resource is not an
    option.  Several applications using CoAP will need to perform partial
    resource modifications.  This proposal adds a new CoAP method, PATCH,
    to modify an existing CoAP resource partially.

Please note that it may take a couple of minutes from the time of 
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Jul 2015 08:50:53 +0200

Since the PATCH method appears to be a good candidate for WG adoption
soon, I have put up a chair's review at

  http://tzi.org/~cabo/draft-vanderstok-core-patch-01-cabo.txt

(Everything not indented is a comment.)

I like the idea of having an idempotent patch method.
However, even the example in the document uses RFC 6902, which can
express both idempotent and non-idempotent patches.  I'm not sure we can
completely limit ourselves to idempotent patches for CoAP.  Or can we?
Maybe we even need both the more general HTTP PATCH and another method
for idempotent patches.

Since HTTP calls its non-idempotent patch method PATCH, we probably
should call ours differently if it is indeed idempotent only.

iPATCH.  You heard it here, first :-)

Grüße, Carsten

PS.: Oops: http://shirt.woot.com/derby/entry/61114/ipatch

peter van der Stok wrote:
> Htmlized:       https://tools.ietf.org/html/draft-vanderstok-core-patch-01
> Diff:          
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: "weigengyu" <[email-masked]>
Date: Fri, 17 Jul 2015 17:47:37 +0800

Hi,

There are some questions:

1. Should CoAP patch be the same as HTTP patch?

2. In the draft, " 1.  Introduction
        PATCH was not adopted in an early design stage of CoAP, however, it 
has
        become necessary with the arrival of applications that require 
partial updates to resources "
    According to this statement, Patch could be used to update the resources 
of CoAP server.
    It is unclear that could Patch is used for operation on RD?

3. If yes, RD server would be accessed by CoAP and HTTP,
    So, both CoAP Patch and HTTP Patch are available, or not?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Carsten Bormann
Sent: Friday, July 17, 2015 2:50 PM
To: [email-masked]
Cc: Core
Subject: Re: [core] Fwd: New Version Notification for 
draft-vanderstok-core-patch-01.txt

Grüße, Carsten

---

From: peter van der Stok <[email-masked]>
Date: Fri, 17 Jul 2015 12:06:39 +0200

Hi Weigenyu,

thanks for your interest.
Answers below.

> 1. Should CoAP patch be the same as HTTP patch?

There are differences between http and coap that need to be taken into 
account, such as cache handling.
Other differences need to be discussed by the wg.

>        PATCH was not adopted in an early design stage of CoAP, however, 
> it has
>    According to this statement, Patch could be used to update the
> resources of CoAP server.

It can be used, but I don't see the need for the moment.
>    So, both CoAP Patch and HTTP Patch are available, or not?

When request is sent to http server on RD, http patch rules apply;
when request is sent to coap server on RD, coap patch rules apply.
> Regards,

Greetings,
Peter
> -----原始邮件----- From: Carsten Bormann

---

From: peter van der Stok <[email-masked]>
Date: Fri, 17 Jul 2015 12:27:13 +0200

Hi Carsten,

I think this a good subject for the CoRE meeting,

Peter

---

From: Michael Koster <[email-masked]>
Date: Sat, 18 Jul 2015 00:59:35 +0200

I would like to discuss link-format patch and the use case of maintaining link collections in CoRE Resource Directory.

Michael

---

From: Michael Koster <[email-masked]>
Date: Sat, 18 Jul 2015 01:11:15 +0200

I think the rules of patch are determined as much or more by the document format (JSON, link-format) rather than the application transport (CoAP, HTTP). We should try to make sure the 2 transport-specific documents (for merge patch) are very similar, which seems to be the case. One difference;  I think we could make patch responses cacheable as provided for in RFC 5789.

Michael

On Jul 17, 2015, at 12:06 PM, peter van der Stok <[email-masked]> wrote:

> There are differences between http and coap that need to be taken into account, such as cache handling.
>>       PATCH was not adopted in an early design stage of CoAP, however, it has

---

From: Bill Silverajan <[email-masked]>
Date: Mon, 20 Jul 2015 14:38:00 +0300

In addition to atomicity, I support idempotence in CoAP's version of 
PATCH. I have a use case of CoAP clients performing partial updates to 
(possibly a large number of) CoAP origin servers that expose link 
collections and multiple resources.

For the draft, would it be a good idea to express how PATCH impacts an 
existing Observe relationship, or would that be akin to stating the obvious?

Regards,
Bill

---

From: peter van der Stok <[email-masked]>
Date: Mon, 20 Jul 2015 14:43:03 +0200

HI Bill

> existing Observe relationship, or would that be akin to stating the

Not to me. I observe with GET. Can you explain?

Peter

Bill Silverajan schreef op 2015-07-20 13:38:
>> I would like to discuss link-format patch and the use case of 
>> maintaining link collections in CoRE Resource Directory.
>> 
>> Michael
>>

---

From: Bill Silverajan <[email-masked]>
Date: Mon, 20 Jul 2015 16:41:51 +0300

Hi Peter,

> Not to me. I observe with GET. Can you explain?

Yes, that's quite right. Client A sets up an Observe relationship on 
resource X with Server B with a GET. If for example, Client C does a PUT 
on X, Server B sends the entire resource representation of X to Client A 
using another GET.

So my question was: If for example, Client D does a PATCH operation on 
X, should the draft state explicitly that Server B would return the 
entire resource representation of X to Client A using a GET?

As I see it, the other alternatives don't make much sense (a PATCH on X 
not triggering a GET from B to A, having Observe support partial 
resource representations, and so on).

Regards,
Bill

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Jul 2015 22:17:56 -0700

On Mon, Jul 20, 2015 at 6:41 AM, Bill Silverajan <[email-masked]
> wrote:

> resource X with Server B with a GET. If for example, Client C does a PUT on
> X, Server B sends the entire resource representation of X to Client A using
> another GET.
>
> So my question was: If for example, Client D does a PATCH operation on X,
> should the draft state explicitly that Server B would return the entire
> resource representation of X to Client A using a GET?
>
> not triggering a GET from B to A, having Observe support partial resource
> representations, and so on).
>

Is it OK for the server to assume all clients observing the resource
have the up-to-date representation, so the delta for the patch
is really correct for all clients?

If not, then the server would need to know what "revision"
of the resource instance each client had, so it could send the
delta to each client (from their revision to the current one).
This is a non-starter.

Of course the clients would have to know the difference between
a full representation and a delta.  Not sure how this is done.
It seems simplest to always send the full representation, not a delta.
This is probably grossly inefficient though, which is a problem.
(I really appreciate the fact that CORE WG does not like sending 1000X
more bytes than required -- not the case in NETCONF WG).

> Bill

Andy

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Jul 2015 09:08:31 +0200

Actually, a client performing a GET can indicate which representations
it has cached by sending along ETag options.  2.03 Valid is just a
specialized (empty!) delta...

A strawman design for a delta GET (and thus a delta observe) function
could be:

New option Accept-Delta, Elective, Not Safe-to-Forward.
This gives the delta content-format(s?) accepted by this client.
Since the option is elective, it can be added to a GET request (or
observe) with little harm -- it will just be ignored if not implemented
by the server.

A server response to a GET with an Accept-Delta can be the usual 2.05
(Content) (or 2.03 (Valid)), ignoring the Accept-Delta option.  If the
server can produce the content-format specified by the client, it can
also send response code 2.nn (Delta) with a payload containing a delta
relative to a representation version indicated by the new response
option Delta-ETag.

Since observe notifications are essentially GET responses, this
continues to work over an observation.  If the client wants to update
the set of ETags it promises to have available to reconstruct
representations from, it can re-express interest (new GET with existing
tokens and a new set of ETags).  (There is a race condition if multiple
of these re-expression GETs with different ETag sets are active at any
one time... A little additional work remaining.)

Accept-Delta is not proxy-safe because different clients of a proxy may
have different ETags cached; in the end, the proxy may have to rebuild
the representation (which it can cache under the new ETag -- different
from the Delta-ETag) and may even built deltas from those reconstructed
representations, deltas that are tailored to the ETags offered by
specific groups of clients each.

Is the savings worth it?  I don't know.  I just wanted to write this up
so we know it's possible and have a concrete design to discuss this with.

Grüße, Carsten

Andy Bierman wrote:
> 
> 
> On Mon, Jul 20, 2015 at 6:41 AM, Bill Silverajan
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Peter,
> 
>             existing Observe relationship, or would that be akin to
>             stating the
>             obvious?
> 
> 
>     resource X with Server B with a GET. If for example, Client C does a
>     PUT on X, Server B sends the entire resource representation of X to
>     Client A using another GET.
> 
>     So my question was: If for example, Client D does a PATCH operation
>     on X, should the draft state explicitly that Server B would return
>     the entire resource representation of X to Client A using a GET?
> 
>     As I see it, the other alternatives don't make much sense (a PATCH
>     on X not triggering a GET from B to A, having Observe support
>     partial resource representations, and so on).
> 
> 
> 
>     [email-masked] <mailto:[email-masked]>