Subject: Re: [core] Fw: New Version Notification fordraft-tcs-coap-no-response-option-02.txt

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 2 Oct 2013 01:51:51 +0530

Hi Akbar & Carsten,
First of all, thank you very much for your detail scrutiny of the draft.  Let us address the comments one by one.

1) Regarding editorial issues:
   -------------------------
Yes, indeed there is deviation. Somehow it happened while submitting the initial version. Did not change the name in the next versions to avoid confusion as rightly pointed out by Carsten.

2) Regarding applicability of 'No-Resp' for POST
   ---------------------------------------------
Yes, the draft should give an example regarding how No-Resp for POST can be useful. The cases where this option can be used with POST have already been put up in the discussion. In fact, the request/response example given in the draft (Figure 1) can also be performed using POST without changing any functionality. In that case each update will actually create a resource with the name-value pairs. Probably that might be useful for a real end-to-end implementation which would need to maintain a database of the updates. 
Let me give a brief background here. This draft is actually a result of an effort to improve an existing HTTP based traffic monitoring system. In the HTTP case the clients actually 'POST' the updates in the form of name-value pair as new resources. The handler at the server extracts the values from the POST call and writes into the server. A typical RESTful request string, in the HTTP based solution, looks like:
POST /<BaseUrl>/insertInfo?VehId=0010&RouteId=DN47&Lat=12.8888&Long=88.2222&timeStamp=2013-08-03T15:55:07

The 'insertInfo' string provides the handler at the server end.

Would the draft sound convincing for POST if we incorporate another example with the same scenario, and with similar request string as the above, but using CoAP? 

3) Regarding the semantics, etc.
   -----------------------------
We can change the 1 byte interpretation to keep the semantic integrity. In fact, I later realized that we should actually do that way if we strictly adhere to the definition of 'uint' in the CoAP specification (the value zero represented as empty to conserve bytes ). This can be done in no time. Basically we have to 'NOT' the table for 1 byte representation. 
However, I need to get my understanding right regarding the concern raised by Carsten on "how a client implementation would handle a response ...... as it no longer knows whether a response is to be expected and when it can stop expecting one." I think it is a more generic question regarding the optional granularity feature. Opening up any given class of response means, the client has to wait up to the defined time-out period for all the requests. The client never knows whether the present request will be a success or a failure. Thus, if the client decides to open up the responses for errors (4.xx & 5.xx) then it has to wait for the entire time-out period even for the instances where the request is successful and the server is not supposed to send back a response. This may affect the performance in terms of time. But the advantage due to resource saving will still hold good. We can leave the use of the granularity feature on the application developer. Is my understanding correct?  

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: [email-masked]
Website: http://www.tcs.com
____________________________________________
Experience certainty.	IT Services
Business Solutions
Consulting
____________________________________________
=====-----=====-----=====
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: "Dijk, Esko" <[email-masked]>
Date: Wed, 2 Oct 2013 14:02:01 +0000

I would argue that also for doing updates, such as frequent event reports, POST can be used with a "No Response" option.
A POST does not necessarily lead to creation of a new resource.

See core-coap 5.8.2. which mentions POST to update a target resource: " It usually results in a new resource being created or the target resource being updated."
So I see the value of a "No Response" option much more in this case, rather than in the resource creation case.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rahman, Akbar
Sent: Monday, September 30, 2013 20:55
To: Carsten Bormann
Cc: Abhijan Bhattacharyya; Arpan Pal; [email-masked]
Subject: Re: [core] Fw: New Version Notification fordraft-tcs-coap-no-response-option-02.txt

> There may still be applications where this is acceptable, e.g. if no
further client access is required, or if the new resources are later picked up by a different client that finds them using a collection resource. The draft probably should give an example for this.

Yes, I agree this is possible.  I just got an impression from the existing I-D examples that the "No Response" feature was mostly targeted towards high frequency updates (i.e. PUT) for which a response was not required (to reduce congestion, reduce BW usage, etc).  But perhaps a new class of examples showing how this would benefit POST can change this perception.

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

________________________________
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: "Rahman, Akbar" <[email-masked]>
Date: Thu, 3 Oct 2013 11:30:29 -0400

Hi Abhijan,

Regarding your point

> Would the draft sound convincing for POST if we incorporate another
example with the same scenario, and with similar request string as the
above, but using CoAP? 

Yes, I think you should provide another example.  Please also look at
Esko's comment on POST (i.e. update vs new resource).  Finally, it would
be useful if you could have explicit guidance on using this option with
the other methods (i.e. GET, DELETE).  Unless you subscribe to Carsten's
philosophy of leaving it "as an exercise for the reader" ...

Akbar

From: Abhijan Bhattacharyya [mailto:[email-masked]] 
Sent: Tuesday, October 01, 2013 4:22 PM
To: Rahman, Akbar; Carsten Bormann
Cc: Arpan Pal; [email-masked]; Soma Bandyopadhyay
Subject: RE: [core] Fw: New Version Notification
fordraft-tcs-coap-no-response-option-02.txt

Hi Akbar & Carsten,

First of all, thank you very much for your detail scrutiny of the draft.
Let us address the comments one by one.

Yes, indeed there is deviation. Somehow it happened while submitting the
initial version. Did not change the name in the next versions to avoid
confusion as rightly pointed out by Carsten.

Yes, the draft should give an example regarding how No-Resp for POST can
be useful. The cases where this option can be used with POST have
already been put up in the discussion. In fact, the request/response
example given in the draft (Figure 1) can also be performed using POST
without changing any functionality. In that case each update will
actually create a resource with the name-value pairs. Probably that
might be useful for a real end-to-end implementation which would need to
maintain a database of the updates. 

Let me give a brief background here. This draft is actually a result of
an effort to improve an existing HTTP based traffic monitoring system.
In the HTTP case the clients actually 'POST' the updates in the form of
name-value pair as new resources. The handler at the server extracts the
values from the POST call and writes into the server. A typical RESTful
request string, in the HTTP based solution, looks like:

POST
/<BaseUrl>/insertInfo?VehId=0010&RouteId=DN47&Lat=12.8888&Long=88.2222&t
imeStamp=2013-08-03T15:55:07

Would the draft sound convincing for POST if we incorporate another
example with the same scenario, and with similar request string as the
above, but using CoAP? 

We can change the 1 byte interpretation to keep the semantic integrity.
In fact, I later realized that we should actually do that way if we
strictly adhere to the definition of 'uint' in the CoAP specification
(the value zero represented as empty to conserve bytes ). This can be
done in no time. Basically we have to 'NOT' the table for 1 byte
representation. 

However, I need to get my understanding right regarding the concern
raised by Carsten on "how a client implementation would handle a
response ...... as it no longer knows whether a response is to be
expected and when it can stop expecting one." I think it is a more
generic question regarding the optional granularity feature. Opening up
any given class of response means, the client has to wait up to the
defined time-out period for all the requests. The client never knows
whether the present request will be a success or a failure. Thus, if the
client decides to open up the responses for errors (4.xx & 5.xx) then it
has to wait for the entire time-out period even for the instances where
the request is successful and the server is not supposed to send back a
response. This may affect the performance in terms of time. But the
advantage due to resource saving will still hold good. We can leave the
use of the granularity feature on the application developer. Is my
understanding correct?  

Regards
Abhijan Bhattacharyya
Associate Consultant

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Fri, 4 Oct 2013 11:50:33 +0530

Hi Akbar,
Sure! We are tracking all the value adding inputs very closely. The 
accumulated inputs blended with our understanding will be reflected in the 
next version of the draft which we are going to upload soon.

Regards
Abhijan Bhattacharyya
Associate Consultant

From:
"Rahman, Akbar" <[email-masked]>
To:
"Abhijan Bhattacharyya" <[email-masked]>
Cc:
"Arpan Pal" <[email-masked]>, <[email-masked]>, "Soma Bandyopadhyay" 
<[email-masked]>, "Carsten Bormann" <[email-masked]>
Date:
10/03/2013 09:00 PM
Subject:
RE: [core] Fw: New Version Notification 
fordraft-tcs-coap-no-response-option-02.txt

Hi Abhijan,

Regarding your point

Yes, I think you should provide another example.  Please also look at 
Esko?s comment on POST (i.e. update vs new resource).  Finally, it would 
be useful if you could have explicit guidance on using this option with 
the other methods (i.e. GET, DELETE).  Unless you subscribe to Carsten?s 
philosophy of leaving it ?as an exercise for the reader? ?

Akbar

Hi Akbar & Carsten,

2) Regarding applicability of 'No-Resp' for POST
   ---------------------------------------------
Yes, the draft should give an example regarding how No-Resp for POST can 
be useful. The cases where this option can be used with POST have already 
been put up in the discussion. In fact, the request/response example given 
in the draft (Figure 1) can also be performed using POST without changing 
any functionality. In that case each update will actually create a 
resource with the name-value pairs. Probably that might be useful for a 
real end-to-end implementation which would need to maintain a database of 
the updates. 
Let me give a brief background here. This draft is actually a result of an 
effort to improve an existing HTTP based traffic monitoring system. In the 
HTTP case the clients actually 'POST' the updates in the form of 
name-value pair as new resources. The handler at the server extracts the 
values from the POST call and writes into the server. A typical RESTful 
request string, in the HTTP based solution, looks like:
POST 
/<BaseUrl>/insertInfo?VehId=0010&RouteId=DN47&Lat=12.8888&Long=88.2222&timeStamp=2013-08-03T15:55:07

 
3) Regarding the semantics, etc.
   -----------------------------
We can change the 1 byte interpretation to keep the semantic integrity. In 
fact, I later realized that we should actually do that way if we strictly 
adhere to the definition of 'uint' in the CoAP specification (the value 
zero represented as empty to conserve bytes ). This can be done in no 
time. Basically we have to 'NOT' the table for 1 byte representation. 
However, I need to get my understanding right regarding the concern raised 
by Carsten on "how a client implementation would handle a response ...... 
as it no longer knows whether a response is to be expected and when it can 
stop expecting one." I think it is a more generic question regarding the 
optional granularity feature. Opening up any given class of response 
means, the client has to wait up to the defined time-out period for all 
the requests. The client never knows whether the present request will be a 
success or a failure. Thus, if the client decides to open up the responses 
for errors (4.xx & 5.xx) then it has to wait for the entire time-out 
period even for the instances where the request is successful and the 
server is not supposed to send back a response. This may affect the 
performance in terms of time. But the advantage due to resource saving 
will still hold good. We can leave the use of the granularity feature on 
the application developer. Is my understanding correct? 
 
Regards
Abhijan Bhattacharyya
Associate Consultant