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

"weigengyu" <weigengyu@bupt.edu.cn> Mon, 28 September 2015 04:09 UTC

Return-Path: <weigengyu@bupt.edu.cn>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927CD1A6FA3 for <core@ietfa.amsl.com>; Sun, 27 Sep 2015 21:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level:
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHQJgqOf1vVX for <core@ietfa.amsl.com>; Sun, 27 Sep 2015 21:09:19 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id B823F1A6F9F for <core@ietf.org>; Sun, 27 Sep 2015 21:09:17 -0700 (PDT)
Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id DBB6F19F40E for <core@ietf.org>; Mon, 28 Sep 2015 12:09:15 +0800 (HKT)
Received: from WeiGengyuPC (unknown [10.103.243.172]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id E0DD619F39C; Mon, 28 Sep 2015 12:09:13 +0800 (HKT)
Message-ID: <95EAA7B6FE5946F392141BB88F7F1D6A@WeiGengyuPC>
From: weigengyu <weigengyu@bupt.edu.cn>
To: Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>
References: <B679F8FD9DB9412C909AD17E699B3D95@WeiGengyuPC>, <55F83752.3090609@tzi.org> <OFA9726B8D.58AF98FE-ON65257EC3.00320D4E-65257EC3.003497B1@tcs.com> <36F5869FE31AB24485E5E3222C288E1F347BAE99@NABESITE.InterDigital.com> <DA8E45B8B6ED4BFCB6C76C961A0FFCB8@WeiGengyuPC> <OF86A82596.2D778C3F-ON65257ECA.0036D734-65257ECA.0046C326@tcs.com> <36F5869FE31AB24485E5E3222C288E1F347BB47D@NABESITE.InterDigital.com> <OFAA56C62B.D9B75DB8-ON65257ECD.0039358A-65257ECD.003A623C@tcs.com>
In-Reply-To: <OFAA56C62B.D9B75DB8-ON65257ECD.0039358A-65257ECD.003A623C@tcs.com>
Date: Mon, 28 Sep 2015 12:09:12 +0800
Organization: BUPT
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01D0F9E6.7D16E0B0"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/v9nah9YSFvFV9CKUhz8V0oo_yCo>
Cc: core <core-bounces@ietf.org>, core@ietf.org
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2015 04:09:23 -0000

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
Network Technology Center
School of Computer 
Beijing University of Posts and Telecommunications

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

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



-----"weigengyu" <weigengyu@bupt.edu.cn> wrote: -----

>To: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>, "Abhijan
>Bhattacharyya" <abhijan.bhattacharyya@tcs.com>
>From: "weigengyu" <weigengyu@bupt.edu.cn>
>Date: 09/25/2015 07:07AM
>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 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
>Network Technology Center
>School of Computer 
>Beijing University of 
>Posts and Telecommunications
>
>
> 
>
>From: Rahman, Akbar 
>Sent: Friday, September 25, 2015 12:59 AM
>To: Abhijan Bhattacharyya ; weigengyu 
>
>Cc: Carsten 
>Bormann ; core@ietf.org ; core 
>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: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
>Website: 
>http://www.tcs.com
>____________________________________________
>Experience 
>certainty.        IT 
>Services
>                       
>Business 
>Solutions
>                       
>Consulting
>____________________________________________
>
>
>"weigengyu" <weigengyu@bupt.edu.cn> wrote on 
>09/24/2015 01:40:50 PM:
>
>> From: 
>"weigengyu" <weigengyu@bupt.edu.cn> 
>
>> To: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>, 
>"Abhijan 
>> Bhattacharyya" 
><abhijan.bhattacharyya@tcs.com>, 
>"Carsten Bormann" 
>> <cabo@tzi.org> 
>> Cc: <core@ietf.org>, "core" <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>
>> Cc: core <core-bounces@ietf.org>; core@ietf.org WG <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
>> 
>Website: http://www.tcs.com
>> 
>____________________________________________
>> Experience 
>certainty.        IT 
>Services
>>                        
>Business 
>Solutions
>>                        
>Consulting
>> 
>____________________________________________
>> 
>> 
>
>> 
>> 
>> 
>From:        Carsten Bormann <cabo@tzi.org> 
>> 
>To:        "mailto:core@ietf.org%20WG" <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> 
>
>> 
>> 
>
>> 
>> 
>> 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
>> 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
>> https://www.ietf.org/mailman/listinfo/core 
>
>