Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Queue as a Transport option #49

Closed
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
9 changes: 9 additions & 0 deletions transports.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,7 @@ Each transport has unique features and properties, so we need to define a standa
The POST method is used to send the DIDComm message.
The POST message MIME type is application/didcomm-enc-env.
A successful response code is 202 (Accepted), but 200 (OK) is also allowed.

#### WebSocket
The usage of this transport can be beneficial when only one side of the communication can initiate a request to the other side, for example, the former is behind a Firewall or behind NAT.
With STOMP over WebSocket, the content-type header is application/didcomm-enc-env as in the HTTP(S) message.
Expand All @@ -17,3 +18,11 @@ TODO: Include details of the websocket message to define a standard usage.
TODO:
* Quic
* Transport binding

#### Queue
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


The Queue Transport is a special form of transport where messages are held at the sender for pickup by the recipient. This is useful in conditions where the recipient does not have a reliable endpoint available for message reception.

The URI for the Queue transport is `didcomm:transport/queue` and can be used in the `serviceEndpoint` attribute in the DIDComm Service Block in a DID Document.

Not all DIDComm Agents will be capable or willing to utilize a queue transport.