Add Queue as a Transport option #49
Conversation
Signed-off-by: Sam Curren <telegramsam@gmail.com>
| @@ -17,3 +18,11 @@ TODO: Include details of the websocket message to define a standard usage. | |||
| TODO: | |||
| * Quic | |||
| * Transport binding | |||
|
|
|||
| #### Queue | |||
There was a problem hiding this comment.
This seems a bit odd to describe it as a transport. It seems like a pattern in how transports are used rather than an actual transport method itself. I agree that this needs to be described within this spec because it's a key function of routing to mobile devices, but let me see if there's a better place for this to live to prevent confusion about what the "transport layer" actually is.
There was a problem hiding this comment.
Agree it doesn't it one aspect of transports (because it isn't an actual transport.) This section is also used to understand how to process the various endpoint types in a DIDComm service entry of a DID Document. In that aspect, it fits right in.
This is on the list of conversation topics for today's call.
|
I'm going to pull close this PR at this point and revisit it later, after routing and some of the other issues have been more thoroughly discussed. |
Discussion that led to this addition: hyperledger/aries-rfcs#405
Signed-off-by: Sam Curren telegramsam@gmail.com