|
|
@ -27,28 +27,28 @@ properties:
|
|
|
|
codes should use the Java package naming convention if not in the following
|
|
|
|
codes should use the Java package naming convention if not in the following
|
|
|
|
list:
|
|
|
|
list:
|
|
|
|
|
|
|
|
|
|
|
|
`m.user`: The user cancelled the verification.
|
|
|
|
* `m.user`: The user cancelled the verification.
|
|
|
|
|
|
|
|
|
|
|
|
`m.timeout`: The verification process timed out. Verification processes
|
|
|
|
* `m.timeout`: The verification process timed out. Verification processes
|
|
|
|
can define their own timeout parameters.
|
|
|
|
can define their own timeout parameters.
|
|
|
|
|
|
|
|
|
|
|
|
`m.unknown_transaction`: The device does not know about the given transaction
|
|
|
|
* `m.unknown_transaction`: The device does not know about the given transaction
|
|
|
|
ID.
|
|
|
|
ID.
|
|
|
|
|
|
|
|
|
|
|
|
`m.unknown_method`: The device does not know how to handle the requested
|
|
|
|
* `m.unknown_method`: The device does not know how to handle the requested
|
|
|
|
method. This should be sent for `m.key.verification.start` messages and
|
|
|
|
method. This should be sent for `m.key.verification.start` messages and
|
|
|
|
messages defined by individual verification processes.
|
|
|
|
messages defined by individual verification processes.
|
|
|
|
|
|
|
|
|
|
|
|
`m.unexpected_message`: The device received an unexpected message. Typically
|
|
|
|
* `m.unexpected_message`: The device received an unexpected message. Typically
|
|
|
|
raised when one of the parties is handling the verification out of order.
|
|
|
|
raised when one of the parties is handling the verification out of order.
|
|
|
|
|
|
|
|
|
|
|
|
`m.key_mismatch`: The key was not verified.
|
|
|
|
* `m.key_mismatch`: The key was not verified.
|
|
|
|
|
|
|
|
|
|
|
|
`m.user_mismatch`: The expected user did not match the user verified.
|
|
|
|
* `m.user_mismatch`: The expected user did not match the user verified.
|
|
|
|
|
|
|
|
|
|
|
|
`m.invalid_message`: The message received was invalid.
|
|
|
|
* `m.invalid_message`: The message received was invalid.
|
|
|
|
|
|
|
|
|
|
|
|
`m.accepted`: A `m.key.verification.request` was accepted by a different
|
|
|
|
* `m.accepted`: A `m.key.verification.request` was accepted by a different
|
|
|
|
device. The device receiving this error can ignore the verification request.
|
|
|
|
device. The device receiving this error can ignore the verification request.
|
|
|
|
|
|
|
|
|
|
|
|
Clients should be careful to avoid error loops. For example, if a device sends
|
|
|
|
Clients should be careful to avoid error loops. For example, if a device sends
|
|
|
@ -56,8 +56,6 @@ properties:
|
|
|
|
gets an unexpected response with `m.unexpected_message`, the client should not
|
|
|
|
gets an unexpected response with `m.unexpected_message`, the client should not
|
|
|
|
respond again with `m.unexpected_message` to avoid the other device potentially
|
|
|
|
respond again with `m.unexpected_message` to avoid the other device potentially
|
|
|
|
sending another error response.
|
|
|
|
sending another error response.
|
|
|
|
|
|
|
|
|
|
|
|
.. The above blank line is important for RST.
|
|
|
|
|
|
|
|
required:
|
|
|
|
required:
|
|
|
|
- transaction_id
|
|
|
|
- transaction_id
|
|
|
|
- code
|
|
|
|
- code
|
|
|
|