Subject: [core] draft-ietf-core-observe-05 - combination of block-wise transfers with notifications

From: Jeroen Hoebeke <[email-masked]>
Date: Wed, 28 Mar 2012 14:21:40 +0200

Dear WG,

While once more reading through draft observe, I have a few questions about section 6 (block-wise transfers with notifications). The server sends all blocks sequentially, which differs from a normal block 2 transfer where the client requests the next block.

- isn't it a drawback to have 2 different block2 transfer mechanisms? E.g. the first response to the initial GET with the observe option, will use normal block2 transfer. All subsequent notifications will use the 'turbo-mode' block2 approach described in section 6. Both client and server now need to implement additional block2 behavior + a congestion control mechanism. 
- the existence of this approach could leave the door open for abuse, where some implementations use it to speed up normal block2 transfer 
- is there a preferred behavior when there are multiple observers? Sending the first block to all observers, then the next block…?

A possible alternative could be the following:
- the server sends an empty (no payload) notification containing the size option and possible etag options. The client now knows that the resource has changed and can decide to fetch it. With multiple observers, this could have a advantage in case there is a cache. As soon as 1 client has retrieved the updated resource, all the other clients can get it from an intermediate cache. 

Block-wise transfer of notifications will certainly occur (e.g. when observing .well-known/core), but should we have a different mechanism for that?

Kind regards,
Jeroen