Subject: [core] WG Last Call for draft-ietf-core-http-mapping-11

From: Jaime Jiménez <[email-masked]>
Date: Wed, 22 Jun 2016 10:43:10 +0000

Dear CoRE WG,

we are issuing a WG Last Call for the HTTP Mapping draft: https://tools.ietf.org/html/draft-ietf-core-http-mapping-11

Please send your comments to the mailing list by Wednesday 29th of June. This new version should address the issues raised in the previous call but please check whether the comments have been addressed.

Thank you for the reviews and the help getting this document ready,
- - Jaime Jimenez

---

From: Jaime Jiménez <[email-masked]>
Date: Mon, 27 Jun 2016 12:42:51 +0000

Hi all,

friendly reminder that the call ends on Wednesday 29th.

Ciao!
- - Jaime Jimenez

On 22 Jun 2016, at 12:43, ejajimn <[email-masked]<mailto:[email-masked]>> wrote:

Dear CoRE WG,

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Tue, 28 Jun 2016 18:58:39 +0530

Hi,
Though I was not involved in reviewing the draft in the past but became 
aware about the issues being raised during the Buenos Aires meeting.
Just now I had a look into the draft. It seems to me that the authors have 
addressed the important issues.  This document should be useful from 
implementation perspective.
+1

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: [email-masked]
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________

"core" <[email-masked]> wrote on 06/27/2016 06:12:51 PM:

> From: Jaime Jiménez <[email-masked]>
> To: "[email-masked] WG" <[email-masked]>
> Date: 06/27/2016 06:13 PM
> Subject: Re: [core] WG Last Call for draft-ietf-core-http-mapping-11
> Sent by: "core" <[email-masked]>
> 
> Hi all, 
> 
> On 22 Jun 2016, at 12:43, ejajimn <[email-masked]> wrote:
> 
> Dear CoRE WG, 
> 
> we are issuing a WG Last Call for the HTTP Mapping draft: https://
> tools.ietf.org/html/draft-ietf-core-http-mapping-11 
> 
> Please send your comments to the mailing list by Wednesday 29th of 
> June. This new version should address the issues raised in the 
> previous call but please check whether the comments have been addressed. 

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 28 Jun 2016 18:08:24 +0200

I've reviewed draft-ietf-core-http-mapping-11. All issues that I
raised in my review of -07 have been solved and I haven't found any
new issues.

Klaus

---

From: Christian Groves <[email-masked]>
Date: Wed, 29 Jun 2016 13:31:43 +1000

Hello Jaime,

My comments:

General: This draft doesn't address mapping related to 
draft-ietf-core-etch. Should this be included?

General: As CoAP evolves with new methods, response codes etc. I wonder 
how those will be covered with respect to http mapping. Should there be 
some guidance about the inclusion of a http mapping section in 
subsequent drafts or whether a ietf-core-http-mapping-bis would be 
required with updates?

Nit: section 5.4.2: is the use of "iff" here "if and only if" or is it a 
typo?

Question 5.4.2: The template variable qq is defined. I didn't see a 
description of what this actually is. Is this the query that relates to 
the COAP URI rather than the HOST URI?

Otherwise OK

Regards, Christian

On 27/06/2016 10:42 PM, Jaime Jiménez wrote:
>> On 22 Jun 2016, at 12:43, ejajimn <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Dear CoRE WG,
>>
>> we are issuing a WG Last Call for the HTTP Mapping draft: 
>> https://tools.ietf.org/html/draft-ietf-core-http-mapping-11
>>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Jun 2016 07:56:38 +0200

> draft-ietf-core-etch. Should this be included?

I don't think so.

We could delay http mapping once more and include that aspect once we
have developed a WG view on how to do that.
My personal view is that we have chewed on HTTP mapping for long enough,
so we should (certainly fix the nits and) publish what we have, and
think about HTTP access to FETCH and PATCH some more in the context of
the applications we are developing that make use of them (e.g., COMI).

Grüße, Carsten

---

From: Jaime Jiménez <[email-masked]>
Date: Wed, 29 Jun 2016 09:41:03 +0000

Thanks Christian for the comments, replies inline. 

> 
> My comments:
> 
> General: This draft doesn't address mapping related to draft-ietf-core-etch. Should this be included?

A new section could be added explaining how he HTTP SEARCH method could be invoked from the Browser to the HC Proxy that would map it to a CoAP FETCH towards the device. I presume this mapping will probably not be straightforward. Also a new table could be added with the Supported Methods for CoAP and HTTP (similar to Section 7).

All of this would take quite a bit of time and, as Carsten pointed out the HTTP mapping for quite a bit. The tentative IESG submission is for the 16-07-15 but it can be pushed for later. I would very much like to hear the thoughts of the authors about FETCH and PATCH. 

> 
> General: As CoAP evolves with new methods, response codes etc. I wonder how those will be covered with respect to http mapping. Should there be some guidance about the inclusion of a http mapping section in subsequent drafts or whether a ietf-core-http-mapping-bis would be required with updates?
> 
> Nit: section 5.4.2: is the use of "iff" here "if and only if" or is it a typo?
> 
> Question 5.4.2: The template variable qq is defined. I didn't see a description of what this actually is. Is this the query that relates to the COAP URI rather than the HOST URI?

The authors should address the nits and question 5.4.2 in the draft.  

>>> On 22 Jun 2016, at 12:43, ejajimn <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Dear CoRE WG,
>>>

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Wed, 29 Jun 2016 10:35:50 +0000

Hi Jaime,

On 29/06/2016 10:41, "core on behalf of Jaime Jiménez"
<[email-masked] on behalf of [email-masked]> wrote:
>A new section could be added explaining how he HTTP SEARCH method could
>be invoked from the Browser to the HC Proxy that would map it to a CoAP
>FETCH towards the device. I presume this mapping will probably not be
>straightforward. Also a new table could be added with the Supported
>Methods for CoAP and HTTP (similar to Section 7).
>
>All of this would take quite a bit of time and, as Carsten pointed out
>the HTTP mapping for quite a bit. The tentative IESG submission is for
>the 16-07-15 but it can be pushed for later. I would very much like to
>hear the thoughts of the authors about FETCH and PATCH.

I'd rather add a section to etch that updates http-mapping to show how the
various HTTP-CoAP mapping dimensions are supposed to work with
FETCH/PATCH, than the other way around.

It looks like a more scalable approach, and one that could be applied to
future CoAP extensions as well.

>The authors should address the nits and question 5.4.2 in the draft.

Yep, thanks.

Cheers, t

---

From: Jaime Jiménez <[email-masked]>
Date: Wed, 29 Jun 2016 11:00:51 +0000

> On 29 Jun 2016, at 12:35, Fossati, Thomas (Nokia - GB) <[email-masked]> wrote:
> 
> Hi Jaime,
> 

I think adding FETCH is probably reasonable, but I am just worried that other new methods might be trickier to add. 
We could go on like this for an undetermined amount of time as CoAP will be growing in functionality.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Jun 2016 13:02:51 +0200

> future CoAP extensions as well.

I completely agree with this as the general approach: each extension
should define its interactions with existing things, as opposed as
existing (nearly finished) things being held up by interactions with
(newer) extensions.

In this specific case, we don't have a lot of existing practice to
recommend something from.  I therefore think that an even better
approach is to collect the (informational) additions that the various
pieces of work bring to HTTP-mapping into an additional document or an
update to HTTP-mapping, at a schedule that is decoupled from the base
-etch spec.  We could start collecting information for that now.

Grüße, Carsten

---

From: Jaime Jiménez <[email-masked]>
Date: Wed, 29 Jun 2016 11:22:21 +0000

> On 29 Jun 2016, at 13:00, Jaime Jiménez <[email-masked]> wrote:
> 
>> 

Ups, sorry I just re-read, you meant adding it on the ETCH draft. That’d be a good idea I think we should go with that. We could ship the HTTP-mapping as is.  You could submit a new version addressing the nits and comments below and leave FETCH/PATCH HTTP mapping for ETCH draft. If everyone is OK I will close the call, please let me know today if there are comments.

---

From: peter van der Stok <[email-masked]>
Date: Wed, 29 Jun 2016 13:33:12 +0200

Hi Carsten,

I agree with the general approach as well.
Collecting every http-coap mapping extension in an additional document 
sounds appealing.
BUT..... who is going to write it?

Although collecting work is not my favored pastime, extending the etch 
draft with the relevant http-coap mapping looks more robust.

Peter

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Wed, 29 Jun 2016 11:59:21 +0000

On 29/06/2016 12:22, "core on behalf of Jaime Jiménez"
<[email-masked] on behalf of [email-masked]> wrote:
>You could submit a new version addressing the nits and comments below and
>leave FETCH/PATCH HTTP mapping for ETCH draft.

OK -- I'll wait until tomorrow though, in case there are other comments.

>If everyone is OK I will close the call, please let me know today if
>there are comments.

+1

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Jun 2016 14:06:14 +0200

> draft with the relevant http-coap mapping looks more robust.

There is a chicken-and-egg problem here:

We won't collect enough experience with mapping FETCH and PATCH to and
from HTTP unless we have it first ias an accepted element in CoAP.  So,
in effect, delaying the -etch draft while waiting for this experience is
a recipe for tabling FETCH/PATCH indefinitely.

Grüße, Carsten

---

From: Christian Groves <[email-masked]>
Date: Thu, 30 Jun 2016 09:27:01 +1000

Hello

I agree with taking a modular approach and adding a HTTP mapping section 
to the Etch draft. That's why I asked in my second comment about whether 
we should add some words in the html draft about that additional 
mappings should be covered by the drafts that add additional elements.
I wouldn't have a separate just just for additional mappings alone.

Regards, Christian

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Thu, 30 Jun 2016 04:02:39 +0000

Hi Christian,

>I wouldn't have a separate just just for additional mappings alone.

How about:

   Any future specification of CoAP protocol elements such as methods,
   options and status codes, should also describe the HTTP mappings for
   each newly defined element.

Cheers, t

---

From: Christian Groves <[email-masked]>
Date: Thu, 30 Jun 2016 15:13:32 +1000

Hello Thomas,

Works for me.

Thanks, Christian

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Thu, 30 Jun 2016 05:53:35 +0000

>Works for me.

Thanks Christian.

Peter, Carsten: is it OK for you as well?  Or do you want to propose a
different wording?

As soon as we agree on the text I plan to add it to the introduction,
solve the other comments from Christian and push -12.

Cheers, t

---

From: peter van der Stok <[email-masked]>
Date: Thu, 30 Jun 2016 11:02:24 +0200

Slightly weaker phrasing

Any future specification of CoAP protocol elements such as methods,
options and status codes, should also describe the HTTP mappings for
each newly defined element' or the document where this mapping will be 
described.

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 30 Jun 2016 12:44:10 +0200

> Peter, Carsten: is it OK for you as well?  Or do you want to propose a

I'm not sure this is the place to make mandates about what other
specifications will be.

I'd rather say that this document describes base CoAP (insert
references) and it is up to extensions... to describe their HTTP mapping.

(Specific example: I don't think we should nail down an HTTP mapping
for FETCH/PATCH at the same time we nail down the CoAP side.  Just as we
nailed down RFC 7252 before completing the HTTP mapping informational
document.)

Grüße, Carsten