Update with Marco's comments #4 #13
Conversation
| @@ -303,8 +303,8 @@ | |||
| body).</t> | |||
|
|
|||
| <t>Q-Block1 Option is useful with the payload-bearing POST, PUT, | |||
| FETCH, PATCH, and iPATCH requests and their responses (2.01 and | |||
| 2.04).</t> | |||
| FETCH, PATCH, and iPATCH requests and their responses (2.01, 2.02, | |||
There was a problem hiding this comment.
I still don't see how Q-Block1 is useful for 2.02.
There was a problem hiding this comment.
A POST using Q-Block1 can cause a resource to get deleted and this returns a 2.02 code.
Section 5.8.2 rfc7252 states
If the POST succeeds and results in the target resource being
deleted, the response SHOULD have a 2.02 (Deleted) Response Code.
POST is neither safe nor idempotent.
There was a problem hiding this comment.
What is probmematic is that the text says:
Q-Block1 Option is useful with the payload-bearing ... and their responses
There was a problem hiding this comment.
The response is 2.02 - there does not have to be any data in the response. The POST body can be large though (but I agree unlikely if the result is the deletion of a resource). Certainly not used (POST caused delete) in the DOTS case.
I agree that DELETE is more useful than POST to do a deletion of the resource (and not the way I would want to do it, but it is in RFC7252).
There was a problem hiding this comment.
2.02 has no paylaod, sure. But the text says "Q-Block1 is USEFUL for ... 2.02). I'm not questioning that 2.02 can be returned as per 7252.
There was a problem hiding this comment.
OK - POST with Q-Block1 can be used to delete a resource. Would changing is useful to can be used help here?
There was a problem hiding this comment.
Actually, not.
We don't return any Q-Block1 for 2.01-...-2.05. Saying Q-Block1 is useful for "their responses" would imply that we return an option for those.
That wording is fine for 7959 as they have:
CLIENT SERVER
| |
| CON [MID=1234], POST, /soap, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
| |
| CON [MID=1235], POST, /soap, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
| |
| CON [MID=1236], POST, /soap, 1:2/0/128, 2:0/0/64 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128, 2:0/1/64 |
while we do the following:
CoAP CoAP
Client Server
| |
+--------->| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024
+--------->| CON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024
+--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024
+--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024
|<---------+ ACK 0.00 M:0x01
|<---------+ ACK 0.00 M:0x02
|<---------+ ACK 0.00 M:0x03
|<---------+ ACK 2.04 M:0x04
There was a problem hiding this comment.
OK - understand now. Will fix accordingly. Now
Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH, PATCH, and iPATCH requests.
draft-ietf-core-new-block.xml
Outdated
| <t>2.04 (Changed)<list style="empty"> | ||
| <t>This Response Code indicates successful receipt of the entire | ||
| body and the resource was updated. The token used SHOULD be from | ||
| the last received payload. The client should then release all of | ||
| the tokens used for this body.</t> | ||
| </list></t> | ||
|
|
||
| <t>2.05 (Content)<list style="empty"> | ||
| <t>This Response Code indicates successful receipt of the entire | ||
| FETCH request body (See Section 2 <xref target="RFC8132"></xref>) |
There was a problem hiding this comment.
Section 2 of <xref target="RFC8132">
draft-ietf-core-new-block.xml
Outdated
| ]]></artwork> | ||
| </figure></t> | ||
|
|
||
| <t>If there is Q-Block1 loss, how this is handled is shown in <xref |
There was a problem hiding this comment.
s/If there is Q-Block1 loss, how this is handled is shown/If a loss of a block conveying Q-Block1 Option is experienced, then this is handled as shown
draft-ietf-core-new-block.xml
Outdated
| target="B3non1"></xref> and <xref target="B3non2"></xref> with FETCH | ||
| substitued for PUT and 2.04 becomes a 2.05 response.</t> | ||
|
|
||
| <t>If there is Q-Block2 loss, how this is handled is shown in <xref |
There was a problem hiding this comment.
Q-Block2 loss may not parse well. Please reword following the same as suggested for Q-Block1
There was a problem hiding this comment.
Gone with later suggestion
draft-ietf-core-new-block.txt
Outdated
| Figure 12: Example of NON FETCH with Q-Block1 and Q-Block2 Options | ||
| (Without Loss) | ||
|
|
||
| If there is Q-Block1 loss, how this is handled is shown in Figure 5 |
There was a problem hiding this comment.
| If there is Q-Block1 loss, how this is handled is shown in Figure 5 | |
| If there is a loss of a message with a Q-Block1 Option, this is handled as shown in Figure 5 |
There was a problem hiding this comment.
Updated to this suggestion
draft-ietf-core-new-block.txt
Outdated
| and Figure 6 with FETCH substitued for PUT and 2.04 becomes a 2.05 | ||
| response. | ||
|
|
||
| If there is Q-Block2 loss, how this is handled is shown in Figure 10 |
There was a problem hiding this comment.
| If there is Q-Block2 loss, how this is handled is shown in Figure 10 | |
| If there is a loss of a message with a Q-Block2 Option, this is handled as shown in Figure 10 |
There was a problem hiding this comment.
Updated to this suggestion
|
Changes pushed |
No description provided.