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

[Abhijan Bhattacharyya <[e-mail]>]

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
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: [e-mail]
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________


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

> From: "Rahman, Akbar" <[e-mail]>
> To: Abhijan Bhattacharyya <[e-mail]>, weigengyu
> <[e-mail]>
> Cc: Carsten Bormann <[e-mail]>, "[e-mail]" <[e-mail]>,
> core <[e-mail]>
> Date: 09/24/2015 10:30 PM
> Subject: 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:[e-mail]] 
> Sent: Thursday, September 24, 2015 8:53 AM
> To: weigengyu <[e-mail]>; Rahman, Akbar 
> <[e-mail]>
> Cc: Carsten Bormann <[e-mail]>; [e-mail]; core <core-
> [e-mail]>
> 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: [e-mail]
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Consulting
> ____________________________________________
> 
> 
> "weigengyu" <[e-mail]> wrote on 09/24/2015 01:40:50 PM:
> 
> > From: "weigengyu" <[e-mail]> 
> > To: "Rahman, Akbar" <[e-mail]>, "Abhijan 
> > Bhattacharyya" <[e-mail]>, "Carsten Bormann" 
> > <[e-mail]> 
> > Cc: <[e-mail]>, "core" <[e-mail]> 
> > 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:[e-mail] ; 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:[e-mail]] On Behalf Of Abhijan 
Bhattacharyya
> > Sent: Thursday, September 17, 2015 5:34 AM
> > To: Carsten Bormann <[e-mail]>
> > Cc: core <[e-mail]>; [e-mail] WG <[e-mail]>
> > 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: [e-mail]
> > Website: http://www.tcs.com
> > ____________________________________________
> > Experience certainty.        IT Services
> >                        Business Solutions
> >                        Consulting
> > ____________________________________________
> > 
> > 
> > 
> > 
> > From:        Carsten Bormann <[e-mail]> 
> > To:        "mailto:[e-mail]%20WG" <[e-mail]> 
> > Date:        09/15/2015 08:51 PM 
> > Subject:        [core] WG last-call (WGLC) of draft-ietf-core-
> http-mapping-07
> > Sent by:        "core" <[e-mail]> 
> > 
> > 
> > 
> > 
> > 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
> > [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/core