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

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:abhijan.bhattacharyya@tcs.com]
Sent: Thursday, September 24, 2015 8:53 AM
To: weigengyu <weigengyu@bupt.edu.cn>; Rahman, Akbar <Akbar.Rahman@InterDigital.com>
Cc: Carsten Bormann <cabo@tzi.org>; core@ietf.org; core <core-bounces@ietf.org>
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
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com<mailto:abhijan.bhattacharyya@tcs.com>
Website: http://www.tcs.com<http://www.tcs.com/>
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________

"weigengyu" <weigengyu@bupt.edu.cn<mailto:weigengyu@bupt.edu.cn>> wrote on 09/24/2015 01:40:50 PM:

> From: "weigengyu" <weigengyu@bupt.edu.cn<mailto:weigengyu@bupt.edu.cn>>
> To: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com<mailto:Akbar.Rahman@InterDigital.com>>, "Abhijan
> Bhattacharyya" <abhijan.bhattacharyya@tcs.com<mailto:abhijan.bhattacharyya@tcs.com>>, "Carsten Bormann"
> <cabo@tzi.org<mailto:cabo@tzi.org>>
> Cc: <core@ietf.org<mailto:core@ietf.org>>, "core" <core-bounces@ietf.org<mailto:core-bounces@ietf.org>>
> Date: 09/24/2015 01:50 PM
> Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
>
> 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:core@ietf.org ; core
> Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
>
> 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:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyya
> Sent: Thursday, September 17, 2015 5:34 AM
> To: Carsten Bormann <cabo@tzi.org<mailto:cabo@tzi.org>>
> Cc: core <core-bounces@ietf.org<mailto:core-bounces@ietf.org>>; core@ietf.org<mailto:core@ietf.org> WG <core@ietf.org<mailto:core@ietf.org>>
> 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: abhijan.bhattacharyya@tcs.com<mailto:abhijan.bhattacharyya@tcs.com>
> Website: http://www.tcs.com<http://www.tcs.com/>
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Consulting
> ____________________________________________
>
>
>
>
> From:        Carsten Bormann <cabo@tzi.org<mailto:cabo@tzi.org>>
> To:        "mailto:core@ietf.org%20WG" <core@ietf.org<mailto:core@ietf.org>>
> Date:        09/15/2015 08:51 PM
> Subject:        [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
> Sent by:        "core" <core-bounces@ietf.org<mailto:core-bounces@ietf.org>>
>
>
>
>
> 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
>
> _______________________________________________
> core mailing list
> core@ietf.org<mailto:core@ietf.org>
> 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
> _______________________________________________
> core mailing list
> core@ietf.org<mailto:core@ietf.org>
> https://www.ietf.org/mailman/listinfo/core