{"action":"created","issue":{"url":"https://api.github.com/repos/mkovatsc/Copper/issues/6","labels_url":"https://api.github.com/repos/mkovatsc/Copper/issues/6/labels{/name}","comments_url":"https://api.github.com/repos/mkovatsc/Copper/issues/6/comments","events_url":"https://api.github.com/repos/mkovatsc/Copper/issues/6/events","html_url":"https://github.com/mkovatsc/Copper/issues/6","id":57592177,"number":6,"title":"observe cancellation sends different events","user":{"login":"chrysn","id":442326,"avatar_url":"https://avatars.githubusercontent.com/u/442326?v=3","gravatar_id":"","url":"https://api.github.com/users/chrysn","html_url":"https://github.com/chrysn","followers_url":"https://api.github.com/users/chrysn/followers","following_url":"https://api.github.com/users/chrysn/following{/other_user}","gists_url":"https://api.github.com/users/chrysn/gists{/gist_id}","starred_url":"https://api.github.com/users/chrysn/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/chrysn/subscriptions","organizations_url":"https://api.github.com/users/chrysn/orgs","repos_url":"https://api.github.com/users/chrysn/repos","events_url":"https://api.github.com/users/chrysn/events{/privacy}","received_events_url":"https://api.github.com/users/chrysn/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-02-13T12:14:50Z","updated_at":"2015-02-13T15:20:16Z","closed_at":null,"body":"when a particular block size is pre-selected, copper sends observation requests with an Observe (=0), an Uri-Path and a Block2 option, but the cancellation message only with Observe (=1) and Uri-Path.\r\n\r\nthis is in conflict with draft-ietf-core-observe-16 3.6, which says about eager cancellation of an observation: \"which has the Token field set to the token of the observation to be cancelled and includes an Observe Option with the value set to 1 (deregister).  All other options MUST be identical to those in the registration request, except for the set of ETag Options\". please consider saving the original request in order to satisfy the draft's requirements.\r\n\r\nthe issue can be worked around by setting \"Block late negotiation\"."},"comment":{"url":"https://api.github.com/repos/mkovatsc/Copper/issues/comments/74269293","html_url":"https://github.com/mkovatsc/Copper/issues/6#issuecomment-74269293","issue_url":"https://api.github.com/repos/mkovatsc/Copper/issues/6","id":74269293,"user":{"login":"mkovatsc","id":664090,"avatar_url":"https://avatars.githubusercontent.com/u/664090?v=3","gravatar_id":"","url":"https://api.github.com/users/mkovatsc","html_url":"https://github.com/mkovatsc","followers_url":"https://api.github.com/users/mkovatsc/followers","following_url":"https://api.github.com/users/mkovatsc/following{/other_user}","gists_url":"https://api.github.com/users/mkovatsc/gists{/gist_id}","starred_url":"https://api.github.com/users/mkovatsc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mkovatsc/subscriptions","organizations_url":"https://api.github.com/users/mkovatsc/orgs","repos_url":"https://api.github.com/users/mkovatsc/repos","events_url":"https://api.github.com/users/mkovatsc/events{/privacy}","received_events_url":"https://api.github.com/users/mkovatsc/received_events","type":"User","site_admin":false},"created_at":"2015-02-13T15:20:16Z","updated_at":"2015-02-13T15:20:16Z","body":"Yes, I can see the issues in proxies and they are also the rational behind the requirement in -observe. There is no question we need to fix this in Copper.\r\n\r\nFrom your description, I guess it would be more robust to better separate token matching (used for the cancellation) from the cache lookups. For observe, you need to provide the full repesentation in your cache anyway (as a whole or all blocks), since the client is likely to fetch the other blocks after a notification (which is always only block no. 0). I do not think we actually have a consensus or best practices how to deal with blockwise transfers in caches. In Californium I would go (proxy development is currently on hold...) for always caching the whole response. This also allows also answering to larger block sizes."}}