[core] CoAP response code in case of "response payload too large" ? 4.13?

[Dijk, Esko]

Dear all,

the following question came up in a system design that uses CoAP. What if a client asks for a resource (e.g. using query arguments) that would get prohibitively large, such that the server can't serve it? Looking at CoAP code 4.13 (Request Entity Too Large ; or in updated HTTP jargon "Payload Too Large" per https://tools.ietf.org/html/rfc7231#section-6.5.11 ); it seems to only pertain to the request payload size - not the response payload size. In both the HTTP and CoAP cases. So it seems unsuitable for the situation I describe above.

4.00 Bad Request seems unsuitable because the syntax / formatting of the CoAP request is fine. 5.00 seems possible if we take the perspective that it is the server's fault that it cannot produce the requested (large) response payload.

Some background discussion is also on http://stackoverflow.com/questions/15192477/http-status-code-when-single-request-asks-for-too-large-resource-or-too-many-of which suggests to use 403 / 4.03 for this case. Which seems not ideal as well because it tells the client that its authorization is insufficient which is not the case here.

Does anyone have a view on this?

best regards

Esko Dijk


________________________________
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.

[Padmanabhan Ramanujam (pramanuj)]

I think the right error should still be 4.03 Forbidden, as it is the client which should modify its request, with something in the payload to provide sufficient indication to the client that the response will not fit. In the particular case would usage of blockwise option solve the problem.

Regards,
paddy

From: core <core-***@ietf.org> on behalf of "Dijk, Esko" <***@philips.com>
Date: Tuesday, 31 January 2017 at 20:59
To: "core (***@ietf.org)" <***@ietf.org>
Subject: [core] CoAP response code in case of "response payload too large" ? 4.13?

Dear all,

the following question came up in a system design that uses CoAP. What if a client asks for a resource (e.g. using query arguments) that would get prohibitively large, such that the server can't serve it? Looking at CoAP code 4.13 (Request Entity Too Large ; or in updated HTTP jargon "Payload Too Large" per https://tools.ietf.org/html/rfc7231#section-6.5.11 ); it seems to only pertain to the request payload size – not the response payload size. In both the HTTP and CoAP cases. So it seems unsuitable for the situation I describe above.

4.00 Bad Request seems unsuitable because the syntax / formatting of the CoAP request is fine. 5.00 seems possible if we take the perspective that it is the server's fault that it cannot produce the requested (large) response payload.

Some background discussion is also on http://stackoverflow.com/questions/15192477/http-status-code-when-single-request-asks-for-too-large-resource-or-too-many-of which suggests to use 403 / 4.03 for this case. Which seems not ideal as well because it tells the client that its authorization is insufficient which is not the case here.

Does anyone have a view on this?

best regards

Esko Dijk


________________________________
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.

[Carsten Bormann]

Hi Esko,

good question.

I agree that 4.13 does not apply, as it is about the request payload.

If you consider management of resource consumption to be part of authorization, 4.03 is somewhat plausible, but it might set the client up on a goose chase for more permissions.

5.00 of course always is possible, as are 5.01 or 5.03. 5.03 has max-age (retry-after) semantics that maybe don’t fit very well here; it is really meant for temporary conditions.

There is little guidance in RFC 7230 (or RFC 2616) when to use 501 (which our 5.01 references); it only gets specific about using it as a response when the request method is not implemented at all.

So, no, I don’t think we have a good fit here. Is the use case important enough that we want to invent a new status code? Otherwise, 4.03 seems to be as good to me as 5.01.

Grüße, Carsten

Post by Dijk, Esko
Dear all,
the following question came up in a system design that uses CoAP. What if a client asks for a resource (e.g. using query arguments) that would get prohibitively large, such that the server can't serve it? Looking at CoAP code 4.13 (Request Entity Too Large ; or in updated HTTP jargon "Payload Too Large" per https://tools.ietf.org/html/rfc7231#section-6.5.11 ); it seems to only pertain to the request payload size – not the response payload size. In both the HTTP and CoAP cases. So it seems unsuitable for the situation I describe above.
4.00 Bad Request seems unsuitable because the syntax / formatting of the CoAP request is fine. 5.00 seems possible if we take the perspective that it is the server's fault that it cannot produce the requested (large) response payload.
Some background discussion is also on http://stackoverflow.com/questions/15192477/http-status-code-when-single-request-asks-for-too-large-resource-or-too-many-of which suggests to use 403 / 4.03 for this case. Which seems not ideal as well because it tells the client that its authorization is insufficient which is not the case here.
Does anyone have a view on this?
best regards
Esko Dijk
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.
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Lauri Piikivi]

Hi alls,

I think there is a need to define further codes. We fall back on HTTP specs, and those are basically made for user interaction with a limitless server. They are not a good match for IoT where apps communicate, often constrained apps. There is space for defining machine understandable codes, or extend headers or something so that we can actually communicate what the issue is.

I propose a bit of info gathering, I imagine there are more similar kinds of situations where HTTP has not had the right code.

It is a bit more work, but in my opinion needed in mid-to-long term for internet of things.

BR
- Lauri

Post by Carsten Bormann
Hi Esko,
good question.
I agree that 4.13 does not apply, as it is about the request payload.
If you consider management of resource consumption to be part of authorization, 4.03 is somewhat plausible, but it might set the client up on a goose chase for more permissions.
5.00 of course always is possible, as are 5.01 or 5.03. 5.03 has max-age (retry-after) semantics that maybe don’t fit very well here; it is really meant for temporary conditions.
There is little guidance in RFC 7230 (or RFC 2616) when to use 501 (which our 5.01 references); it only gets specific about using it as a response when the request method is not implemented at all.
So, no, I don’t think we have a good fit here. Is the use case important enough that we want to invent a new status code? Otherwise, 4.03 seems to be as good to me as 5.01.
Grüße, Carsten

Post by Dijk, Esko
Dear all,
the following question came up in a system design that uses CoAP. What if a client asks for a resource (e.g. using query arguments) that would get prohibitively large, such that the server can't serve it? Looking at CoAP code 4.13 (Request Entity Too Large ; or in updated HTTP jargon "Payload Too Large" per https://tools.ietf.org/html/rfc7231#section-6.5.11 ); it seems to only pertain to the request payload size – not the response payload size. In both the HTTP and CoAP cases. So it seems unsuitable for the situation I describe above.
4.00 Bad Request seems unsuitable because the syntax / formatting of the CoAP request is fine. 5.00 seems possible if we take the perspective that it is the server's fault that it cannot produce the requested (large) response payload.
Some background discussion is also on http://stackoverflow.com/questions/15192477/http-status-code-when-single-request-asks-for-too-large-resource-or-too-many-of which suggests to use 403 / 4.03 for this case. Which seems not ideal as well because it tells the client that its authorization is insufficient which is not the case here.
Does anyone have a view on this?
best regards
Esko Dijk
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.
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[Carsten Bormann]

Hi Lauri,

indeed, the CoRE world is different from the HTTP world.

Post by Lauri Piikivi
I propose a bit of info gathering, I imagine there are more similar kinds of situations where HTTP has not had the right code.

When we do this, I would like to approach new codes not just with “what should the server do” but more importantly with “how is the client going to react differently”. If the error response is just about telling what went wrong so a human can debug the situation, diagnostic payloads are fine. If we need more detail in an error response so the client can formulate a better request based on those details, we may want to standardize “problem detail” payloads, inspired by RFC 7807.

Grüße, Carsten

[Dijk, Esko]

Thanks Carsten, Paddy, Lauri,

for the case I referred to indeed the response needs to be machine-readable so that the client can limit its query scope. For our constrained device context I would at first expect a few additional response codes defined, a perhaps more into the future a complete "problem detail" payload.

For the time being it can be one of 5.00, 5.01 or 4.03.

Esko

-----Original Message-----
From: Carsten Bormann [mailto:***@tzi.org]
Sent: Wednesday, February 01, 2017 8:22
To: Lauri Piikivi <***@arm.com>
Cc: Dijk, Esko <***@philips.com>; core (***@ietf.org) <***@ietf.org>
Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13?

Hi Lauri,

indeed, the CoRE world is different from the HTTP world.

Post by Lauri Piikivi
I propose a bit of info gathering, I imagine there are more similar kinds of situations where HTTP has not had the right code.

When we do this, I would like to approach new codes not just with “what should the server do” but more importantly with “how is the client going to react differently”. If the error response is just about telling what went wrong so a human can debug the situation, diagnostic payloads are fine. If we need more detail in an error response so the client can formulate a better request based on those details, we may want to standardize “problem detail” payloads, inspired by RFC 7807.

Grüße, Carsten


________________________________
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.

[Smith, Kevin, (R&D) Vodafone Group]

HI all,

I general it makes sense to let the client know whether it can/should repeat the request. In this case we can assume that 'response too large' is a temporary condition (if not then there is a bigger problem :))

The client should therefore be informed that (1) the condition is perceived to be temporary and (2) a recommended delay before the client repeats the request. This IMO puts the error in the 5xx range, as the client has not done anything wrong as such, and the same request being made n seconds later could return a success code and a manageable response.

So my preference would simply be 503 Service Unavailable [1], with a Retry-After header [2]:

"The server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. The server MAY send a Retry-After header field1 to suggest an appropriate amount of time for the client to wait before retrying the request."

Since 5xx also recommends "the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition" [3], then the client can be informed via the representation that 'response too large' was the temporary cause.

All best,
Kevin
Vodafone

[1] https://tools.ietf.org/html/rfc7231#section-6.6.4
[2] https://tools.ietf.org/html/rfc7231#section-7.1.3
[3] https://tools.ietf.org/html/rfc7231#section-6.6

-----Original Message-----
From: core [mailto:core-***@ietf.org] On Behalf Of Carsten Bormann
Sent: 01 February 2017 07:22
To: Lauri Piikivi <***@arm.com>
Cc: core (***@ietf.org) <***@ietf.org>
Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13?

Hi Lauri,

indeed, the CoRE world is different from the HTTP world.

Post by Lauri Piikivi
I propose a bit of info gathering, I imagine there are more similar kinds of situations where HTTP has not had the right code.

When we do this, I would like to approach new codes not just with “what should the server do” but more importantly with “how is the client going to react differently”. If the error response is just about telling what went wrong so a human can debug the situation, diagnostic payloads are fine. If we need more detail in an error response so the client can formulate a better request based on those details, we may want to standardize “problem detail” payloads, inspired by RFC 7807.

Grüße, Carsten

_______________________________________________
core mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/core

[Dijk, Esko]

Or for the shorter term: the HTTP code 507 Insufficient Storage (from https://tools.ietf.org/html/rfc4918#section-11.5) is very suitable for the use case of 'client requesting too much data via URI query parameters'.
Could we request registration of 5.07 in the CoAP Response Codes registry with direct reference to RFC 4918 / code 507 ? (following the IESG approval route)

best regards
Esko

-----Original Message-----
From: Dijk, Esko
Sent: Wednesday, February 01, 2017 9:50
To: 'Carsten Bormann' <***@tzi.org>; Lauri Piikivi <***@arm.com>
Cc: core (***@ietf.org) <***@ietf.org>
Subject: RE: [core] CoAP response code in case of "response payload too large" ? 4.13?

Thanks Carsten, Paddy, Lauri,

for the case I referred to indeed the response needs to be machine-readable so that the client can limit its query scope. For our constrained device context I would at first expect a few additional response codes defined, a perhaps more into the future a complete "problem detail" payload.

For the time being it can be one of 5.00, 5.01 or 4.03.

Esko

-----Original Message-----
From: Carsten Bormann [mailto:***@tzi.org]
Sent: Wednesday, February 01, 2017 8:22
To: Lauri Piikivi <***@arm.com>
Cc: Dijk, Esko <***@philips.com>; core (***@ietf.org) <***@ietf.org>
Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13?

Hi Lauri,

indeed, the CoRE world is different from the HTTP world.

Post by Lauri Piikivi
I propose a bit of info gathering, I imagine there are more similar kinds of situations where HTTP has not had the right code.

When we do this, I would like to approach new codes not just with “what should the server do” but more importantly with “how is the client going to react differently”. If the error response is just about telling what went wrong so a human can debug the situation, diagnostic payloads are fine. If we need more detail in an error response so the client can formulate a better request based on those details, we may want to standardize “problem detail” payloads, inspired by RFC 7807.

Grüße, Carsten


________________________________
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.

[Smith, Kevin, (R&D) Vodafone Group]

Hi Esko,

Not sure if you saw my earlier reply (copied below for convenience), but it proposed 503 because that explicitly hints the next step to the client - which is certainly in the HATEOAS spirit. It also seems that insufficient storage may not be the only reason for the server not wishing to return a large response, it may also be because of bandwidth constraints, network congestion etc. So for that reason I would propose 503, with Retry Header and optional explanatory body, over 507.

All best,
Kevin

-----

In general it makes sense to let the client know whether it can/should repeat the request. In this case we can assume that 'response too large' is a temporary condition (if not then there is a bigger problem :))

The client should therefore be informed that (1) the condition is perceived to be temporary and (2) a recommended delay before the client repeats the request. This IMO puts the error in the 5xx range, as the client has not done anything wrong as such, and the same request being made n seconds later could return a success code and a manageable response.

So my preference would simply be 503 Service Unavailable [1], with a Retry-After header [2]:

"The server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. The server MAY send a Retry-After header field1 to suggest an appropriate amount of time for the client to wait before retrying the request."

Since 5xx also recommends "the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition" [3], then the client can be informed via the representation that 'response too large' was the temporary cause.

All best,
Kevin
Vodafone

[1] https://tools.ietf.org/html/rfc7231#section-6.6.4
[2] https://tools.ietf.org/html/rfc7231#section-7.1.3
[3] https://tools.ietf.org/html/rfc7231#section-6.6



-----Original Message-----
From: core [mailto:core-***@ietf.org] On Behalf Of Dijk, Esko
Sent: 08 February 2017 14:10
To: core (***@ietf.org) <***@ietf.org>
Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13?

Or for the shorter term: the HTTP code 507 Insufficient Storage (from https://tools.ietf.org/html/rfc4918#section-11.5) is very suitable for the use case of 'client requesting too much data via URI query parameters'.
Could we request registration of 5.07 in the CoAP Response Codes registry with direct reference to RFC 4918 / code 507 ? (following the IESG approval route)

best regards
Esko

-----Original Message-----
From: Dijk, Esko
Sent: Wednesday, February 01, 2017 9:50
To: 'Carsten Bormann' <***@tzi.org>; Lauri Piikivi <***@arm.com>
Cc: core (***@ietf.org) <***@ietf.org>
Subject: RE: [core] CoAP response code in case of "response payload too large" ? 4.13?

Thanks Carsten, Paddy, Lauri,

for the case I referred to indeed the response needs to be machine-readable so that the client can limit its query scope. For our constrained device context I would at first expect a few additional response codes defined, a perhaps more into the future a complete "problem detail" payload.

For the time being it can be one of 5.00, 5.01 or 4.03.

Esko

-----Original Message-----
From: Carsten Bormann [mailto:***@tzi.org]
Sent: Wednesday, February 01, 2017 8:22
To: Lauri Piikivi <***@arm.com>
Cc: Dijk, Esko <***@philips.com>; core (***@ietf.org) <***@ietf.org>
Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13?

Hi Lauri,

indeed, the CoRE world is different from the HTTP world.

Post by Lauri Piikivi
I propose a bit of info gathering, I imagine there are more similar kinds of situations where HTTP has not had the right code.

When we do this, I would like to approach new codes not just with “what should the server do” but more importantly with “how is the client going to react differently”. If the error response is just about telling what went wrong so a human can debug the situation, diagnostic payloads are fine. If we need more detail in an error response so the client can formulate a better request based on those details, we may want to standardize “problem detail” payloads, inspired by RFC 7807.

Grüße, Carsten


________________________________
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.
_______________________________________________
core mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/core

[Dijk, Esko]

Hello Kevin,

the response code 5.03 implies that a client could retry the exact same CoAP request after some time. That seems ok if the network is temporarily congested, or other resource-related issues occur. However if the client requests (using query parameters) a representation that is fundamentally too large, e.g. perhaps it does not fit in a single UDP datagram, then retrying is unwanted. So for that case actually 4.03 looks fitting; I just saw the sentence in RFC 7231 there stating "However, a request might be forbidden for reasons unrelated to the credentials". So the reason could also be that "it is forbidden to ask so much using query parameters."

regards
Esko

-----Original Message-----
From: core [mailto:core-***@ietf.org] On Behalf Of Smith, Kevin, (R&D) Vodafone Group
Sent: Wednesday, February 08, 2017 15:32
To: core (***@ietf.org) <***@ietf.org>
Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13?

Hi Esko,

Not sure if you saw my earlier reply (copied below for convenience), but it proposed 503 because that explicitly hints the next step to the client - which is certainly in the HATEOAS spirit. It also seems that insufficient storage may not be the only reason for the server not wishing to return a large response, it may also be because of bandwidth constraints, network congestion etc. So for that reason I would propose 503, with Retry Header and optional explanatory body, over 507.

All best,
Kevin

-----

In general it makes sense to let the client know whether it can/should repeat the request. In this case we can assume that 'response too large' is a temporary condition (if not then there is a bigger problem :))

The client should therefore be informed that (1) the condition is perceived to be temporary and (2) a recommended delay before the client repeats the request. This IMO puts the error in the 5xx range, as the client has not done anything wrong as such, and the same request being made n seconds later could return a success code and a manageable response.

So my preference would simply be 503 Service Unavailable [1], with a Retry-After header [2]:

"The server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. The server MAY send a Retry-After header field1 to suggest an appropriate amount of time for the client to wait before retrying the request."

Since 5xx also recommends "the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition" [3], then the client can be informed via the representation that 'response too large' was the temporary cause.

All best,
Kevin
Vodafone

[1] https://tools.ietf.org/html/rfc7231#section-6.6.4
[2] https://tools.ietf.org/html/rfc7231#section-7.1.3
[3] https://tools.ietf.org/html/rfc7231#section-6.6



-----Original Message-----
From: core [mailto:core-***@ietf.org] On Behalf Of Dijk, Esko
Sent: 08 February 2017 14:10
To: core (***@ietf.org) <***@ietf.org>
Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13?

Or for the shorter term: the HTTP code 507 Insufficient Storage (from https://tools.ietf.org/html/rfc4918#section-11.5) is very suitable for the use case of 'client requesting too much data via URI query parameters'.
Could we request registration of 5.07 in the CoAP Response Codes registry with direct reference to RFC 4918 / code 507 ? (following the IESG approval route)

best regards
Esko

-----Original Message-----
From: Dijk, Esko
Sent: Wednesday, February 01, 2017 9:50
To: 'Carsten Bormann' <***@tzi.org>; Lauri Piikivi <***@arm.com>
Cc: core (***@ietf.org) <***@ietf.org>
Subject: RE: [core] CoAP response code in case of "response payload too large" ? 4.13?

Thanks Carsten, Paddy, Lauri,

for the case I referred to indeed the response needs to be machine-readable so that the client can limit its query scope. For our constrained device context I would at first expect a few additional response codes defined, a perhaps more into the future a complete "problem detail" payload.

For the time being it can be one of 5.00, 5.01 or 4.03.

Esko

-----Original Message-----
From: Carsten Bormann [mailto:***@tzi.org]
Sent: Wednesday, February 01, 2017 8:22
To: Lauri Piikivi <***@arm.com>
Cc: Dijk, Esko <***@philips.com>; core (***@ietf.org) <***@ietf.org>
Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13?

Hi Lauri,

indeed, the CoRE world is different from the HTTP world.

Post by Lauri Piikivi
I propose a bit of info gathering, I imagine there are more similar kinds of situations where HTTP has not had the right code.

When we do this, I would like to approach new codes not just with “what should the server do” but more importantly with “how is the client going to react differently”. If the error response is just about telling what went wrong so a human can debug the situation, diagnostic payloads are fine. If we need more detail in an error response so the client can formulate a better request based on those details, we may want to standardize “problem detail” payloads, inspired by RFC 7807.

Grüße, Carsten


________________________________
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.
_______________________________________________
core mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/core

[Smith, Kevin, (R&D) Vodafone Group]

Hello Esko,

Yes, agreed. 4xx is saying to the client, "if you repeat this same request, no matter how many times you try, then it will fail." and ideally "the mistake you made is this - correct that and you should be fine".

5xx indicates that either the server is broken, and needs to be fixed before anyone can retry, or that the server is temporarily unable to server the response.

As you say, it may be the case that both situations can occur - client error and server temporary issue - in which case it's valid to have both in the error catalogue. The key part is that the client knows what to do next.

All best,
Kevin



-----Original Message-----
From: Dijk, Esko [mailto:***@philips.com]
Sent: 13 February 2017 15:05
To: Smith, Kevin, (R&D) Vodafone Group <***@vodafone.com>; core (***@ietf.org) <***@ietf.org>
Subject: RE: [core] CoAP response code in case of "response payload too large" ? 4.13?

Hello Kevin,

the response code 5.03 implies that a client could retry the exact same CoAP request after some time. That seems ok if the network is temporarily congested, or other resource-related issues occur. However if the client requests (using query parameters) a representation that is fundamentally too large, e.g. perhaps it does not fit in a single UDP datagram, then retrying is unwanted. So for that case actually 4.03 looks fitting; I just saw the sentence in RFC 7231 there stating "However, a request might be forbidden for reasons unrelated to the credentials". So the reason could also be that "it is forbidden to ask so much using query parameters."

regards
Esko

-----Original Message-----
From: core [mailto:core-***@ietf.org] On Behalf Of Smith, Kevin, (R&D) Vodafone Group
Sent: Wednesday, February 08, 2017 15:32
To: core (***@ietf.org) <***@ietf.org>
Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13?

Hi Esko,

Not sure if you saw my earlier reply (copied below for convenience), but it proposed 503 because that explicitly hints the next step to the client - which is certainly in the HATEOAS spirit. It also seems that insufficient storage may not be the only reason for the server not wishing to return a large response, it may also be because of bandwidth constraints, network congestion etc. So for that reason I would propose 503, with Retry Header and optional explanatory body, over 507.

All best,
Kevin

-----

In general it makes sense to let the client know whether it can/should repeat the request. In this case we can assume that 'response too large' is a temporary condition (if not then there is a bigger problem :))

The client should therefore be informed that (1) the condition is perceived to be temporary and (2) a recommended delay before the client repeats the request. This IMO puts the error in the 5xx range, as the client has not done anything wrong as such, and the same request being made n seconds later could return a success code and a manageable response.

So my preference would simply be 503 Service Unavailable [1], with a Retry-After header [2]:

"The server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. The server MAY send a Retry-After header field1 to suggest an appropriate amount of time for the client to wait before retrying the request."

Since 5xx also recommends "the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition" [3], then the client can be informed via the representation that 'response too large' was the temporary cause.

All best,
Kevin
Vodafone

[1] https://tools.ietf.org/html/rfc7231#section-6.6.4
[2] https://tools.ietf.org/html/rfc7231#section-7.1.3
[3] https://tools.ietf.org/html/rfc7231#section-6.6



-----Original Message-----
From: core [mailto:core-***@ietf.org] On Behalf Of Dijk, Esko
Sent: 08 February 2017 14:10
To: core (***@ietf.org) <***@ietf.org>
Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13?

Or for the shorter term: the HTTP code 507 Insufficient Storage (from https://tools.ietf.org/html/rfc4918#section-11.5) is very suitable for the use case of 'client requesting too much data via URI query parameters'.
Could we request registration of 5.07 in the CoAP Response Codes registry with direct reference to RFC 4918 / code 507 ? (following the IESG approval route)

best regards
Esko

-----Original Message-----
From: Dijk, Esko
Sent: Wednesday, February 01, 2017 9:50
To: 'Carsten Bormann' <***@tzi.org>; Lauri Piikivi <***@arm.com>
Cc: core (***@ietf.org) <***@ietf.org>
Subject: RE: [core] CoAP response code in case of "response payload too large" ? 4.13?

Thanks Carsten, Paddy, Lauri,

for the case I referred to indeed the response needs to be machine-readable so that the client can limit its query scope. For our constrained device context I would at first expect a few additional response codes defined, a perhaps more into the future a complete "problem detail" payload.

For the time being it can be one of 5.00, 5.01 or 4.03.

Esko

-----Original Message-----
From: Carsten Bormann [mailto:***@tzi.org]
Sent: Wednesday, February 01, 2017 8:22
To: Lauri Piikivi <***@arm.com>
Cc: Dijk, Esko <***@philips.com>; core (***@ietf.org) <***@ietf.org>
Subject: Re: [core] CoAP response code in case of "response payload too large" ? 4.13?

Hi Lauri,

indeed, the CoRE world is different from the HTTP world.

Post by Lauri Piikivi
I propose a bit of info gathering, I imagine there are more similar kinds of situations where HTTP has not had the right code.

When we do this, I would like to approach new codes not just with “what should the server do” but more importantly with “how is the client going to react differently”. If the error response is just about telling what went wrong so a human can debug the situation, diagnostic payloads are fine. If we need more detail in an error response so the client can formulate a better request based on those details, we may want to standardize “problem detail” payloads, inspired by RFC 7807.

Grüße, Carsten


________________________________
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.
_______________________________________________
core mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/core