Skip to main content
Version: 0.6

Termination

info

The IOTA DIDComm Specification is in the RFC phase and may undergo changes. Suggestions are welcome at GitHub #464.

  • Version: 0.1
  • Status: IN-PROGRESS
  • Last Updated: 2021-10-29

Overview​

Indicates the graceful termination of a connection. It is expected that no reconnection attempt will be made on any of the message thread/s in this connection following termination. This provides a chance for the receiver to clean up or archive any resources allocated to the connection.

Relationships​

Example Use-Cases​

  • A verifier terminates the connection following a successful presentation from a holder.
  • One participant experiences an error and terminates the connection gracefully after sending a problem-report.

Roles​

  • Sender: initiates the connection termination.
  • Receiver: is notified of the termination.

Interaction​

TerminationDiagram

For guidance on diagrams see the corresponding section in the overview.

Messages​

1. termination​

  • Type: iota/termination/0.1/termination
  • Role: sender

Used to inform the receiver that the sender wishes to terminate the established connection.

Structure​

{}

2. termination-response​

  • Type: iota/termination/0.1/termination-response
  • Role: receiver

Response from the receiver that the request to terminate the connection was acknowledged. MUST be sent if the field please_ack is present in the termination message.

Structure​

{}

Considerations​

This section is non-normative.

  • Which party terminates a connection depends on the application but is usually the same as the one that initiated it following a successful interaction to achieve.
  • Any party may terminate a connection at any time, even during a protocol.
  • A termination message indicates a graceful end to a connection but the underlying transport layer connection could terminate without this message. Implementors should implement reasonable timeouts and reconnection capabilities.