* For the variable length data (uri in open request, error payload, etc) you'll want to specify a length in the message. It allows for more efficient parsing (knowing a buffer size up front) and prevents some security(ish) issues - e.g. i could just send an open followed by uri that follows the scheme but is essentially gibberish until the connection is closed by the server (or the server chokes on it somehow).
You may also want to consider a lenth field for READ responses - in the specified range where the server has all of the resource this is redundant, but if the server doesn't have all the resource, it allows the client to request from another at an adjusted offset even while still receiving the values from the first READ.
* Tokens: If i'm understanding the draft (incl erata) correctly you're using tokens as handles for message pairs, additionally one of the tokens is used to associate the open request and read request, and they are all chosen by the client.
Like this:
Client Server
Open ---------new_token(val1)-->
<---------reuest_token(val1)-- OpenResponse
Read --new_token(val2), open_token(val1) -->
< --- request_token(val2) --- ReadResponse
I'd suggest making the payload of the OPEN request be a server chosen open_token. Having the client manage all of the token values forces the server to track tokens and sender IP or other, similar unique identifying information. It also opens the door for various token collision and/or exhaustion attacks.
* Specify various edge cases well (client closes connection early, connection breaks, etc), because they will have interop consequences, and affect server design (e.g. how tokens are handled in the program) too.
* For the variable length data (uri in open request, error payload, etc) you'll want to specify a length in the message. It allows for more efficient parsing (knowing a buffer size up front) and prevents some security(ish) issues - e.g. i could just send an open followed by uri that follows the scheme but is essentially gibberish until the connection is closed by the server (or the server chokes on it somehow).
You may also want to consider a lenth field for READ responses - in the specified range where the server has all of the resource this is redundant, but if the server doesn't have all the resource, it allows the client to request from another at an adjusted offset even while still receiving the values from the first READ.
* Tokens: If i'm understanding the draft (incl erata) correctly you're using tokens as handles for message pairs, additionally one of the tokens is used to associate the open request and read request, and they are all chosen by the client.
Like this:
I'd suggest making the payload of the OPEN request be a server chosen open_token. Having the client manage all of the token values forces the server to track tokens and sender IP or other, similar unique identifying information. It also opens the door for various token collision and/or exhaustion attacks.* Specify various edge cases well (client closes connection early, connection breaks, etc), because they will have interop consequences, and affect server design (e.g. how tokens are handled in the program) too.