Subject: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07

From: Carsten Bormann <[email-masked]>
Date: Tue, 15 Sep 2015 17:20:50 +0200

In Prague, we said we were going to WGLC the HTTP mapping draft after
close of the vacation period, which is now behind us.  All outstanding
tickets are closed, and there was enough time to review the current
draft.  Three people raised their hands when we asked who would submit
reviews (Michael K., Klaus, Darshak), but of course additional reviews
beyond that are also very useful.

So this starts a working group last call for
draft-ietf-core-http-mapping for submission as an informational RFC,
ending on

  24:00 PDT on Tuesday, September 29, 2015.

The draft is located at:
https://tools.ietf.org/html/draft-ietf-core-http-mapping-07

Please start a new email thread for each major issue that will need
discussion and make sure the subject line includes the draft name and
some sort of name for the issue. For minor issues such as typos and
things that are not likely to lead to much discussion, it is probably
easier to group them all in to one email but again, please make sure
the subject line includes the draft name. If you read the draft and
think it looks fine, please send a one line email to the list or to
the chairs letting us know that so we can get a feel of how broad the
review has been.

In the unlikely event that you are aware of any patent claims that
might apply to systems that implement the suggestions in this draft,
please review BCP 78 and BCP 79 and make any appropriate IPR
declaration. If you are not sure whether you need to make a
declaration or not, please talk to the chairs and we will help get you
in touch with people that can provide appropriate advice.

Grüße, Carsten

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Thu, 17 Sep 2015 15:04:26 +0530

Dear all,
I think this draft is indeed an appreciable effort as it will ease out 
many implementation decisions for the developers and should be very useful 
as an RFC.

Dear authors,
I have one small comment :
Given that No-Response now has a number (284) from IANA in the CoRE option 
registry (
http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#option-numbers
) probably it will be a good idea to keep a section to discuss how to 
handle this option since this is not there in HTTP. Somewhere in Section 8 
should be a good place for such discussion. 

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
____________________________________________

From:   Carsten Bormann <[email-masked]>
To:     "[email-masked] WG" <[email-masked]>
Date:   09/15/2015 08:51 PM
Subject:        [core] WG last-call (WGLC) of 
draft-ietf-core-http-mapping-07
Sent by:        "core" <[email-masked]>

The draft is located at:

Grüße, Carsten

_______________________________________________
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: "Rahman, Akbar" <[email-masked]>
Date: Wed, 23 Sep 2015 18:00:25 +0000

Hi Abhijan,

Thanks for your support on the draft!

With regards to your question:

> Given that No-Response now has a number (284) from IANA in the CoRE option registry (http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#option-numbers) probably it will be a good idea to keep a section to discuss how to handle this option since this is not there in HTTP. Somewhere in Section 8 should be a good place for such discussion.

Yes, I agree this is a good topic to add to the draft.  How about something based on the following text:

--------------------------------
8.8 CoAP No Response

CoAP supports sending a Request indicating that "No Response" is required when the CoAP header option number is set to 284.  An HC Proxy may translate an incoming HTTP Request to a corresponding CoAP Request indicating that no response is required following the guidance in (Ref: http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#option-numbers).

---------------------------------

Any feedback?

/Akbar

From: core [mailto:[email-masked]] On Behalf Of Abhijan Bhattacharyya
Sent: Thursday, September 17, 2015 5:34 AM
To: Carsten Bormann <[email-masked]>
Cc: core <[email-masked]>; [email-masked] WG <[email-masked]>
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07

Dear all,
I think this draft is indeed an appreciable effort as it will ease out many implementation decisions for the developers and should be very useful as an RFC.

Dear authors,
I have one small comment :
Given that No-Response now has a number (284) from IANA in the CoRE option registry (http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#option-numbers) probably it will be a good idea to keep a section to discuss how to handle this option since this is not there in HTTP. Somewhere in Section 8 should be a good place for such discussion.

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

From:        Carsten Bormann <[email-masked]<mailto:[email-masked]>>
To:        "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
Date:        09/15/2015 08:51 PM
Subject:        [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
Sent by:        "core" <[email-masked]<mailto:[email-masked]>>
________________________________

The draft is located at:

Grüße, Carsten

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

---

From: "weigengyu" <[email-masked]>
Date: Thu, 24 Sep 2015 16:10:50 +0800

Hi， 

When a http client accesses a CoAP server, 
how does the CoAP client of HC proxy create a NON-reposnse option since there is not in HTTP. 
Or it is useless for HC proxy, or not? 

Regards,

Gengyu WEI
Network Technology Center
School of Computer 
Beijing University of Posts and Telecommunications

From: Rahman, Akbar 
Sent: Thursday, September 24, 2015 2:00 AM
To: Abhijan Bhattacharyya ; Carsten Bormann 
Cc: mailto:[email-masked] ; core 
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07

Hi Abhijan,

 

8.8 CoAP No Response

CoAP supports sending a Request indicating that “No Response” is required when the CoAP header option number is set to 284.  An HC Proxy may translate an incoming HTTP Request to a corresponding CoAP Request indicating that no response is required following the guidance in (Ref: http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#option-numbers).

 

Any feedback?

/Akbar

Dear all, 

Dear authors, 

Regards
Abhijan Bhattacharyya
Associate Consultant

To:        "mailto:[email-masked]%20WG" <[email-masked]> 

--------------------------------------------------------------------------------

The draft is located at:

Grüße, Carsten

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

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Thu, 24 Sep 2015 18:22:54 +0530

Hi Akbar,
Thanks.

Taking clue from Gengyu's response I would like to share the following 
input:

The decision to convert an HTTP request to a CoAP request with "No 
Response" should be purely based on the application context. 
Let us consider a scenario. 
We want to operate the lights of a building from a remote control-center 
(controlling commands may not be essentially multicast). Let us assume 
that the control-center has legacy HTTP infrastructure. But the lights are 
CoAP enabled. So the requests from the control-center goes through an HC 
proxy. The application requirement, in that case, will decide whether the 
requests from HTTP client are to be made CoAP requests with No-Response or 
not. 

But, there is one point. The HTTP client needs a response as per the HTTP 
protocol requirements. So, what response should proxy return? 
Looking at Table 2 of the http mapping draft we see that CoAP's 2.04 
(Changed) is mapped to either 200 (OK) or 204 (No Content) for the HTTP. 
Can we suggest that in cases as described above the proxy SHOULD respond 
with the status code: 204  No Content ? This way the client knows that 
No-Response is enabled at the CoAP side for the particular PUTs.

Does it make sense?

Regards
Abhijan Bhattacharyya
Associate Consultant

"weigengyu" <[email-masked]> wrote on 09/24/2015 01:40:50 PM:

> From: "weigengyu" <[email-masked]>
> To: "Rahman, Akbar" <[email-masked]>, "Abhijan 
> Bhattacharyya" <[email-masked]>, "Carsten Bormann" 
> <[email-masked]>
> Cc: <[email-masked]>, "core" <[email-masked]>
> Date: 09/24/2015 01:50 PM
> > Given that No-Response now has a number (284) from IANA in the 
> CoRE option registry (http://www.iana.org/assignments/core-
> parameters/core-parameters.xhtml#option-numbers) probably it will be
> a good idea to keep a section to discuss how to handle this option 
> since this is not there in HTTP. Somewhere in Section 8 should be a 
> good place for such discussion. 

> CoAP supports sending a Request indicating that “No Response” is 
> required when the CoAP header option number is set to 284.  An HC 
> Proxy may translate an incoming HTTP Request to a corresponding CoAP
> Request indicating that no response is required following the guidance 
in 
> (Ref: http://www.iana.org/assignments/core-parameters/core-
> parameters.xhtml#option-numbers).
> 
> I think this draft is indeed an appreciable effort as it will ease 
> out many implementation decisions for the developers and should be 
> very useful as an RFC. 
> 
> Dear authors, 
> Given that No-Response now has a number (284) from IANA in the CoRE 
> option registry (http://www.iana.org/assignments/core-parameters/
> core-parameters.xhtml#option-numbers) probably it will be a good 
> idea to keep a section to discuss how to handle this option since 
> this is not there in HTTP. Somewhere in Section 8 should be a good 
> place for such discussion. 
> 
> 
> 
> Regards
> Abhijan Bhattacharyya
> Associate Consultant

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 24 Sep 2015 16:59:55 +0000

Hi Abhijan,

Okay, please review the updated proposed text for draft-ietf-core-http-mapping based on the feedback from Carsten, Weigengyu and you.

--------------------------------
(New) Section 8.x “Use of CoAP No Response”:

CoAP supports sending a Request indicating that “No Response” is required when the CoAP header option number is set to 284 [see Ref-1].  An HC Proxy may translate an incoming HTTP Request to a corresponding CoAP Request indicating that No Response is required based on some application knowledge (see [Ref-2] for further guidance).  In this case, it is recommend that the HC Proxy SHOULD send an HTTP Response with status code 204 (No Content).

[Ref-1] - http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#option-numbers

[Ref-2] - https://tools.ietf.org/html/draft-tcs-coap-no-response-option-11

Also, Abhijan, it may be good for you to put the application scenario you outlined below in your draft-tcs-coap-no-response-option as that should be document that contains all such guidance information.

Do you agree?

/Akbar

From: Abhijan Bhattacharyya [mailto:[email-masked]]
Sent: Thursday, September 24, 2015 8:53 AM
To: weigengyu <[email-masked]>; Rahman, Akbar <[email-masked]>
Cc: Carsten Bormann <[email-masked]>; [email-masked]; core <[email-masked]>
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07

Hi Akbar,
Thanks.

Taking clue from Gengyu's response I would like to share the following input:

The decision to convert an HTTP request to a CoAP request with "No Response" should be purely based on the application context.
Let us consider a scenario.
We want to operate the lights of a building from a remote control-center (controlling commands may not be essentially multicast). Let us assume that the control-center has legacy HTTP infrastructure. But the lights are CoAP enabled. So the requests from the control-center goes through an HC proxy. The application requirement, in that case, will decide whether the requests from HTTP client are to be made CoAP requests with No-Response or not.

But, there is one point. The HTTP client needs a response as per the HTTP protocol requirements. So, what response should proxy return?
Looking at Table 2 of the http mapping draft we see that CoAP's 2.04 (Changed) is mapped to either 200 (OK) or 204 (No Content) for the HTTP. Can we suggest that in cases as described above the proxy SHOULD respond with the status code: 204  No Content ? This way the client knows that No-Response is enabled at the CoAP side for the particular PUTs.

Does it make sense?

Regards
Abhijan Bhattacharyya
Associate Consultant

"weigengyu" <[email-masked]<mailto:[email-masked]>> wrote on 09/24/2015 01:40:50 PM:

> From: "weigengyu" <[email-masked]<mailto:[email-masked]>>
> To: "Rahman, Akbar" <[email-masked]<mailto:[email-masked]>>, "Abhijan
> Bhattacharyya" <[email-masked]<mailto:[email-masked]>>, "Carsten Bormann"
> <[email-masked]<mailto:[email-masked]>>
> Cc: <[email-masked]<mailto:[email-masked]>>, "core" <[email-masked]<mailto:[email-masked]>>

> Request indicating that no response is required following the guidance in
> To: Carsten Bormann <[email-masked]<mailto:[email-masked]>>
> Cc: core <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>
> To:        "mailto:[email-masked]%20WG" <[email-masked]<mailto:[email-masked]>>

---

From: "weigengyu" <[email-masked]>
Date: Fri, 25 Sep 2015 09:36:57 +0800

Hi Abhijan, 

Thank you for your explainations.

For CoAP to CoAP proxy, there is not any question to use a NON-response option 
if the CoAP2CoAP Proxy does not have any knowledge about applications.

It is questionalbe that whether the HC proxoy needs to unstandstand application sematics. 
Is it required, or not? 

Regards,

Gengyu WEI

From: Rahman, Akbar 
Sent: Friday, September 25, 2015 12:59 AM
To: Abhijan Bhattacharyya ; weigengyu 
Cc: Carsten Bormann ; [email-masked] ; core 
Subject: RE: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07

Hi Abhijan,

 

 

 

Do you agree?

/Akbar

Hi Akbar, 
Thanks. 

Does it make sense? 

Regards
Abhijan Bhattacharyya
Associate Consultant

---

From: "weigengyu" <[email-masked]>
Date: Fri, 25 Sep 2015 10:52:17 +0800

Hi Abhijan, 

It is questionable that whether the HC proxy needs to unstandstand application semantics 
when translating HTTP message into CoAP message. 
Is it required, or not? 

Sorry for typing errors in last email. 

Regards,

Gengyu WEI

From: Rahman, Akbar 

Hi Abhijan,

 

 

 

Do you agree?

/Akbar

Hi Akbar, 
Thanks. 

Does it make sense? 

Regards
Abhijan Bhattacharyya
Associate Consultant

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Sun, 27 Sep 2015 16:07:42 +0530

Hi Akbar,
Thanks!

Hi Gengyu,

>Is it required, or not? 
What we intend to ensure is that if any application has a demand to optimize resources with No-Response option at the CoAP end while the request originates at the HTTP side, then there should be some guidance in the draft stating how to handle such situation. It is purely application specific consideration.

Regards
Abhijan Bhattacharyya
Associate Consultant

-----"weigengyu" <[email-masked]> wrote: -----

>Bhattacharyya" <[email-masked]>
>Date: 09/25/2015 07:07AM
>Cc: "Carsten Bormann" <[email-masked]>, <[email-masked]>, "core"
><[email-masked]>
>For CoAP to CoAP proxy, there is not any question to use a
>NON-response 
>option 
>Gengyu 
>WEI
>Hi 
>Abhijan,
>Okay, 
>please review the updated proposed text for
>draft-ietf-core-http-mapping based 
>on the feedback from Carsten, Weigengyu and you.
> 
> 
>(New) 
>Section 8.x &#8220;Use of CoAP No Response&#8221;:
> 
>CoAP 
>supports sending a Request indicating that &#8220;No Response&#8221; is required
>when the 
>CoAP header option number is set to 284 [see Ref-1].  An HC Proxy may
>
>translate an incoming HTTP Request to a corresponding CoAP Request
>indicating 
>that No Response is required based on some application knowledge (see
>[Ref-2] 
>for further guidance).  In this case, it is recommend that the HC
>Proxy 
>SHOULD send an HTTP Response with status code 204 (No 
>Content).
> 
>[Ref-1] -
>[Ref-2] 
>- https://tools.ietf.org/html/draft-tcs-coap-no-response-option-11
> 
>Also, 
>Abhijan, it may be good for you to put the application scenario you
>outlined 
>below in your draft-tcs-coap-no-response-option as that should be
>document that 
>contains all such guidance information.
> 
> 
>Do 
>you agree?
> 
> 
>/Akbar
> 
> 
> 
>From: Abhijan 
>Bhattacharyya [mailto:[email-masked]] 
>Sent: Thursday, 
>To: weigengyu 
><[email-masked]>; Rahman, Akbar 
><[email-masked]>
>Cc: Carsten Bormann 
><[email-masked]>; [email-masked]; core 
><[email-masked]>
>Taking 
>clue from Gengyu's response I would like to share the following
>input: 
>
>
>The 
>decision to convert an HTTP request to a CoAP request with "No
>Response" should 
>be purely based on the application context. 
>Let us consider a 
>scenario. 
>We want to operate the 
>lights of a building from a remote control-center (controlling
>commands may not 
>be essentially multicast). Let us assume that the control-center has
>legacy HTTP 
>infrastructure. But the lights are CoAP enabled. So the requests from
>the 
>control-center goes through an HC proxy. The application requirement,
>in that 
>case, will decide whether the requests from HTTP client are to be
>made CoAP 
>requests with No-Response or not. 
>
>But, there is one 
>point. The HTTP client needs a response as per the HTTP protocol
>requirements. 
>So, what response should proxy return? 
>Looking at Table 2 of 
>the http mapping draft we see that CoAP's 2.04 (Changed) is mapped to
>either 200 
>(OK) or 204 (No Content) for the HTTP. Can we suggest that in cases
>as described 
>above the proxy SHOULD respond with the status code: 204  No Content 
>? This way the client knows that No-Response is enabled at the CoAP
>side for the 
>particular PUTs. 
>
>Does it make 
>sense? 
>
>
>Regards
>Abhijan 
>Bhattacharyya
>Associate Consultant
>Experience 
>certainty.        IT 
>Services
>Business 
>Solutions
>> Bhattacharyya" 
><[email-masked]>, 
>"Carsten Bormann" 
>> <[email-masked]> 
>> Subject: Re: [core] WG last-call 
>(WGLC) of draft-ietf-core-http-mapping-07 
>> 
>> 
>HiC 
>>ÿ 
>> how does the CoAP client 
>of HC proxy create a NON-reposnse option 
>> since there is 
>not in HTTP. 
>> Or it is 
>>ÿ 
>>ÿ 
>> Network 
>Technology Center
>> Beijing 
>University of Posts and Telecommunications 
>>ÿ 
>> From: Rahman, Akbar 
>>ÿ 
>>ÿ 
>>ÿ 
>>ÿ 
>>ÿ 
>> CoRE option 
>registry (http://www.iana.org/assignments/core-
>> 
>>ÿ 
>> Yes, I agree this is a 
>good topic to add to the draft.ÿ How about 
>> something based 
>on the following text: 
>>ÿ 
>>ÿ 
>> CoAP supports sending a Request indicating that &#8220;No 
>Response&#8221; is 
>> required when 
>the CoAP header option number is set to 284.ÿ An HC 
>> Proxy 
>may translate an incoming HTTP Request to a corresponding CoAP
>> 
>>ÿ 
>>ÿ 
>>ÿ 
>>ÿ 
>>ÿ 
>>ÿ 
>>ÿ 
>> Subject: Re: 
>[core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07 
>
>>ÿ 
>> Dear all, 
>> I think this 
>draft is indeed an appreciable effort as it will ease 
>> out many 
>implementation decisions for the developers and should be 
>> very 
>useful as an RFC. 
>> 
>> Dear authors, 
>
>> Given that 
>No-Response now has a number (284) from IANA in the CoRE 
>> 
>> Tata Consultancy 
>Services
>> Experience 
>certainty.ÿÿÿÿÿÿÿ IT 
>Services
>>ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 
>Business 
>Solutions
>>ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 
>From:ÿÿÿÿÿÿÿ Carsten Bormann <[email-masked]> 
>> 
>To:ÿÿÿÿÿÿÿ "mailto:[email-masked]%20WG" <[email-masked]> 
>> 
>Date:ÿÿÿÿÿÿÿ 09/15/2015 08:51 PM 
>
>> Subject:ÿÿÿÿÿÿÿ [core] WG 
>last-call (WGLC) of draft-ietf-core-http-mapping-07
>> Sent 
>by:ÿÿÿÿÿÿÿ "core" <[email-masked]> 
>
>> 
>> 
>
>> 
>> 
>> In Prague, we said we were 
>going to WGLC the HTTP mapping draft after
>> close of the 
>vacation period, which is now behind us.ÿ All outstanding
>> 
>> draft.ÿ Three people raised their hands when we 
>asked who would submit
>> The 
>draft is located at:
>> the subject line includes 
>the draft name. If you read the draft and
>> think it looks fine, 
>please send a one line email to the list or to
>> the chairs 
>letting us know that so we can get a feel of how broad the
>> 
>review has been.
>> 
>> might apply to systems 
>that implement the suggestions in this draft,
>> please review BCP 
>78 and BCP 79 and make any appropriate IPR
>> declaration. If you 
>> declaration or not, 
>please talk to the chairs and we will help get you
>> in touch 
>with people that can provide appropriate advice.
>> 
>
>> Gráe, Carsten
>> 
>> 
>> core mailing 
>list
>> core mailing 
>list

---

From: "weigengyu" <[email-masked]>
Date: Mon, 28 Sep 2015 12:09:12 +0800

Hi Abhijan, 

thank you for your explanations. 

> if any application has a demand to optimize resources with No-Response option at the CoAP end while the request originates at the HTTP side, 
> then there should be some guidance in the draft stating how to handle such situation.
> It is purely application specific consideration.

Yes.  
I wonder how much intelligence on applications the HC proxy should have, 
and whether the HC proxy draft should touch it. 

Regards,

Gengyu WEI

From: Abhijan Bhattacharyya 
Sent: Sunday, September 27, 2015 6:37 PM
To: weigengyu 
Cc: [email-masked] ; Carsten Bormann ; [email-masked] ; core 
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07

Hi Akbar,
Thanks!

Hi Gengyu,

Regards
Abhijan Bhattacharyya
Associate Consultant

>Section 8.x “Use of CoAP No Response”:
> 
>CoAP 
>supports sending a Request indicating that “No Response” is required
>when the 
>good topic to add to the draft.  How about 
>> something based 
>on the following text: 
>>  
>the CoAP header option number is set to 284.  An HC 
>> Proxy 
>> Subject:        [core] WG 
>by:        "core" <[email-masked]> 
>
>> 
>> 
>
>> 
>> 
>vacation period, which is now behind us.  All outstanding
>>

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Mon, 28 Sep 2015 10:46:14 +0530

Hi Akbar,

> Also, Abhijan, it may be good for you to put the application 
> scenario you outlined below in your draft-tcs-coap-no-response-
> option as that should be document that contains all such guidance 
information.
> Do you agree?

Let us collect all the comments within the deadline (2015-10-12) set by 
Carsten then we may decide the modifications collectively. 

Regards
Abhijan Bhattacharyya
Associate Consultant

"Rahman, Akbar" <[email-masked]> wrote on 09/24/2015 
10:29:55 PM:

> From: "Rahman, Akbar" <[email-masked]>
> To: Abhijan Bhattacharyya <[email-masked]>, weigengyu
> <[email-masked]>
> Cc: Carsten Bormann <[email-masked]>, "[email-masked]" <[email-masked]>,
> core <[email-masked]>
> Date: 09/24/2015 10:30 PM
> Okay, please review the updated proposed text for draft-ietf-core-
> http-mapping based on the feedback from Carsten, Weigengyu and you.
> 
> 
> required when the CoAP header option number is set to 284 [see 
> Ref-1].  An HC Proxy may translate an incoming HTTP Request to a 
> corresponding CoAP Request indicating that No Response is required 
> based on some application knowledge (see [Ref-2] for further 
> guidance).  In this case, it is recommend that the HC Proxy SHOULD 
> send an HTTP Response with status code 204 (No Content).
> 
> [Ref-2] - 
https://tools.ietf.org/html/draft-tcs-coap-no-response-option-11
> Also, Abhijan, it may be good for you to put the application 
> scenario you outlined below in your draft-tcs-coap-no-response-
> option as that should be document that contains all such guidance 
information.
input:
> We want to operate the lights of a building from a remote control-
> center (controlling commands may not be essentially multicast). Let 
> us assume that the control-center has legacy HTTP infrastructure. 
> But the lights are CoAP enabled. So the requests from the control-
> center goes through an HC proxy. The application requirement, in 
> that case, will decide whether the requests from HTTP client are to 
> be made CoAP requests with No-Response or not. 
> 
> But, there is one point. The HTTP client needs a response as per the
> HTTP protocol requirements. So, what response should proxy return? 
> (Changed) is mapped to either 200 (OK) or 204 (No Content) for the 
> HTTP. Can we suggest that in cases as described above the proxy 
> SHOULD respond with the status code: 204  No Content ? This way the 
> client knows that No-Response is enabled at the CoAP side for the 
> particular PUTs. 
> 
> Does it make sense? 
> 
> 
> Regards
> Abhijan Bhattacharyya
> Associate Consultant
in

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 28 Sep 2015 16:08:41 +0200

Here's my review of draft-ietf-core-http-mapping-07:

Overall -- the document is 'Informational', but it makes a lot of use
of requirement keywords (SHOULD, MUST, etc.). Do these keywords
indicate conformance requirements? What happens if a proxy
implementation ignores any of the requirements? Where do
interoperability problems occur in this case? Please review all
occurrences of a requirement keywords in the document and verify that
is really necessary for interoperability. Explain what happens when a
proxy implementation fails to implement a requirement keyword. IMHO
the only requirement is really that the proxy MUST keep up the
illusion that it is an HTTP origin server; everything else seems to be
OPTIONAL to me.

1. "is to reduce variation between proxy implementations, thereby
increasing interoperability" -- where do these interoperability
problems occur? A HTTP-CoAP cross-protocol reverse proxy appears as an
origin server to the HTTP client, so for the HTTP client any such
proxy looks the same.

5. "base URI" -- the term "base URI" has a well-defined meaning in the
context of URI reference resolution (RFC 3986, Section 5). You're
using it here for something else, which is confusing. Please use a
different term.

5.2 "The default URI mapping function is RECOMMENDED to be
implemented" -- why? What happens when this requirement is ignored?

5.3 -- I don't understand this section. What is this? Why do we need
this? How is this different from the default mapping in Section 5.2?
Who uses these templates, the client or the proxy?

5.3 -- Section 5.2 defines a default mapping, 5.3.1 seems to define
three additional mappings, 5.3.2 seems to define yet another mapping.
Section 1 says that one goal of the spec "is to reduce variation
between proxy implementations, thereby increasing interoperability".
How does this multitude of mappings reduce variability?

5.4 -- "to discover the proxy function, the HC proxy SHOULD publish
information related to the location and syntax of the HC proxy
function" -- the proxy is a reverse proxy. It appears as an origin
server to any client. Why does the proxy function need to be
discovered? Who are the "third parties"?

5.4.1 -- Section 5.4 is about discovering the proxy function, 5.4.1 is
about discovering resources, 5.4.2 is about discovering the proxy
function again. This is confusing.

5.4.2 "The first example exercises the CoAP interface" -- why does a
CoAP client need to discover a HTTP-CoAP proxy?

6.5.2. -- to keep the illusion up that the proxy is an origin server,
the proxy MUST rewrite _all_ URIs in _all_ representation formats, not
just Link Formats. This includes _all_ URIs generated on-the-fly by
JavaScript code! Unless the proxy has a very deep understanding of the
application, this is generally not possible. But a reverse proxy with
a very deep understanding of the application is unlikely to use any of
the URI mapping schemes defined in the document. So basically the
whole Section 5 is useless.

6.5.3. "the CoAP diagnostic payload must be used as the HTTP
reason-phrase of the HTTP status line" -- a diagnostic payload is
similar to the HTTP reason phrase, but it can be much more verbose
and, e.g., can include CR-LF line breaks. It's probably best to stick
the diagnostic payload into the payload and use the default reason
phrase for the status code.

7. "4.02 Bad Option | 400 Bad Request" -- can the HTTP client make a
change to its request so that the proxy does not include the bad
option in its CoAP request? If not, the bad option is the proxy's
fault (5xx status code) and not the HTTP client's fault (4xx status
code).

7. "The proxy receiving 2.03 updates the freshness of its cached
representation and returns the entire representation to the HTTP
client." -- If the proxy receives a response indicating that the etag
supplied by the HTTP client is valid, why does the proxy need to send
the representation to the client?

7. "If the HC proxy does not implement a proper authentication method
that can be used to gain access to the target CoAP resource, it can
include a 'dummy' challenge for example "WWW-Authenticate: None"." --
if the proxy cannot gain access to the CoAP resource, it should
probably return a 403 (Forbidden) status code to the HTTP client.

7. "In this case the HC Proxy SHOULD also return a HTTP reason-phrase
in the HTTP status line that starts with the string "405" in order to
facilitate troubleshooting." -- this leads to a status line like
"HTTP/1.1 400 405 Method Not Allowed" which looks wrong and may
confuse implementers.

7. "The value of the HTTP "Retry-After" response-header field is taken
from the value of the CoAP Max-Age Option, if present." -- if the
Max-Age Option is not present, it means that the Max-Age is 60
seconds, not that the representation doesn't have a Max-Age.

8.1 "An HC proxy SHOULD limit the number of requests to CoAP servers
by responding, where applicable, with a cached representation of the
resource." -- The proxy actually MUST perform congestion control as
specified in RFC 7252. Caching is not about congestion control, it is
about efficiency. So, as a matter of quality of implementation, it is
a good idea for a proxy to implement caching. But responding with a
cached representation of the resource is not a tool to enforce
congestion control.

8.1 "Duplicate idempotent pending requests by an HC proxy to the same
CoAP resource SHOULD in general be avoided, by using the same response
for multiple requesting HTTP clients without duplicating the CoAP
request." -- this is not how caching in CoAP works. Please read RFC
7252.

8.1 "According to [RFC7252], a proxy MUST limit the number of
outstanding interactions to a given CoAP server to NSTART." -- this
has already been specified in RFC 7252. There is no need to repeat
that here.

9.2 -- have you submitted the registration to the [email-masked]
mailing list for review? It's probably a good idea to do this before
sending the document to the IESG.

Are there any implementations of this document?

Klaus

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 29 Sep 2015 14:59:12 +0000

Thanks Klaus for your review comments! I hope to go through these in the coming days and then discuss with my co-authors how to address the open issues.

Regards
Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Klaus Hartke
Sent: Monday, September 28, 2015 16:09
To: [email-masked] WG <[email-masked]>
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07

Overall -- the document is 'Informational', but it makes a lot of use of requirement keywords (SHOULD, MUST, etc.). Do these keywords indicate conformance requirements? What happens if a proxy implementation ignores any of the requirements? Where do interoperability problems occur in this case? Please review all occurrences of a requirement keywords in the document and verify that is really necessary for interoperability. Explain what happens when a proxy implementation fails to implement a requirement keyword. IMHO the only requirement is really that the proxy MUST keep up the illusion that it is an HTTP origin server; everything else seems to be OPTIONAL to me.

1. "is to reduce variation between proxy implementations, thereby increasing interoperability" -- where do these interoperability problems occur? A HTTP-CoAP cross-protocol reverse proxy appears as an origin server to the HTTP client, so for the HTTP client any such proxy looks the same.

5. "base URI" -- the term "base URI" has a well-defined meaning in the context of URI reference resolution (RFC 3986, Section 5). You're using it here for something else, which is confusing. Please use a different term.

5.2 "The default URI mapping function is RECOMMENDED to be implemented" -- why? What happens when this requirement is ignored?

5.3 -- I don't understand this section. What is this? Why do we need this? How is this different from the default mapping in Section 5.2?
Who uses these templates, the client or the proxy?

5.3 -- Section 5.2 defines a default mapping, 5.3.1 seems to define three additional mappings, 5.3.2 seems to define yet another mapping.
Section 1 says that one goal of the spec "is to reduce variation between proxy implementations, thereby increasing interoperability".
How does this multitude of mappings reduce variability?

5.4 -- "to discover the proxy function, the HC proxy SHOULD publish information related to the location and syntax of the HC proxy function" -- the proxy is a reverse proxy. It appears as an origin server to any client. Why does the proxy function need to be discovered? Who are the "third parties"?

5.4.1 -- Section 5.4 is about discovering the proxy function, 5.4.1 is about discovering resources, 5.4.2 is about discovering the proxy function again. This is confusing.

5.4.2 "The first example exercises the CoAP interface" -- why does a CoAP client need to discover a HTTP-CoAP proxy?

6.5.2. -- to keep the illusion up that the proxy is an origin server, the proxy MUST rewrite _all_ URIs in _all_ representation formats, not just Link Formats. This includes _all_ URIs generated on-the-fly by JavaScript code! Unless the proxy has a very deep understanding of the application, this is generally not possible. But a reverse proxy with a very deep understanding of the application is unlikely to use any of the URI mapping schemes defined in the document. So basically the whole Section 5 is useless.

6.5.3. "the CoAP diagnostic payload must be used as the HTTP reason-phrase of the HTTP status line" -- a diagnostic payload is similar to the HTTP reason phrase, but it can be much more verbose and, e.g., can include CR-LF line breaks. It's probably best to stick the diagnostic payload into the payload and use the default reason phrase for the status code.

7. "4.02 Bad Option | 400 Bad Request" -- can the HTTP client make a change to its request so that the proxy does not include the bad option in its CoAP request? If not, the bad option is the proxy's fault (5xx status code) and not the HTTP client's fault (4xx status code).

7. "The proxy receiving 2.03 updates the freshness of its cached representation and returns the entire representation to the HTTP client." -- If the proxy receives a response indicating that the etag supplied by the HTTP client is valid, why does the proxy need to send the representation to the client?

7. "If the HC proxy does not implement a proper authentication method that can be used to gain access to the target CoAP resource, it can include a 'dummy' challenge for example "WWW-Authenticate: None"." -- if the proxy cannot gain access to the CoAP resource, it should probably return a 403 (Forbidden) status code to the HTTP client.

7. "In this case the HC Proxy SHOULD also return a HTTP reason-phrase in the HTTP status line that starts with the string "405" in order to facilitate troubleshooting." -- this leads to a status line like
"HTTP/1.1 400 405 Method Not Allowed" which looks wrong and may confuse implementers.

7. "The value of the HTTP "Retry-After" response-header field is taken from the value of the CoAP Max-Age Option, if present." -- if the Max-Age Option is not present, it means that the Max-Age is 60 seconds, not that the representation doesn't have a Max-Age.

8.1 "An HC proxy SHOULD limit the number of requests to CoAP servers by responding, where applicable, with a cached representation of the resource." -- The proxy actually MUST perform congestion control as specified in RFC 7252. Caching is not about congestion control, it is about efficiency. So, as a matter of quality of implementation, it is a good idea for a proxy to implement caching. But responding with a cached representation of the resource is not a tool to enforce congestion control.

8.1 "Duplicate idempotent pending requests by an HC proxy to the same CoAP resource SHOULD in general be avoided, by using the same response for multiple requesting HTTP clients without duplicating the CoAP request." -- this is not how caching in CoAP works. Please read RFC 7252.

8.1 "According to [RFC7252], a proxy MUST limit the number of outstanding interactions to a given CoAP server to NSTART." -- this has already been specified in RFC 7252. There is no need to repeat that here.

9.2 -- have you submitted the registration to the [email-masked] mailing list for review? It's probably a good idea to do this before sending the document to the IESG.

Klaus

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: "Kepeng Li" <[email-masked]>
Date: Thu, 01 Oct 2015 09:28:15 +0800

One feedback about this document is the intended status, should we change it
from „informational“ to „Experimental“?

This happened to the group communication (RFC7390), maybe we should apply
the same logic here.

Thanks,
Kind Regards
Kepeng 

To:        "[email-masked] WG <mailto:[email-masked]%20WG> " <[email-masked]>

The draft is located at:
https://tools.ietf.org/html/draft-ietf-core-http-mapping-07
<https://tools.ietf.org/html/draft-ietf-core-http-mapping-07>

Grüße, Carsten

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