Subject: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-08.txt

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 21 Jan 2015 18:04:39 +0530

Hi all,
A modified version of the No-Response draft has been submitted. This draft 
has so far addressed all the technical comments received during the past 
meetings and mailing list discussions. We would urge the CoRE members to 
do a review of the draft and share their comments. Also, would request 
people to implement this option.

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
____________________________________________
----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 01/21/2015 05:58 PM 
-----

From:   [email-masked]
To:     Soma Bandyopadhyay <[email-masked]>, "Abhijan 
Bhattacharyya" <[email-masked]>, "Arpan Pal" 
<[email-masked]>, Arpan Pal <[email-masked]>, "Soma Bandyopadhyay" 
<[email-masked]>, Abhijan Bhattacharyya 
<[email-masked]>
Date:   01/21/2015 05:57 PM
Subject:        New Version Notification for 
draft-tcs-coap-no-response-option-08.txt

A new version of I-D, draft-tcs-coap-no-response-option-08.txt
has been successfully submitted by Abhijan Bhattacharyya and posted to the
IETF repository.

Name:                            draft-tcs-coap-no-response-option
Revision:                08
Title:                           CoAP option for no server-response
Document date:           2015-01-21
Group:                           Individual Submission
Pages:                           17
URL:            
http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-08.txt

Status:         
https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/
Htmlized:       
http://tools.ietf.org/html/draft-tcs-coap-no-response-option-08
Diff:           
http://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-08

Abstract:
   There can be typical M2M scenarios where responses from server
   against request from client might be considered redundant. This kind
   of open-loop exchange (with no reverse path from the server to the
   client) may be typically desired to minimize resource consumption in
   constrained systems while simultaneously updating a bulk of
   resources or updating a resource with a very high frequency. CoAP
   already provides a non-confirmable (NON) mode of exchange where the
   server end-point does not respond with ACK. However, the server end-
   point responds back with a status code indicating "the result of the
   attempt to understand and satisfy the request".

   This draft introduces a header option for CoAP called 'No-Response'.
   The option explicitly tells the server to suppress responses about
   the state of the resource against the request from the client. This
   option also provides granular control by allowing suppression of a
   typical class or a combination of classes of responses. This option
   may be effective for both unicast and multicast requests. This draft
   discusses few exemplary applications which might benefit from this
   option.

Please note that it may take a couple of minutes from the time of 
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=====-----=====-----=====
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: Mon, 26 Jan 2015 04:30:44 +0000

Hi Abhijan,

Thanks for continuing to update and progress this interesting topic.  I reviewed your latest draft and it looks in good shape.  I just had one technical question.  Can you please explain what would happen in the case of a successful POST with a NO RESP when a new URI is created (see http://tools.ietf.org/html/rfc7252#section-5.8.2?  I don’t think the POSTing client can know in advance if a new URI is created or an existing URI is updated (as this is a server run time decision).  I wasn’t sure of how this case was handled from your Table 2.

Best Regards,

Akbar

From: core [mailto:[email-masked]] On Behalf Of Abhijan Bhattacharyya
Sent: Wednesday, January 21, 2015 7:35 AM
To: [email-masked]
Subject: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-08.txt

Hi all,
A modified version of the No-Response draft has been submitted. This draft has so far addressed all the technical comments received during the past meetings and mailing list discussions. We would urge the CoRE members to do a review of the draft and share their comments. Also, would request people to implement this option.

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
____________________________________________
----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 01/21/2015 05:58 PM -----

From:        [email-masked]<mailto:[email-masked]>
To:        Soma Bandyopadhyay <[email-masked]<mailto:[email-masked]>>, "Abhijan Bhattacharyya" <[email-masked]<mailto:[email-masked]>>, "Arpan Pal" <[email-masked]<mailto:[email-masked]>>, Arpan Pal <[email-masked]<mailto:[email-masked]>>, "Soma Bandyopadhyay" <[email-masked]<mailto:[email-masked]>>, Abhijan Bhattacharyya <[email-masked]<mailto:[email-masked]>>
Date:        01/21/2015 05:57 PM
Subject:        New Version Notification for draft-tcs-coap-no-response-option-08.txt
________________________________

Name:                                  draft-tcs-coap-no-response-option
Revision:                 08
Title:                                  CoAP option for no server-response
Document date:                 2015-01-21
Group:                                  Individual Submission
Pages:                                  17
URL:            http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-08.txt
Status:         https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/
Htmlized:       http://tools.ietf.org/html/draft-tcs-coap-no-response-option-08
Diff:           http://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-08

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 26 Jan 2015 11:30:30 +0000

Hi Akbar, Abhijan,

If the client needs to know what the POST would return, it better not use No-Response.
But if the client does use it, the POST is executed and any outcome (e.g. new resource) remains unknown.  Don’t think there’s a need to explain this specifically for POST, or …?

regards
Esko

From: core [mailto:[email-masked]] On Behalf Of Rahman, Akbar
Sent: Monday, January 26, 2015 05:31
To: Abhijan Bhattacharyya; [email-masked]
Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-08.txt

Hi Abhijan,

Best Regards,

Akbar

From: core [mailto:[email-masked]] On Behalf Of Abhijan Bhattacharyya
Sent: Wednesday, January 21, 2015 7:35 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-08.txt

Hi all,

Regards
Abhijan Bhattacharyya
Associate Consultant
----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 01/21/2015 05:58 PM -----

Abstract:

The IETF Secretariat

________________________________
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: Mon, 26 Jan 2015 17:35:22 +0000

Hi Esko,

I agree with your logic.  However, my comment was in relation to Table 2 which did try to explain (and I personally think it is worthwhile info for developers who are most likely not sitting in IETF and understanding all the nuances of the protocol)

   +-------------+----------------------------------------------------+
   | Method Name |              Remarks on applicability              |
   +-------------+----------------------------------------------------+
   |             | This option does not apply to GET under usual      |
   |             | circumstances when the client requests the contents|
   |             | of a resource. However, this option may be useful  |
   |             | for special  GET requests. At present only one such|
   |             | application is identified which is the             |
   |             | 'cancellation' procedure for 'Observe'. Observe-   |
   |     GET     | cancellation requires a client to issue a GET      |
   |             | request with Observe option set to 'deregister'    |
   |             | (1). Since, in this case the server response does  |
   |             | not contain any payload, the client MAY express its|
   |             | disinterest in server responses.                   |
   +-------------+----------------------------------------------------+
   |             | Suitable for frequent updates in NON mode on       |
   |     PUT     | existing resources. Might not be useful when       |
   |             | PUT creates a new resource.                        |
   +-------------+----------------------------------------------------+
   |             | If POST is used just to update a target resource   |
   |             | then No-Response can be used in the same manner as |
   |             | in NON-PUT. May also be applicable when POST       |
   |    POST     | creates 'transient' resources as part of name/value|
   |             | pair in a query string for frequent updates (may be|
   |             | to update some database; see Section 5.1.2.2<http://tools.ietf.org/html/draft-tcs-coap-no-response-option-08#section-5.1.2.2>).     |
   +-------------+----------------------------------------------------+
   |             | Deletion is usually a permanent action and the     |
   |    DELETE   | client SHOULD make sure that the deletion actually |
   |             | happened. SHOULD NOT be applicable.                |
   +-------------+----------------------------------------------------+
              Table 2: Suggested applicability of No-Response

From: Dijk, Esko [mailto:[email-masked]]
Sent: Monday, January 26, 2015 6:31 AM
To: Rahman, Akbar; Abhijan Bhattacharyya; [email-masked]
Subject: RE: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-08.txt

Hi Akbar, Abhijan,

regards
Esko

From: core [mailto:[email-masked]] On Behalf Of Rahman, Akbar
Sent: Monday, January 26, 2015 05:31
To: Abhijan Bhattacharyya; [email-masked]<mailto:[email-masked]>
Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-08.txt

Hi Abhijan,

Best Regards,

Akbar

Hi all,

Regards
Abhijan Bhattacharyya
Associate Consultant
----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 01/21/2015 05:58 PM -----

Abstract:

The IETF Secretariat

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 28 Jan 2015 09:09:08 +0530

Hi Akbar, Esko,

Thank you very much for sparing your time to review the draft. Let me address your comments one by one:

Akbar's comments:

>I reviewed your latest draft and it looks in good shape.

Thanks.

> Can you please explain what would happen in the case of a successful

>POST with a NO RESP when a new URI is created (see

>http://tools.ietf.org/html/rfc7252#section-5.8.2?  I don&#8217;t think the

>POSTing client can know in advance if a new URI is created or an

>existing URI is updated (as this is a server run time decision). 

> I wasn&#8217;t sure of how this case was handled from your Table 2.

As you can see, the table 2 says, "Might not be useful when PUT creates a new resource". We have not specified this in POST explicitly. That is why we have taken the update issue for POST at first: "If POST is used just to update a target resource then No-Response can be used in the same manner as in NON-PUT." However, what we have mentioned on applicability of POST for CREATE is about creating 'transient resources'. Now, this is a very application specific case and we have mentioned this since we have come across this kind of condition while doing practical exercises with this option. We have elaborated this situation in section 5.1.2.2 "POST updating through resource creation". In this case creation is actually an update operation.The updates of vehicle location is transferred as query strings over POST request. The data base at the backend is running the update query after each POST. In this case, resource creation is just a transient phenomenon and the client is not going to access these resources in future. 

Please let me know if the above explanation clarifies the doubt. Do you think we should explicitly tell  in table 2 that this option SHOULD NOT be used for normal resource creation with POST?

Esko&#8217;s comments:

>If the client needs to know what the POST would return, it better not

>use No-Response.

>But if the client does use it, the POST is executed and any outcome

>(e.g. new resource) remains unknown.  Don&#8217;t think there&#8217;s a need to

>explain this specifically for POST,

> or &#8230;?

I think the above explanation should encompass your question also. Again, may be we need some more explicit sentences?

>For the PUT entry for example, it is also not explained what happens

>if the PUT is unsuccessful and the client thinks it was a success.

We have tried to address similar point in the context of granular response suppression in the &#8216;implementation note&#8217; of section 2.1 : 

&#8220;A point to be noted in this context is that there may

      be situations when the response on errors might get lost. In such

      a situation the client would wait up to the time-out period but

      will not receive any response. But this should not lead to the

      impression to the client that the request was successful. The

      application designer needs to tackle such situation. For example,

      while performing frequent updates, the client may strategically

      interweave requests without No-Response into a series of requests

      with No-Response to check time to time if things are fine at the

      server end the server is actively responding.&#8221;

Does this answer the concern? Or do you think that some more text should be in covering the generic case?

>&#8230;.with concurrent access and all

We have deliberately avoided the issue of concurrent access. It is actually a classic general computer science problem and depends very much on how the server logic is implemented. It may well happen that the server treats the resource as a critical section, keeps the concurrent PUTs in some kind of buffers and then applies semaphores for gracefully handling the concurrent updation.

We avoided these details. Do you think it would be really useful to explicitly mention about these cases?

Looking forward to hear your opinions.

Regards
Abhijan Bhattacharyya
Associate Consultant

-----"Dijk, Esko" <[email-masked]> wrote: -----

>To: "Rahman, Akbar" <[email-masked]>, Abhijan
>Bhattacharyya <[email-masked]>
>From: "Dijk, Esko" <[email-masked]>
>Date: 01/27/2015 10:20PM
>Hi Akbar,
>I don&#8217;t fully understand your answer &#8211; sorry
>J
>For the PUT entry for example, it is also not explained what happens
>if the PUT is unsuccessful and the client thinks it was a success.
>Also the client wouldn&#8217;t know perhaps
> if a resource was updated or if a new resource was created &#8211; if the
>client &#8220;thinks&#8221; the resource is already there doesn&#8217;t mean it is
>actually there, with concurrent access and all.
>
> 
>I was just thinking that such more detailed considerations and also
>the ones you had on POST and the considerations I had on PUT are not
>meant to be in the Table 2?
> 
>Esko
> 
>
>
>From: Rahman, Akbar [mailto:[email-masked]]
>
>
>Sent: Monday, January 26, 2015 18:35
>
>To: Dijk, Esko; Abhijan Bhattacharyya; [email-masked]
>
>ÿ
>ÿ
>ÿ
>I agree with your logic.ÿ However, my comment was in relation to
>Table 2 which did try to explain (and I personally think it is
>worthwhile info for developers
> who are most likely not sitting in IETF and understanding all the
>nuances of the protocol)
>ÿ
>ÿ
>
>ÿÿ | Method Name |ÿÿÿÿÿÿÿÿÿÿÿÿÿ Remarks on applicability
>|
>
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | This option does not apply to GET under usual
>|
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | circumstances when the client requests the
>contents|
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | of a resource. However, this option may be useful
>|
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | for specialÿ GET requests. At present only one
>such|
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | application is identified which is the
>|
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | 'cancellation' procedure for 'Observe'. Observe-
>|
>ÿÿ |ÿÿÿÿ GETÿÿÿÿ | cancellation requires a client to issue a GET
>|
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | request with Observe option set to 'deregister'
>|
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | (1). Since, in this case the server response does
>|
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | not contain any payload, the client MAY express
>its|
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | disinterest in server responses.
>|
>
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | Suitable for frequent updates in NON mode on
>|
>ÿÿ |ÿÿÿÿ PUTÿÿÿÿ | existing resources. Might not be useful when
>|
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | PUT creates a new resource.
>|
>
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | If POST is used just to update a target resource
>|
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | then No-Response can be used in the same manner as
>|
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | in NON-PUT. May also be applicable when POST
>|
>ÿÿ |ÿÿÿ POSTÿÿÿÿ | creates 'transient' resources as part of
>name/value|
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | pair in a query string for frequent updates (may
>be|
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | to update some database; see
>
>Section 5.1.2.2).ÿÿÿÿ |
>
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | Deletion is usually a permanent action and the
>|
>ÿÿ |ÿÿÿ DELETEÿÿ | client SHOULD make sure that the deletion actually
>|
>ÿÿ |ÿÿÿÿÿÿÿÿÿÿÿÿ | happened. SHOULD NOT be applicable.
>|
>
>ÿÿÿÿÿÿÿÿÿÿÿÿÿ Table 2: Suggested applicability of No-Response
>ÿ
>ÿ
>ÿ
>ÿ
>
>
>ÿ
>ÿ
>But if the client does use it, the POST is executed and any outcome
>(e.g. new resource) remains unknown. ÿDon&#8217;t think there&#8217;s a need to
>explain this specifically for POST,
> or &#8230;?
>ÿ
>regards
>Esko
>ÿ
>
>
>ÿ
>ÿ
>ÿ
>Thanks for continuing to update and progress this interesting topic.
>I reviewed your latest draft and it looks in good shape.ÿ I just had
>one technical question.ÿ
> Can you please explain what would happen in the case of a successful
>POST with a NO RESP when a new URI is created (see
>http://tools.ietf.org/html/rfc7252#section-5.8.2?ÿ I don&#8217;t think the
>POSTing client can know in advance if a new URI is created or an
>existing URI is updated (as this is a server run time decision).ÿ
> I wasn&#8217;t sure of how this case was handled from your Table 2.
>ÿ
>ÿ
>Best Regards,
>ÿ
>ÿ
>Akbar
>
>ÿ
>ÿ
>ÿ
>ÿ
>A modified version of the No-Response draft has been submitted. This
>draft has so far addressed all the technical comments received during
>the past meetings and mailing list discussions. We would
> urge the CoRE members to do a review of the draft and share their
>comments. Also, would request people to implement this option.
>
>
>
>
>Regards
>
>Abhijan Bhattacharyya
>
>Associate Consultant
>
>Experience certainty. ÿ ÿ ÿ ÿIT Services
>
>ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿBusiness Solutions
>
>ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿConsulting
>
>From: ÿ ÿ ÿ [email-masked]
>
>
>To: ÿ ÿ ÿ ÿSoma Bandyopadhyay <[email-masked]>, "Abhijan
>Date: ÿ ÿ ÿ ÿ01/21/2015 05:57 PM
>
>
>Subject: ÿ ÿ ÿ ÿNew Version Notification for
>Name:
>ÿdraft-tcs-coap-no-response-option
>
>Revision: ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ 08
>
>Title: ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿCoAP option for no
>server-response
>
>Document date: ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ 2015-01-21
>
>Group: ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿIndividual Submission
>
>Pages: ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ17
>
>URL:
>ÿhttp://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-optio
>n-08.txt
>
>Status:
>ÿ There can be typical M2M scenarios where responses from server
>
>ÿ against request from client might be considered redundant. This
>kind
>
>ÿ of open-loop exchange (with no reverse path from the server to the
>
>ÿ client) may be typically desired to minimize resource consumption
>in
>
>ÿ constrained systems while simultaneously updating a bulk of
>
>ÿ resources or updating a resource with a very high frequency. CoAP
>
>ÿ already provides a non-confirmable (NON) mode of exchange where the
>
>ÿ server end-point does not respond with ACK. However, the server
>end-
>
>ÿ point responds back with a status code indicating "the result of
>the
>
>ÿ attempt to understand and satisfy the request".
>
>
>
>ÿ This draft introduces a header option for CoAP called
>'No-Response'.
>
>ÿ The option explicitly tells the server to suppress responses about
>
>ÿ the state of the resource against the request from the client. This
>
>ÿ option also provides granular control by allowing suppression of a
>
>ÿ typical class or a combination of classes of responses. This option
>
>ÿ may be effective for both unicast and multicast requests. This
>draft
>
>ÿ discusses few exemplary applications which might benefit from this
>
>ÿ option.
>
>
>
>
>ÿ ÿ ÿ ÿ ÿ ÿ
>
>
>
>
>
>ÿ
>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: "Dijk, Esko" <[email-masked]>
Date: Wed, 28 Jan 2015 09:08:29 +0000

Hello,

On the comments I made I would just suggest to keep Table 2 as "lean" as possible; not putting too much text in there explaining specific failure cases. However Akbar suggested doing some more explanation for POST which I feel is not needed in the table itself.

On concurrent access: no need to consider this in the draft, I just used it as example to illustrate some specific 'failure' cases for PUT.

Esko

From: Abhijan Bhattacharyya [mailto:[email-masked]]
Sent: Wednesday, January 28, 2015 04:39
To: Dijk, Esko; [email-masked]
Cc: [email-masked]; Soma Bandyopadhyay; Arpan Pal
Subject: RE: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-08.txt

Hi Akbar, Esko,

Thanks.

>http://tools.ietf.org/html/rfc7252#section-5.8.2?  I don't think the

> I wasn't sure of how this case was handled from your Table 2.

>(e.g. new resource) remains unknown.  Don't think there's a need to

> or ...?

>if the PUT is unsuccessful and the client thinks it was a success.

We have tried to address similar point in the context of granular response suppression in the 'implementation note' of section 2.1 :

"A point to be noted in this context is that there may

      server end the server is actively responding."

>....with concurrent access and all

-----"Dijk, Esko" <[email-masked]<mailto:[email-masked]>> wrote: -----

>To: "Rahman, Akbar" <[email-masked]<mailto:[email-masked]>>, Abhijan
>Bhattacharyya <[email-masked]<mailto:[email-masked]>>
>From: "Dijk, Esko" <[email-masked]<mailto:[email-masked]>>
>Date: 01/27/2015 10:20PM
>I don't fully understand your answer - sorry
>J
>Also the client wouldn't know perhaps
> if a resource was updated or if a new resource was created - if the
>client "thinks" the resource is already there doesn't mean it is
>To: Dijk, Esko; Abhijan Bhattacharyya; [email-masked]<mailto:[email-masked]>
>
>I agree with your logic.  However, my comment was in relation to
>   |             | to update some database; see
>
>Section 5.1.2.2).     |
>
>To: Rahman, Akbar; Abhijan Bhattacharyya; [email-masked]<mailto:[email-masked]>
>
>(e.g. new resource) remains unknown.  Don't think there's a need to
> or ...?
>I reviewed your latest draft and it looks in good shape.  I just had
>one technical question.
>http://tools.ietf.org/html/rfc7252#section-5.8.2?  I don't think the
> I wasn't sure of how this case was handled from your Table 2.
>
>
>Best Regards,
>
>
>Akbar
>
>
>
>
>To:        Soma Bandyopadhyay <[email-masked]<mailto:[email-masked]>>, "Abhijan
> Bhattacharyya" <[email-masked]<mailto:[email-masked]>>, "Arpan Pal"
><[email-masked]<mailto:[email-masked]>>, Arpan Pal <[email-masked]<mailto:[email-masked]>>, "Soma
>Bandyopadhyay"
> <[email-masked]<mailto:[email-masked]>>, Abhijan Bhattacharyya
><[email-masked]<mailto:[email-masked]>>
>
>
> draft-tcs-coap-no-response-option
>
>Revision:                 08
>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 28 Jan 2015 20:09:11 +0000

Hi Esko,

Okay, I am okay with not having more explanation in Table 2 if that is the consensus.

Best Regards,

Akbar

From: Dijk, Esko [mailto:[email-masked]]
Sent: Wednesday, January 28, 2015 4:08 AM
To: Abhijan Bhattacharyya; Rahman, Akbar
Cc: [email-masked]; Soma Bandyopadhyay; Arpan Pal
Subject: RE: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-08.txt

Hello,

On the comments I made I would just suggest to keep Table 2 as “lean” as possible; not putting too much text in there explaining specific failure cases. However Akbar suggested doing some more explanation for POST which I feel is not needed in the table itself.

On concurrent access: no need to consider this in the draft, I just used it as example to illustrate some specific ‘failure’ cases for PUT.

Esko

From: Abhijan Bhattacharyya [mailto:[email-masked]]
Sent: Wednesday, January 28, 2015 04:39
To: Dijk, Esko; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Soma Bandyopadhyay; Arpan Pal
Subject: RE: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-08.txt

Hi Akbar, Esko,

Thanks.

>http://tools.ietf.org/html/rfc7252#section-5.8.2?  I don’t think the

> I wasn’t sure of how this case was handled from your Table 2.

>(e.g. new resource) remains unknown.  Don’t think there’s a need to

> or …?

>if the PUT is unsuccessful and the client thinks it was a success.

We have tried to address similar point in the context of granular response suppression in the ‘implementation note’ of section 2.1 :

“A point to be noted in this context is that there may

      server end the server is actively responding.”

>….with concurrent access and all

>I don’t fully understand your answer – sorry
>J
>Also the client wouldn’t know perhaps
> if a resource was updated or if a new resource was created – if the
>client “thinks” the resource is already there doesn’t mean it is
>(e.g. new resource) remains unknown.  Don’t think there’s a need to
> or …?
>http://tools.ietf.org/html/rfc7252#section-5.8.2?  I don’t think the
> I wasn’t sure of how this case was handled from your Table 2.
>
>
>Best Regards,
>
>
>Akbar
>
>
>
>