Propose HIPE: Transports #94
Conversation
Signed-off-by: Sam Curren <telegramsam@gmail.com>
Signed-off-by: Sam Curren <telegramsam@gmail.com>
Signed-off-by: Sam Curren <telegramsam@gmail.com>
|
|
||
| - The MIME Type for the POST request is `application/ssi-agent-wire`. | ||
|
|
||
| - A received message should be responded to with a 202 Accepted status code. This indicates that the request was received, but not necessarily processed. Accepting a 200 OK status code is allowed. |
There was a problem hiding this comment.
Any reason why we can't have all 2XX status codes allowed here? As a transport definition, I feel it should allow for broader use of all Success status codes, including 201 Created, 204 No Content, etc.
There was a problem hiding this comment.
I think if we are to support a broader range of 2xx response codes, we should define what they indicate.
|
What's the extent of error handling that we want to cover with the transport layer. For example, would a misformatted wire message return a 4XX status code? I'd think that it wouldn't make sense to use the status code to push this error back. On the other hand, what about a message that is posted to the wrong endpoint? I would think that it would be acceptable to return a 4XX status code. Also, given that we support IoT devices I think it's only fair to support the 418 status code if we're interacting with a teapot. |
I do think we need to be careful here to not step into full message processing. Errors related to message receipt might be acceptable though.
Definitely need to work out the particulars of this one. :) |
|
|
||
| - POST requests are considered transmit only by default. No agent messages will be returned in the response. This behavior may be modified with additional signaling. | ||
|
|
||
| - Using HTTPS with TLS 1.2 or greater with a forward secret cipher will provide Perfect Forward Secrecy (PFS) on the transmission leg. |
There was a problem hiding this comment.
This is true. However, the statement needs to be reconciled against the merged HIPE that says we will achieve perfect forward secrecy a different way.
|
Aside from the comments I left, my other point of feedback is just that I think we need discussion of a few more issues and transports before we merge this. For example:
|
Signed-off-by: Sam Curren <telegramsam@gmail.com>
|
@dhh1128 I think I've addressed the points you mentioned. Any additional feedback is very welcome. |
Signed-off-by: Oskar van Deventer oskar.vandeventer@tno.nl
|
@TelegramSam I believe this PR is now superseded by Aries RFC 0025, so this PR can be closed. Correct? |
Signed-off-by: Sam Curren telegramsam@gmail.com