From a9f0b658f7a6be02400aaddfd6d6a0cbf95a695c Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Tue, 18 Jul 2017 11:15:32 +0100 Subject: [PATCH] Corrections and Clarifications --- xep-0369.xml | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index d48baf36..4606de52 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -38,7 +38,7 @@ &stpeter; 0.9.3 - 2017-06-20 + 2017-07-18 sek

Remove Legacy MIX Namespace; @@ -701,7 +701,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

- The MIX specification is built on layered services that have defined errors. This enables the core MIX specification to reflect primarily the successful use case, as in almost all cases the error reporting of the layer service provides what is needed. A message sender MUST be prepared to handle any valid error from the layer services. When a message receiver encounters an error situation, it MUST use the most appropriate layer server error to report this issue back to the sender. For example a message receiver might use the "not authorized" IQ error in response to a MIX disco that is not authorized. Errors for the following layer services need to be handled for MIX: + The MIX specification is built on layered services that have defined errors. This enables the core MIX specification to reflect primarily the successful use case, as in almost all cases the error reporting of the layer service provides what is needed. A message sender MUST be prepared to handle any valid error from the layer services. When a message receiver encounters an error situation, it MUST use the most appropriate layer server error to report this issue back to the sender. For example a receiving entity might use the "not authorized" error in response to a disco query that is not authorized. Errors for the following layer services need to be handled for MIX:

  1. IQ. All of the IQ errors of &rfc6120; MUST be supported.
    2. @@ -1374,7 +1374,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]>

    - The channel will return the nick that is to be used, noting that this MAY be different to the requested nick. MIX services SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, as defined in &rfc7700;. + On successful nick assignment, the channel will return the nick that is to be used, noting that this MAY be different to the requested nick. MIX services SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, as defined in &rfc7700;. The channel MAY return a conflict error or other appropriate error.

    ]]> -

    If the requested nick is already taken, the MIX service returns a <conflict/> error:

    +

    If the requested nick is already taken and the MIX service does not assign an alternate nick, the MIX service MUST return a <conflict/> error:

    ]]> -

    If the register request does not contain a <nick/> element, then the MIX service assigns one. It is RECOMMENDED that the assigned nick is a UUID following &rfc4122;. +

    If the register request does not contain a <nick/> element, then the MIX service MUST assign one. It is RECOMMENDED that the assigned nick is a UUID following &rfc4122;.

    @@ -1717,13 +1717,20 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    - A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. If this is done the original message MAY be replaced by a tombstone. The protocol to request retraction does this by adding to the message a <retract> element qualified by the 'urn:xmpp:mix:1' namespace as shown in the following example. + A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. If this is done the original message MAY be replaced by a tombstone. The protocol to request retraction does this by adding to the message a <retract> element qualified by the 'urn:xmpp:mix:1' namespace. The <retract> element MUST include an <id> attribute that holds the id of the original message. A message and it's retraction shown in the following example.

    + A Message I did not mean to send + + - + ]]>