You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not all descriptions of options make explicit whether the option can be used on requests, responses, or both. E.g., 5.10.4 Accept doesn't say explicitly that this option is for requests.
5.10.8 does imply that conditional request options are for requests, but doesn't say so outright.
The text was updated successfully, but these errors were encountered:
If that information is added to tables, some option properties could be
split up by it.
For example, ETag is repeatable in requests but not in responses.
Though I currently redesigned the option implementation in Eclipse/Californium, I assume, this issue has at least two parts.
it's not only request or response, considering DELETE, I don't see ACCEPT nor CONTENT_TYPE as useful. So it may be even related to the message code. Same would be an etag for error responses.
if the RFC is improved specifying the proper usage of option in relation if the message code, I guess it's also required to specify, what should happen, if this "late limitation" is violated.
cabo
transferred this issue from core-wg/corrclar-old
Jul 22, 2023
Not all descriptions of options make explicit whether the option can be used on requests, responses, or both. E.g., 5.10.4 Accept doesn't say explicitly that this option is for requests.
5.10.8 does imply that conditional request options are for requests, but doesn't say so outright.
The text was updated successfully, but these errors were encountered: