Subject: Re: [core] 🔔 WG Last Call of draft-ietf-core-etch-01

From: Jaime Jiménez <[email-masked]>
Date: Tue, 12 Jul 2016 09:29:41 +0000

Hi all,

from the email discussion it seems to me that the current editor draft https://core-wg.github.io/etch/ contains all the required modifications.
We will also have a slot for discussing during the Tuesday session. The authors should then submit the new version after IETF.

Ciao,
- - Jaime Jimenez

---

From: Francesca Palombini <[email-masked]>
Date: Wed, 13 Jul 2016 09:42:48 +0000

Hi Authors,

I apologize for the late comment.

I think the draft is ready for publication, and I think the sentence in section 3. : " The indication of idempotence may enable the server to keep less state about the interaction; some constrained servers may only implement the iPATCH variant for this reason." motivates the existence of both methods.

I may have missed it in the draft, but I couldn't see where in the draft is defined that error 4.12 Precondition Failed is returned when iPATCH is used with a non-idempotent modification (as it is specified in the error). I think this should be specified in section 3.4.

Best,
Francesca

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: den 28 juni 2016 22:24
To: Klaus Hartke <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [core] 🔔 WG Last Call of draft-ietf-core-etch-01

> I'm not convinced that two PATCH methods are needed, because the 
> idempotency of the request really depends on the idempotency of the 
> patch and not on the method: if the repeated application of the patch 
> leads to the same result, then the request is idempotent; otherwise, 
> it's not. I don't see the benefit of repeating this bit of information 
> in the request method.

The request method is an indication of the intent of the client.
The server can make use of the information encoded in this intent.

If you only ever implement less-constrained (and not-so-high-speed) servers and proxies, that information may not be very useful.  Both for constrained and high-speed implementations, it is an advantage to know when a request is intended to be idempotent.

> Two methods are a problem when mapping HTTP PATCH to CoAP
> PATCH/iPATCH: 

It is not really a problem: A HTTP-to-CoAP cross-proxy doesn't know the intent, so it will have to use PATCH (unless there is some other way to derive that intent).

> The proxy would need to analyze the patch in the HTTP request to 
> determine if the HTTP PATCH can be mapped to CoAP iPATCH of if CoAP 
> PATCH has to be used. The proxy cannot just map to CoAP PATCH always, 
> because the CoAP server might only support iPATCH but not PATCH even 
> if the patch itself is actually idempotent.

The server might not even support iPATCH, either.  I don't think one should expect a proxy to do method translation.  (Well, it may be a nice differentiating feature, which is easy to implement if the proxy happens to know that the media type used in the PATCH request only supports idempotent operations, e.g. for RFC 7396 merge-patch.)

An obvious way to "solve" this problem would be to require a server that supports iPATCH to always support PATCH as well.

I think much of the cognitive dissonance here comes from the fact that the best place to carry this bit of information is the method code, and REST traditionally has been using only four methods, so adding three codes in one extension may seem a lot.  (HTTP actually has methods like HEAD, which is just an optimized variant of GET, so this isn't even new
territory.)

> Apart from this, I think the draft is ready for publication.

Thank you for reviewing this draft.

Grüße, Carsten

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

---

From: peter van der Stok <[email-masked]>
Date: Wed, 13 Jul 2016 12:39:09 +0200

Hi Francesca,

Thanks for your late by welcome comment.

> 
> I may have missed it in the draft, but I couldn't see where in the
> draft is defined that error 4.12 Precondition Failed is returned when
> iPATCH is used with a non-idempotent modification (as it is specified
> in the error). I think this should be specified in section 3.4.
> 
You suggest that under the Failed precondition header of section 3.4 the 
draft mentions that iPATCH should return 4.12 also when the modification 
in non-idempotent.
I think that an excellent suggestion and will add it to the if-* option 
usage.

Peter

---

From: Ari Keränen <[email-masked]>
Date: Wed, 13 Jul 2016 11:27:58 +0000

Hi,

I read the draft and have couple of questions/comments.

What media type could be today used with FETCH? What do the implementations use? I'm thinking that something like xpath (/jsonpath?) media type would be easy to define.

Section 2:
> The payload returned in response to a FETCH cannot be assumed to be a complete representation of the resource identified by the effective request URI.

Can't I use FETCH to produce same result as GET? Even if I use it without any additional request parameters?

>  (Note that this aspect differs markedly from [I-D.snell-search-method].)

I'm not sure these references to the HTTP search method draft are of any use, rather they are a distraction. Since that draft is expired and apparently not going anywhere, I'd suggest simply removing all the references. If you want to acknowledge that work, the ACK section is better for that.

> 2.5. FETCH discussion

This could be called e.g., "Generating FETCH requests" since that's all this is apparently about

Section 2.6:
> (with a Content-Format ID of NNN – not defined as this is just an example),

This is not specific to this draft, but maybe we should allocate one content format ID for example purposes.

Cheers,
Ari

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 13 Jul 2016 14:20:28 +0200

Hi Ari,

Unfortunately, before SEARCH/FETCH there was little incentive to register a media type for a search structure. Eg, see rfc6901 (which would otherwise work quite well, except for just being a single pointer). Of course we could invent one just to use in the example, but I'd rather have these registrations be driven by actual application requirements. Inventing a useful one on the spot sounds like a recipe for delay. I think COMI/COOL will be the first real customer.   

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 13 Jul 2016 14:22:59 +0200

Hi Ari,

On the editorial items: these are all good suggestions. To bad there is no section "historical references" for the pointer to the SEARCH draft...

Grüße, Carsten

---

From: peter van der Stok <[email-masked]>
Date: Wed, 13 Jul 2016 14:28:13 +0200

Hi Ari,

thanks for the comments. See below for my reaction.
Carsten may have different opinions though.

Ari Keränen schreef op 2016-07-13 13:27:
> What media type could be today used with FETCH? What do the
> implementations use? I'm thinking that something like xpath
> (/jsonpath?) media type would be easy to define.

An array of JSON identifiers looks reasonable. Is it your suggestion to 
define that in this draft?

> 
> Section 2:
>> The payload returned in response to a FETCH cannot be assumed to be a 
>> complete representation of the resource identified by the effective 
>> request URI.
> 
> Can't I use FETCH to produce same result as GET? Even if I use it
> without any additional request parameters?

Depends on media type, but by using an array of one JSON identifier, I 
would say yes.

> I'm not sure these references to the HTTP search method draft are of
> any use, rather they are a distraction. Since that draft is expired
> and apparently not going anywhere, I'd suggest simply removing all the
> references. If you want to acknowledge that work, the ACK section is
> better for that.

For me OK.

> content format ID for example purposes.

YEP, could be useful it seems.

> Ari

Cheerio,

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 13 Jul 2016 14:40:28 +0200

> Can't I use FETCH to produce same result as GET? Even if I use it without any additional request parameters?

Depending on the request body media type, you may be able to (it may not
always be obvious that you just did -- the server may have some leeway
in some cases).  This sentence is an admonition not to cache a FETCH
result as if it were a GET result.  (Should we say this more explicitly?)

Grüße, Carsten

---

From: Ari Keränen <[email-masked]>
Date: Thu, 14 Jul 2016 11:44:13 +0000

> On 13 Jul 2016, at 15:40, Carsten Bormann <[email-masked]> wrote:
> 
> Ari Keränen wrote:
>> Section 2:

OK, making it more explicit sounds like a very good idea. 

Cheers,
Ari

---

From: Ari Keränen <[email-masked]>
Date: Thu, 14 Jul 2016 11:44:16 +0000

> On 13 Jul 2016, at 15:28, peter van der Stok <[email-masked]> wrote:
> 
> Hi Ari,
> 
> An array of JSON identifiers looks reasonable. Is it your suggestion to define that in this draft?

What would be the semantics of that array? "Give only these key-value-pairs"? How would that work with nested structures and arrays?

The xpath and jsonpath media types could do that and much more. Some of that complexity may not be good for the most constrained devices though.

Perhaps the most simple thing would be to be able to define arbitrary number of (string?) key-value pairs, like in query parameters, and have resource specific semantics for those. 

I think Carsten has a valid point that these should be driven by real customers, but if we don't have yet any user for this mechanism defined, why are we in a hurry to get it finalized?

> Depends on media type, but by using an array of one JSON identifier, I would say yes.

Or would that be zero identifiers? Anyway, maybe here you could clarify that the reason for above is that media type and the payload of request impact the response, and hence one cannot assume anything based on the URI alone.

Cheers,
Ari

P.S. I removed parts of the thread that were clear already

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Jul 2016 14:00:58 +0200

> I think Carsten has a valid point that these should be driven by real customers, but if we don't have yet any user for this mechanism defined, why are we in a hurry to get it finalized?

As I said, the first customer is COMI.  They can of course work around
the lack of FETCH by coming up with some horrible base64-encoded
Uri-Query parameter encoding hack or some such, and will probably do
this if FETCH does not go through.

The IETF has a long history of inappropriately intermingling the
timelines of unrelated drafts.  RFC 7252 (CoAP) is a great example: Its
publication had to wait for an extra year to go through because of some
petty squabble in the security area about documents that we somehow
didn't prevent from becoming normative references.

I will never knowingly contribute to repeating that kind of mistake again.
Keep dependencies simple.

Grüße, Carsten

---

From: peter van der Stok <[email-masked]>
Date: Thu, 14 Jul 2016 17:19:33 +0200

Carsten Bormann schreef op 2016-07-14 14:00:
> Ari Keränen wrote:
>> I think Carsten has a valid point that these should be driven by real 
>> customers, but if we don't have yet any user for this mechanism 
>> defined, why are we in a hurry to get it finalized?
> 
As one of the authors of CoMI I like to confirm that we have taken pains
to get the FETCH part of this draft of the ground.

Greetings,

Peter

---

From: peter van der Stok <[email-masked]>
Date: Thu, 14 Jul 2016 17:28:00 +0200

What do the
> What would be the semantics of that array? "Give only these
> key-value-pairs"? How would that work with nested structures and
> arrays?
> 
> The xpath and jsonpath media types could do that and much more. Some
> of that complexity may not be good for the most constrained devices
> though.
> 
In CoMI we will define an array of YANG identifiers.
I can imagine that this is confirmed (extended) in a later content 
format draft.

PS.
For the other point I refer to Carsten's e-mails.

Peter

---

From: Ari Keränen <[email-masked]>
Date: Fri, 15 Jul 2016 13:45:42 +0000

> On 14 Jul 2016, at 14:00, Carsten Bormann <[email-masked]> wrote:
> 
> Ari Keränen wrote:

I agree there's bit of a chicken-egg problem here. Considering that CoMI has already stuff coming for this, getting this done makes sense.

Cheers,
Ari