From cde2abe151ac8ecaacf46ad5d0cc43caae5b9a62 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 22 Feb 2017 17:01:14 +0100 Subject: [PATCH 01/54] XEP-0045: Add tag to MUC-PMs --- xep-0045.xml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/xep-0045.xml b/xep-0045.xml index 6a496107..704ab8cf 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -1903,6 +1903,7 @@

Since each occupant has its own occupant JID, an occupant can send a "private message" to a selected occupant via the service by sending a message to the intended recipient's occupant JID. The message type SHOULD be "chat" and MUST NOT be "groupchat", but MAY be left unspecified (i.e., a normal message). This privilege is controlled by the "muc#roomconfig_allowpm" room configuration option.

+

To allow for proper synchronization of these messages to the user's other clients by &xep0280;, the sending client SHOULD add an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace to the message.

I'll give thee a wind. + ]]> -

The service is responsible for changing the 'from' address to the sender's occupant JID and delivering the message to the intended recipient's full JID.

+

The service is responsible for changing the 'from' address to the sender's occupant JID and delivering the message to the intended recipient's full JID. The service SHOULD add the <x/> element if the message does not contain it already.

I'll give thee a wind. + ]]>

If the sender attempts to send a private message of type "groupchat" to a particular occupant, the service MUST refuse to deliver the message (since the recipient's client would expect in-room messages to be of type "groupchat") and return a &badrequest; error to the sender:

From 0dd74fde8d8a676b07431873848c8dfc4d27be31 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Thu, 9 Mar 2017 17:34:49 +0100 Subject: [PATCH 02/54] XEP-0045: clients MUST NOT rely on --- xep-0045.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/xep-0045.xml b/xep-0045.xml index 704ab8cf..1d9f590f 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -1904,6 +1904,7 @@

Since each occupant has its own occupant JID, an occupant can send a "private message" to a selected occupant via the service by sending a message to the intended recipient's occupant JID. The message type SHOULD be "chat" and MUST NOT be "groupchat", but MAY be left unspecified (i.e., a normal message). This privilege is controlled by the "muc#roomconfig_allowpm" room configuration option.

To allow for proper synchronization of these messages to the user's other clients by &xep0280;, the sending client SHOULD add an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace to the message.

+

Note: because this requirement was only added in revision 1.28 of this XEP, receiving clients MUST NOT rely on the existence of the <x/> element on private messages for proper processing.

Date: Tue, 14 Mar 2017 09:23:28 +0100 Subject: [PATCH 03/54] Changed wording from 'clients' to 'entities' --- xep-0045.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0045.xml b/xep-0045.xml index 1d9f590f..0ea8892e 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -1904,7 +1904,7 @@

Since each occupant has its own occupant JID, an occupant can send a "private message" to a selected occupant via the service by sending a message to the intended recipient's occupant JID. The message type SHOULD be "chat" and MUST NOT be "groupchat", but MAY be left unspecified (i.e., a normal message). This privilege is controlled by the "muc#roomconfig_allowpm" room configuration option.

To allow for proper synchronization of these messages to the user's other clients by &xep0280;, the sending client SHOULD add an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace to the message.

-

Note: because this requirement was only added in revision 1.28 of this XEP, receiving clients MUST NOT rely on the existence of the <x/> element on private messages for proper processing.

+

Note: because this requirement was only added in revision 1.28 of this XEP, receiving entities MUST NOT rely on the existence of the <x/> element on private messages for proper processing.

Date: Thu, 20 Apr 2017 00:02:46 +0200 Subject: [PATCH 04/54] Add "Compare-And-Publish PubSub Items" ProtoXEP --- inbox/cap.xml | 169 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 inbox/cap.xml diff --git a/inbox/cap.xml b/inbox/cap.xml new file mode 100644 index 00000000..92dfd031 --- /dev/null +++ b/inbox/cap.xml @@ -0,0 +1,169 @@ + + +%ents; +]> + + +
+ Atomically Compare-And-Publish PubSub Items + This specification provides a mechanism to atomically Compare-And-Publish items to a PubSub node. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XEP-0030 + XEP-0060 + + + + cap + &flow; + + 0.0.1 + 2017-04-20 + fs +

First draft.

 + +
+ + + +

This specification provides a mechanism to atomically publish + items to a PubSub node depending on the item ID of the node's latest + item. This allows to prevent race conditions and avoids data + loss in certain situations.

+ + + + + +

If an entity supports the Compared-And-Publish feature it MUST + advertise the fact by returning a <feature/> with the 'var' + attribute set to 'urn:xmpp:pubsub:cap:0' in response to a &xep0030; + query for information.

+ + + + + +

In order to atomically compare-and-publish an item, a client + sends an &IQ; with a 'pubsub' element qualified by the + 'urn:xmpp:pubsub:cap:0' namespace. The element MUST contain the same + attributes and elements as the <publish/> element defined in + &xep0060; and it MUST contain a previd attribute containing + an item ID.

+ +

The PubSub service MUST only publish the item if the node's + latest item ID is equal to the ID found in the 'previd' + attribute.

+ + + + + + + Soliloquy + +To be, or not to be: that is the question: +Whether 'tis nobler in the mind to suffer +The slings and arrows of outrageous fortune, +Or to take arms against a sea of troubles, +And by opposing end them? + + + tag:denmark.lit,2003:entry-32397 + 2003-12-13T18:30:02Z + 2003-12-13T18:30:02Z + + + + + +]]> + + + +

If the 'previd' matched the latest item's ID and if the service + was able to successfully process the request then the protocol + continues as defined in XEP-0060 7.1.2.

+ + + + + +

In case the Compare-And-Publish operation failed because the + latest node id is not the same as given in the 'previd' attribute + in the request, the server returns an &IQ; result with 'pubsub' + element qualified by the 'urn:xmpp:pubsub:cap:0' namespace which + contains a <compare-and-publish-failed/> element. The + element MUST have a 'id' attribute with the ID of the lastest + item.

+ + + + + + +]]> + + + + + +

All other error cases are handled as specified in + XEP-0060 § 7.1.3

+ + + + + + + +

This extension protocol does not add any further security + considerations to the ones mentioned in XEP-0060 § + 14..

+ + + + + +

This document requires no interaction with the Internet Assigned + Numbers Authority (IANA).

+ + + + + +

This specification defines the following XML namespaces:

+
    +
  • urn:xmpp:pubsub:cap:0
    • +
+ + urn:xmpp:pubsub:cap:0 + Indicates support for Compare-And-Publish + XEP-XXXX +]]> + + + + +

TODO: Add after the XEP leaves the 'experimental' state.

+ + + From 809876d6d5de34842d371fb1204d93e046ebbc0c Mon Sep 17 00:00:00 2001 From: Tarun Gupta Date: Sun, 11 Jun 2017 04:23:21 +0530 Subject: [PATCH 05/54] XEP-0369: Correct XML syntax. Example 46 and 47 incorrectly uses . --- xep-0369.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 2235d795..687ec1f6 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -1532,7 +1532,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - hecate@mix.shakespeare.example + hecate@mix.shakespeare.example @@ -1574,7 +1574,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - hecate@mix.shakespeare.example + hecate@mix.shakespeare.example From 30e7f4f9d2853dc49fdbc4b04b93057807598aed Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Tue, 13 Jun 2017 11:56:52 +0100 Subject: [PATCH 06/54] Remove Legacy Namespace --- xep-0369.xml | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/xep-0369.xml b/xep-0369.xml index 2235d795..a13075e5 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -36,6 +36,14 @@ &ksmithisode; &skille; &stpeter; + + 0.9.3 + 2017-06-13 + sek +

+ Remove Legacy MIX Namespace; +

+ 0.9.2 2017-04-03 @@ -933,7 +941,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - + ]]> From b9cd664a7728899936b803135fb9fecbe7a562de Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Tue, 13 Jun 2017 12:18:39 +0100 Subject: [PATCH 07/54] Mix element in message --- xep-0369.xml | 50 +++++++++++++++++++++++++++++++++++--------------- 1 file changed, 35 insertions(+), 15 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index a13075e5..893d6e68 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -42,6 +42,7 @@ sek

Remove Legacy MIX Namespace; + Add mix element in message to hold MIX additional information;

@@ -1652,8 +1653,15 @@ This approach enables flexible support of multiple clients for a MIX channel pa Harpier cries: 'tis time, 'tis time. ]]> +

+ The MIX channel then adds information to the message using a <mix> element. This element contains two elements: +

+
    +
  1. A <nick> element that contains the Nick of the message sender, taken from the Participants Node.
    2. +
  2. A <jid> element containing the full proxy JID of the sender.
    3. +

The MIX channel then puts a copy of the message into the MAM archive for the channel and sends a copy of the message to each participant in - standard groupchat format. These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's local server. The message from value is the JID of the channel. To enable sender identification, the Nick and bare proxy JID of the sender are included in the message as MIX parameters. The id of the message is the ID from the MAM archive and NOT the id used by the sender. The message placed in the MAM archive is the reflected message without a 'to' element.

+ standard groupchat format. These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's local server. The message from value is the JID of the channel. The id of the message is the ID from the MAM archive and NOT the id used by the sender. The message placed in the MAM archive is the reflected message without a 'to' element.

Harpier cries: 'tis time, 'tis time. - thirdwitch - 123456#coven@mix.shakespeare.example + + thirdwitch + 123456#coven@mix.shakespeare.example + ]]> @@ -1672,12 +1682,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' type='groupchat'> Harpier cries: 'tis time, 'tis time. - thirdwitch - 123456#coven@mix.shakespeare.example + + thirdwitch + 123456#coven@mix.shakespeare.example + ]]>

- The messages sent to participants have a different message id to the originally submitted message. This does not impact most recipients, but it does not allow the message originator to correlate the message with the submitted message. To address this the MIX channel MUST include an additional element of the message copy going back to the originator's bare JID that includes the original id. This enables the originator to correlate the received message with the message submitted. + The messages sent to participants have a different message id to the originally submitted message. This does not impact most recipients, but it does not allow the message originator to correlate the message with the submitted message. To address this the MIX channel MUST include an additional <submission-id> element in the <mix> element of the message copy going back to the originator's bare JID. The <submission-id> element holds the original id provided by the sender. This enables the originator to correlate the received message with the message submitted.

Harpier cries: 'tis time, 'tis time. - thirdwitch - 123456#coven@mix.shakespeare.example - 92vax143g + + thirdwitch + 123456#coven@mix.shakespeare.example + 92vax143g + ]]> @@ -2399,8 +2413,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' type='groupchat'> Harpier cries: 'tis time, 'tis time. - thirdwitch - 123456#coven@mix.shakespeare.example + + thirdwitch + 123456#coven@mix.shakespeare.example + ]]> @@ -2414,8 +2430,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' type='groupchat'> Harpier cries: 'tis time, 'tis time. - thirdwitch - 123456#coven@mix.shakespeare.example + + thirdwitch + 123456#coven@mix.shakespeare.example + Harpier cries: 'tis time, 'tis time. - thirdwitch - 123456#coven@mix.shakespeare.example + + thirdwitch + 123456#coven@mix.shakespeare.example + ]]> From 9133ca2f0ad3f4dd6315a97a1508a5512bae955b Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Tue, 13 Jun 2017 14:15:17 +0100 Subject: [PATCH 08/54] Roster Update Clarifications --- xep-0369.xml | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 893d6e68..a00f0056 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -43,6 +43,7 @@

Remove Legacy MIX Namespace; Add mix element in message to hold MIX additional information; + Roster Update Clarifications;

@@ -2519,22 +2520,23 @@ This approach enables flexible support of multiple clients for a MIX channel pa -

It will be useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A standard roster item is encoded as follows.

+

It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A standard roster item is encoded as follows.

]]>

- MIX channels in the roster have an attribute 'channel' set to true. + MIX channels in the roster have an empty element 'channel' included in the roster item.

+ ]]>

+ A server following the MIX specification MUST determine whether or not a client supports MIX. The server will often have this information prior to the roster request, due to &xep0115; Entity Capabilities. If the server does not have this information it MUST use service discovery to determine it before providing roster information. When sending roster information to a client that advertises MIX capability, the server MUST return all MIX channels and MUST use this encoding. Presence of MIX roster items MUST be set to offline (unavailable).

@@ -2542,6 +2544,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa Where a client does not advertise MIX capability, the server MAY choose to not return MIX channels as roster items. If this is done care needs to be taken, in particular around support of roster versioning &xep0237;.

+

+ When a server determines that a client has added or removed MIX capability, the entire roster MUST be sent and roster version reset. This is not a particularly efficient approach, but this is expected to be a rare event and so a simple approach is preferred. +

From bee049fbef72f66f72ccac4fb53d71c3f05a1f82 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Tue, 13 Jun 2017 14:23:18 +0100 Subject: [PATCH 09/54] Clarify delivery --- xep-0369.xml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xep-0369.xml b/xep-0369.xml index a00f0056..05c87f6c 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -44,6 +44,7 @@ Remove Legacy MIX Namespace; Add mix element in message to hold MIX additional information; Roster Update Clarifications; + Clarify when messages are delivered to clients;

@@ -2422,6 +2423,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]>

+ The server receiving the message will then deliver the messages to all online clients with status available and a non-negative resource priority. The following example shows how the participant's server modifies the inbound message to replace the bare JID in the 'to' with a full JID for each of two active MIX clients.

From 39611ada6fb1293b389d4b29970f9b22dbf684e0 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Tue, 13 Jun 2017 15:04:35 +0100 Subject: [PATCH 10/54] Corrections --- xep-0369.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 05c87f6c..feb6f9eb 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -2528,7 +2528,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]>

- MIX channels in the roster have an empty element 'channel' included in the roster item. + MIX channels in the roster have an element 'channel' included in the roster item.

- A server following the MIX specification MUST determine whether or not a client supports MIX. The server will often have this information prior to the roster request, due to &xep0115; Entity Capabilities. If the server does not have this information it MUST use service discovery to determine it before providing roster information. + A server following the MIX specification MUST determine whether or not a client supports MIX. If the server does not have this information it MUST use service discovery to determine it before providing roster information. When sending roster information to a client that advertises MIX capability, the server MUST return all MIX channels and MUST use this encoding. Presence of MIX roster items MUST be set to offline (unavailable).

@@ -2547,7 +2547,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

- When a server determines that a client has added or removed MIX capability, the entire roster MUST be sent and roster version reset. This is not a particularly efficient approach, but this is expected to be a rare event and so a simple approach is preferred. + When a client adds MIX capability, additional information needs to be provided by the server. To support this, a server MUST maintain information about client MIX support status. When a server detects this change it needs to update the roster which it MAY do incrementally or by sending all of the roster.

From f3a9ca6b393c0aaa1ae216b75740ad2ab097ca27 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Tue, 30 May 2017 17:18:37 +0200 Subject: [PATCH 11/54] xep-0390: clearly specify handling of xml:lang attributes --- xep-0390.xml | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/xep-0390.xml b/xep-0390.xml index 0ed820e4..3d474642 100644 --- a/xep-0390.xml +++ b/xep-0390.xml @@ -51,6 +51,16 @@ jonas@wielicki.name jonas@wielicki.name + + 0.2 + 2017-06-14 + jwi + +
    +
  • Clearly specify handling of xml:lang attributes.
    • +
+ + 0.1 2017-03-23 @@ -109,7 +119,11 @@

The input to this algorithm is a &xep0030; disco#info <query/> response. The output is an octet string which can be used as input to a hash function or an error.

-

General remarks: The algorithm strongly distinguishes between character data (sequences of Unicode code points) and octet strings (sequences of 8-bit bytes). Whenever character data is encoded to octet strings in the following algorithm, the UTF-8 encoding as specified in &rfc3629; is used. Whenever octet strings are sorted in the following algorithm, the i;octet collation as specified in &rfc4790; is used.

+

General remarks:

+
    +

  • The algorithm strongly distinguishes between character data (sequences of Unicode code points) and octet strings (sequences of 8-bit bytes). Whenever character data is encoded to octet strings in the following algorithm, the UTF-8 as specified in &rfc3629; encoding is used. Whenever octet strings are sorted in the following algorithm, the i;octet collation as specified in &rfc4790; is used.

    • +

  • The algorithm uses the xml:lang attribute. Implementations must take implicit values for the xml:lang attribute into account, for example those inherited from the disco#info or the IQ element.

    • +
  1. If the <query/> element contains any elements except <identity/>, <feature/> (both from the &xep0030; disco#info namespace) or &xep0128; data forms, abort with an error.
  2. If any &xep0128; <x/> element contains a data form which contains a <reported/> or <item/> element, abort with an error.
    3. @@ -739,6 +753,7 @@ cDp0aW1lHxw=

    Instead of issuing a &xep0030; disco#info <query/> with absent 'node' attribute to a target entity, an entity MAY use a &hashcache; to obtain the response. To look up the disco#info response in the &hashcache;, an entity MUST use a hash from the &hashset; which was most recently received from the entity to which the <query/> would have been sent otherwise. If none of the most recently received &hashes; are found in the &hashcache;, the entity MUST fall back to sending the request.

    An entity MUST NOT use &hashes; which were not included in the most recent &hashset; received from the target entity.

    An entity MAY use external data sources to fill the &hashcache;.

    +

    An entity MUST ensure that implicit values for xml:lang attributes is preserved when disco#info data is cached. This can for example happen by making the implicit values explicit in the storage.

    @@ -773,6 +788,7 @@ cDp0aW1lHxw=

    This was an issue with &xep0115; and has been addressed with a new algorithm for generating the hash function input which keeps the structural information of the disco#info input.

    An entity MUST NOT ever use disco#info which has not been verified to belong to a &hash; obtained from a cache using that &hash;. Using cache contents from a trusted source (at the discretion of the entity) counts as verifying.

    A malicious entity could send a large amount of &hashsets; in short intervals, while making sure that it provides matching disco#info responses. If a &procent; uses caching, this can overflow or thrash the caches. &procents; should be aware of this risk and apply proper rate-limiting for processing &hashsets;. To reduce the attack surface, an entity MAY choose to not cache &hashes; obtained from entities not in its roster.

    +

    As mentioned earlier, when storing disco#info data in a cache for later retrieval, implementations MUST ensure that implicit values for xml:lang attributes are reconstructed correctly when the disco#info is restored.

    From 5d7576ad6f550b573d394e3c2a27d1738194be82 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?louiz=E2=80=99?= Date: Thu, 15 Jun 2017 11:37:16 +0200 Subject: [PATCH 12/54] xep-0321 Use neutral pronouns instead of his/he --- xep-0321.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xep-0321.xml b/xep-0321.xml index caccb092..0210c352 100644 --- a/xep-0321.xml +++ b/xep-0321.xml @@ -55,7 +55,7 @@

    This document addresses the following requirements:

    1. Make it possible for remote services or entities to manage user's roster by the same mechanisms that descibed in the &rfc6121;.
      2. -
    2. Provide a way for user to control which services have permission to manage his roster.
      3. +
    3. Provide a way for user to control which services have permission to manage their roster.
    @@ -82,7 +82,7 @@ You must have a presence subscription to be able to request remote roster management service. ]]> -

    The user's server SHOULD then generate a form request using &xep0004; to client in order to ask user if he's OK with granting the permission to the remote entity. The "challenge" form field is generated by the server and is used to identify the client's response. The server also MUST immediatly answer to the request IQ.

    +

    The user's server SHOULD then generate a form request using &xep0004; to client in order to ask user if they are OK with granting the permission to the remote entity. The "challenge" form field is generated by the server and is used to identify the client's response. The server also MUST immediatly answer to the request IQ.

    NOTE: if the entity is already granted with the permission, the server SHOULD immediatly answer with a success response and skip querying the user.

    You have tried to modify the item you don't allowed to. ]]>     - +

    User can ask the server to provide a list of components or servers which have permissions to edit their roster.

    From 5a8418a5400806fcd513b962372c0b8db9bde21a Mon Sep 17 00:00:00 2001 From: vanitasvitae Date: Thu, 15 Jun 2017 11:44:05 +0200 Subject: [PATCH 13/54] Add Proposal for Jingle Encrypted Transfers (jet) --- inbox/xep-jet.xml | 165 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 165 insertions(+) create mode 100644 inbox/xep-jet.xml diff --git a/inbox/xep-jet.xml b/inbox/xep-jet.xml new file mode 100644 index 00000000..2640381e --- /dev/null +++ b/inbox/xep-jet.xml @@ -0,0 +1,165 @@ + + +%ents; +]> + + +
    + Jingle Encrypted Transfers + This specification defines a method that allows file transfers via Jingle File Transfer to be end-to-end encrypted using established encryption schemes like OpenPGP or OMEMO. + &LEGALNOTICE; + XXXX + ProtoXEP + Standards Track + Standards + Council + + XEP-0234 + + + + jet + + jingle + http://xmpp.org/schemas/jingle.xsd + + + jingle:errors + http://xmpp.org/schemas/jingle-errors.xsd + + + jingle + + Paul + Schaub + vanitasvitae@riseup.net + vanitasvitae@jabberhead.tk + + + 0.0.1 + 2017-06-12 + vv +

    First draft

     +     +
    + +

    &xep0234; has the disadvantage, that transmitted files are not encrypted (aside from regular TLS transport encryption), which means that intermediate nodes like the XMPP server(s) have access to the transferred data. Considering that end-to-end encryption becomes more and more important for communications, this is a major flaw that needs to be addressed.

    +

    This document defines a method to enable two communication partners to utilize an already established secure channel (eg. an OMEMO session) to exchange an encryption key which can then be used to encrypt/decrypt the offered/requested file.

    +     + +

    In order to initiate an encrypted file transfer, the initiator includes a key-element in the jingle-request. This key-element contains an encryption key which is used to encrypt/decryt the transferred key. In both file offers and file requests, it is the initiator, which dictates this key. The key is encrypted using the encryption method of the initiators choice. The initiator and responder must establish a session beforehand.

    + + +

    In this scenario Romeo wants to send an encrypted text file over to Juliet. He chooses to use their existing OMEMO session to do so. First, he generates a fresh TODO-AES key and IV. This will later be used to encrypt and decrypt the file. In order to be transmitted, key and IV have to be serialized. Key and IV are both Base64 encoded and appended in the following form:

    + +

    This text is encrypted using the established secure encryption method. The resulting OMEMO element is sent as part of the security element along with the rest of the jingle stanza over to Juliet.

    + + + + + + 1969-07-21T02:56:15Z + This is a test. If this were a real file... + text/plain + test.txt + + 6144 + w0mcJylzCn+AfvuGdqkty2+KP48= + + + + + + + +
    + BASE64ENCODED... + BASE64ENCODED... + BASE64ENCODED... +
    + BASE64-ENCODED-ENCRYPTED-KEY +     +     +     +     +]]>     + +

    Juliet decrypts the OMEMO element using her session with Romeo to retrieve the key and IV. Both Juliet and Romeo then carry on with the session negotiation as described in &xep0234;. Before Romeo starts transmitting the file, he encrypts it using the key and IV. He then transmitts the encrypted file over to Juliet.

    +

    When Juliet received the file, she uses the decrypted key and IV to decrypt the received file.

    +     + + +

    Juliet might want to request a file transfer from Romeo. This can be the case, when Romeo hosts the file. In order to do so, she sends him a key and IV which Romeo will use to encrypt the file before sending it to Juliet. In this example we assume, that Romeo and Juliet secured their communications using &xep0374;.

    + + + + + + w0mcJylzCn+AfvuGdqkty2+KP48= + + + + + + + + + + + + +]]> +     +     + + +

    This is only a rough draft and there is still a ton of questions left to be answered. Here is a small non-exhaustive list of things I can think of:

    +
      +
    • What cipher is used to encrypt the file? Examples would be AES-GCM128/256...
      • +
    • Cipher agility? What format is used to serialize key and IV?
      • +
    • How exactly are interrupted transfers resumed? How (long) are keys/IVs cached?
      • +
    • Is it in the scope of this approach to hide metadata?
      • +
    • How are transferred files authenticated? (See OMEMO audit)
      • +
    • May it be desirable to split data into chunks?
      • +
    • Please add to this list :)
      • +
    +     +     From 5d1cd5b69d793997d33c73ac343d7853ba7008e1 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Thu, 15 Jun 2017 12:44:11 +0100 Subject: [PATCH 14/54] Another go at delivery clarification --- xep-0369.xml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index feb6f9eb..84927f00 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -38,7 +38,7 @@ &stpeter; 0.9.3 - 2017-06-13 + 2017-06-15 sek

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

    - The server receiving the message will then deliver the messages to all online clients with status available and a non-negative resource priority. + The server receiving the message will then deliver the messages to all online clients. Messages are delivered to all available online resources irrespective of + status and resource priority. The following example shows how the participant's server modifies the inbound message to replace the bare JID in the 'to' with a full JID for each of two active MIX clients.

    From da21b293484855e9ab2b58f11a749eab37dc66f9 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Thu, 15 Jun 2017 13:18:08 +0100 Subject: [PATCH 15/54] Add MIX extension to Roster Get --- xep-0369.xml | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 84927f00..ecc7087a 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -45,6 +45,7 @@ Add mix element in message to hold MIX additional information; Roster Update Clarifications; Clarify when messages are delivered to clients; + Extend Roster Get to select format;

    @@ -2523,13 +2524,23 @@ This approach enables flexible support of multiple clients for a MIX channel pa     -

    It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A standard roster item is encoded as follows.

    +

    It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A MIX client MAY request that the server return this additional information. The server MUST return the additional information. The request is made by adding to the standard roster get request and element <mix-info-request/> qualified by the ‘urn:xmpp:mix:0' namespace.

    + + + + +]]> + +

    A standard roster item is encoded as follows.

    ]]>

    - MIX channels in the roster have an element 'channel' included in the roster item. + MIX channels in the roster information returned in response to a request for this additional MIX information MUST have an element <channel/> qualified by the ‘urn:xmpp:mix:0' namespace included in the roster item, as shown inf the following example.

    ]]> -

    - A server following the MIX specification MUST determine whether or not a client supports MIX. If the server does not have this information it MUST use service discovery to determine it before providing roster information. - When sending roster information to a client that advertises MIX capability, the server MUST return all MIX channels and MUST use this encoding. Presence of MIX roster items MUST be set to offline (unavailable). -

    - -

    - Where a client does not advertise MIX capability, the server MAY choose to not return MIX channels as roster items. If this is done care needs to be taken, in particular around support of roster versioning &xep0237;. -

    - -

    - When a client adds MIX capability, additional information needs to be provided by the server. To support this, a server MUST maintain information about client MIX support status. When a server detects this change it needs to update the roster which it MAY do incrementally or by sending all of the roster. -

    +     From 91d80e00d8ffd68c1130c2cfdf0f9ac17e0fda23 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Thu, 15 Jun 2017 15:14:44 +0100 Subject: [PATCH 16/54] Ensure elements specifed in text and qualified by namespace --- xep-0369.xml | 42 +++++++++++++++++++++++------------------- 1 file changed, 23 insertions(+), 19 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index ecc7087a..0be22e4f 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -46,6 +46,7 @@ Roster Update Clarifications; Clarify when messages are delivered to clients; Extend Roster Get to select format; + Ensure that text defining attributes and elements reference the namespace;

    @@ -499,7 +500,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa -

    Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the bare proxy JID of the participant. For example '123456#coven@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. The nick associated with the user is mandatory and is stored in the item. The nick for each channel participant MUST be different to the nick of other participants. +

    Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the bare proxy JID of the participant. For example '123456#coven@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:0' namespace. The nick associated with the user is mandatory and is stored in a <nick/> sub-element of the <participant/> element. The nick for each channel participant MUST be different to the nick of other participants.

    When a user joins a channel, the user's bare JID is added to the participants node by the MIX service. When a user leaves a channel, they are removed from the participants node. The participants node MUST NOT be directly modified using pubsub. @@ -522,7 +523,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. The JID Map node MUST have one entry for each entry in the Participants node. This value is added when a user joins the channel and is removed when the user leaves the channel. Each item is identified by proxy bare JID, mapping to the real bare JID. This node is used to give administrator access to real JIDs and participant access to real JIDs in jid-visible channels. This node MUST NOT be modified directly using pubsub. - In JID Visible channels, all participants MAY subscribe to this node. In JID Hidden and JID Maybe Visible channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant.

    + In JID Visible channels, all participants MAY subscribe to this node. In JID Hidden and JID Maybe Visible channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:0' namespace. The real JID is stored in a <jid/> sub-element of the <participant/> element.

    @@ -543,7 +544,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    - The presence node contains the presence value for clients belonging to participants that choose to publish presence to the channel. A MIX channel MAY require that all participants publish presence. Each item in the presence node is identified by the full proxy JID, and contains the current presence value for that JID. The presence is encoded in the same way as data that would be sent in a presence stanza. The full proxy JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control MAY be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list. + The presence node contains the presence value for clients belonging to participants that choose to publish presence to the channel. A MIX channel MAY require that all participants publish presence. Each item in the presence node is identified by the full proxy JID, and contains the current presence value for that JID. The presence is encoded in the same way as data that would be sent in a presence stanza using a <presence/> element qualified by the 'jabber:client' namespace. The full proxy JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control MAY be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list.

    @@ -955,8 +956,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa -

    A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to messages, and presence. - This will lead to the server subscribing the user to each of the requested nodes associated with the channel. The MIX service will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically. +

    A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to messages, and presence. The <join/> is a sub-element of <iq/> qualified by the 'urn:xmpp:mix:0' namespace. The channel is specified by a 'channel' attribute in the <join/> element. The requested nodes are encoded as <subscribe/> sub-elements of the <join/> element. + The join leads to the server subscribing the user to each of the requested nodes associated with the channel. The MIX service will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.

    The default MIX model is that only channel participants are allowed to subscribe to nodes. A MIX channel MAY allow non-participant subscription. This will be handled by clients directly subscribing to the desired PubSub nodes.

    @@ -1067,7 +1068,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa At the same time the participant MUST be added to the JID Map node, to map from proxy JID to real JID. For a JID Maybe Visible channel, the participant MUST be added to the JID Maybe Visible Map node. The value in this node MUST reflect the user's visibility preference for the channel and MUST be updated to reflect any changes to this preference.

    - A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request, as shown in the following example. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. + A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a <update-subscription/$gt; sub-element of <iq/> qualified by the 'urn:xmpp:mix:0' namespace. The requested notes are encoded as <subscribe/> sub-elements of the <update-subscription/$gt; element with the node name encoded as a 'node' attribute. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification.

    ]]> -

    The client MAY also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard, by providing a form template in the result. This query is direct from the client to the MIX channel.

    +

    The client MAY also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard, by providing a form template in the result. The request is encoded as a <user-preference/> sub-element of <iq/> qualified by the 'urn:xmpp:mix:0' namespace. The result is encoded as a form sub-element in the <user-preference/> element.

    -

    Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, a user sends a MIX "leave" command to the channel. When a user leaves the channel, the user's server will remove the channel from the user's roster. Leave commands are sent indirectly through the user's server, to enable roster removal. Leaving is initiated by a client request, as shown in the following example.

    +

    Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, a user sends a MIX "leave" command to the channel. The leave command is encoded as a <leave/> sub-element of <iq/> element qualified by the 'urn:xmpp:mix:0' namespace, with the channel specified as a 'channel" attribute. When a user leaves the channel, the user's server will remove the channel from the user's roster. Leave commands are sent indirectly through the user's server, to enable roster removal. Leaving is initiated by a client request, as shown in the following example.

    The MIX service generates the nick. In this case it is RECOMMENDED that the assigned nick is a UUID following &rfc4122;.

- A user will typically set a nick when joining a channel and MAY update this nick from time to time. The user does this by sending a command to the channel to set the nick. If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result. + A user will typically set a nick when joining a channel and MAY update this nick from time to time. The user does this by sending a command to the channel to set the nick. This command is a <setnick/> sub-element of <iq/> element qualified by the 'urn:xmpp:mix:0' namespace. The nick is encoded as a <nick/> sub-element of the <setnick/> element. If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result.

To register a nick with the MIX service the user sends - a <register/> command to the service.

+ a register command to the service. This is encoded as a <register/> sub-element of an <iq/> element qualified by the urn:xmpp:mix:0' namespace. The nick is encoded in a <nick/> sub-element of the <register/> element.

]]>

- The MIX channel then adds information to the message using a <mix> element. This element contains two elements: + The MIX channel then adds information to the message using a <mix> element qualified by the 'urn:xmpp:mix:0' namespace. This element contains two sub-elements:

  1. A <nick> element that contains the Nick of the message sender, taken from the Participants Node.
    2. @@ -1711,7 +1712,7 @@ 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 a message with a <retract> element 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:0' namespace as shown in the following example.

    The second approach is to leave a tombstone, which if taken MUST be done in the following manner. This is appropriate where it is desired to leave a record of the message that was redacted. - With this approach, the original message <body> is removed and replaced with a tombstone using the <retracted> element that shows the JID of user performing the retraction and the time of the retraction. + With this approach, the original message <body> is removed and replaced with a tombstone using the <retracted> element qualified by the 'urn:xmpp:mix:0' namespace that shows the JID of user performing the retraction and the time of the retraction.

    @@ -1768,7 +1769,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
  2. The invitee MAY send a response to the inviter, indicating if the invitation was accepted or declined.

- The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time. + The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time. The invitation request is encoded as an <invite/> sub-element of an <iq/> element qualified by the 'urn:xmpp:mix:0' namespace. <invite/> contains an <invitation/> sub-element, which contain <inviter/>, <invitee/>, <channel/> and <token/> sub-elements.

]]>

- The inviter can now send the invitee a message containing the invitation, as shown in the following example. + The inviter can now send the invitee a message containing the invitation within the <message/> element, as shown in the following example.

]]> -

The invitation can now be used by the invitee to join a channel. The invitation is simply added to the standard channel join, so that the channel can validate the invitation using the token. If the allowed node is present and the invitee is not matched against any item, the channel MUST add the invitee to the allowed node as part of the join.

+

The invitation can now be used by the invitee to join a channel. The <invitation/> sub-element is simply added to the standard channel <join/> element, so that the channel can validate the invitation using the token. If the allowed node is present and the invitee is not matched against any item, the channel MUST add the invitee to the allowed node as part of the join.

]]> -

The invitee MAY send an acknowledgement back to the inviter, noting the status of the invitation. Values are:

+

The invitee MAY send an acknowledgement back to the inviter, noting the status of the invitation. + This is encoded as an <invitation-ack/> sub-element of <message/> element qualified by the 'urn:xmpp:mix:0' namespace. The <invitation-ack/> has an <invitation/> sub-element that encodes the invitation being acknowledged and a <value/> sub-element to encode the acknowledgement value. + <value/> has the following values:

  • 'Joined': The invitee has joined the channel.
  • 'Declined': The invitee is not taking up the invitation.
    • @@ -1946,7 +1949,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa It is important that messages are all transferred from the MIX channel to the server associated with the each channel participant. Transfer between servers will typically happen quickly and &xep0198; will deal with short connection failures between servers. Longer connection failures could lead to message loss. This would lead to online users (who remain connected to their servers) missing messages, and to messages being missed out of the user archive. This section describes how MIX addresses this.

    - When there is a long term connection failure, the MIX channel will receive an error from the XMPP server indicating that a message failed to transfer to a recipient. When this happens, the MIX channel MUST take responsibility to ensure that the message is retransmitted and delivered. When the MIX channel detects a failure it will make use of an IQ Marker message to determine when the connection to the peer server is working again. Once the channel has received a response to the marker IQ it will retransmit the pending messages. + When there is a long term connection failure, the MIX channel will receive an error from the XMPP server indicating that a message failed to transfer to a recipient. When this happens, the MIX channel MUST take responsibility to ensure that the message is retransmitted and delivered. When the MIX channel detects a failure it will make use of an IQ Marker message to determine when the connection to the peer server is working again. Once the channel has received a response to the marker IQ it will retransmit the pending messages. The marker is encoded as a <marker/> sub-element of an <iq/> element qualified by the 'urn:xmpp:mix:0' namespace.

    - A client creates a channel by sending a simple request to the MIX service. A channel MAY be created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). Creating and destroying a channel is done direct from a client. + A client creates a channel by sending a simple request to the MIX service. A channel MAY be created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). The create is encoded as a <create/> sub-element of <iq/> element qualified by the 'urn:xmpp:mix:0' namespace. The <create/> element MUST have a 'channel' attribute to specify the channel name.

    + The destroy operation is encoded as a <destroy/> sub-element of an <iq/> element qualified by the 'urn:xmpp:mix:0' namespace. The <destroy/> element MUST have a 'channel' attribute to specify the channel to be destroyed. A client destroys a channel using a simple set operation, as shown in the following example.

    Date: Thu, 15 Jun 2017 15:22:49 +0100 Subject: [PATCH 17/54] Correct get roster encoding --- xep-0369.xml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 0be22e4f..20d79df4 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -2528,13 +2528,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa -

    It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A MIX client MAY request that the server return this additional information. The server MUST return the additional information. The request is made by adding to the standard roster get request and element <mix-info-request/> qualified by the ‘urn:xmpp:mix:0' namespace.

    +

    It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A MIX client MAY request that the server return this additional information. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a sub-element <mix-info-request/> to the <query/> element qualified by the ‘urn:xmpp:mix:0' namespace.

    - - + + + ]]> From ceaf2e2a4aa0b61dc3983270fe7615c7b536aa36 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Thu, 15 Jun 2017 15:35:33 +0100 Subject: [PATCH 18/54] minor edits --- xep-0369.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0369.xml b/xep-0369.xml index 20d79df4..49b0966b 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -1665,7 +1665,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
  • A <jid> element containing the full proxy JID of the sender.

    • The MIX channel then puts a copy of the message into the MAM archive for the channel and sends a copy of the message to each participant in - standard groupchat format. These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's local server. The message from value is the JID of the channel. The id of the message is the ID from the MAM archive and NOT the id used by the sender. The message placed in the MAM archive is the reflected message without a 'to' element.

    + standard groupchat format. These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's local server. The message 'from' attribute is the JID of the channel. The id of the message is the ID from the MAM archive and NOT the id used by the sender. The message placed in the MAM archive is the reflected message without a 'to' attribute.

    Date: Thu, 15 Jun 2017 16:04:16 +0100 Subject: [PATCH 19/54] Change sub-element to child element --- xep-0369.xml | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 49b0966b..c3d5e290 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -500,7 +500,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa     -

    Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the bare proxy JID of the participant. For example '123456#coven@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:0' namespace. The nick associated with the user is mandatory and is stored in a <nick/> sub-element of the <participant/> element. The nick for each channel participant MUST be different to the nick of other participants. +

    Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the bare proxy JID of the participant. For example '123456#coven@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:0' namespace. The nick associated with the user is mandatory and is stored in a <nick/> child element of the <participant/> element. The nick for each channel participant MUST be different to the nick of other participants.

    When a user joins a channel, the user's bare JID is added to the participants node by the MIX service. When a user leaves a channel, they are removed from the participants node. The participants node MUST NOT be directly modified using pubsub. @@ -523,7 +523,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. The JID Map node MUST have one entry for each entry in the Participants node. This value is added when a user joins the channel and is removed when the user leaves the channel. Each item is identified by proxy bare JID, mapping to the real bare JID. This node is used to give administrator access to real JIDs and participant access to real JIDs in jid-visible channels. This node MUST NOT be modified directly using pubsub. - In JID Visible channels, all participants MAY subscribe to this node. In JID Hidden and JID Maybe Visible channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:0' namespace. The real JID is stored in a <jid/> sub-element of the <participant/> element.

    + In JID Visible channels, all participants MAY subscribe to this node. In JID Hidden and JID Maybe Visible channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:0' namespace. The real JID is stored in a <jid/> child element of the <participant/> element.

    @@ -956,7 +956,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa -

    A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to messages, and presence. The <join/> is a sub-element of <iq/> qualified by the 'urn:xmpp:mix:0' namespace. The channel is specified by a 'channel' attribute in the <join/> element. The requested nodes are encoded as <subscribe/> sub-elements of the <join/> element. +

    A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to messages, and presence. The <join/> is a child element of <iq/> element. The <join/> element is qualified by the 'urn:xmpp:mix:0' namespace. The channel is specified by a 'channel' attribute in the <join/> element. The requested nodes are encoded as <subscribe/> child elements of the <join/> element. The join leads to the server subscribing the user to each of the requested nodes associated with the channel. The MIX service will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.

    @@ -1068,7 +1068,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa At the same time the participant MUST be added to the JID Map node, to map from proxy JID to real JID. For a JID Maybe Visible channel, the participant MUST be added to the JID Maybe Visible Map node. The value in this node MUST reflect the user's visibility preference for the channel and MUST be updated to reflect any changes to this preference.

    - A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a <update-subscription/$gt; sub-element of <iq/> qualified by the 'urn:xmpp:mix:0' namespace. The requested notes are encoded as <subscribe/> sub-elements of the <update-subscription/$gt; element with the node name encoded as a 'node' attribute. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification. + A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a <update-subscription/$gt; child element of <iq/> element. The <update-subscription/$gt; element is qualified by the 'urn:xmpp:mix:0' namespace. The requested notes are encoded as <subscribe/> child elements of the <update-subscription/$gt; element with the node name encoded as a 'node' attribute. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification.

    ]]> -

    The client MAY also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard, by providing a form template in the result. The request is encoded as a <user-preference/> sub-element of <iq/> qualified by the 'urn:xmpp:mix:0' namespace. The result is encoded as a form sub-element in the <user-preference/> element.

    +

    The client MAY also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard, by providing a form template in the result. The request is encoded as a <user-preference/> child element of <iq/>. <user-preference/> is qualified by the 'urn:xmpp:mix:0' namespace. The result is encoded as a form child element in the <user-preference/> element.

    -

    Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, a user sends a MIX "leave" command to the channel. The leave command is encoded as a <leave/> sub-element of <iq/> element qualified by the 'urn:xmpp:mix:0' namespace, with the channel specified as a 'channel" attribute. When a user leaves the channel, the user's server will remove the channel from the user's roster. Leave commands are sent indirectly through the user's server, to enable roster removal. Leaving is initiated by a client request, as shown in the following example.

    +

    Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, a user sends a MIX "leave" command to the channel. The leave command is encoded as a <leave/> child element of <iq/> element. The <leave/> element is qualified by the 'urn:xmpp:mix:0' namespace, with the channel specified as a 'channel" attribute. When a user leaves the channel, the user's server will remove the channel from the user's roster. Leave commands are sent indirectly through the user's server, to enable roster removal. Leaving is initiated by a client request, as shown in the following example.

    The MIX service generates the nick. In this case it is RECOMMENDED that the assigned nick is a UUID following &rfc4122;.

    - A user will typically set a nick when joining a channel and MAY update this nick from time to time. The user does this by sending a command to the channel to set the nick. This command is a <setnick/> sub-element of <iq/> element qualified by the 'urn:xmpp:mix:0' namespace. The nick is encoded as a <nick/> sub-element of the <setnick/> element. If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result. + A user will typically set a nick when joining a channel and MAY update this nick from time to time. The user does this by sending a command to the channel to set the nick. This command is a <setnick/> child element of <iq/> element. The <setnick/> element is qualified by the 'urn:xmpp:mix:0' namespace. The nick is encoded as a <nick/> child element of the <setnick/> element. If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result.

    To register a nick with the MIX service the user sends - a register command to the service. This is encoded as a <register/> sub-element of an <iq/> element qualified by the urn:xmpp:mix:0' namespace. The nick is encoded in a <nick/> sub-element of the <register/> element.

    + a register command to the service. This is encoded as a <register/> child element of an <iq/> element. The <register/> element is qualified by the urn:xmpp:mix:0' namespace. The nick is encoded in a <nick/> child element of the <register/> element.

    ]]>

    - The MIX channel then adds information to the message using a <mix> element qualified by the 'urn:xmpp:mix:0' namespace. This element contains two sub-elements: + The MIX channel then adds information to the message using a <mix> element qualified by the 'urn:xmpp:mix:0' namespace. This element contains two child elements:

    1. A <nick> element that contains the Nick of the message sender, taken from the Participants Node.
      2. @@ -1769,7 +1769,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
    2. The invitee MAY send a response to the inviter, indicating if the invitation was accepted or declined.

    - The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time. The invitation request is encoded as an <invite/> sub-element of an <iq/> element qualified by the 'urn:xmpp:mix:0' namespace. <invite/> contains an <invitation/> sub-element, which contain <inviter/>, <invitee/>, <channel/> and <token/> sub-elements. + The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time. The invitation request is encoded as an <invite/> child element of an <iq/> element. The <invite/> element is qualified by the 'urn:xmpp:mix:0' namespace. <invite/> contains an <invitation/> child element, which contain <inviter/>, <invitee/>, <channel/> and <token/> child elements.

    ]]> -

    The invitation can now be used by the invitee to join a channel. The <invitation/> sub-element is simply added to the standard channel <join/> element, so that the channel can validate the invitation using the token. If the allowed node is present and the invitee is not matched against any item, the channel MUST add the invitee to the allowed node as part of the join.

    +

    The invitation can now be used by the invitee to join a channel. The <invitation/> child element is simply added to the standard channel <join/> element, so that the channel can validate the invitation using the token. If the allowed node is present and the invitee is not matched against any item, the channel MUST add the invitee to the allowed node as part of the join.

    ]]>

    The invitee MAY send an acknowledgement back to the inviter, noting the status of the invitation. - This is encoded as an <invitation-ack/> sub-element of <message/> element qualified by the 'urn:xmpp:mix:0' namespace. The <invitation-ack/> has an <invitation/> sub-element that encodes the invitation being acknowledged and a <value/> sub-element to encode the acknowledgement value. + This is encoded as an <invitation-ack/> child element of <message/> element. The <invitation-ack/> element is qualified by the 'urn:xmpp:mix:0' namespace. The <invitation-ack/> has an <invitation/> child element that encodes the invitation being acknowledged and a <value/> child element to encode the acknowledgement value. <value/> has the following values:

    • 'Joined': The invitee has joined the channel.
      • @@ -1949,7 +1949,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa It is important that messages are all transferred from the MIX channel to the server associated with the each channel participant. Transfer between servers will typically happen quickly and &xep0198; will deal with short connection failures between servers. Longer connection failures could lead to message loss. This would lead to online users (who remain connected to their servers) missing messages, and to messages being missed out of the user archive. This section describes how MIX addresses this.

      - When there is a long term connection failure, the MIX channel will receive an error from the XMPP server indicating that a message failed to transfer to a recipient. When this happens, the MIX channel MUST take responsibility to ensure that the message is retransmitted and delivered. When the MIX channel detects a failure it will make use of an IQ Marker message to determine when the connection to the peer server is working again. Once the channel has received a response to the marker IQ it will retransmit the pending messages. The marker is encoded as a <marker/> sub-element of an <iq/> element qualified by the 'urn:xmpp:mix:0' namespace. + When there is a long term connection failure, the MIX channel will receive an error from the XMPP server indicating that a message failed to transfer to a recipient. When this happens, the MIX channel MUST take responsibility to ensure that the message is retransmitted and delivered. When the MIX channel detects a failure it will make use of an IQ Marker message to determine when the connection to the peer server is working again. Once the channel has received a response to the marker IQ it will retransmit the pending messages. The marker is encoded as a <marker/> child element of an <iq/> element. The <marker/> element is qualified by the 'urn:xmpp:mix:0' namespace.

      - A client creates a channel by sending a simple request to the MIX service. A channel MAY be created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). The create is encoded as a <create/> sub-element of <iq/> element qualified by the 'urn:xmpp:mix:0' namespace. The <create/> element MUST have a 'channel' attribute to specify the channel name. + A client creates a channel by sending a simple request to the MIX service. A channel MAY be created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). The create is encoded as a <create/> child element of <iq/> element. The <create/> is qualified by the 'urn:xmpp:mix:0' namespace. The <create/> element MUST have a 'channel' attribute to specify the channel name.

      - The destroy operation is encoded as a <destroy/> sub-element of an <iq/> element qualified by the 'urn:xmpp:mix:0' namespace. The <destroy/> element MUST have a 'channel' attribute to specify the channel to be destroyed. + The destroy operation is encoded as a <destroy/> child element of an <iq/> element. The <destroy/> element is qualified by the 'urn:xmpp:mix:0' namespace. The <destroy/> element MUST have a 'channel' attribute to specify the channel to be destroyed. A client destroys a channel using a simple set operation, as shown in the following example.

      -

      It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A MIX client MAY request that the server return this additional information. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a sub-element <mix-info-request/> to the <query/> element qualified by the ‘urn:xmpp:mix:0' namespace.

      +

      It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A MIX client MAY request that the server return this additional information. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a child element <mix-info-request/> to the <query/> element. The <mix-info-request/> is qualified by the ‘urn:xmpp:mix:0' namespace.

      Date: Fri, 16 Jun 2017 07:08:31 +0100 Subject: [PATCH 20/54] mick-register rename --- xep-0369.xml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index c3d5e290..233943cb 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -38,7 +38,7 @@ &stpeter; 0.9.3 - 2017-06-15 + 2017-06-16 sek

      Remove Legacy MIX Namespace; @@ -47,6 +47,7 @@ Clarify when messages are delivered to clients; Extend Roster Get to select format; Ensure that text defining attributes and elements reference the namespace; + Change mix_nick_register to nick-register;

      @@ -1403,12 +1404,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='mix.shakespeare.example' id='7nve413p'> - + ]]>

      - The response will be a list of features of the MIX channel. If Nick Registration is supported, then the result set will include <feature var="urn:xmpp:mix:0#mix_nick_register"/>. + The response will be a list of features of the MIX channel. If Nick Registration is supported, then the result set will include <feature var="urn:xmpp:mix:0#nick-register"/>.

      To register a nick with the MIX service the user sends From 9d5d201be9f0ac9b7fc03fe91d4aad58d0fdbb06 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Fri, 16 Jun 2017 07:14:17 +0100 Subject: [PATCH 21/54] New roster namespace --- xep-0369.xml | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 233943cb..6dcd7432 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -48,6 +48,7 @@ Extend Roster Get to select format; Ensure that text defining attributes and elements reference the namespace; Change mix_nick_register to nick-register; + Separate namespace for roster information;

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

      It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A MIX client MAY request that the server return this additional information. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a child element <mix-info-request/> to the <query/> element. The <mix-info-request/> is qualified by the ‘urn:xmpp:mix:0' namespace.

      +

      It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A MIX client MAY request that the server return this additional information that annotates roster elements with MIX capability. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a child element <annotate/> to the <query/> element. The <mix-info-request/> is qualified by the ‘urn:xmpp:mix:roster:0' namespace.

      - + ]]> @@ -2546,12 +2547,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]>

      - MIX channels in the roster information returned in response to a request for this additional MIX information MUST have an element <channel/> qualified by the ‘urn:xmpp:mix:0' namespace included in the roster item, as shown inf the following example. + MIX channels in the roster information returned in response to a request for this additional MIX information MUST have an element <channel/> qualified by the ‘urn:xmpp:mix:roster:0' namespace included in the roster item, as shown inf the following example.

      - + ]]> From 7d66f8009bbcd990a7a42dccc1f8431c5358b1b8 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Fri, 16 Jun 2017 10:34:06 +0100 Subject: [PATCH 22/54] Correction --- xep-0369.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0369.xml b/xep-0369.xml index 6dcd7432..5f9d3764 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -2530,7 +2530,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa -

      It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A MIX client MAY request that the server return this additional information that annotates roster elements with MIX capability. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a child element <annotate/> to the <query/> element. The <mix-info-request/> is qualified by the ‘urn:xmpp:mix:roster:0' namespace.

      +

      It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A MIX client MAY request that the server return this additional information that annotates roster elements with MIX capability. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a child element <annotate/> to the <query/> element. The <annotate/> element is qualified by the ‘urn:xmpp:mix:roster:0' namespace.

      Date: Fri, 16 Jun 2017 11:03:39 +0100 Subject: [PATCH 23/54] rename jidmap2 to jidmap-visible --- xep-0369.xml | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 5f9d3764..5e68193c 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -49,6 +49,7 @@ Ensure that text defining attributes and elements reference the namespace; Change mix_nick_register to nick-register; Separate namespace for roster information; + rename jidmap2 to jidmap-visible;

      @@ -449,7 +450,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa Messages'urn:xmpp:mix:nodes:messages'For distributing messages to the channel. Each item of this node will contain a message sent to the channel.MessageMessage Participants'urn:xmpp:mix:nodes:participants'For storing the list of participants and the associated nick. Channel participants are added when they join the channel and removed when they leave Join/Leave/Set NickPubSub JID Map'urn:xmpp:mix:nodes:jidmap'For storing a list of bare proxy JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs.AutomaticPubSub - JID Maybe Visible Map'urn:xmpp:mix:nodes:jidmap2'For storing a list of bare proxy JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs for participants that choose to share real JIDs in a channel with JID Maybe Visible mode.AutomaticPubSub + JID Maybe Visible Map'urn:xmpp:mix:nodes:jidmap-visible'For storing a list of bare proxy JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs for participants that choose to share real JIDs in a channel with JID Maybe Visible mode.AutomaticPubSub Presence'urn:xmpp:mix:nodes:presence'For storing information about the availability status of online participants, which MAY include multiple clients for a single participant.PresencePresence Information'urn:xmpp:mix:nodes:info'For storing general channel information, such as description. PubSubPubSub Allowed'urn:xmpp:mix:nodes:allowed'For storing JIDs that are allowed to be channel participants.PubSubPubSub @@ -523,7 +524,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa       -

      The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. The JID Map node MUST have one entry for each entry in the Participants node. This value is added when a user joins the channel and is removed when the user leaves the channel. +

      The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap'. The JID Map node MUST have one entry for each entry in the Participants node. This value is added when a user joins the channel and is removed when the user leaves the channel. Each item is identified by proxy bare JID, mapping to the real bare JID. This node is used to give administrator access to real JIDs and participant access to real JIDs in jid-visible channels. This node MUST NOT be modified directly using pubsub. In JID Visible channels, all participants MAY subscribe to this node. In JID Hidden and JID Maybe Visible channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:0' namespace. The real JID is stored in a <jid/> child element of the <participant/> element.

      -

      The JID Maybe Visible Map node is a similar node to the JID Map node that is used in addition to the JID Map Node in JID Maybe Visible channels. All participants may subscribe to and access this node. It uses the same encoding as JID Map node and all participant JIDs MUST be included. Where a participant's preference is to not share the JID, the encoded participant value is the proxy JID. This will enable a user looking up a JID to clearly determine that the user preference is to not share the JID and to clearly distinguish this case from an erroneous proxy JID. +

      The JID Maybe Visible Map node is a similar node to the JID Map node that is used in addition to the JID Map Node in JID Maybe Visible channels. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap-visible'. All participants may subscribe to and access this node. It uses the same encoding as JID Map node and all participant JIDs MUST be included. Where a participant's preference is to not share the JID, the encoded participant value is the proxy JID. This will enable a user looking up a JID to clearly determine that the user preference is to not share the JID and to clearly distinguish this case from an erroneous proxy JID.

      @@ -642,7 +643,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa 'Owner'Bare JIDs with Owner rights as defined in ACL node. When a channel is created, the JID creating the channel is configured as an owner, unless this attribute is explicitly configured to another value.jid-multi-- 'Administrator'Bare JIDs with Administrator rights.jid-multi-- 'End of Life'The date and time at which the channel will be automatically removed by the server. If this is not set, the channel is permanent.text-single-- - 'Nodes Present'Specifies which nodes are present. Presence of config nodes is implicit. Jidmap node MUST be present if participants node is present. 'avatar' means that both Avatar Data and Avatar Metadata nodes are present.list-multi'participants'; 'presence'; 'information'; 'allowed'; 'banned'; 'jidmap2'; 'avatar'- + 'Nodes Present'Specifies which nodes are present. Presence of config nodes is implicit. Jidmap node MUST be present if participants node is present. 'avatar' means that both Avatar Data and Avatar Metadata nodes are present.list-multi'participants'; 'presence'; 'information'; 'allowed'; 'banned'; 'jidmap-visible'; 'avatar'- 'Messages Node Subscription'Controls who can subscribe to messages node.list-single'participants'; 'allowed'; 'anyone''participants' 'Presence Node Subscription'Controls who can subscribe to presence node.list-single'participants'; 'allowed'; 'anyone''participants' 'Participants Node Subscription'Controls who can subscribe to participants node.list-single'participants'; 'allowed'; 'anyone'; 'nobody'; 'admins'; 'owners''participants' From 2c4f00756136c6b98705e81951284f074855f9ff Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 31 May 2017 18:01:31 +0200 Subject: [PATCH 24/54] XEP-0045: add revision block --- xep-0045.xml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/xep-0045.xml b/xep-0045.xml index 0ea8892e..238d2fcb 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -45,6 +45,14 @@ &stpeter; + + 1.28 + 2017-05-31 + gl + +

      Introduce <x/> tag in MUC-PMs to support better Carbon delivery.

      +       +       1.27.1 2016-12-03 From 85a4305b68370c732c215d2f2b77486051ba9761 Mon Sep 17 00:00:00 2001 From: vanitasvitae Date: Mon, 19 Jun 2017 13:47:31 +0200 Subject: [PATCH 25/54] Fix xml of error examples --- xep-0234.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xep-0234.xml b/xep-0234.xml index 79ddd7e5..7f2be7cd 100644 --- a/xep-0234.xml +++ b/xep-0234.xml @@ -880,7 +880,7 @@ a=file-range:1024-*]]> - + @@ -904,7 +904,7 @@ a=file-range:1024-*]]> - + From 8e5e03168ad14c9b97dfc82a7448b7411eb3a179 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Tue, 20 Jun 2017 09:42:17 +0100 Subject: [PATCH 26/54] Namespace bump to mix:1 --- xep-0369.xml | 213 ++++++++++++++++++++++++++------------------------- 1 file changed, 107 insertions(+), 106 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 5e68193c..cf683589 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -50,6 +50,7 @@ Change mix_nick_register to nick-register; Separate namespace for roster information; rename jidmap2 to jidmap-visible; + version bump to urn:xmpp:mix:1;

      @@ -503,7 +504,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa -

      Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the bare proxy JID of the participant. For example '123456#coven@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:0' namespace. The nick associated with the user is mandatory and is stored in a <nick/> child element of the <participant/> element. The nick for each channel participant MUST be different to the nick of other participants. +

      Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the bare proxy JID of the participant. For example '123456#coven@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:1' namespace. The nick associated with the user is mandatory and is stored in a <nick/> child element of the <participant/> element. The nick for each channel participant MUST be different to the nick of other participants.

      When a user joins a channel, the user's bare JID is added to the participants node by the MIX service. When a user leaves a channel, they are removed from the participants node. The participants node MUST NOT be directly modified using pubsub. @@ -515,7 +516,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - + thirdwitch @@ -526,11 +527,11 @@ This approach enables flexible support of multiple clients for a MIX channel pa

      The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. It is a PubSub node with the 'node' attribute set to 'urn:xmpp:mix:nodes:jidmap'. The JID Map node MUST have one entry for each entry in the Participants node. This value is added when a user joins the channel and is removed when the user leaves the channel. Each item is identified by proxy bare JID, mapping to the real bare JID. This node is used to give administrator access to real JIDs and participant access to real JIDs in jid-visible channels. This node MUST NOT be modified directly using pubsub. - In JID Visible channels, all participants MAY subscribe to this node. In JID Hidden and JID Maybe Visible channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:0' namespace. The real JID is stored in a <jid/> child element of the <participant/> element.

      + In JID Visible channels, all participants MAY subscribe to this node. In JID Hidden and JID Maybe Visible channels, only administrators can subscribe. The JID Map node is a permanent node with one item per participant. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:1' namespace. The real JID is stored in a <jid/> child element of the <participant/> element.

      - + hecate@mix.shakespeare.example @@ -590,7 +591,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - urn:xmpp:mix:0 + urn:xmpp:mix:1 Witches Coven @@ -670,7 +671,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - urn:xmpp:mix:0 + urn:xmpp:mix:1 hecate@shakespeare.lit @@ -742,7 +743,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]> -

      The MIX service then MUST return its identity and the features it supports, which MUST include the 'urn:xmpp:mix:0' feature, and the identity MUST have a category of 'conference' and a type of 'text', as shown in the following example:

      +

      The MIX service then MUST return its identity and the features it supports, which MUST include the 'urn:xmpp:mix:1' feature, and the identity MUST have a category of 'conference' and a type of 'text', as shown in the following example:

      - - + + ]]>

      - A MIX service MUST return the 'urn:xmpp:mix:0' feature and MAY return the other features listed here: + A MIX service MUST return the 'urn:xmpp:mix:1' feature and MAY return the other features listed here:

        -
      • 'urn:xmpp:mix:0': This indicates support of MIX, and is returned by all MIX services.
        • -
      • 'urn:xmpp:mix:0#searchable': This is shown in the above example and indicates that a the MIX Service MAY be searched for channels. This presence of this feature can be used by a client to guide the user to search for channels in a MIX service.
        • -
      • 'urn:xmpp:mix:0#create-channel': This is described in Checking for Permission to Create a Channel in support of channel administration. When an end user client needs to create channels, perhaps for short term usage, this feature helps the client to identify an MIX service to use. It enables a configuration where permanent (searchable) channels are placed in one MIX service and clients will be able to create channels in another MIX service which is not searchable.
        • +
      • 'urn:xmpp:mix:1': This indicates support of MIX, and is returned by all MIX services.
        • +
      • 'urn:xmpp:mix:1#searchable': This is shown in the above example and indicates that a the MIX Service MAY be searched for channels. This presence of this feature can be used by a client to guide the user to search for channels in a MIX service.
        • +
      • 'urn:xmpp:mix:1#create-channel': This is described in Checking for Permission to Create a Channel in support of channel administration. When an end user client needs to create channels, perhaps for short term usage, this feature helps the client to identify an MIX service to use. It enables a configuration where permanent (searchable) channels are placed in one MIX service and clients will be able to create channels in another MIX service which is not searchable.

      A MIX service MUST NOT advertise support for &xep0313;, as MAM is supported by the channels and not by the service. A MIX service MUST NOT advertise support for generic &xep0060;, as although MIX makes use of PubSub it is not a generic PubSub service.

      @@ -812,7 +813,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa category='conference' name='A Dark Cave' type='mix'/> - + @@ -866,10 +867,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa + - urn:xmpp:mix:0 + urn:xmpp:mix:1 Witches Coven @@ -909,12 +910,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa - + thirdwitch - + top witch @@ -949,7 +950,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - + ]]>       @@ -959,7 +960,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa -

      A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to messages, and presence. The <join/> is a child element of <iq/> element. The <join/> element is qualified by the 'urn:xmpp:mix:0' namespace. The channel is specified by a 'channel' attribute in the <join/> element. The requested nodes are encoded as <subscribe/> child elements of the <join/> element. +

      A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to messages, and presence. The <join/> is a child element of <iq/> element. The <join/> element is qualified by the 'urn:xmpp:mix:1' namespace. The channel is specified by a 'channel' attribute in the <join/> element. The requested nodes are encoded as <subscribe/> child elements of the <join/> element. The join leads to the server subscribing the user to each of the requested nodes associated with the channel. The MIX service will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.

      @@ -975,7 +976,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='hag66@shakespeare.example/UUID-a1j/7533' to='hag66@shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - @@ -993,7 +994,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='hag66@shakespeare.example' to='coven@mix.shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + @@ -1007,7 +1008,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='coven@mix.shakespeare.example' to='hag66@shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + @@ -1025,7 +1026,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='coven@mix.shakespeare.example' to='hag66@shakespeare.example/UUID-a1j/7533' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + @@ -1045,7 +1046,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='hag66@shakespeare.example' to='coven@mix.shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + @@ -1060,7 +1061,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - + @@ -1071,14 +1072,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa At the same time the participant MUST be added to the JID Map node, to map from proxy JID to real JID. For a JID Maybe Visible channel, the participant MUST be added to the JID Maybe Visible Map node. The value in this node MUST reflect the user's visibility preference for the channel and MUST be updated to reflect any changes to this preference.

      - A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a <update-subscription/$gt; child element of <iq/> element. The <update-subscription/$gt; element is qualified by the 'urn:xmpp:mix:0' namespace. The requested notes are encoded as <subscribe/> child elements of the <update-subscription/$gt; element with the node name encoded as a 'node' attribute. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification. + A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a <update-subscription/$gt; child element of <iq/> element. The <update-subscription/$gt; element is qualified by the 'urn:xmpp:mix:1' namespace. The requested notes are encoded as <subscribe/> child elements of the <update-subscription/$gt; element with the node name encoded as a 'node' attribute. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification.

      - + @@ -1087,7 +1088,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='coven@mix.shakespeare.example' to='hag66@shakespeare.example/UUID-a1j/7533' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + @@ -1143,12 +1144,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='hag66@shakespeare.example' to='coven@mix.shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + - urn:xmpp:mix:0 + urn:xmpp:mix:1 never @@ -1163,12 +1164,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='coven@mix.shakespeare.example' to='hag66@shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + - urn:xmpp:mix:0 + urn:xmpp:mix:1 never @@ -1183,23 +1184,23 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]> -

      The client MAY also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard, by providing a form template in the result. The request is encoded as a <user-preference/> child element of <iq/>. <user-preference/> is qualified by the 'urn:xmpp:mix:0' namespace. The result is encoded as a form child element in the <user-preference/> element.

      +

      The client MAY also query the channel in order to find out which user preferences are supported and the options available. This will allow users to set options not specified in the standard, by providing a form template in the result. The request is encoded as a <user-preference/> child element of <iq/>. <user-preference/> is qualified by the 'urn:xmpp:mix:1' namespace. The result is encoded as a form child element in the <user-preference/> element.

      - + - + - urn:xmpp:mix:0 + urn:xmpp:mix:1 @@ -1226,10 +1227,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='hag66@shakespeare.example/UUID-a1j/7533' to='coven@mix.shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + - urn:xmpp:mix:0 + urn:xmpp:mix:1 never @@ -1247,10 +1248,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='coven@mix.shakespeare.example' to='hag66@shakespeare.example/UUID-a1j/7533' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + - urn:xmpp:mix:0 + urn:xmpp:mix:1 never @@ -1268,7 +1269,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa       -

      Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, a user sends a MIX "leave" command to the channel. The leave command is encoded as a <leave/> child element of <iq/> element. The <leave/> element is qualified by the 'urn:xmpp:mix:0' namespace, with the channel specified as a 'channel" attribute. When a user leaves the channel, the user's server will remove the channel from the user's roster. Leave commands are sent indirectly through the user's server, to enable roster removal. Leaving is initiated by a client request, as shown in the following example.

      +

      Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, a user sends a MIX "leave" command to the channel. The leave command is encoded as a <leave/> child element of <iq/> element. The <leave/> element is qualified by the 'urn:xmpp:mix:1' namespace, with the channel specified as a 'channel" attribute. When a user leaves the channel, the user's server will remove the channel from the user's roster. Leave commands are sent indirectly through the user's server, to enable roster removal. Leaving is initiated by a client request, as shown in the following example.

      - ]]> @@ -1290,7 +1291,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='hag66@shakespeare.example' to='coven@mix.shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + ]]> @@ -1302,7 +1303,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='coven@mix.shakespeare.example' to='hag66@shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + ]]> @@ -1316,7 +1317,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='coven@mix.shakespeare.example' to='hag66@shakespeare.example/UUID-a1j/7533' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + ]]>

      When the user leaves the channel, the MIX service is responsible for unsubscribing the user from all nodes in the channel and for removing the user from the participants and presence list. If the user has online presence when the user leaves the channel, the change of presence status caused by removing the user's entry or entries from the presence node will ensure that subscribers to the presence node are correctly updated on presence status. @@ -1358,14 +1359,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    • The MIX service generates the nick. In this case it is RECOMMENDED that the assigned nick is a UUID following &rfc4122;.

      • - A user will typically set a nick when joining a channel and MAY update this nick from time to time. The user does this by sending a command to the channel to set the nick. This command is a <setnick/> child element of <iq/> element. The <setnick/> element is qualified by the 'urn:xmpp:mix:0' namespace. The nick is encoded as a <nick/> child element of the <setnick/> element. If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result. + A user will typically set a nick when joining a channel and MAY update this nick from time to time. The user does this by sending a command to the channel to set the nick. This command is a <setnick/> child element of <iq/> element. The <setnick/> element is qualified by the 'urn:xmpp:mix:1' namespace. The nick is encoded as a <nick/> child element of the <setnick/> element. If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result.

      - + thirdwitch @@ -1380,7 +1381,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='coven@mix.shakespeare.example' to'hag66@shakespeare.example/UUID-a1j/7533' id='7nve413p'> - + thirdwitch @@ -1406,22 +1407,22 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='mix.shakespeare.example' id='7nve413p'> - + ]]>

      - The response will be a list of features of the MIX channel. If Nick Registration is supported, then the result set will include <feature var="urn:xmpp:mix:0#nick-register"/>. + The response will be a list of features of the MIX channel. If Nick Registration is supported, then the result set will include <feature var="urn:xmpp:mix:1#nick-register"/>.

      To register a nick with the MIX service the user sends - a register command to the service. This is encoded as a <register/> child element of an <iq/> element. The <register/> element is qualified by the urn:xmpp:mix:0' namespace. The nick is encoded in a <nick/> child element of the <register/> element.

      + a register command to the service. This is encoded as a <register/> child element of an <iq/> element. The <register/> element is qualified by the urn:xmpp:mix:1' namespace. The nick is encoded in a <nick/> child element of the <register/> element.

      - + thirdwitch @@ -1437,7 +1438,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa to='mix.shakespeare.example' from='hag66@shakespeare.example/UUID-a1j/7533' id='7nve413p'> - + thirdwitch @@ -1547,7 +1548,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - + hecate@mix.shakespeare.example @@ -1589,7 +1590,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - + hecate@mix.shakespeare.example @@ -1661,7 +1662,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]>

      - The MIX channel then adds information to the message using a <mix> element qualified by the 'urn:xmpp:mix:0' namespace. This element contains two child elements: + The MIX channel then adds information to the message using a <mix> element qualified by the 'urn:xmpp:mix:1' namespace. This element contains two child elements:

      1. A <nick> element that contains the Nick of the message sender, taken from the Participants Node.
        2. @@ -1676,7 +1677,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' type='groupchat'> Harpier cries: 'tis time, 'tis time. - + thirdwitch 123456#coven@mix.shakespeare.example @@ -1689,7 +1690,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' type='groupchat'> Harpier cries: 'tis time, 'tis time. - + thirdwitch 123456#coven@mix.shakespeare.example @@ -1704,7 +1705,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' type='groupchat'> Harpier cries: 'tis time, 'tis time. - + thirdwitch 123456#coven@mix.shakespeare.example 92vax143g @@ -1715,13 +1716,13 @@ 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:0' 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 as shown in the following example.

        - + ]]>

        @@ -1735,7 +1736,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

        The second approach is to leave a tombstone, which if taken MUST be done in the following manner. This is appropriate where it is desired to leave a record of the message that was redacted. - With this approach, the original message <body> is removed and replaced with a tombstone using the <retracted> element qualified by the 'urn:xmpp:mix:0' namespace that shows the JID of user performing the retraction and the time of the retraction. + With this approach, the original message <body> is removed and replaced with a tombstone using the <retracted> element qualified by the 'urn:xmpp:mix:1' namespace that shows the JID of user performing the retraction and the time of the retraction.

        @@ -1744,7 +1745,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa - @@ -1772,14 +1773,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa
      2. The invitee MAY send a response to the inviter, indicating if the invitation was accepted or declined.

      - The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time. The invitation request is encoded as an <invite/> child element of an <iq/> element. The <invite/> element is qualified by the 'urn:xmpp:mix:0' namespace. <invite/> contains an <invitation/> child element, which contain <inviter/>, <invitee/>, <channel/> and <token/> child elements. + The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time. The invitation request is encoded as an <invite/> child element of an <iq/> element. The <invite/> element is qualified by the 'urn:xmpp:mix:1' namespace. <invite/> contains an <invitation/> child element, which contain <inviter/>, <invitee/>, <channel/> and <token/> child elements.

      - + cat@shakespeare.lit @@ -1789,7 +1790,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='kl2fax27' to='hag66@shakespeare.lit/UUID-h5z/0253' type='result'> - + hag66@shakespeare.lit cat@shakespeare.lit @@ -1807,7 +1808,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='f5pp2toz' to='cat@shakespeare.lit'> Would you like to join the coven? - + hag66@shakespeare.lit cat@shakespeare.lit coven@mix.shakespeare.lit @@ -1821,7 +1822,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='cat@shakespeare.example' to='coven@mix.shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + hag66@shakespeare.lit @@ -1833,7 +1834,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]>

      The invitee MAY send an acknowledgement back to the inviter, noting the status of the invitation. - This is encoded as an <invitation-ack/> child element of <message/> element. The <invitation-ack/> element is qualified by the 'urn:xmpp:mix:0' namespace. The <invitation-ack/> has an <invitation/> child element that encodes the invitation being acknowledged and a <value/> child element to encode the acknowledgement value. + This is encoded as an <invitation-ack/> child element of <message/> element. The <invitation-ack/> element is qualified by the 'urn:xmpp:mix:1' namespace. The <invitation-ack/> has an <invitation/> child element that encodes the invitation being acknowledged and a <value/> child element to encode the acknowledgement value. <value/> has the following values:

      • 'Joined': The invitee has joined the channel.
        • @@ -1845,7 +1846,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='b6p9llze' to='hag66@shakespeare.lit/UUID-h5z/0253'> No Thanks - too busy chasing mice.... - + Declined hag66@shakespeare.lit @@ -1952,14 +1953,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa It is important that messages are all transferred from the MIX channel to the server associated with the each channel participant. Transfer between servers will typically happen quickly and &xep0198; will deal with short connection failures between servers. Longer connection failures could lead to message loss. This would lead to online users (who remain connected to their servers) missing messages, and to messages being missed out of the user archive. This section describes how MIX addresses this.

        - When there is a long term connection failure, the MIX channel will receive an error from the XMPP server indicating that a message failed to transfer to a recipient. When this happens, the MIX channel MUST take responsibility to ensure that the message is retransmitted and delivered. When the MIX channel detects a failure it will make use of an IQ Marker message to determine when the connection to the peer server is working again. Once the channel has received a response to the marker IQ it will retransmit the pending messages. The marker is encoded as a <marker/> child element of an <iq/> element. The <marker/> element is qualified by the 'urn:xmpp:mix:0' namespace. + When there is a long term connection failure, the MIX channel will receive an error from the XMPP server indicating that a message failed to transfer to a recipient. When this happens, the MIX channel MUST take responsibility to ensure that the message is retransmitted and delivered. When the MIX channel detects a failure it will make use of an IQ Marker message to determine when the connection to the peer server is working again. Once the channel has received a response to the marker IQ it will retransmit the pending messages. The marker is encoded as a <marker/> child element of an <iq/> element. The <marker/> element is qualified by the 'urn:xmpp:mix:1' namespace.

        - + @@ -1967,7 +1968,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='lx09df27' to='coven@mix.shakespeare.example' type='result'> - + ]]> @@ -2003,7 +2004,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

        - MIX does not standardize an access control model for creating and deleting MIX channels. The choice is left to the MIX implementer, and could be a very simple or complex approach. A client can determine if it has permission to create a channel on a MIX service, which MAY be used to control options presented to the user. This is achieved by a disco command on the MIX service. If the 'urn:xmpp:mix:0#create-channel' feature is returned, the user is able to create a channel. + MIX does not standardize an access control model for creating and deleting MIX channels. The choice is left to the MIX implementer, and could be a very simple or complex approach. A client can determine if it has permission to create a channel on a MIX service, which MAY be used to control options presented to the user. This is achieved by a disco command on the MIX service. If the 'urn:xmpp:mix:1#create-channel' feature is returned, the user is able to create a channel.

        - - + + ]]>

        - A client creates a channel by sending a simple request to the MIX service. A channel MAY be created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). The create is encoded as a <create/> child element of <iq/> element. The <create/> is qualified by the 'urn:xmpp:mix:0' namespace. The <create/> element MUST have a 'channel' attribute to specify the channel name. + A client creates a channel by sending a simple request to the MIX service. A channel MAY be created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). The create is encoded as a <create/> child element of <iq/> element. The <create/> is qualified by the 'urn:xmpp:mix:1' namespace. The <create/> element MUST have a 'channel' attribute to specify the channel name.

        - + - + ]]>

        @@ -2055,10 +2056,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='lx09df27' to='mix.shakespeare.example' type='set'> - + - urn:xmpp:mix:0 + urn:xmpp:mix:1 hecate@shakespeare.lit @@ -2081,7 +2082,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='lx09df27' to='hag66@shakespeare.example/UUID-a1j/7533' type='result'> - + ]]> @@ -2097,14 +2098,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='lx09df27' to='mix.shakespeare.example' type='set'> - + - + ]]> @@ -2140,7 +2141,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa MIX channels are always explicitly destroyed by an owner of the channel or by a server operator. There is no concept of temporary channel, equivalent to &xep0045; temporary room which is automatically destroyed by the server when the users leave. However, channels MAY be configured with an explicit lifetime, after which the channel MUST be removed by the MIX service. Where a channel is created for ad hoc use, it MAY be desirable to keep the channel for history reference or for re-use by the same set of users. Note that the owner of the channel does not need to have presence registered in the channel in order to destroy it.

        - The destroy operation is encoded as a <destroy/> child element of an <iq/> element. The <destroy/> element is qualified by the 'urn:xmpp:mix:0' namespace. The <destroy/> element MUST have a 'channel' attribute to specify the channel to be destroyed. + The destroy operation is encoded as a <destroy/> child element of an <iq/> element. The <destroy/> element is qualified by the 'urn:xmpp:mix:1' namespace. The <destroy/> element MUST have a 'channel' attribute to specify the channel to be destroyed. A client destroys a channel using a simple set operation, as shown in the following example.

        - + - urn:xmpp:mix:0 + urn:xmpp:mix:1 Information Node Modification - urn:xmpp:mix:0 + urn:xmpp:mix:1 Witches Coven @@ -2236,7 +2237,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='result'> - + @@ -2260,10 +2261,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa to='hag66@shakespeare.example/UUID-a1j/7533' type='result'> - + - urn:xmpp:mix:0 + urn:xmpp:mix:1 Configuration Node Modification - urn:xmpp:mix:0 + urn:xmpp:mix:1 hecate@shakespeare.lit @@ -2310,7 +2311,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='result'> - + @@ -2423,7 +2424,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' type='groupchat'> Harpier cries: 'tis time, 'tis time. - + thirdwitch 123456#coven@mix.shakespeare.example @@ -2442,7 +2443,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' type='groupchat'> Harpier cries: 'tis time, 'tis time. - + thirdwitch 123456#coven@mix.shakespeare.example @@ -2453,7 +2454,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' type='groupchat'> Harpier cries: 'tis time, 'tis time. - + thirdwitch 123456#coven@mix.shakespeare.example @@ -2488,7 +2489,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='hag66@shakespeare.example/UUID-a1j/7533' to='hag66@shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - @@ -2505,7 +2506,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='hag66@shakespeare.example' to='coven@mix.shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + @@ -2587,11 +2588,11 @@ This approach enables flexible support of multiple clients for a MIX channel pa category='conference' name='Shakespearean Chat Service' type='text'/> - + - urn:xmpp:mix:0#serviceinfo + urn:xmpp:mix:1#serviceinfo @@ -2610,10 +2611,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa category='conference' name='Shakespearean Chat Service' type='text'/> - + - urn:xmpp:mix:0#serviceinfo + urn:xmpp:mix:1#serviceinfo ]]> -

        The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'. The field with var='muc-mirror' is the value of which is the mirrored MUC domain's JID.

        +

        The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:1#serviceinfo'. The field with var='muc-mirror' is the value of which is the mirrored MUC domain's JID.

        Where a client supporting both MIX and MUC is given a reference to a MUC room, it is desirable that the client can determine the MIX channel and join using MIX. This is achieved by an equivalent extension to MUC service discover.

        - urn:xmpp:mix:0#serviceinfo + urn:xmpp:mix:1#serviceinfo ]]> -

        The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'. The field with var='mix-mirror' is the value of which is the mirrored MIX domain's JID.

        +

        The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:1#serviceinfo'. The field with var='mix-mirror' is the value of which is the mirrored MIX domain's JID.

        Where a client supports MUC and MIX and has determined that for a channel that the server also supports a MUC room, the client has a choice as to which type of invite to send. This SHOULD be done by determining if the client support MIX using the mechanism specified in From fe21cb5ae3ab0f67f687f69ca25893838ab5138c Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Tue, 20 Jun 2017 15:52:34 +0100 Subject: [PATCH 27/54] Correct date --- xep-0369.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index cf683589..0618cb73 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -38,7 +38,7 @@ &stpeter; 0.9.3 - 2017-06-16 + 2017-06-20 sek

        Remove Legacy MIX Namespace; @@ -50,7 +50,7 @@ Change mix_nick_register to nick-register; Separate namespace for roster information; rename jidmap2 to jidmap-visible; - version bump to urn:xmpp:mix:1; + Namespace bump to mix:1;

        From 1f02a18d2bdd23c4a2ca98e69701ce4d2299ca9f Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Wed, 14 Jun 2017 11:28:58 +0200 Subject: [PATCH 28/54] xep-0390: specify query interception --- xep-0390.xml | 32 ++++++++++++++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/xep-0390.xml b/xep-0390.xml index 3d474642..ffee4acd 100644 --- a/xep-0390.xml +++ b/xep-0390.xml @@ -20,6 +20,7 @@ Processing Entities"> Generating Entity"> Generating Entities"> + Query Interception"> org.jabber.security Mailing List Archive: '[Security] Trivial preimage attack against the entity capabilities protocol)' from 2009-07-22, <https://mail.jabber.org/pipermail/security/2009-July/000812.html>."> capsdb https://github.com/xnyhps/capsdb/"> ]> @@ -58,6 +59,7 @@
        • Clearly specify handling of xml:lang attributes.
          • +
        • Add Query Interception.
                 @@ -95,7 +97,7 @@
      • The bandwidth consumption should be as minimal as possible, while reusing existing specifications.
      • It must be possible to write &xep0045; and &xep0369; implementations which can forward this protocol with negligible extra work.
      • Entities must be able to update their published information arbitrarily often in a single presence session.
        • -
      • Server infrastructure beyond XMPP Core and XMPP IM must not be required for this to work.
        • +
      • Server infrastructure beyond XMPP Core and XMPP IM must not be required for this to work (but may be beneficial).
      • Entities must be able to be confident that the information obtained from the broadcast is equivalent to the information which would be obtained from querying the generating entity directly at the time the broadcast was generated.
      • The protocol must be able to coexist (but not necessarily exchange information) with &xep0115;.
      • No special XML features beyond what is needed to implement XMPP Core itself should be required.
        • @@ -111,6 +113,7 @@
        Capability Hash Set
        A set of &hashes; which cover the same XEP-0030 response, possibly in the form of a <c/> element with &xep0300; <hash/> children.
        Generating Entity
        An entity which emits a &hashset; to other entities.
        Processing Entity
        An entity which receives and processes a &hashset; from a &genent;.
         +
        Query Interception
        Server-side processing of disco#info queries directed to a resource based on the &hashsets; published by that resource.
         @@ -766,6 +769,17 @@ cDp0aW1lHxw=
      • Servers MAY answer disco#info requests for &hashnodes; on behalf of their and others clients if the disco#info response belonging to that &hash; is known to them.
       + + +

      Servers MAY implement &queryintercept; to further optimise bandwidth consumption. The idea is that servers intercept &xep0030; disco#info queries sent to clients if they already know the answer from &hashes; published by the client. The rules for &queryintercept; are the following (to be applied in this order):

      +
        +
      • Servers MUST NOT intercept disco#info queries except those with empty node or a node which refers to a &hashnode; known to the server.
        • +
      • Servers MUST NOT intercept disco#info queries on behalf of the resource unless the query would be forwarded to the resource otherwise.
        • +
      • Servers MUST NOT intercept disco#info queries to resources which do not support ∩︀ (clients not implementing ∩︀ may legitimately use disco#info nodes matching the format of &hashnodes; for different purposes).
        • +
      • Servers SHOULD intercept disco#info queries with empty node and answer them with the disco#info of the most recent &hashset; published by the client.
        • +
      • Servers SHOULD intercept disco#info queries a valid &hashnode; node, if the server knows the disco#info for the &hashnode;. Otherwise, the query MUST be forwarded to the addressed resource. Note that it is valid for a sevrer to reply for &hashnodes; which have not been published by the resource.
        • +
      +       @@ -794,6 +808,20 @@ cDp0aW1lHxw=

      Entities MAY choose to not send &hashsets; with directed presence (for example to increase privacy). In that case, entities SHOULD also refuse direct &xep0030; queries.

       + + +

      The server replies to certain disco#info queries on behalf of the client. This means that the client has no choice on to whom they reply. Otherwise, a client could choose to reply with <service-unavailable/> to mask its existence. We consider two effects of this:

      +
        +
      • +

        A remote entity could attempt to detect that an entity exists behind a resource. For this, they send a disco#info query to the resource since nearly everyone implements disco#info. As the client responds with <service-unavailable/>, it looks as if no client was present at this resource.

        +

        With &queryintercept;, the server would reply on behalf of the client. However, the consensus in the community is that by measuring the difference between the reply from the server of the resource and the reply from the actual resource, it would generally be possible to detect the existence of a resource.

        +
        • +
      • +

        A remote entity can obtain the disco#info information of any resource which supports ∩︀ and of which the entity knows the resource.

        +

        This cannot be mitigated with &queryintercept;. The risk is deemed acceptable considering that resources should generally be chosen randomly.

        +
        • +
      +       @@ -887,7 +915,7 @@ cDp0aW1lHxw=

      Thanks to the authors of &xep0115; for coming up with the original idea of using presence broadcast to convey service discovery information, as well as the optimization strategies.

      The note below the example in Advertisement of Support and Capabilities by Servers has been copied verbatimly from XEP-0115.

      Thanks to Waqas Hussain for originally (to my knowledge) pointing out the security flaws in XEP-0115 (see &mlwaqas1;).

      -

      Thanks to Georg Lukas, Link Mauve, Sebastian Riese, Florian Schmaus and Sam Whithed for their input, editorial and otherwise.

      +

      Thanks to Dave Cridland, Georg Lukas, Link Mauve, Sebastian Riese, Florian Schmaus and Sam Whited for their input, editorial and otherwise.

       From e0e48ce412ee7dca0944046b22417e2650b63fc8 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Wed, 14 Jun 2017 11:44:58 +0200 Subject: [PATCH 29/54] xep-0390: gratuitous caps for pre-presence publishing of caps to the server --- xep-0390.xml | 45 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 44 insertions(+), 1 deletion(-) diff --git a/xep-0390.xml b/xep-0390.xml index ffee4acd..c93d1f2c 100644 --- a/xep-0390.xml +++ b/xep-0390.xml @@ -21,6 +21,7 @@ Generating Entity"> Generating Entities"> Query Interception"> + Gratuitous Capabilities"> org.jabber.security Mailing List Archive: '[Security] Trivial preimage attack against the entity capabilities protocol)' from 2009-07-22, <https://mail.jabber.org/pipermail/security/2009-July/000812.html>."> capsdb https://github.com/xnyhps/capsdb/"> ]> @@ -60,6 +61,7 @@
      • Clearly specify handling of xml:lang attributes.
      • Add Query Interception.
        • +
      • Add Gratuitous Caps.
      @@ -102,6 +104,7 @@
    • The protocol must be able to coexist (but not necessarily exchange information) with &xep0115;.
    • No special XML features beyond what is needed to implement XMPP Core itself should be required.
    • Obsoletion of hash functions should not need a new version of the specification.
      • +
    • Support for pushing Entity Capabilities to the clients server without sending presence.
      • @@ -114,6 +117,7 @@
      Generating Entity
      An entity which emits a &hashset; to other entities.
      Processing Entity
      An entity which receives and processes a &hashset; from a &genent;.
      Query Interception
      Server-side processing of disco#info queries directed to a resource based on the &hashsets; published by that resource.
       +
      Gratuitous Capabilities
      The sending of a &hashset; to a server before initial presence has been sent and without being asked by the server.
       @@ -731,6 +735,44 @@ cDp0aW1lHxw= ]]> + +

      A server MAY support pushing of &hashes; from clients before sending initial presence. This allows servers to discover capabilities of clients before those have sent initial presence, which may be useful or important for some protocols (such as &xep0369;). This feature is called &gratcaps;.

      +

      To advertise support, the server publishes the urn:xmpp:caps:gratuitous feature:

      + + + ... + + + ... + + +]]> +

      After determining server support, a client can send &hashes; via &gratcaps; before sending initial presence:

      + + + u79ZroNJbdSWhdSp311mddz44oHHPsEBntQ5b1jqBSY= + XpUJzLAc93258sMECZ3FJpebkzuyNXDzRNwQog8eycg= + + + + + +]]> +

      The server replies with an empty result on success.

      +

      The server MUST NOT broadcast the &hashes; submitted via &gratcaps; using presence.

      +

      Clients SHOULD NOT send &gratcaps; after they have sent initial presence; instead, they SHOULD re-send presence to update the &hashes;. Otherwise, entities subscribed to the presence will not receive the updated &hashes;.

      +       @@ -738,7 +780,8 @@ cDp0aW1lHxw=
      • Entities MUST respond to disco#info queries for all &hashnodes; of at least the most recent 3 &hashsets; emitted.
      • Entities MUST broadcast the &hashset; of the current disco#info it publishes in every non-directed "available" <presence/> they send and SHOULD do so for directed "available" <presence/>.
        • -
      • Entities MUST re-broadcast the &hashset; after their disco#info response changes, but MAY limit the rate at which presences are emitted solely for the purpose of sending new &hashsets;.
        • +
      • After initial presence has been sent, entities MUST re-broadcast the &hashset; after their disco#info response changes, but MAY limit the rate at which presences are emitted solely for the purpose of sending new &hashsets;.
        • +
      • Before initial presence has been sent and if the server supports &gratcaps;, entities SHOULD send &gratcaps; after their disco#info response changes, but MAY limit the rate at which &gratcaps; are sent. (For example, a client may load and enable additional functionality (thus changing its features) based on server support and only send &gratcaps; once all functionality has been set up, not after each individual feature.)
      • Entities MAY assume that another entity supports ∩︀ after receiving a &hashset; from that entity.
      • Entities MAY also send &xep0115; capabilities to support legacy entities.
      From e6f2db3841c637fc41ebf62d403912a76ab022c1 Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Tue, 27 Jun 2017 17:50:30 +0200 Subject: [PATCH 30/54] XEP-0060: Clarify behaviour of publish-options. Fields must be registered --- xep-0060.xml | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/xep-0060.xml b/xep-0060.xml index 8c099df9..9a02d401 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -49,6 +49,12 @@ &stpeter; &ralphm; + + 1.13.6 + 2017-06-22 + dg +

      Clarify behaviour of publish-options. Fields must be registered

       +       1.13.5 2016-12-21 @@ -2940,11 +2946,11 @@ And by opposing end them? ]]> -

      The <publish-options/> element SHOULD contain a data form (see XEP-0004), whose FORM_TYPE SHOULD be "http://jabber.org/protocol/pubsub#publish-options" (see XEP-0068).

      -

      How the fields are to be handled is up to the the pubsub service, which in the language of XEP-0004 functions as a form-processing entity.

      -

      For example, the service may treat the field as a precondition, in which case the service should proceed as follows:

      +

      The <publish-options/> element MUST contain a data form (see XEP-0004), whose FORM_TYPE MUST be "http://jabber.org/protocol/pubsub#publish-options" (see XEP-0068).

      +

      Fields and their behaviour MUST be registered with the XMPP Registrar. Each field MUST specify whether it defines METADATA to be attached to the item, a per-item OVERRIDE of the node configuration, or a PRECONDITION to be checked against the node configuration. A pubsub service advertising support for publishing options MUST reject publications with unknown fields.

      +

      A field defined as a precondition MUST be processed as follows:

        -
      1. If the node exists and the precondition is not met, then the publish shall fail with a &conflict; error condition and a pubsub-specific condition of <precondition-not-met/>.
        2. +
      2. If the node exists and the precondition is not met, then the publish MUST fail with a &conflict; error condition and a pubsub-specific condition of <precondition-not-met/>.
      3. If the node exists and the precondition is met, then the publish succeeds.
      4. If the node does not exist and the service supports the "auto-create" feature, then the service shall auto-create the node with default configuration in all respects except those specified in the preconditions, and the publish succeeds.
      5. If the node does not exist and the service does not support the "auto-create" feature, then the publish shall fail.
        6. From 7c3eb51290e07ca3babe8713ed68f965bccd5f09 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Thu, 6 Jul 2017 15:50:16 +0100 Subject: [PATCH 31/54] Correct from in response of join/leave IQs; --- xep-0369.xml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 0618cb73..d48baf36 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -51,6 +51,7 @@ Separate namespace for roster information; rename jidmap2 to jidmap-visible; Namespace bump to mix:1; + Correct from in response of join/leave IQs;

        @@ -1023,7 +1024,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -1314,7 +1315,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa @@ -2713,7 +2714,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa -

        Thanks to the following who have made contributions: Dave Cridland, Philipp Hancke, Waqas Hussain, Timothée Jaussoin, Evgeny Khramtsov, Georg Lukas, Tobias Markmann, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Jonas Wielicki, Matthew Wild and one anonymous reviewer.

        +

        Thanks to the following who have made contributions: Dave Cridland, Tarun Gupta, Philipp Hancke, Waqas Hussain, Timothée Jaussoin, Evgeny Khramtsov, Georg Lukas, Tobias Markmann, Ralph Meijer, Edwin Mons, Emmanuel Gil Peyrot, Florian Schmaus, Lance Stout, Sam Whited, Jonas Wielicki, Matthew Wild and one anonymous reviewer.

         From a9f0b658f7a6be02400aaddfd6d6a0cbf95a695c Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Tue, 18 Jul 2017 11:15:32 +0100 Subject: [PATCH 32/54] 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 + + - + ]]>

          From 53d9cd7be7809e3154ee978947f8f7937f3fb821 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Wed, 19 Jul 2017 11:47:00 +0100 Subject: [PATCH 33/54] Clarification on join with no subscribes --- xep-0369.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 4606de52..d01440cd 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -961,7 +961,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa -

          A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to messages, and presence. The <join/> is a child element of <iq/> element. The <join/> element is qualified by the 'urn:xmpp:mix:1' namespace. The channel is specified by a 'channel' attribute in the <join/> element. The requested nodes are encoded as <subscribe/> child elements of the <join/> element. +

          A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to both messages and presence nodes. A user will typically subscribe to at least the message and/or presence nodes but MAY join and not subscribe to any nodes. The <join/> is a child element of <iq/> element. The <join/> element is qualified by the 'urn:xmpp:mix:1' namespace. The channel is specified by a 'channel' attribute in the <join/> element. The requested nodes are encoded as <subscribe/> child elements of the <join/> element. The join leads to the server subscribing the user to each of the requested nodes associated with the channel. The MIX service will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.

          @@ -1036,7 +1036,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa ]]>

          - If a user cannot be subscribed to one or more of the requested nodes (e.g., because the node does not exist), but can be subscribed to some the response simply lists the nodes successfully subscribed. If none of the nodes requested are successfully subscribed to, an error response is sent indicating the reason that the first node requested was not subscribed to. This error response will also include other nodes requested where subscription failed for the same reason.

          + If a user cannot be subscribed to one or more of the requested nodes (e.g., because the node does not exist), but can be subscribed to some the response simply lists the nodes successfully subscribed. If at least one node is requested and none of the nodes requested are successfully subscribed to, an error response is sent indicating the reason that the first node requested was not subscribed to. This error response will also include other nodes requested where subscription failed for the same reason.

          The following response example shows a successful response to the initial request example where From 8f65b5da822a09b6df67e100832a13953fdc6b23 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Wed, 19 Jul 2017 16:55:58 +0100 Subject: [PATCH 34/54] Clarification and minor corrections of presnece examples --- xep-0369.xml | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index d01440cd..8b1b45d0 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -1477,18 +1477,27 @@ This approach enables flexible support of multiple clients for a MIX channel pa Presence status and availability is set in a MIX channel by standard presence stanzas sent to the MIX channel by the user's server. Users wishing to receive presence updates will subscribe to the MIX channel presence node. Presence updates are sent out to subscribing participants using standard presence stanzas.

          - A user setting status is now used as an example. Unlike in &xep0045; where coming online is a special action, coming online in MIX is implicit when presence status is set. Going offline is a achieved by setting presence status to unavailable, which removes the client full JID entry from the presence node. When a user sets a presence status, the user's server sends updated presence to the MIX channel, and the MIX service then publishes the user's availability to the "urn:xmpp:mix:nodes:presence" node. If there is not an item named by the full JID of the client with updated presence status, this item is created.

          - - + + + dnd + Making a Brew +]]> + +

          + The server then sends the presence information to roster entries. The following example then shows the presence message from the client's server to the MIX channel. +

          + + dnd Making a Brew ]]> -

          The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node, with the 'publisher' attribute set to the user's participant identifier (the proxy JID). The MIX channel then broadcasts the presence change to all users who are subscribed to the "urn:xmpp:mix:nodes:presence" node. The presence stanza is sent from the full proxy JID of the user. - Note that presence is associated with a client and so will have a full JID as it comes directly from the client and not from the user's server.

          +

          The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node, with the 'publisher' attribute set to the user's participant identifier (the proxy JID). The MIX channel then broadcasts the presence change to all users who are subscribed to the "urn:xmpp:mix:nodes:presence" node. The presence stanza is sent from the full proxy JID of the client updating status. + Note that presence is associated with a client and so will have a full JID. The following example shows a presence message as distributed by the server to a presences subscriber.

          thirdwitch dnd From 6a4afe20bd308ca685401e780b760af9194ac91c Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Fri, 28 Jul 2017 14:02:50 +0100 Subject: [PATCH 35/54] Add capability for MIX in client's server; --- xep-0369.xml | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/xep-0369.xml b/xep-0369.xml index 8b1b45d0..c9a8386f 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -52,6 +52,7 @@ rename jidmap2 to jidmap-visible; Namespace bump to mix:1; Correct from in response of join/leave IQs; + Add capability for MIX in client's server;

          @@ -2487,6 +2488,29 @@ This approach enables flexible support of multiple clients for a MIX channel pa + +

          + Servers supporting the capabilities necessary to enable MIX clients MUST advertise this. A client wishing to use MIX MUST check for this capability in the server before using MIX. The capability is represented by the 'urn:xmpp:mix:account:0' feature. +

          + + + + + + + + + +]]> + +           +#

          Most interaction between a MIX client and a MIX channel is directly between the client and the channel. The participant's server relays the message but does not modify the messages. In particular configuration management and discovery is direct. Interaction will be direct, unless explicitly stated otherwise. From 0180ff20ce9feba8d467e46c46c1627db16b209a Mon Sep 17 00:00:00 2001 From: Emmanuel Gil Peyrot Date: Fri, 16 Jun 2017 20:35:24 +0100 Subject: [PATCH 36/54] XEP-0234: Fix a date missing its timezone in examples. --- xep-0234.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xep-0234.xml b/xep-0234.xml index 79ddd7e5..5a035e1f 100644 --- a/xep-0234.xml +++ b/xep-0234.xml @@ -327,7 +327,7 @@ text/plain test.txt - 2015-07-26T21:46:00 + 2015-07-26T21:46:00+01:00 6144 w0mcJylzCn+AfvuGdqkty2+KP48= @@ -750,7 +750,7 @@ a=file-range:-<(offset + length) | *>]]> text/plain test.txt - 2015-07-26T21:46:00 + 2015-07-26T21:46:00+01:00 6144 w0mcJylzCn+AfvuGdqkty2+KP48= From 105bf2ed27eeab3b90209d7ab1b148f4e7caae2f Mon Sep 17 00:00:00 2001 From: Emmanuel Gil Peyrot Date: Mon, 7 Aug 2017 17:47:50 +0200 Subject: [PATCH 37/54] XEP-0234: Remove extraneous mention of UTC. The DateTime profile in XEP-0082 is already explicit about timezones. --- xep-0234.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0234.xml b/xep-0234.xml index 5a035e1f..c016bc51 100644 --- a/xep-0234.xml +++ b/xep-0234.xml @@ -343,7 +343,7 @@ date - UTC timestamp specifying the last modified time of the file (which MUST conform to the DateTime profile of &xep0082;). + Timestamp specifying the last modified time of the file (which MUST conform to the DateTime profile of &xep0082;). OPTIONAL From e86da6befe6c6eb534581fb5dd309e9b6fca8d3f Mon Sep 17 00:00:00 2001 From: Emmanuel Gil Peyrot Date: Fri, 16 Jun 2017 20:35:40 +0100 Subject: [PATCH 38/54] XEP-0234: Release version 0.18.2. --- xep-0234.xml | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/xep-0234.xml b/xep-0234.xml index c016bc51..0a922214 100644 --- a/xep-0234.xml +++ b/xep-0234.xml @@ -24,6 +24,15 @@ NOT_YET_ASSIGNED &stpeter; &lance; + + 0.18.2 + 2017-06-16 + egp +

            +
          • Fix a date missing its timezone in examples.
            • +
          • Remove the mention of UTC, timestamps are already properly described in &xep0082;.
            • +
          +           0.18.1 2017-05-20 From 0dc187d16c6ac197bf2140ff390aca7c22c3dcdd Mon Sep 17 00:00:00 2001 From: Dave Cridland Date: Tue, 15 Aug 2017 09:13:20 +0100 Subject: [PATCH 39/54] SASL2 Updates Updated according to implementation experience: * Updated namespace * Continue "mechanisms" are not; changed these to "tasks". * Added stream features after Success. * Don't need complexity of "=" encoding; removed. * Fixed internal links. * Updated examples. --- xep-0388.xml | 96 ++++++++++++++++++++++++++++++++-------------------- 1 file changed, 59 insertions(+), 37 deletions(-) diff --git a/xep-0388.xml b/xep-0388.xml index 82fd2e84..9c4b7d3e 100644 --- a/xep-0388.xml +++ b/xep-0388.xml @@ -20,6 +20,22 @@ sasl2 &dcridland; + + 0.2.0 + 2017-08-14 + dwd + +

          Updated according to implementation experience:

          +
            +
          • Updated namespace
            • +
          • Continue "mechanisms" are not; changed these to "tasks".
            • +
          • Added stream features after Success.
            • +
          • Don't need complexity of "=" encoding; removed.
            • +
          • Fixed internal links.
            • +
          • Updated examples.
            • +
          +           +           0.1.0 2017-03-16 @@ -60,28 +76,28 @@ -

          Servers capable of SASL2 offer a stream feature of <mechanisms/>, qualified by the "urn:xmpp:sasl:0" namespace. This in turn contains one or more <mechanism/> elements in the same namespace, and potentially other elements (for example, the <hostname/> element defined within XEP-0233).

          +

          Servers capable of SASL2 offer a stream feature of <mechanisms/>, qualified by the "urn:xmpp:sasl:1" namespace. This in turn contains one or more <mechanism/> elements in the same namespace, and potentially other elements (for example, the <hostname/> element defined within XEP-0233).

          Note that SASL2 is impossible for clients to initiate without at least one mechanism being available, and therefore MUST NOT be offered.

          The feature so advertised, and its child content, SHOULD be stable for the given stream to and from attributes and encryption state, and therefore MAY be cached by clients for later connections.

          The Service Name used by XMPP is unchanged from RFC 6120.

           -

          In all cases, both Clients and Servers encode SASL exchanges using Base 64 encoding. This SHOULD NOT include any line wrapping or other whitespace. As the form <element/> is equivalent to <element></element>, these both indicate an empty string, which is used to indicate no data (ie, the absence of the data). In order to explicitly transmit a zero-length SASL challenge or response, the sending party sends a single equals sign character ("=").

          +

          In all cases, both Clients and Servers encode SASL exchanges using Base 64 encoding. This SHOULD NOT include any line wrapping or other whitespace. As the form <element/> is equivalent to <element></element>, these both indicate an empty string. Challenges and responses with no data do not occur in SASL, and so require no special handling. To indicate the absence of an initial response, or the absence of success data, the element is simply not included.

          Clients, upon observing this stream feature, initiate the authentication by the use of the <authenticate/> top-level element, within the same namespace. The nature of this element is to inform the server about properties of the final stream state, as well as initiate authentication itself. To achieve the latter, it has a single mandatory attribute of "mechanism", with a string value of a mechanism name offered by the Server in the stream feature, and an optional child element of <initial-response/>, containing a base64-encoded SASL Initial Response.

          On subsequent connections, if a Client has previously cache the stream feature, the Client MAY choose to send it before seeing the stream features - sending it "pipelined" with the Stream Open tag for example.

          - SW1wcm92ZWQgZW5jYXNwdWxhdGlvbiBvZiBvcHRpb25hbCBTQVNMLUlSIGRhdGE= + + Tm9ib2R5IGV2ZXIgZGVjb2RlcyB0aGUgZXhhbXBsZXMu ]]>

          In order to provide support for other desired stream states beyond authentication, additional child elements are used. For example, a hypothetical XEP-0198 session resumption element might be included, and/or Resource Binding requests.

          + - U0FTTC1JUiBlbmNvZGVkIGFsb25nc2lkZSBiaW5kIHJlcXVlc3Q= + SSBzaG91bGQgbWFrZSB0aGlzIGEgY29tcGV0aXRpb24= @@ -92,13 +108,13 @@

          Server Challenges MAY then be sent. Each Challenge MUST be responded to by a Client in a Client Response. These are not extensible, and contain the corresponding base64 encoded SASL data:

          - - QmFzZSA2NCBlbmNvZGVkIFNBU0wgY2hhbGxlbmdlIGRhdGE= + + U28sIG5leHQgRk9TREVNIC0gMjAxOCwgdGhhdCBpcy4uLg== - - QmFzZSA2NCBlbmNvZGVkIFNBU0wgcmVzcG9uc2UgZGF0YQ== + + Li4uSSdsbCBidXkgYSBiZWVyIGZvciB0aGUgZmlyc3QgcGVyc29uIHdoby4uLg== ]]> @@ -112,29 +128,30 @@

          If the Client is now authenticated, the Server sends a <success/> element, which contains an OPTIONAL <additional-data/> element containing SASL additional data. It also contains a <authorization-identity/> element containing the negotiated identity - this is a bare JID, unless resource binding has occurred, in which case it is a full JID.

          + - T3B0aW9uYWwgQmFzZSA2NCBlbmNvZGVkIFNBU0wgc3VjY2VzcyBkYXRh + ip/AeIOfZXKBV+fW2smE0GUB3I//nnrrLCYkt0Vj juliet@montague.example/Balcony/a987dsh9a87sdh ]]>

          Other extension elements MAY also be contained by the <success/> element.

          + - T3B0aW9uYWwgQmFzZSA2NCBlbmNvZGVkIFNBU0wgc3VjY2VzcyBkYXRh + SGFkIHlvdSBnb2luZywgdGhlcmUsIGRpZG4ndCBJPw== juliet@montague.example/Balcony/a987dsh9a87sdh ]]> -

          Any security layer negotiated SHALL take effect after the ">" octet of the closing tag (ie, immediately after "</success>").

          +

          Any security layer negotiated SHALL take effect after the ">" octet of the closing tag (ie, immediately after "</success>"), if it has not already taken effect at a <continue> - see Continue below.

          +

          The <success> element is immediately followed by a <features> element containing the applicable stream features of the newly authenticated stream. Note that no stream restart occurs.

          A <failure/> element is used by the server to terminate the authentication attempt. It MAY contain application-specific error codes, and MAY contain a textual error. It MUST contain one of the SASL error codes from RFC 6120 Section 6.5.

          + This is a terrible example. @@ -143,25 +160,28 @@

          A <continue/> element is used to indicate that while the SASL exchange was successful, it is insufficient to allow authentication at this time.

          -

          This can be used to indicate that the Client needs to perform a Second Factor Authentication ("2FA"), or is required to change password. These are conducted as additional SASL mechanisms. Such SASL mechanisms MUST NOT change the authorization identifier, or introduce any security layer. The authorization identifer transmitted during the subsequent <success/>, and any security layer which comes into effect after the eventual <success/>, therefore MUST be that of the first mechanism.

          -

          The element contains a <mechanisms/> element, as defined above as a stream feature, containing suitable mechanisms. It MAY contain an <additional-data/> element, as the <success/> element does.

          +

          This can be used to indicate that the Client needs to perform a Second Factor Authentication ("2FA"), or is required to change password.

          +

          Such tasks are presented within a <tasks> element, which contains a sequence of <task> elements, each containing a name. These tasks are analogous to a SASL mechanism, but have a number of differences - they may never attempt to negotiate a new authorization identifier, nor a new security layer.

          +

          A client MAY choose any one of the offered tasks; if multiple are required a sequence of <continue> exchanges will occur until all mandatory tasks are complete.

          +

          The <continue element therefore always contains a <tasks/> element, as defined above. It MAY contain an <additional-data/> element, as the <success/> element does.

          Finally, it MAY contain a <text/> element, which can contain human-readable data explaining the nature of the step required.

          + - T3B0aW9uYWwgQmFzZSA2NCBlbmNvZGVkIFNBU0wgc3VjY2VzcyBkYXRh + SSdtIGJvcmVkIG5vdy4= - - HOTP-EXAMPLE - TOTP-EXAMPLE - + + HOTP-EXAMPLE + TOTP-EXAMPLE + This account requires 2FA ]]> -

          Clients respond with a <next-authenticate/> element, which has a single mandatory attribute of "mechanism", containing the selected mechanism name, and contains an OPTIONAL base64 encoded initial response.

          +

          After the final octet of the first <continue> element, any SASL security layer negotiated in the preceding exchange SHALL be immediately in effect.

          +

          Clients respond with a <next/> element, which has a single mandatory attribute of "task", containing the selected task name, and contains an OPTIONAL base64 encoded initial response.

          - MkZBIG9yIHBhc3N3b3JkIGNoYW5nZSBvciBzb21ldGhpbmc= + + SSd2ZSBydW4gb3V0IG9mIGlkZWFzIGhlcmUu ]]>           @@ -169,46 +189,48 @@           -

          This provides pointers and/or clarifications to the in the order and manner defined in RFC 4422, section 4.

          +

          This provides pointers and/or clarifications to the Overview in the order and manner defined in RFC 4422, section 4.

          The service name SHALL be "xmpp", as defined by RFC 6120.

           -

          Servers list mechanisms during stream features (See ) and within the <continue/> element (See ).

          -

          TODO: Neither this specification nor RFC 6120 allow clients access to the mechanism list after SASL negotiation...?

          +

          Servers list mechanisms during stream features (See Discovering Support).

           -

          Clients initiate using the <authenticate/> top level element (See , and after any <continue/> with the <next-authenticate/> message (See ).

          +

          Clients initiate using the <authenticate/> top level element (See Initiation.

           -

          See .

          +

          See Challenges and Responses.

           -

          See .

          +

          See Completing Authentication.

          If a Client specifies an authorization string which is non-empty, the identifier is normalized by treating it as a JID, and performing normalization as described in RFC 7622.

          +

          In general, implementors are advised that a non-empty authorization string MAY be considered an error if the stream's from attribute (if present) does not match.

           -

          Clients MAY abort unilaterally by sending <abort/> as specified in .

          -

          Servers MAY abort unliterally by sending <failure/> with the <aborted/> error code as defined in .

          +

          Clients MAY abort unilaterally by sending <abort/> as specified in Client Aborts.

          +

          Servers MAY abort unliterally by sending <failure/> with the <aborted/> error code as defined in Failure.

           -

          See .

          +

          Security Layers take effect after the SASL mechanism itself (ie, the first negotiation) has completed successfully, after the final octet of the server's <success> or <continue>. See Success and Continue.

          Option (a) is used - any SASL Security Layer is applied first to data being sent, and TLS applied last.

           -

          Although the <continue/> concept does use multiple SASL sequences, only the first SASL mechanism used is considered an authentication, and only the first can negotiate a security layer.

          +

          Although the <continue/> concept does use tasks analogous to multiple SASL sequences, only the first SASL mechanism used is considered an authentication, and only the first can negotiate a security layer.

          In particular, once <success/> has been sent by the server, any further <authenticate/> element MUST result in a stream error.

          Relative to the SASL profile documented in RFC 6120, this introduces more data unprotected by any security layer negotiated by SASL itself.

          +

          While no actual exchanges are introduced that are unprotected, the nature of this exchange might allow for (for example) a resource binding extension to be introduced.

          +

          SASL security layers are sparingly used in the field, however., so this is thought to be a theoretical, rather than practical, concern.

           From 1a679824b2528f31934b1521d8cad01c06215dd4 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Wed, 23 Aug 2017 09:26:05 +0200 Subject: [PATCH 40/54] tooling: Tool to extract a XEP metadata list from the repository --- tools/extract-metadata.py | 211 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 211 insertions(+) create mode 100755 tools/extract-metadata.py diff --git a/tools/extract-metadata.py b/tools/extract-metadata.py new file mode 100755 index 00000000..3656a7d3 --- /dev/null +++ b/tools/extract-metadata.py @@ -0,0 +1,211 @@ +#!/usr/bin/env python3 +import pathlib +import xml.dom.minidom + +import xml.etree.ElementTree as etree + + +DESCRIPTION = """\ +Extract a list of XEPs with metadata from the xeps repository.""" + +EPILOG = """""" + + +def open_xml(f): + return xml.dom.minidom.parse(f) + + +def find_child(elem, child_tag): + for child in elem.childNodes: + if hasattr(child, "tagName") and child.tagName == child_tag: + return child + return None + + +def find_header(document): + header = find_child(document.documentElement, "header") + if header is None: + raise ValueError("cannot find
          ") + return header + + +def get_text(elem): + return "".join( + child.nodeValue + for child in elem.childNodes + if isinstance(child, (xml.dom.minidom.Text, + xml.dom.minidom.CDATASection)) + ) + + +def children(elem): + return [ + child for child in elem.childNodes + if isinstance(child, (xml.dom.minidom.Element)) + ] + + +def extract_xep_metadata(document): + header = find_header(document) + + latest_revision = find_child(header, "revision") + if latest_revision is not None: + last_revision_version = get_text(find_child(latest_revision, "version")) + last_revision_date = get_text(find_child(latest_revision, "date")) + remark_el = find_child(latest_revision, "remark") + last_revision_remark = None + if remark_el is not None: + remark_children = children(remark_el) + if len(remark_children) == 1 and remark_children[0].tagName == "p": + last_revision_remark = get_text(remark_children[0]) + + if last_revision_remark is not None: + initials_el = find_child(latest_revision, "initials") + last_revision_initials = initials_el and get_text(initials_el) + else: + last_revision_initials = None + else: + last_revision_version = None + last_revision_date = None + last_revision_remark = None + last_revision_initials = None + + status = get_text(find_child(header, "status")) + type_ = get_text(find_child(header, "type")) + abstract = " ".join(get_text(find_child(header, "abstract")).split()) + sig_el = find_child(header, "sig") + if sig_el is None: + sig = None + else: + sig = get_text(sig_el) + shortname = get_text(find_child(header, "shortname")) + if shortname.replace("-", " ").replace("_", " ").lower() in [ + "not yet assigned", "n/a", "none", "to be assigned", + "to be issued"]: + shortname = None + title = get_text(find_child(header, "title")) + + approver_el = find_child(header, "approver") + if approver_el is not None: + approver = get_text(approver_el) + else: + approver = "Board" if type_ == "Procedural" else "Council" + + return { + "last_revision": { + "version": last_revision_version, + "date": last_revision_date, + "initials": last_revision_initials, + "remark": last_revision_remark, + }, + "status": status, + "type": type_, + "sig": sig, + "abstract": abstract, + "shortname": shortname, + "title": title, + "approver": approver, + } + + +def text_element(tag, text): + el = etree.Element(tag) + el.text = text + return el + + +def make_metadata_element(number, metadata, accepted, *, protoname=None): + result = etree.Element("xep") + result.append(text_element("number", number)) + result.append(text_element("title", metadata["title"])) + result.append(text_element("abstract", metadata["abstract"])) + result.append(text_element("type", metadata["type"])) + result.append(text_element("status", metadata["status"])) + result.append(text_element("approver", metadata["approver"])) + + if metadata["shortname"] is not None: + result.append(text_element("shortname", metadata["shortname"])) + + if metadata["last_revision"]["version"] is not None: + last_revision = metadata["last_revision"] + revision_el = etree.Element("last-revision") + revision_el.append(text_element("date", last_revision["date"])) + revision_el.append(text_element("version", last_revision["version"])) + if last_revision["initials"]: + revision_el.append(text_element("initials", + last_revision["initials"])) + if last_revision["remark"]: + revision_el.append(text_element("remark", + last_revision["remark"])) + result.append(revision_el) + + if metadata["sig"] is not None: + result.append( + text_element("sig", metadata["sig"]) + ) + + if accepted: + result.set("accepted", "true") + else: + result.set("accepted", "false") + + if protoname is not None: + result.append(text_element("proto-name", protoname)) + + return result + + +def main(): + import argparse + import sys + + parser = argparse.ArgumentParser( + description=DESCRIPTION, + epilog=EPILOG, + ) + parser.add_argument( + "xepdir", + nargs="?", + type=pathlib.Path, + default=pathlib.Path.cwd(), + help="Directory where the XEP XMLs are. Defaults to current directory." + ) + + args = parser.parse_args() + + tree = etree.Element("xep-infos") + + for xepfile in args.xepdir.glob("xep-*.xml"): + number = xepfile.name.split("-", 1)[1].split(".", 1)[0] + try: + number = str(int(number)) + except ValueError: + continue + + with xepfile.open("rb") as f: + parsed = open_xml(f) + + tree.append(make_metadata_element( + number, + extract_xep_metadata(parsed), + True, + )) + + for xepfile in (args.xepdir / "inbox").glob("*.xml"): + protoname = xepfile.name.rsplit(".", 1)[0] + + with xepfile.open("rb") as f: + parsed = open_xml(f) + + tree.append(make_metadata_element( + "xxxx", + extract_xep_metadata(parsed), + False, + protoname=protoname + )) + + sys.stdout.buffer.raw.write(etree.tostring(tree)) + + +if __name__ == "__main__": + main() From 2fac2f0b391e65e910ffa82c3a7d100afcedfa21 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Wed, 23 Aug 2017 09:26:24 +0200 Subject: [PATCH 41/54] tooling: Tool to create changenote mails based on xeplist differences --- tools/send-updates.py | 534 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 534 insertions(+) create mode 100755 tools/send-updates.py diff --git a/tools/send-updates.py b/tools/send-updates.py new file mode 100755 index 00000000..454e7aaa --- /dev/null +++ b/tools/send-updates.py @@ -0,0 +1,534 @@ +#!/usr/bin/env python3 +import configparser +import getpass +import itertools +import email.message +import enum +import os +import smtplib +import sys +import textwrap + +from datetime import datetime + +import xml.etree.ElementTree as etree + + +DESCRIPTION = """\ +Send email updates for XEP changes based on the difference between two \ +xeplist files.""" + +EPILOG = """\ +Configuration file contents: + +[smtp] +host= +port=587 +user= +password= +from=
          + +If user is omitted, anonymous mail sending is attempted. + +If options are missing from the configuration file and the standard input and \ +standard output are a terminal, the script interactively asks for the option \ +values. If no terminal is connected, the script exits with an error instead.""" + + +class Status(enum.Enum): + PROTO = 'ProtoXEP' + EXPERIMENTAL = 'Experimental' + PROPOSED = 'Proposed' + DRAFT = 'Draft' + ACTIVE = 'Active' + FINAL = 'Final' + RETRACTED = 'Retracted' + OBSOLETE = 'Obsolete' + DEFERRED = 'Deferred' + REJECTED = 'Rejected' + DEPRECATED = 'Deprecated' + + @classmethod + def fromstr(cls, s): + if s == "Proto" or s.lower() == "protoxep": + s = "ProtoXEP" + return cls(s) + + +class Action(enum.Enum): + PROTO = "Proposed XMPP Extension" + NEW = "NEW" + DRAFT = "DRAFT" + ACTIVE = "ACTIVE" + FINAL = "FINAL" + RETRACT = "RETRACTED" + OBSOLETE = "OBSOLETED" + DEFER = "DEFERRED" + UPDATE = "UPDATED" + + @classmethod + def fromstatus(cls, status): + return { + Status.EXPERIMENTAL: cls.NEW, + Status.DRAFT: cls.DRAFT, + Status.ACTIVE: cls.ACTIVE, + Status.FINAL: cls.FINAL, + Status.RETRACTED: cls.RETRACT, + Status.OBSOLETED: cls.OBSOLETE, + Status.DEPRECATED: cls.DEPRECATE, + Status.DEFERRED: cls.DEFERRED, + } + + +XEP_URL_PREFIX = "https://xmpp.org/extensions/" + + +MAIL_PROTO_TEMPLATE = """\ +The XMPP Extensions Editor has received a proposal for a new XEP. + +Title: {info[title]} +Abstract: +{info[abstract]} + +URL: {url} + +The {approver} will decide in the next two weeks whether to accept this \ +proposal as an official XEP.""" + + +SUBJECT_PROTO_TEMPLATE = "Proposed XMPP Extension: {info[title]}" + + +MAIL_NONPROTO_TEMPLATE = """\ +Version {info[last_revision][version]} of XEP-{info[number]:04d} \ +({info[title]}) has been released. + +Abstract: +{info[abstract]} + +Changelog: +{changelog} + +URL: {url}""" + + +SUBJECT_NONPROTO_TEMPLATE = \ + "{action.value}: XEP-{info[number]:04d} ({info[title]})" + + +def load_xepinfo(el): + accepted = el.get("accepted").lower() == "true" + + info = { + "title": el.find("title").text, + "abstract": el.find("abstract").text, + "type": el.find("type").text, + "status": Status.fromstr(el.find("status").text), + "approver": el.find("approver").text, + "accepted": accepted, + } + + last_revision_el = el.find("last-revision") + if last_revision_el is not None: + last_revision = { + "version": last_revision_el.find("version").text, + "date": last_revision_el.find("date").text, + "initials": None, + "remark": None, + } + + initials_el = last_revision_el.find("initials") + if initials_el is not None: + last_revision["initials"] = initials_el.text + + remark_el = last_revision_el.find("remark") + if remark_el is not None: + last_revision["remark"] = remark_el.text + + info["last_revision"] = last_revision + + sig = el.find("sig") + if sig is not None: + info["sig"] = sig.text + + if accepted: + info["number"] = int(el.find("number").text) + else: + info["protoname"] = el.find("proto-name").text + + return info + + +def load_xepinfos(tree): + accepted, protos = {}, {} + for info_el in tree.getroot(): + info = load_xepinfo(info_el) + if info["accepted"]: + accepted[info["number"]] = info + else: + protos[info["protoname"]] = info + + return accepted, protos + + +def dummy_info(number): + return { + "status": None, + "accepted": False, + "number": number, + } + + +def diff_infos(old, new): + if old["status"] != new["status"]: + if new["status"] == Status.PROTO: + return Action.PROTO + elif old["status"] is None: + return Action.NEW + else: + return Action.fromstatus(new["status"]) + + old_version = old.get("last_revision", {}).get("version") + new_version = new.get("last_revision", {}).get("version") + + if old_version != new_version: + return Action.UPDATE + + return None + + +def wraptext(text): + return "\n".join( + itertools.chain( + *[textwrap.wrap(line) if line else [line] for line in text.split("\n")] + ) + ) + + +def make_proto_mail(info): + kwargs = { + "info": info, + "approver": info["approver"], + "url": "{}inbox/{}.html".format( + XEP_URL_PREFIX, + info["protoname"], + ), + } + + mail = email.message.EmailMessage() + mail["Subject"] = SUBJECT_PROTO_TEMPLATE.format(**kwargs) + mail["XSF-XEP-Action"] = "PROTO" + mail["XSF-XEP-Title"] = info["title"] + mail["XSF-XEP-Type"] = info["type"] + mail["XSF-XEP-Status"] = info["status"].value + mail["XSF-XEP-Url"] = kwargs["url"] + mail["XSF-XEP-Approver"] = kwargs["approver"] + mail.set_content( + wraptext(MAIL_PROTO_TEMPLATE.format(**kwargs)), + "plain", + "utf-8", + ) + + return mail + + +def make_nonproto_mail(action, info): + last_revision = info.get("last_revision") + changelog = "(see in-document revision history)" + if last_revision is not None: + remark = last_revision.get("remark") + initials = last_revision.get("initials") + if remark and initials: + changelog = "{} ({})".format(remark, initials) + + kwargs = { + "info": info, + "changelog": changelog, + "action": action, + "url": "{}xep-{:04d}.html".format( + XEP_URL_PREFIX, + info["number"], + ), + } + + mail = email.message.EmailMessage() + mail["Subject"] = SUBJECT_NONPROTO_TEMPLATE.format(**kwargs) + mail["XSF-XEP-Action"] = action.value + mail["XSF-XEP-Title"] = info["title"] + mail["XSF-XEP-Type"] = info["type"] + mail["XSF-XEP-Status"] = info["status"].value + mail["XSF-XEP-Number"] = "{:04d}".format(info["number"]) + mail["XSF-XEP-Url"] = kwargs["url"] + mail.set_content( + wraptext(MAIL_NONPROTO_TEMPLATE.format(**kwargs)), + "plain", + "utf-8", + ) + + return mail + + +def get_or_ask(config, section, name, prompt): + try: + return config.get(section, name) + except (configparser.NoSectionError, + configparser.NoOptionError): + return input(prompt) + + +def interactively_extend_smtp_config(config): + try: + host = config.get("smtp", "host") + except (configparser.NoSectionError, + configparser.NoOptionError): + host = input("SMTP server: ").strip() + port = int(input("SMTP port (blank for 587): ").strip() or "587") + user = input( + "SMTP user (leave blank for anon): " + ).strip() or None + if user: + password = getpass.getpass() + else: + password = None + else: + port = config.getint("smtp", "port", fallback=587) + user = config.get("smtp", "user", fallback=None) + password = config.get("smtp", "password", fallback=None) + + try: + from_ = config.get("smtp", "from") + except (configparser.NoSectionError, + configparser.NoOptionError): + from_ = input("From address: ").strip() + + if not config.has_section("smtp"): + config.add_section("smtp") + config.set("smtp", "host", host) + config.set("smtp", "port", str(port)) + if user: + config.set("smtp", "user", user) + if password is None: + password = getpass.getpass() + config.set("smtp", "password", password) + config.set("smtp", "from", from_) + + +def choose(prompt, options, *, + eof=EOFError, + keyboard_interrupt=KeyboardInterrupt): + while True: + try: + choice = input(prompt).strip() + except EOFError: + if eof is EOFError: + raise + return eof + except KeyboardInterrupt: + if keyboard_interrupt is KeyboardInterrupt: + raise + return keyboard_interrupt + + if choice not in options: + print("invalid choice. please enter one of: {}".format( + ", ".join(map(str, options)) + )) + continue + + return choice + + +def make_smtpconn(config): + host = config.get("smtp", "host") + port = config.getint("smtp", "port") + user = config.get("smtp", "user", fallback=None) + password = config.get("smtp", "password", fallback=None) + + conn = smtplib.SMTP(host, port) + conn.starttls() + if user is not None: + conn.login(user, password) + + return conn + + +def make_fake_smtpconn(): + class Fake: + def send_message(self, mail): + print("---8<---") + print(mail.as_string()) + print("--->8---") + + def close(self): + pass + + return Fake() + + +def main(): + import argparse + + parser = argparse.ArgumentParser( + description=wraptext(DESCRIPTION), + epilog=wraptext(EPILOG), + formatter_class=argparse.RawDescriptionHelpFormatter + ) + + parser.add_argument( + "-c", "--config", + metavar="FILE", + type=argparse.FileType("r"), + help="Configuration file", + ) + parser.add_argument( + "-y", + dest="ask_confirmation", + default=True, + action="store_false", + help="'I trust this script to do the right thing and send emails" + "without asking for confirmation.'" + ) + parser.add_argument( + "--no-proto", + dest="process_proto", + default=True, + action="store_false", + help="Disable processing of ProtoXEPs.", + ) + parser.add_argument( + "-n", "--dry-run", + dest="dry_run", + action="store_true", + default=False, + help="Instead of sending emails, print them to stdout (implies -y)", + ) + + parser.add_argument( + "old", + type=argparse.FileType("rb"), + help="Old xep-infos XML file", + ) + parser.add_argument( + "new", + type=argparse.FileType("rb"), + help="New xep-infos XML file", + ) + + parser.add_argument( + "to", + nargs="+", + help="The mail addresses to send the update mails to." + ) + + args = parser.parse_args() + + can_be_interactive = ( + os.isatty(sys.stdin.fileno()) and + os.isatty(sys.stdout.fileno()) + ) + + if args.dry_run: + args.ask_confirmation = False + + if args.ask_confirmation and not can_be_interactive: + print("Cannot ask for confirmation (stdio is not a TTY), but -y is", + "not given either. Aborting.", sep="\n", file=sys.stderr) + sys.exit(2) + + config = configparser.ConfigParser() + if args.config is not None: + config.read_file(args.config) + + with args.old as f: + tree = etree.parse(f) + old_accepted, old_proto = load_xepinfos(tree) + + with args.new as f: + tree = etree.parse(f) + new_accepted, new_proto = load_xepinfos(tree) + + old_xeps = set(old_accepted.keys()) + new_xeps = set(new_accepted.keys()) + + common_xeps = old_xeps & new_xeps + added_xeps = new_xeps - old_xeps + + added_protos = set(new_proto.keys()) - set(old_proto.keys()) + + updates = [] + + for common_xep in common_xeps: + old_info = old_accepted[common_xep] + new_info = new_accepted[common_xep] + + action = diff_infos(old_info, new_info) + if action is not None: + updates.append((common_xep, action, new_info)) + + for added_xep in added_xeps: + old_info = dummy_info(added_xep) + new_info = new_accepted[common_xep] + + action = diff_infos(old_info, new_info) + if action is not None: + updates.append((added_xep, action, new_info)) + + if args.process_proto: + for added_proto in added_protos: + old_info = dummy_info('xxxx') + new_info = new_proto[added_proto] + + action = diff_infos(old_info, new_info) + if action is not None: + updates.append((added_proto, action, new_info)) + + if args.dry_run: + smtpconn = make_fake_smtpconn() + else: + if can_be_interactive: + interactively_extend_smtp_config(config) + + try: + smtpconn = make_smtpconn(config) + except (configparser.NoSectionError, + configparser.NoOptionError) as exc: + print("Missing configuration: {}".format(exc), + file=sys.stderr) + print("(cannot ask for configuration on stdio because it is " + "not a TTY)", file=sys.stderr) + sys.exit(3) + + try: + for id_, action, info in updates: + if action == Action.PROTO: + mail = make_proto_mail(info) + else: + mail = make_nonproto_mail(action, info) + mail["Date"] = datetime.utcnow() + mail["From"] = config.get("smtp", "from") + mail["To"] = args.to + + if args.ask_confirmation: + print() + print("---8<---") + print(mail.as_string()) + print("--->8---") + print() + choice = choose( + "Send this email? [y]es, [n]o, [a]bort: ", + "yna", + eof="a", + ) + + if choice == "n": + continue + elif choice == "a": + print("Exiting on user request.", file=sys.stderr) + sys.exit(4) + + smtpconn.send_message(mail) + finally: + smtpconn.close() + + +if __name__ == "__main__": + main() From c880be3f534cf1d1f6e74d8f54ec9a5ce247372c Mon Sep 17 00:00:00 2001 From: vanitasvitae Date: Wed, 23 Aug 2017 14:43:22 +0200 Subject: [PATCH 42/54] Add missing length attribute to XML Schema --- xep-0234.xml | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/xep-0234.xml b/xep-0234.xml index 79ddd7e5..f47f4814 100644 --- a/xep-0234.xml +++ b/xep-0234.xml @@ -24,6 +24,12 @@ NOT_YET_ASSIGNED &stpeter; &lance; + + 0.18.2 + 2017-08-23 + ps +

          Add missing length attribute to XML schema.

           +           0.18.1 2017-05-20 @@ -1054,6 +1060,7 @@ a=file-range:1024-*]]> + @@ -1080,7 +1087,7 @@ a=file-range:1024-*]]> -

          Thanks to Diana Cionoiu, Olivier Crête, Viktor Fast, Philipp Hancke, Waqas Hussain, Justin Karneges, Steffen Larsen, Yann Leboulanger, Marcus Lundblad, Robert McQueen, Joe Maissel, Glenn Maynard, Ali Sabil, Sjoerd Simons, Will Thompson, Matthew Wild, and Jiří Zárevúcky for their feedback.

          +

          Thanks to Diana Cionoiu, Olivier Crête, Viktor Fast, Philipp Hancke, Waqas Hussain, Justin Karneges, Steffen Larsen, Yann Leboulanger, Marcus Lundblad, Robert McQueen, Joe Maissel, Glenn Maynard, Ali Sabil, Sjoerd Simons, Will Thompson, Matthew Wild, Paul Schaub and Jiří Zárevúcky for their feedback.

           From a4fbf95e1b2a19f52b6249c7f189d2303a848449 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Wed, 23 Aug 2017 13:20:46 +0200 Subject: [PATCH 43/54] Fix bitrot in inbox --- inbox/Makefile | 8 ++ inbox/account-management.xml | 22 ++-- inbox/bidi.xml | 1 + inbox/buddycloud-channels.xml | 188 ++++++++++------------------- inbox/carbons.xml | 1 + inbox/cmr.xml | 12 +- inbox/decloak.xml | 19 +-- inbox/distributedmuc.xml | 2 +- inbox/dmuc3.xml | 34 +++--- inbox/dna.xml | 1 + inbox/dsig.xml | 1 + inbox/ft-metadata.xml | 2 +- inbox/instant-gaming.xml | 2 +- inbox/iot-events.xml | 4 +- inbox/jingle-ibb.xml | 3 +- inbox/jingle-nodes.xml | 18 +-- inbox/jingle-rtp-codecs.xml | 2 +- inbox/jingle-rtp-mti.xml | 2 +- inbox/jingle-s5b.xml | 2 +- inbox/jingle-xtls.xml | 1 + inbox/jingle-zrtp.xml | 2 +- inbox/json.xml | 141 +++++++++++----------- inbox/lop.xml | 108 ++++++++--------- inbox/mobile.xml | 37 +++--- inbox/moved.xml | 11 +- inbox/muc-light.xml | 48 ++++---- inbox/muji.xml | 34 +++--- inbox/multi-user_gaming.xml | 22 ++-- inbox/multistage-ibr.xml | 2 +- inbox/notification-inbox.xml | 1 - inbox/nsver.xml | 5 +- inbox/s2s-components.xml | 2 +- inbox/sasl2.xml | 216 ++++++++++++++++++++++++++++++++++ inbox/sensors.xml | 31 ++--- inbox/sift.xml | 32 ++--- inbox/spim.xml | 7 +- inbox/sxe.xml | 2 +- inbox/tictactoe-mug.xml | 45 +++---- inbox/tictactoe.xml | 45 +++---- inbox/user-auth.xml | 20 ++-- inbox/userrating.xml | 12 +- inbox/xep.dtd | 1 + inbox/xep.ent | 1 + inbox/xtls.xml | 1 + 44 files changed, 647 insertions(+), 504 deletions(-) create mode 100644 inbox/Makefile create mode 100644 inbox/sasl2.xml create mode 120000 inbox/xep.dtd create mode 120000 inbox/xep.ent diff --git a/inbox/Makefile b/inbox/Makefile new file mode 100644 index 00000000..2e27a1f6 --- /dev/null +++ b/inbox/Makefile @@ -0,0 +1,8 @@ +OUTDIR?=../build/ + +xeps=$(wildcard *.xml) + +.PHONY: all +all: html + +html: $(patsubst %.xml, $(OUTDIR)/%.html, $(xeps)) diff --git a/inbox/account-management.xml b/inbox/account-management.xml index 6e71fb0b..b2a8e75a 100644 --- a/inbox/account-management.xml +++ b/inbox/account-management.xml @@ -23,7 +23,7 @@ XMPP Core - XEP-0077 + XEP-0077 NOT_YET_ASSIGNED @@ -72,11 +72,11 @@
          Account Management
          Gestion of a client XMPP account on a given server deployment. An account is being defined by the locale part of the JID, and by the authentication mechanisms available for this account.
          -
          In-Band
          -
          Capacity of acting directly through a XMPP stream. As a consequence, an In-Band Account Management MAY allow users to bootstrap the existence of their account, and oppositely to end it, or modify it, without ever having to use another medium (like the web for instance), or without the existence of a previous account.
          -
          Storage Mechanism
          -
          The internal logics of a server to store authentication data.
           +
          In-Band
          +
          Capacity of acting directly through a XMPP stream. As a consequence, an In-Band Account Management MAY allow users to bootstrap the existence of their account, and oppositely to end it, or modify it, without ever having to use another medium (like the web for instance), or without the existence of a previous account.
           +
          Storage Mechanism
          +
          The internal logics of a server to store authentication data.
           @@ -481,13 +481,13 @@
        2. For a better user experience, it is important to provide <challenge/> fallbacks rather than directly fail with a <failure/> on the first user error. XEP-0158 for instance proposes to fail directly on a wrong answer to a CAPTCHA challenge, while it is well known that many actual human users regularly fails, sometimes even several, captchas before succeeding one. As a consequence, in such a case or other similar challenge, it is better to return a new challenge (a new CAPTCHA for instance) rather than cancelling the negotiation, doing so eventually only after a few retries.
        3. The storage mechanism does not mean necessarily that credentials have to be stored in the given form, in particular when the server estimates a storage mechanism being stronger than the one desired by the user, and still without losing any authentication possibility. For instance if a client was to exchange credentials in PLAIN, and if the server usually provides SCRAM-SHA1, SCRAM-SHA-256 and PLAIN authentication mechanisms, then it would be wise to store it as both SCRAM-SHA-1 and SCRAM-SHA-256 instead of PLAIN. This way the security of the password is highly renforced in the case of the database being stolen and the three authentication mechanisms are still available to this user. Of course it would have been even more secure for the client itself to exchange the credentials as SCRAM-SHA-1 and SCRAM-SHA-256 from the start, because by exchanging PLAIN data, possibility is given to a man-in-the-middle attack to steal directly the password during this one-time account registration.
        4. Security may have a price. If you were to store credentials with SCRAM-SHA-256 only, and later you change to a client which supports only PLAIN and SCRAM-SHA-1, you may fall in a case where you force yourself to log in using PLAIN. For this reason, a good client implementation SHOULD be able to determine such edge case. In the previous case, if possible, it SHOULD have stored both SCRAM-SHA-1 and SCRAM-SHA-256 on registration or silently modify later its storage.
          5. -
        5. When registering a new account, considering that the user has obviously not been authenticated yet, the server MUST NOT rely on the 'from' value of the initiating stream. In particular:
          6. +
        6. When registering a new account, considering that the user has obviously not been authenticated yet, the server MUST NOT rely on the 'from' value of the initiating stream. In particular:
            -
          • the server MUST NOT decide whether or not to propose the <registration/> feature based on the existence of the JID filled in 'from'. Doing so would leak away information about the existence of a JID which could therefore be sent undesirable messages. Being consistent on showing the feature forces to try to register which can already eliminates part of the risk if the challenge provides some bot protection (for instance CAPTCHAs). -
            A perfectly valid alternative would be to always provide the <registration/> feature when no "from" is filled but never provide it when a "from is filled" (no matter it is an existing JID or not). This consistent logics does not leak information.
            • -
          • Do not modify the SASL authentication's mechanisms listed in the <mechanisms/> feature depending on the 'from'. Even though a given JID might not be able to connect with some mechanisms because the credentials storage is incompatible, this would leak information on the kind of storage mechanism used for this user. This information would allow attackers to determine, then target, users whose storage would be weaker. -
            Of course this particular point might cause issues for users regularly changing their clients or log in from various computer. For instance the SCRAM-SHA-1 and SCRAM-SHA-256 storage are incompatible. If you first registered by specifying the SCRAM-SHA-256 storage, then on another client which does not support SCRAM-SHA-256 or even who supports it, but for some reason always try and gives priority to SCRAM-SHA-1, the user could be found in a situation where he never manages to authenticate while providing the right password. For this reason, it could be wiser for server deployments to choose compatible mechanisms, when possible. On client side, if they are provided a raw password, instead of pre-computed data for a specific mechanism, then they should intelligently try the various mechanisms, starting from the one they consider the stronger. Hence try SCRAM-SHA-256, then SCRAM-SHA-1 if the first failed, then only if both failed, tell the user that authentication failed (note that the client should not try PLAIN as a last fallback, because we remind that any SCRAM-* storage is compatible with the SASL PLAIN mechanism. Trying PLAIN would therefore be a security risk.
            • -
          +

        7. the server MUST NOT decide whether or not to propose the <registration/> feature based on the existence of the JID filled in 'from'. Doing so would leak away information about the existence of a JID which could therefore be sent undesirable messages. Being consistent on showing the feature forces to try to register which can already eliminates part of the risk if the challenge provides some bot protection (for instance CAPTCHAs).

          +

          A perfectly valid alternative would be to always provide the <registration/> feature when no "from" is filled but never provide it when a "from is filled" (no matter it is an existing JID or not). This consistent logics does not leak information.

          8. +

        8. Do not modify the SASL authentication's mechanisms listed in the <mechanisms/> feature depending on the 'from'. Even though a given JID might not be able to connect with some mechanisms because the credentials storage is incompatible, this would leak information on the kind of storage mechanism used for this user. This information would allow attackers to determine, then target, users whose storage would be weaker.

          +

          Of course this particular point might cause issues for users regularly changing their clients or log in from various computer. For instance the SCRAM-SHA-1 and SCRAM-SHA-256 storage are incompatible. If you first registered by specifying the SCRAM-SHA-256 storage, then on another client which does not support SCRAM-SHA-256 or even who supports it, but for some reason always try and gives priority to SCRAM-SHA-1, the user could be found in a situation where he never manages to authenticate while providing the right password. For this reason, it could be wiser for server deployments to choose compatible mechanisms, when possible. On client side, if they are provided a raw password, instead of pre-computed data for a specific mechanism, then they should intelligently try the various mechanisms, starting from the one they consider the stronger. Hence try SCRAM-SHA-256, then SCRAM-SHA-1 if the first failed, then only if both failed, tell the user that authentication failed (note that the client should not try PLAIN as a last fallback, because we remind that any SCRAM-* storage is compatible with the SASL PLAIN mechanism. Trying PLAIN would therefore be a security risk.

          9. +
diff --git a/inbox/bidi.xml b/inbox/bidi.xml index 71940237..850555b6 100644 --- a/inbox/bidi.xml +++ b/inbox/bidi.xml @@ -1,6 +1,7 @@ + rfc3920bis RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-ietf-saintandre-rfc3920bis>." > %ents; ]> diff --git a/inbox/buddycloud-channels.xml b/inbox/buddycloud-channels.xml index a5cb5976..fe4cb0f1 100644 --- a/inbox/buddycloud-channels.xml +++ b/inbox/buddycloud-channels.xml @@ -8,14 +8,44 @@ ]> -
+
Buddycloud Channels This document describes a profile and conventions for usage of the PubSub protocol in the context of a new type of communication. + &LEGALNOTICE; xxxx ProtoXEP Standards Track Standards Council + + XMPP Core + XEP-0059 + XEP-0060 + XEP-0313 + XEP-0255 + XEP-0107 + + + + NOT_YET_ASSIGNED + + Simon + Tennant + simon@buddycloud.com + simon@buddycloud.com + + + Lloyd + Watkin + lloyd@evilprofessor.co.uk + lloyd@evilprofessor.co.uk + + + Ashley + Ward + ashley.ward@surevine.com + ashley.ward@surevine.com + 0.0.2 2014-04-29 @@ -24,92 +54,8 @@

First draft.

 - NOT_YET_ASSIGNED - - This XMPP Extension Protocol is copyright (c) 1999 - 2014 - by the XMPP Standards Foundation (XSF). - - Permission is hereby granted, free of charge, to any - person obtaining a copy of this specification (the - "Specification"), to make use of the Specification without - restriction, including without limitation the rights to implement - the Specification in a software program, deploy the Specification in - a network service, and copy, modify, merge, publish, translate, - distribute, sublicense, or sell copies of the Specification, and to - permit persons to whom the Specification is furnished to do so, - subject to the condition that the foregoing copyright notice and - this permission notice shall be included in all copies or - substantial portions of the Specification. Unless separate - permission is granted, modified works that are redistributed shall - not contain misleading information regarding the authors, title, - number, or publisher of the Specification, and shall not claim - endorsement of the modified works by the authors, any organization - or project to which the authors belong, or the XMPP Standards - Foundation. - - ## NOTE WELL: This Specification is provided on an - "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY - KIND, express or implied, including, without limitation, any - warranties or conditions of TITLE, NON-INFRINGEMENT, - MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event - shall the XMPP Standards Foundation or the authors of this - Specification be liable for any claim, damages, or other liability, - whether in an action of contract, tort, or otherwise, arising from, - out of, or in connection with the Specification or the - implementation, deployment, or other use of the Specification. ## - - In no event and under no legal theory, whether in tort - (including negligence), contract, or otherwise, unless required by - applicable law (such as deliberate and grossly negligent acts) or - agreed to in writing, shall the XMPP Standards Foundation or any - author of this Specification be liable for damages, including any - direct, indirect, special, incidental, or consequential damages of - any character arising out of the use or inability to use the - Specification (including but not limited to damages for loss of - goodwill, work stoppage, computer failure or malfunction, or any and - all other commercial damages or losses), even if the XMPP Standards - Foundation or such author has been advised of the possibility of - such damages. - - - This XMPP Extension Protocol has been contributed in full - conformance with the XSF's Intellectual Property Rights Policy (a - copy of which may be found at < - http://xmpp.org/extensions/ipr-policy.shtml - > or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 - USA). - - - - XMPP Core - XEP-0059 - XEP-0060 - XEP-0313 - XEP-0255 - XEP-0107 - - - - - Simon - Tennant - simon@buddycloud.com - simon@buddycloud.com - - - Lloyd - Watkin - lloyd@evilprofessor.co.uk - lloyd@evilprofessor.co.uk - - - Ashley - Ward - ashley.ward@surevine.com - ashley.ward@surevine.com -
- +

The Buddycloud project is a set of independently deployable services, that inter-operate to create a rich collaboration service. @@ -188,7 +134,7 @@ - +

Each XMPP domain can have one Buddycloud server that serves user's channels. Buddycloud clients and servers need to be able to discover the authoratative Buddycloud server. find the @@ -196,7 +142,7 @@

To find the correct remote Buddycloud service for a domain, the Buddycloud - server should: + server should:

  1. Use a disco#items query against the XMPP service for the remote Buddycloud domain. @@ -206,7 +152,6 @@ discovery method.
-

The Buddycloud service first sends an items discovery request to the domain @@ -274,12 +219,12 @@

This example delegates all the Buddycloud service to an XMPP component running the Buddycloud named - buddycloud-component.verona.lit + buddycloud-component.verona.lit .

- +

Upon connection to the buddycloud server a user should send a register stanza.

@@ -300,15 +245,16 @@

- +

Node metadata is used to describe the channel to users. All nodes in a channel have the same metadata and permission.

- - using disco-info - with the node specified - using XEP-0060 5.4 Discover Node Metadata + +

- using disco-info + with the node specified - using &xep0060; 5.4 Discover Node Metadata

 - set Not sure what - goes here? +

set Not sure what + goes here?

minimum setting/optional recommended fallbacks @@ -401,7 +347,6 @@

Channel owners and moderators can also set the default affiliation for the channel

-

@@ -429,8 +374,6 @@
Channel Type
-

-

@@ -455,7 +398,6 @@
Access Model
-

Buddycloud is designed to be extended with new node and content types. To @@ -523,16 +465,14 @@ - +

Buddycloud adapts XEP-0060's machine-to-machine design goals with logic and presets that work better in a social person-to-person and person-to-group environment. For example, to discourage "glorifying the wicked", the list of banned users is only presented to the channel's moderators.

-

- @@ -544,8 +484,6 @@ - - @@ -665,12 +603,8 @@ -
Property Access modelAnonymous (e.g. web) Banned users
channel name allno no
-

-

- @@ -680,8 +614,6 @@ - - @@ -745,9 +677,7 @@ -
Property ProducerAnonymous (e.g. web) Banned users
change channel name only at creation timeno no
-

A Buddycloud server MUST maintain similar affiliations and permissions for a subscribed @@ -762,7 +692,7 @@

- +

Many of the item use cases follow those from XEP-0060. This section notes the departures from the parent XEP and specific requirements. @@ -864,8 +794,8 @@ ]]> - A retraction message is sent to all online clients, with an Atom tombstone to - replace the deleted post +

A retraction message is sent to all online clients, with an Atom tombstone to + replace the deleted post

@@ -900,7 +830,7 @@ review ; extensions.

- +

The minimal payload for a publish request must be formatted as follows:

@@ -962,11 +892,11 @@ - + +

Posts in Buddycloud can be formed into threads consisting of a parent post - and comments to a maximum thread depth of 1. Posts follow the - ATOM threading specification + and comments to a maximum thread depth of 1. Posts follow the &rfc4685; and utilise the & thread ; namespace with the 'ref' attribute referring to the full global ID of the @@ -992,7 +922,7 @@ ]]> - +

  • parent-item-not-found @@ -1003,7 +933,9 @@ : An attempt to comment on a comment will result in this error response
- + + +

Within a single thread comments can reference other comments or the parent item. This is for the purpose of making a comment to a post further back in the thread. @@ -1052,6 +984,7 @@ +

By making use of the & @@ -1119,13 +1052,13 @@ - +

Buddycloud clients follow XEP-0060 subscription mechanisms for following and unfollowing a channel.

 - +

- Buddycloud channels build on XEP-0060's node affiliations. + Buddycloud channels build on XEP-0060's node affiliations.

@@ -1183,10 +1116,9 @@
XEP-0060 AffiliationRECOMMENDED
-

- + @@ -1204,7 +1136,7 @@

- +

The Buddycloud server should make sure that the remote server diff --git a/inbox/carbons.xml b/inbox/carbons.xml index 997b229f..d77b9424 100644 --- a/inbox/carbons.xml +++ b/inbox/carbons.xml @@ -1,6 +1,7 @@ + rfc3921bis RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/draft-ietf-saintandre-rfc3921bis>." > %ents; ]> diff --git a/inbox/cmr.xml b/inbox/cmr.xml index 5b27ad0d..67964291 100644 --- a/inbox/cmr.xml +++ b/inbox/cmr.xml @@ -117,7 +117,7 @@ Examples for balancing algorithms include: -An entity advertises support for this protocol by including the 'urn:xmpp:cmr:0' feature in its service discovery information features as specified in Service Discovery (XEP-0030) or section 6.3 of Entity Capabilities (XEP-0015). +

An entity advertises support for this protocol by including the 'urn:xmpp:cmr:0' feature in its service discovery information features as specified in Service Discovery (XEP-0030) or section 6.3 of Entity Capabilities (XEP-0015).

-If allowed and supported by the server, clients are able to annotate message stanza with a routing hint, that SHOULD affect the used message routing algorithm for the annotated stanza. +

If allowed and supported by the server, clients are able to annotate message stanza with a routing hint, that SHOULD affect the used message routing algorithm for the annotated stanza.

@@ -306,7 +306,7 @@ The CMR state, ie. the used routing algorithm, is identical for every session of

Algorithm Namespace: 'urn:xmpp:cmr:all'

-Deliver to all non-negative resources with share the same maximum priority. And if message type is 'chat', only to those that have opted in to receive chat messages. +

Deliver to all non-negative resources with share the same maximum priority. And if message type is 'chat', only to those that have opted in to receive chat messages.

 @@ -314,7 +314,7 @@ Deliver to all non-negative resources with share the same maximum priority. And

Algorithm Namespace: 'urn:xmpp:cmr:mostactive'

-Deliver the message to the "most available" resource or resources, depending on the server's implementation. +

Deliver the message to the "most available" resource or resources, depending on the server's implementation.

@@ -322,7 +322,7 @@ Deliver the message to the "most available" resource or resources, depending on

Algorithm Namespace: 'urn:xmpp:cmr:roundrobin'

-Deliver the message to the next resource selected by a round-robin algorithm. +

Deliver the message to the next resource selected by a round-robin algorithm.

@@ -330,7 +330,7 @@ Deliver the message to the next resource selected by a round-robin algorithm.

Algorithm Namespace: 'urn:xmpp:cmr:weighted'

-Deliver the message to a resource selected by a weighted round-robin algorithm. The weight of a resource is determined by its priority. +

Deliver the message to a resource selected by a weighted round-robin algorithm. The weight of a resource is determined by its priority.

 diff --git a/inbox/decloak.xml b/inbox/decloak.xml index 388b344a..f7ab7336 100644 --- a/inbox/decloak.xml +++ b/inbox/decloak.xml @@ -149,15 +149,20 @@

To signal the type of communication that is desired, the entity that first decloaks MAY include a 'reason' attribute on the <decloak/> element. The following values for the 'reason' attribute are defined:

-
media
-
Presence is requested for a voice and/or video call, e.g. via &xep0167;.
+ +
media
+
Presence is requested for a voice and/or video call, e.g. via &xep0167;.
+ -
text
+ +
text
+
Presence is requested for a plaintext or &xep0071; conversation, e.g. with end-to-end encryption (which requires capabilities to be disclosed).
+ -
Presence is requested for a plaintext or &xep0071; conversation, e.g. with end-to-end encryption (which requires capabilities to be disclosed).
- -
file
-
Presence is requested for one or more file transfers, e.g. via &xep0234; or &xep0095;.
+ +
file
+
Presence is requested for one or more file transfers, e.g. via &xep0234; or &xep0095;.
+

Inclusion of the 'reason' attribute can be interpreted by the receiving client as a signal that communication is about to start; for instance, a call accept/reject dialog could double as a UI for accepting or rejecting a decloaking request.

diff --git a/inbox/distributedmuc.xml b/inbox/distributedmuc.xml index 37403faf..cf5134d6 100644 --- a/inbox/distributedmuc.xml +++ b/inbox/distributedmuc.xml @@ -357,7 +357,7 @@ -

If a MUC service supports distributed rooms, it MUST return a feature of "urn:xmpp:dmuc:0" &NSVER; in response to &xep0030; information requests.

+

If a MUC service supports distributed rooms, it MUST return a feature of "urn:xmpp:dmuc:0" in response to &xep0030; information requests.

 diff --git a/inbox/dmuc3.xml b/inbox/dmuc3.xml index 4b287bb3..45099a37 100644 --- a/inbox/dmuc3.xml +++ b/inbox/dmuc3.xml @@ -54,7 +54,7 @@

-

The following is a list of goals for the design of this extension: +

The following is a list of goals for the design of this extension:

  • DMUC should be transparent to the end user
  • DMUC should be transparent to the client program
    • @@ -63,35 +63,33 @@
  • Mirrors of the master room will not communicate directly with each other
  • If the S2S link is broken, it will appear to a user as if other users have left the room
  • Users in the same mirror can communicate with each other until the link is re-established with the master
    • -
  • DMUC will improve upon the &xep0033; concept
    • by eliminating the need for <addresses/> +
  • DMUC will improve upon the &xep0033; concept by eliminating the need for <addresses/>
-

-
master
-
The the actual MUC server
-
mirror
-
A mirror for a master MUC room on another machine
+
master
+
The the actual MUC server
 +
mirror
+
A mirror for a master MUC room on another machine

The following JIDs are used in this document.

-
fairfax.tridsys.com
XMPP server where the master MUC room is located
-
conference.fairfax.tridsys.com
MUC service on fairfax.tridsys.com.
-
chatroom@conference.fairfax.tridsys.com
MUC room.
-
kevin@fairfax.tridsys.com
User on fairfax.tridsys.com
-
scott@fairfax.tridsys.com
Another user on fairfax.tridsys.com
-
-
raleigh.tridsys.com
A remote service, connected to fairfax.tridsys.com over constrained link
-
mirror.raleigh.tridsys.com
DMUC service on raleigh.tridsys.com
-
wayne@raleigh.tridsys.com
User on raleigh.tridsys.com
-
keith@raleigh.tridsys.com
Another user on raleigh.tridsys.com
+
fairfax.tridsys.com
XMPP server where the master MUC room is located
 +
conference.fairfax.tridsys.com
MUC service on fairfax.tridsys.com.
 +
chatroom@conference.fairfax.tridsys.com
MUC room.
 +
kevin@fairfax.tridsys.com
User on fairfax.tridsys.com
 +
scott@fairfax.tridsys.com
Another user on fairfax.tridsys.com
 +
raleigh.tridsys.com
A remote service, connected to fairfax.tridsys.com over constrained link
 +
mirror.raleigh.tridsys.com
DMUC service on raleigh.tridsys.com
 +
wayne@raleigh.tridsys.com
User on raleigh.tridsys.com
 +
keith@raleigh.tridsys.com
Another user on raleigh.tridsys.com

@@ -105,7 +103,7 @@ Support for Distributed MUC in a given server instance SHOULD be determined usin A conforming server MUST respond to disco#info requests.

-To determine if a server or service supports Distributed MUC, the requesting entity SHOULD send a disco#info request to it. +

To determine if a server or service supports Distributed MUC, the requesting entity SHOULD send a disco#info request to it.

%ents; +rfc3920bis RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-ietf-saintandre-rfc3920bis>." > ]> diff --git a/inbox/dsig.xml b/inbox/dsig.xml index 7c415193..4a8215e0 100644 --- a/inbox/dsig.xml +++ b/inbox/dsig.xml @@ -5,6 +5,7 @@ DATETIME RFC 3339: Date and Time on the Internet Timestamps <http://tools.ietf.org/html/rfc3339>." > XMLDSIG XML Signature Syntax and Processing, W3C Recommendation, 10 June 2008 <http://www.w3.org/TR/xmldsig-core/>." > E2EEncrypt End-to-End Object Encryption for the Extensible Messaging and Presence Protocol (XMPP), Miller, M. and P. Saint-Andre, work in progress <http://datatracker.ietf.org/doc/draft-miller-3923bis>." > + rfc3920bis RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-ietf-saintandre-rfc3920bis>." > %ents; ]> diff --git a/inbox/ft-metadata.xml b/inbox/ft-metadata.xml index 2761c6ae..50ddab1e 100644 --- a/inbox/ft-metadata.xml +++ b/inbox/ft-metadata.xml @@ -13,8 +13,8 @@ xxxx ProtoXEP Standards Track - Council Standards + Council XMPP Core XEP-0096 diff --git a/inbox/instant-gaming.xml b/inbox/instant-gaming.xml index f74367d5..3b6c4def 100644 --- a/inbox/instant-gaming.xml +++ b/inbox/instant-gaming.xml @@ -20,6 +20,7 @@
Instant Gaming This document defines an XMPP protocol extension for serverless instant gaming in a one-to-one context. + &LEGALNOTICE; xxxx ProtoXEP Standards Track @@ -53,7 +54,6 @@ tg

First draft.

 - &LEGALNOTICE;

diff --git a/inbox/iot-events.xml b/inbox/iot-events.xml index 97905ebf..2de007fd 100644 --- a/inbox/iot-events.xml +++ b/inbox/iot-events.xml @@ -367,7 +367,7 @@ - +

To unsubscribe a subscription, send the unsubscribe element in a request to the Thing with the seqnr sequence number corresponding to the subscription. The Thing responds with an empty response to acknowledge the un-subscription, regardless if the subscription existed or not. @@ -726,4 +726,4 @@ - \ No newline at end of file + diff --git a/inbox/jingle-ibb.xml b/inbox/jingle-ibb.xml index 9cecae00..5091fbaf 100644 --- a/inbox/jingle-ibb.xml +++ b/inbox/jingle-ibb.xml @@ -1,6 +1,7 @@ + rfc3920bis RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-ietf-saintandre-rfc3920bis>." > %ents; ]> @@ -35,7 +36,7 @@ - The basic flow is as follows. +

The basic flow is as follows.

- Jingle Nodes + Jingle Nodes Thiago Camargo thiago@xmppjingle.com @@ -120,7 +120,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring ]]> -In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services. +

In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services.

A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on the known Tracker Services.

@@ -139,7 +139,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring type='result'> ]]> -In this example 'capulet.lit' returned an empty service list, meaning that it does NOT known ANY Relay or Tracker Services. +

In this example 'capulet.lit' returned an empty service list, meaning that it does NOT known ANY Relay or Tracker Services.

A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on his Roster Items until find the desired amount of Relay Services, or while it does NOT exceed a search depth or ANY other Client implementation policy. The Client SHOULD keep a list of visited Tracker Services in order to avoid searching twice in same Service Entity.

@@ -161,7 +161,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring ]]>

In this example 'juliet@capulet.lit/balcony' returned a Relay Service entry that is restricted to its roster. This Service is usable as the requester has 'juliet@capulet.lit/balcony' on its roster. Although, services with policy 'roster' MUST NOT be listed in Tracker Responses expects in Tracker Responses that comes from the Service Entity itself, in this case 'juliet@capulet.lit/balcony'.

-In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry. +

In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry.

A Jingle Client with direct access to a public IP can potentially provide the Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, whitelist, blacklist, domain, etc...

@@ -372,15 +372,9 @@ All signalling, request, response and publishing is done via XMPP, not requiring

Relay Channels auto expires MUST expire on traffic inactivity. The inactivity timeout recommended is 60 seconds.

It is heavily recommended that the Super Node implements throttle:

    -

  • Based on JID, allowing the control of how many concurrent channels an specific JID can have.
    • -

    -

  • Based on JID, allowing the control of how many channel requests an specific JID can request in a time period.
    • -

    -

    -

  • Based on Bandwidth, allowing the control of how much bandwidth a channel can use. The maximum bandwidth SHOULD be included on the candidate element provided by a Super Node on the attribute maxkbps. If no attribute is present, it means that it has no bandwidth control.
    • -

    +
  • Based on Bandwidth, allowing the control of how much bandwidth a channel can use. The maximum bandwidth SHOULD be included on the candidate element provided by a Super Node on the attribute maxkbps. If no attribute is present, it means that it has no bandwidth control. - ]]> + ]]>
 diff --git a/inbox/jingle-rtp-codecs.xml b/inbox/jingle-rtp-codecs.xml index a64dfb17..2c7aa8f4 100644 --- a/inbox/jingle-rtp-codecs.xml +++ b/inbox/jingle-rtp-codecs.xml @@ -80,7 +80,7 @@ Good quality; optimized for voice; can be used for wide-band audio. - See &rtpspeex;. + See &rfc5574;. Freely downloadable under a revised BSD license at <http://speex.org/> and commonly deployed on Internet (VoIP) systems; not commonly deployed on non-Internet systems. Designed to be patent-clear. diff --git a/inbox/jingle-rtp-mti.xml b/inbox/jingle-rtp-mti.xml index ea644e13..ae80a77e 100644 --- a/inbox/jingle-rtp-mti.xml +++ b/inbox/jingle-rtp-mti.xml @@ -64,7 +64,7 @@ Good quality; optimized for voice; can be used for wide-band audio. - See &rtpspeex;. + See &rfc5574;. Widely available and freely downloadable under a revised BSD license at <http://speex.org/>. Designed to be patent-free. diff --git a/inbox/jingle-s5b.xml b/inbox/jingle-s5b.xml index b9737fa4..53064496 100644 --- a/inbox/jingle-s5b.xml +++ b/inbox/jingle-s5b.xml @@ -54,7 +54,7 @@ - The basic flow is as follows. +

The basic flow is as follows.

+ rfc3920bis RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-ietf-saintandre-rfc3920bis>." > %ents; ]> diff --git a/inbox/jingle-zrtp.xml b/inbox/jingle-zrtp.xml index 8088e0b8..85058b08 100644 --- a/inbox/jingle-zrtp.xml +++ b/inbox/jingle-zrtp.xml @@ -40,7 +40,7 @@
-

&xep0167; recommends the use of the Secure Real-time Transport Protocol (SRTP) for end-to-end encryption of RTP sessions negotiated using &xep0166;. An alternative approach to end-to-end encryption of RTP traffic is provided by &zrtp;. Although negotiation of ZRTP mainly occurs in the media channel rather than the signalling channel, the ZRTP specification defines one SDP attribute called "zrtp-hash" (this communicates the ZRTP version supported as well as a hash of the Hello message).

+

&xep0167; recommends the use of the Secure Real-time Transport Protocol (SRTP) for end-to-end encryption of RTP sessions negotiated using &xep0166;. An alternative approach to end-to-end encryption of RTP traffic is provided by &rfc6189;. Although negotiation of ZRTP mainly occurs in the media channel rather than the signalling channel, the ZRTP specification defines one SDP attribute called "zrtp-hash" (this communicates the ZRTP version supported as well as a hash of the Hello message).

The SDP format is shown below.

a=zrtp-hash:zrtp-version zrtp-hash-value diff --git a/inbox/json.xml b/inbox/json.xml index 4c754345..f05c4271 100644 --- a/inbox/json.xml +++ b/inbox/json.xml @@ -48,13 +48,11 @@

The following design requirements reflect the need to offer performance as close as possible to standard XMPP-based stanza handling.

-

  1. JSON default character set must be UTF-8
  2. JSON stanza must contain (or retain) all XMPP stanza content and hierarchy
  3. Server must support both XML and JSON content-types.
-

Intent for following use-cases is to support JavaScript-based clients which typically start XMPP-session from HTTP-dialog, and then depending on network environment and run-time support end using BOSH or C2S through Web Sockets.

@@ -69,23 +67,23 @@

Client (and server) implementation needs to take care of using such JSON object format which retains all structure of all XMPP XML stanzas.

-

Following http-header is used to communicate with server using JSON playload: - 

+   
Following http-header is used to communicate with server using JSON playload:

+    
 POST /http-bind HTTP/1.1
 Host: httpcm.jabber.org
 Accept-Encoding: gzip, deflate
 Content-Type: application/jsonrequest
 Content-Length: 230
-
- 
+    
+    
 HTTP/1.1 200 OK
 Content-Type: application/jsonrequest
 Content-Length: 513
-

+ -

In following example server name is modified so content length is not accurate. Also JSON payload is modified for better clarity of its structure. - 

+   
In following example server name is modified so content length is not accurate. Also JSON payload is modified for better clarity of its structure.

+    
 POST /http-bind HTTP/1.1
 Host: httpcm.jabber.org
 Accept-Encoding: gzip, deflate
@@ -106,8 +104,8 @@ Content-Length: 230
     "@xmpp" : "urn:xmpp:xbosh" }
   }
 }
-
- 
+
+    
 HTTP/1.1 200 OK
 Content-Type: application/jsonrequest
 Content-Length: 513
@@ -141,140 +139,139 @@ Content-Length: 513
     }
   }
 }
-
+
    -
  • Tag with text value
    • - XMPP-XML:
    +      
  • Tag with text value
+       XMPP-XML:
 <tag>txt-value</tag>
-
    • - JSON:
    +
+       JSON:
 { "tag" : "txt-value" }
-
    -
  • Tag with another tag
    • - XMPP-XML:
    +
+      
  • Tag with another tag
+       XMPP-XML:
 <tag>
  <tag2>txt-value</tag2>
 </tag>
-
    • - JSON:
    +
+       JSON:
 { "tag" : {
   "$" : {
     "tag2" : "txt-value" }
   }
 }
-
    -
  • Multiple text value tags as array
    • - XMPP-XML:
    +
+      
  • Multiple text value tags as array
+       XMPP-XML:
 <tag>
  <tag2>txt-value1</tag2>
  <tag2>txt-value2</tag2>
 </tag>
-
    • - JSON:
    +
+       JSON:
 { "tag" : {
   "$" : {
     "tag2" : [ "txt-value1", "txt-value2" ] }
   }
 }
-
    -
  • Tag with attribute, no value
    • - XMPP-XML:
    +
+      
  • Tag with attribute, no value
+       XMPP-XML:
 <tag attr="attr-value" />
-
    • - JSON:
    +
+       JSON:
 { "tag" : { "attr" : "attr-value" } }
-
    -
  • Tag with multiple attributes as array, no value
    • - XMPP-XML:
    +
+      
  • Tag with multiple attributes as array, no value
+       XMPP-XML:
 <tag attr="attr-value1" attr="attr-value2" />
-
    • - JSON:
    +
+       JSON:
 { "tag" : {
   "attr" : [ "attr-value1", "attr-value2" ] }
 }
-
    -
  • Tags as array with unique attributes, no value
    • - XMPP-XML:
    +
+      
  • Tags as array with unique attributes, no value
+       XMPP-XML:
 <tag>
  <tag2 attr="attr-value1" />
  <tag2 attr="attr-value2" />
 </tag>
-
    • - JSON:
    +
+       JSON:
 { "tag" : {
   "tag2" : [
     { "attr" : "attr-value1" },
     { "attr" : "attr-value2" } ]
   }
 }
-
    -
  • Tag with namespace attribute, no value
    • - XMPP-XML:
    +
+      
  • Tag with namespace attribute, no value
+       XMPP-XML:
 <tag xmlns:ns="ns-value" />
-
    • - JSON:
    +
+       JSON:
 { "tag" : {
   "xmlns" : {
     "@ns" : "attr-value" }
   }
 }
-
    -
  • Tag with many attributes to namespace, no value
    • - XMPP-XML:
    +
+      
  • Tag with many attributes to namespace, no value
+       XMPP-XML:
 <tag xmlns="root-value" xmlns:ns="ns-value" />
-
    • - JSON:
    +
+       JSON:
 { "tag" : {
   "xmlns" : {
     "$" : "root-value",
     "@ns" : "attr-value" }
   }
 }
-
    -
  • Tag with namespace attribute, no value
    • - XMPP-XML:
    +
+      
  • Tag with namespace attribute, no value
+       XMPP-XML:
 <ns:tag attr="attr-value" />
-
    • - JSON:
    +
+       JSON:
 { "tag" : {
   "$$" : "ns",
   "attr" : "attr-value" }
 }
-
    -
  • Tag with attribute and text value
    • - XMPP-XML:
    +
+      
  • Tag with attribute and text value
+       XMPP-XML:
 <tag attr="attr-value">txt-value</tag>
-
    • - JSON:
    +
+       JSON:
 { "tag" : {
   "attr" : "attr-value",
   "$" : "txt-value" }
 }
-
    -
  • Namespace tag with attribute and text value
    • - XMPP-XML:
    +
+      
  • Namespace tag with attribute and text value
+       XMPP-XML:
 <ns:tag attr="attr-value">txt-value</tag>
-
    • - JSON:
    +
+       JSON:
 { "tag" : {
   "$$" : "ns",
   "attr" : "attr-value",
   "$" : "txt-value" }
 }
-
    +
  • Complex combination
    • -
  • Tag name conversions
    • -

    JSON data is typically converted to JS-object in browser client. Practically this means that tag string name / value string pairs are converted to tag name / value string pairs. Example:

    +      
  • Tag name conversions
+       
    JSON data is typically converted to JS-object in browser client. Practically this means that tag string name / value string pairs are converted to tag name / value string pairs. Example:
    
 var s = '{ "key" : "value" }';
 var sObj = JSON.parse(s);        // sObj = { key : "value" };
 var sStr = JSON.stringify(sObj); // sStr = '{"key":"value"}';
-

    • +

    Javascript variable naming doesn't support full colon characters ':'. Intented conversion between JSON and JS-objects is based on native JavaScript class JSON, more spesifically methods JSON.stringify() for converting object to JSON, and JSON.parse() from JSON to object.
    - Because of this namespace definitions are constructed hiearchically and their scope is within tag it is defined. Currently only reserved namespace name is 'xml'.

    + Because of this namespace definitions are constructed hiearchically and their scope is within tag it is defined. Currently only reserved namespace name is 'xml'.

 -

diff --git a/inbox/lop.xml b/inbox/lop.xml index b87e499f..6cf31aee 100644 --- a/inbox/lop.xml +++ b/inbox/lop.xml @@ -66,12 +66,12 @@

Linked Process is a protocol for Internet-scale, general-purpose distributed computing. With an implementation of this protocol, any computing device with an Internet connection can contribute computing resources to a user-generated compute cloud. +

  • The term computing device is broad and spans particulars such as cell phones, laptops, desktops, servers, supercomputers, etc. In Linked Process, a computing device is anything that maintains a central processing unit (CPU) that can be programmed to execute any desired computation.
  • The term computing resources is broad and spans particulars such as clock cycles, data sets, software application programming interfaces (APIs), or specialized hardware componets such as cell phone cameras, field-programmable gate array (FPGA) circuits, etc.
  • The term compute cloud is the collection of all Linked Process enabled devices, their resources, and the Linked Process specific software components defined later in this specification.
-

Within the category of computing devices, Linked Process makes a distinction between resource consumers (devices making use of non-local computing resources) and a resource providers (devices offering computing resources)Nothing prevents the same device from being a resource consumer in one context and being a resource provider in another.. Linked Process allows a resource consumer to leverage the computing resources offered by a resource provider in anyway deemed appropriate by the resource consumer. This is accomplished by the resource consumer providing/migrating/sending code (i.e. software instructions) to a computer language interpreter maintained by the resource provider. As such, it is up to the resource consumer to define the instructions to be executed by the provider. Given this architecture, resource providing devices in a Linked Process cloud are general-purpose computing sandboxes (i.e. they can be leveraged for computational ends that are defined by a resource consumer).

@@ -84,18 +84,18 @@ Linked Process was developed to address the following two distributed computing requirements: Internet-scale and general-purpose. These requirements imply yet more requirements which accompany their description below.

    -
  • Internet-scale: it is required that any device with an Internet connection (from a cell phone to a supercomputer) be able provide/contribute and consume/leverage computing resources in a Linked Process cloud.
    • +
  • Internet-scale: it is required that any device with an Internet connection (from a cell phone to a supercomputer) be able provide/contribute and consume/leverage computing resources in a Linked Process cloud.
    • Decentralized: it is required that the computing resources are not necessarily centralized or controlled by any one party.
    • Discoverable: it is required that resource providers be discoverable by resources consumers.
    • Transient: it is required that devices coming online and offline are gracefully incoporated and removed from the cloud.
      • -
    -
  • General-purpose: It is required that consumers be able to utilize provided resources for any desired purpose.
    • +
+
  • General-purpose: It is required that consumers be able to utilize provided resources for any desired purpose.
    • Language-agnostic: it is required that the protocol support the migration of code written in any computer language.
    • Safe: it is required that the execution of consumer code be confined by permissions clearly specified by the resource providerThere is a tradeoff between "general-purpose" and "safety." It is important to ensure that the integrity of resource providers are not compomised due to malicious or poorly written code..
    • Accessible: it is required that computing resources be accessible when permissions allow by ensuring the supported language interpreters provide necessary "low-level" manipulations of such resources.
      • -
    +
    • @@ -161,18 +161,18 @@ A <spawn_vm/> element is wrapped by an <iq/> element. The purpose of <spawn_vm/> is to have a farm create a new virtual machine. It is through a virtual machine that a villein is able to access the computing resources of the physical device that hosts the farm (i.e. the resource provider). A virtual machine will maintain a state throughout a villein "session" with that virtual machine. The only way to alter the state of a virtual machine is through submitting jobs and updating its variable bindingsThis is an important concept to understand. During the life of a virtual machine, the virtual machine has a state that changes as jobs are submitted and bindings are managed. In other words, a virtual machine is not a "one-job" machine..

      -
    • Villein generated <iq type="get"> <spawn_vm/>:
      • +
    • Villein generated <iq type="get"> <spawn_vm/>:
      • xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
      • vm_species attribute: the language of the virtual machine to be spawned (values are implementation dependent).
      • farm_password attribute: the password of the farmThis is an OPTIONAL attribute. Farm passwords are useful for creating private farms in order, for example, to allow "looser" permissions with known villeins. If no password is required (e.g. a public farm), then no farm_password attribute SHOULD be provided..
        • -
      -
    • Farm generated <iq type="result"> or <iq type="error"> <spawn_vm/>:
      • +
    +
  • Farm generated <iq type="result"> or <iq type="error"> <spawn_vm/>:
    • xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
    • vm_id attribute: a farm-internal unique identifier for the newly created virtual machine. This MUST be provided if <iq type="result"/>.
    • vm_species attribute: the species of the newly created virtual machine. This MUST be provided if <iq type="result"/>.
      • -
    • One of these error conditions MUST be provided if <iq type="error"/>.
      • +
    • One of these error conditions MUST be provided if <iq type="error"/>.
      • <species_not_supported/>
      • <farm_is_busy/>
        • @@ -180,8 +180,8 @@
      • <internal_error/>
      • <wrong_farm_password/>
      • if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <text/>. Error responses extend the requirements set forth by the Core XMPP specification.
        • -
      -
    +
    • + <submit_job/> element is wrapped by an <iq/> element. The purpose of <submit_job/> is to send code (i.e. expressions, statements, instructions) to a virtual machine for execution (i.e. evaluation, interpretation). The expression SHOULD be respective of the virtual machine's language (i.e. the virtual machine's species). If they are not, then evaluation errors SHOULD occur. The expression submitted through a <submit_job/> stanza can be short (e.g. set a variable value, get a variable value) or long (e.g. define a class/method, execute a long running body of statements). The submitted expression is called a job in Linked Process and is assigned a job_id as specified by the <iq/> id attribute value. That is, the staza id of the <submit_job/> is the job's id.

      -
    • Villein generated <iq type="get"> <submit_job/>:
      • +
    • Villein generated <iq type="get"> <submit_job/>:
      • xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
      • vm_id attribute: the farm-internal unique identifier of the virtual machine.
      • <submit_job/> text body: the expression for the virtual machine to evaluate. If no text body is provided, the expression to be evaluated can be interpreted as a blank string or a null expression. The behavior of such an evaluation is up to the virtual machine implementation.
        • -
      -
    • Farm generated <iq type="result"> or <iq type="error"> <submit_job/>:
      • +
    +
  • Farm generated <iq type="result"> or <iq type="error"> <submit_job/>:
    • xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
    • vm_id attribute: the farm-internal unique identifier of the virtual machine.
    • <submit_job/> text body: the result of the expression evaluated.
      • -
    • One of these error conditions MUST be provided if <iq type="error"/>Note that, according to XMPP Core, it is RECOMMENDED that an <iq type="error"/> return the the query provided by the villein. In the example above, only the tag name is provided without the full body. The reason for this is that for <submit_job/>, the length of the text body of the tag is unrestricted and thus could be a very large piece of code. Thus, returning the original <submit_job/> stanza in the error response could lead to excessive communication overhead..
      • +
    • One of these error conditions MUST be provided if <iq type="error"/>Note that, according to XMPP Core, it is RECOMMENDED that an <iq type="error"/> return the the query provided by the villein. In the example above, only the tag name is provided without the full body. The reason for this is that for <submit_job/>, the length of the text body of the tag is unrestricted and thus could be a very large piece of code. Thus, returning the original <submit_job/> stanza in the error response could lead to excessive communication overhead..
      • <malformed_packet/>
      • <internal_error/>
        • @@ -240,8 +240,8 @@
      • <vm_not_found/>
      • <job_timed_out/>
      • if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <text/>. Error responses extend the requirements set forth by the Core XMPP specification.
        • -
      -
    +
    • + <ping_job/> element is wrapped by an <iq/> element. The purpose of <ping_job/> is to determine the status (i.e. progress, state) of a previously submitted <submit_job/> stanza (i.e. job) that has yet to complete.

      -
    • Villein generated <iq type="get"> <ping_job/>:
      • +
    • Villein generated <iq type="get"> <ping_job/>:
      • xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
      • vm_id attribute: the farm-internal unique identifier of the virtual machine.
      • job_id attribute: the job identifier (the job identifier is the stanza identifier of the respective <submit_job/>).
        • -
      -
    • Farm generated <iq type="result"> or <iq type="error"> <ping_job/>:
      • +
    +
  • Farm generated <iq type="result"> or <iq type="error"> <ping_job/>:
    • xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
    • vm_id attribute: the farm-internal unique identifier of the virtual machine.
      • -
    • status attribute: the job's status. This MUST be provided if <iq type="result"/>.
      • +
    • status attribute: the job's status. This MUST be provided if <iq type="result"/>.
      • in_progress: the job is in progress.
        • -
      +
  • job_id attribute: the job identifier for the status being reported.
    • -
  • One of these error conditions MUST be provided if <iq type="error"/>.
    • +
  • One of these error conditions MUST be provided if <iq type="error"/>.
    • <malformed_packet/>
    • <vm_not_found/>
    • <internal_error/>
    • <job_not_found/>
    • if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <text/>. Error responses extend the requirements set forth by the Core XMPP specification.
      • -
    - +
    • + @@ -348,26 +348,26 @@ An <abort_job/> element is wrapped by an <iq/> element. The purpose of <abort_job/> is to cancel (i.e. quit, stop, halt) a previously submitted, yet not completed <submit_job/> stanza (i.e. job).

      -
    • Villein generated <iq type="get"> <abort_job/>:
      • +
    • Villein generated <iq type="get"> <abort_job/>:
      • xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
      • vm_id attribute: the farm-internal unique identifier of the virtual machine.
      • job_id attribute: the job identifier (the job identifier is the stanza identifier of the respective <submit_job/>).
        • -
      +
    -
  • Farm generated <iq type="result"> or <iq type="error"> <abort_job/>:
    • +
  • Farm generated <iq type="result"> or <iq type="error"> <abort_job/>:
    • xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
    • vm_id attribute: the farm-internal unique identifier of the virtual machine.
      • -
    • One of these error conditions MUST be provided if <iq type="error"/>.
      • +
    • One of these error conditions MUST be provided if <iq type="error"/>.
      • <malformed_packet/>
      • <vm_not_found/>
      • <internal_error/>
      • <job_not_found/>
      • if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <text/>. Error responses extend the requirements set forth by the Core XMPP specification.
        • -
      -
    +
    • + <manage_bindings/> element is wrapped by an <iq/> element. The purpose of <manage_bindings/> is to allow a villein to get and set variables in the variable space of a virtual machine. The definition of the "variable space" is up to the implementation of the virtual machine. In general, this is the set of all global variables for the virtual machine.

      -
    • Villein generated <iq type="get"> or <iq type="set"> <manage_bindings/>:
      • +
    • Villein generated <iq type="get"> or <iq type="set"> <manage_bindings/>:
      • xmlns attribute: http://linkedprocess.org/2009/06/Farm#
      • vm_id attribute: the farm-internal unique identifier of the virtual machine.
        • -
      • <binding/> child tag of <manage_bindings/> for <iq type="get"/>
        • +
      • <binding/> child tag of <manage_bindings/> for <iq type="get"/>
        • name attribute: the name of the variable.
          • -
        -
      • <binding/> child tag of <manage_bindings/> for <iq type="set"/>
        • +
      • +
    • <binding/> child tag of <manage_bindings/> for <iq type="set"/>
      • name attribute: the name of the variable.
      • value attribute: the value of the variable.
      • datatype attribute: the datatype of the variable (specified using XML schema for datatypes).
        • -
      -
    -
  • Farm generated <iq type="result"> or <iq type="error"> <manage_bindings/>:
    • + + +
  • Farm generated <iq type="result"> or <iq type="error"> <manage_bindings/>:
    • xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
    • vm_id attribute: the farm-internal unique identifier of the virtual machine.
      • -
    • <binding/> child tag of <manage_bindings/> for <iq type="get"/>
      • +
    • <binding/> child tag of <manage_bindings/> for <iq type="get"/>
      • name attribute: the name of the variable.
      • value attribute: the value of the variable.
        • -
      -
    • One of these error conditions MUST be provided if <iq type="error"/>.
      • +
    • +
  • One of these error conditions MUST be provided if <iq type="error"/>.
    • <malformed_packet/>
    • <vm_not_found/>
      • @@ -435,8 +435,8 @@
    • <unknown_datatype/>
    • <invalid_value/>
    • if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <text/>. Error responses extend the requirements set forth by the Core XMPP specification.
      • -
    - +
    • + @@ -468,11 +468,11 @@ ]]>

    - After the previous <manage_bindings/> stanza has been processed by the virtual machine, it is possible to use the bindings in a statement. For example, in JavaScript + After the previous <manage_bindings/> stanza has been processed by the virtual machine, it is possible to use the bindings in a statement. For example, in JavaScript

    var fact = name + " knows josh and peter"; - will set fact to the value "marko knows josh and peter" as well as make it an accessible binding. +

    will set fact to the value "marko knows josh and peter" as well as make it an accessible binding.

    @@ -490,11 +490,11 @@ ]]>

    - A useful aspect of <manage_bindings/> is that it can be used to track the state of a variable during the execution of a job. For example, suppose the following job is submitted to a JavaScript virtual machine.var x = 1.0; + A useful aspect of <manage_bindings/> is that it can be used to track the state of a variable during the execution of a job. For example, suppose the following job is submitted to a JavaScript virtual machine.

    var x = 1.0; while(true) { x = x + 0.0001; } - This job will continue indefinitely (or until it is timed out by the virtual machine). However, during its execution, it is possible to determine the current state of x using <manage_bindings/>. Each get-based <manage_bindings/> call should return a larger x value. +

    This job will continue indefinitely (or until it is timed out by the virtual machine). However, during its execution, it is possible to determine the current state of x using <manage_bindings/>. Each get-based <manage_bindings/> call should return a larger x value.

    @@ -502,23 +502,23 @@ while(true) { A <terminate_vm/> element is wrapped by an <iq/> element. The purpose of a <terminate_vm/> is to shutdown (i.e. quit, exit, halt) the virtual machine. Upon termination, the virtual machine will lose its state and will no longer be able to be communicated with.

      -
    • Villein generated <iq type="get"> <terminate_vm/>:
      • +
    • Villein generated <iq type="get"> <terminate_vm/>:
      • xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
      • vm_id attribute: the farm-internal unique identifier of the virtual machine.
        • -
      -
    • Farm generated <iq type="result"> or <iq type="error"> <terminate_vm/>:
      • +
    +
  • Farm generated <iq type="result"> or <iq type="error"> <terminate_vm/>:
    • xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
    • vm_id attribute: the farm-internal unique identifier of the virtual machine.
      • -
    • One of these error conditions MUST be provided if <iq type="error"/>.
      • +
    • One of these error conditions MUST be provided if <iq type="error"/>.
      • <malformed_packet/>
      • <vm_not_found/>
      • <internal_error/>
      • if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <text/>. Error responses extend the requirements set forth by the Core XMPP specification.
        • -
      -
    +
    • + @@ -928,7 +928,7 @@ while(true) {

    - The following namespaces are defined by Linked Process: +

    The following namespaces are defined by Linked Process:

    • http://linkedprocess.org/2006/06/Farm#
    • http://linkedprocess.org/2006/06/Registry#
      • diff --git a/inbox/mobile.xml b/inbox/mobile.xml index 7cdfeecc..70c62605 100644 --- a/inbox/mobile.xml +++ b/inbox/mobile.xml @@ -1,6 +1,7 @@ + rfc3920bis RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-ietf-saintandre-rfc3920bis>." > %ents; ]> @@ -107,27 +108,27 @@

      As with anything, there are no hard and fast rules. If there were, they might look like these. First, for devices:

      -
      Transmit no data.
      -
      Transmitting costs significant power, and moreover raises the radio state. Not transmitting will allow it to maximize the time spent in the low-cost Idle state.
      -
      If you must transmit, then transmit only a small volume.
      -
      If there is only a small amount of data transmitted - less than 128 octets typically - the radio will only raise to FACH, which is significantly cheaper than DCH.
      -
      If you must transmit, then compress as hard as possible.
      -
      Since individual octets have an associate power - and often financial - cost, it's worth maximizing the compression algorithm, even if the volume of traffic will raise to DCH.
      -
      If you have transmit a lot, then do a lot
      -
      If the radio is raised to DCH anyway, then you may as well go fetch that avatar you were missing, since you're chewing through power anyway.
      -
      If you receive, then transmit
      -
      If your peer raises the radio state, you may as well use it.
      +
      Transmit no data.
      +
      Transmitting costs significant power, and moreover raises the radio state. Not transmitting will allow it to maximize the time spent in the low-cost Idle state.
       +
      If you must transmit, then transmit only a small volume.
      +
      If there is only a small amount of data transmitted - less than 128 octets typically - the radio will only raise to FACH, which is significantly cheaper than DCH.
       +
      If you must transmit, then compress as hard as possible.
      +
      Since individual octets have an associate power - and often financial - cost, it's worth maximizing the compression algorithm, even if the volume of traffic will raise to DCH.
       +
      If you have transmit a lot, then do a lot
      +
      If the radio is raised to DCH anyway, then you may as well go fetch that avatar you were missing, since you're chewing through power anyway.
       +
      If you receive, then transmit
      +
      If your peer raises the radio state, you may as well use it.

      And for servers, similar rules apply:

      -
      Send no data.
      -
      Sending data will cause the handset to be raised out of Idle. This immediately costs massively higher power.
      -
      If you must send, send tiny bits.
      -
      Sending small enough data maximizes the likelyhood that the devices radio will only be raised to FACH levels.
      -
      If you receive, then send anything you have.
      -
      Receiving data indicates that the radio is active - it'll stay active for some time, so sending data doesn't incur the overhead of raising the radio state, and won't increase power drain on the handset.
      -
      If you must send when not receiving, send plenty.
      -
      Sending data will raise the radio's state - unless you can tell this will only raise it to FACH, it's worth sending as much as possible.
      +
      Send no data.
      +
      Sending data will cause the handset to be raised out of Idle. This immediately costs massively higher power.
       +
      If you must send, send tiny bits.
      +
      Sending small enough data maximizes the likelyhood that the devices radio will only be raised to FACH levels.
       +
      If you receive, then send anything you have.
      +
      Receiving data indicates that the radio is active - it'll stay active for some time, so sending data doesn't incur the overhead of raising the radio state, and won't increase power drain on the handset.
       +
      If you must send when not receiving, send plenty.
      +
      Sending data will raise the radio's state - unless you can tell this will only raise it to FACH, it's worth sending as much as possible.

      Finally, protocol designers should aim to minimize any responses required from the handset, and ensure keepalive traffic, if any, fits inside FACH wherever possible.

       diff --git a/inbox/moved.xml b/inbox/moved.xml index a0535d52..d6177881 100644 --- a/inbox/moved.xml +++ b/inbox/moved.xml @@ -2,6 +2,7 @@ + rfc3920bis RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-ietf-saintandre-rfc3920bis>." > %ents; ]> @@ -111,10 +112,10 @@ user@example.com.

      -
      original JID
      -
      user@example.com
      -
      new JID
      -
      user2@example2.com
      +
      original JID
      +
      user@example.com
       +
      new JID
      +
      user2@example2.com

      Because of the ability to spoof the &MOVED; element, the client SHOULD - NOT automatically subscribe to the &MOVED; element target

      . + NOT automatically subscribe to the &MOVED; element target.

      diff --git a/inbox/muc-light.xml b/inbox/muc-light.xml index 92e12c83..3275e62c 100644 --- a/inbox/muc-light.xml +++ b/inbox/muc-light.xml @@ -531,13 +531,12 @@

      The client MAY include initial configuration and occupant list (the list MUST NOT include the creator). The server MAY allow sending incomplete configuration form. In such case the server MUST use default values for missing fields. The server MAY enforce a minimal occupant list length.

      The service MAY either give the creator the 'owner' or 'member' status. In the latter case all users are equal.

      Upon room creation success, the service MUST reply with an empty IQ result.

      -

      The following rules (similar to the ones relevant to the affiliation change request) apply to the occupant list: -

        -
      • 'none' affiliation cannot be used.
        • -
      • All user bare JIDs must be unique
        • -
      • At most one owner can be chosen. In such case the room creator will become "just" a 'member'.
        • -
      -

      +

      The following rules (similar to the ones relevant to the affiliation change request) apply to the occupant list:

      +
        +
      • 'none' affiliation cannot be used.
        • +
      • All user bare JIDs must be unique
        • +
      • At most one owner can be chosen. In such case the room creator will become "just" a 'member'.
        • +

      After the room is created (but before receiving IQ result), new occupants (including creator) receive &MESSAGE; from the room with their affiliations (stanza MUST include only recipient's affiliation) and initial room version. <prev-version /> element MUST NOT be included.

      All changes must be meaningful, e.g. setting member's affiliation to 'member' is considered a bad request.
    • Server MAY allow members to add new members but they still cannot make anyone an 'owner' or remove other users from the room.
      • -

      On success the server will reply with result IQ with all changed items. BEFORE returning the IQ result, the service MUST route a message with affiliation change to all relevant users.

      +

      On success the server will reply with result IQ with all changed items. BEFORE returning the IQ result, the service MUST route a message with affiliation change to all relevant users.

      Newcomers, i.e. users that were not occupants before the change, SHOULD receive only their own affiliation and SHOULD NOT receive <prev-version /> element.

      The notifications must include both the new and old room version (<version /> and <prev-version /> respectively) string (except for the ones directed to users that have been removed from the room).

      The notifications contain a list of items. The item list may be different from the list in IQ set, because some of the changes may require additional operations, e.g. choosing new owner when the old one leaves. Users, that are still in the room after change, will receive full change list. Users, that have been removed from the room with the request, will get only one item: themselves with affiliation 'none'.

      @@ -1007,13 +1006,12 @@

      If the request sender does not have sufficient privileges (but is a room occupant), the service MUST reply with a 'not-allowed' error.

      -

      It occurs in the following cases: -

        -
      • A member tries to change the configuration but the service is not configured to allow it. It does not apply to the subject change, although it has to be performed by sending &MESSAGE; with &SUBJECT;, not configuration &IQ;.
        • -
      • A member tries to change anyone's affiliation to 'none' or 'owner'.
        • -
      • A member tries to change someone's affiliation to 'member' but the service is not configured to allow it.
        • -
      -

      +

      It occurs in the following cases:

      +
        +
      • A member tries to change the configuration but the service is not configured to allow it. It does not apply to the subject change, although it has to be performed by sending &MESSAGE; with &SUBJECT;, not configuration &IQ;.
        • +
      • A member tries to change anyone's affiliation to 'none' or 'owner'.
        • +
      • A member tries to change someone's affiliation to 'member' but the service is not configured to allow it.
        • +

      MUC Light service may be abused by malicious users, e.g. due to replicating single message for every room occupant. The list below contains suggested configurable limits that SHOULD be implemented.

      The service features that might vary depending on specific application are included as well.

      -

      -

        -
      • Maximal count of rooms the user occupies.
        • -
      • Blocking feature enabled/disabled.
        • -
      • XEP-0045 compatibility mode enabled/disabled.
        • -
      • Room creator's initial affiliation: owner/member.
        • -
      • Room configuration may be changed by owner/occupants.
        • -
      • New members can be invited by owner/occupants.
        • -
      • Maximal room size.
        • -
      -

      +
        +
      • Maximal count of rooms the user occupies.
        • +
      • Blocking feature enabled/disabled.
        • +
      • XEP-0045 compatibility mode enabled/disabled.
        • +
      • Room creator's initial affiliation: owner/member.
        • +
      • Room configuration may be changed by owner/occupants.
        • +
      • New members can be invited by owner/occupants.
        • +
      • Maximal room size.
        • +
      diff --git a/inbox/muji.xml b/inbox/muji.xml index 229cd766..3d326411 100644 --- a/inbox/muji.xml +++ b/inbox/muji.xml @@ -49,25 +49,25 @@ -Jingle XEP-0166 is used to negotiate peer to peer media sessions. +

      Jingle XEP-0166 is used to negotiate peer to peer media sessions. Muji is a way to coordinate Jingle sessions between a group of people. -Muji conferences are held in XEP-0045 rooms. +Muji conferences are held in XEP-0045 rooms.

       -A Muji conference has a number of contents, each of which has unique name. +

      A Muji conference has a number of contents, each of which has unique name. content type, and an encoding. Each participant may provide a stream for each content, and communicates which contents they are willing to provide streams for, along with encoding information, in their MUC presence. This serves two purposes. Firstly, so that each participant knows which contents every other participant provides. Secondly, so that there is a global payload type (PT) mapping for the various contents, so that clients only need to encode and -payload each content that they provide once. +payload each content that they provide once.

      -Participants are not required to participate all the contents that are +

      Participants are not required to participate all the contents that are available. For example, a Muji client might choose to only request audio -streams. +streams.

       @@ -75,7 +75,7 @@ streams. Joining a conference is done in two stages. The first step is to declare that preparations are being done to either join or start a muji session inside the MUC. This is indicated by the client sending a presence - stanza to the MUC with a preparing element in muji section. + stanza to the MUC with a preparing element in muji section.

      ]]> - The client MUST then wait until the MUC rebroadcasts its presence message, +

      The client MUST then wait until the MUC rebroadcasts its presence message, after which it MUST wait for all other participants that had a preparing element in their presence to finish preparation. Afterwards it should finish it's own preparation by updating its presence with the contents it wants to - take part in. + take part in.

      ]]> -

      -

      - - When a client adds a payload ID to a content description, it MUST have the +

      When a client adds a payload ID to a content description, it MUST have the same codec name and receiving parameters as the corresponding entries in other participants' payload maps for that content. For instance, if Alice defines a payload type with ID 98, codec Speex and a a clock rate of 8000 @@ -170,7 +167,7 @@ streams.

      Adding a stream follows a process similar to the joining a conference. As a first step an updated presence stanza MUST be send which contains a preparing - element as part of the Muji section. + element as part of the Muji section.

      ]]> - The client MUST then wait until the MUC rebroadcasts its presence message, +

      The client MUST then wait until the MUC rebroadcasts its presence message, after which it MUST wait for all other participants that had a preparing - element in their presence to finish their changes. + element in their presence to finish their changes.

      - Afterwards the client should add the new content to the muji section of its +

      Afterwards the client should add the new content to the muji section of its presence and add the content to all the jingle sessions it had with - participants it shared the content with. + participants it shared the content with.

      ]]> -

      diff --git a/inbox/multi-user_gaming.xml b/inbox/multi-user_gaming.xml index a19cab2a..38652c04 100644 --- a/inbox/multi-user_gaming.xml +++ b/inbox/multi-user_gaming.xml @@ -23,6 +23,7 @@
      Multi-User Gaming This document defines an XMPP protocol extension for multi-user gaming. + &LEGALNOTICE; xxxx ProtoXEP Standards Track @@ -74,7 +75,6 @@ tg

      First draft.

       - &LEGALNOTICE;

      @@ -197,8 +197,8 @@ - Most of the examples in this document use the scenario of Miranda and Ferdinand playing chess in Act V, Scene I of Shakespeare's The Tempest, - represented here as the "island-chess@games.shakespeare.lit" room. The characters are as follows: +

      Most of the examples in this document use the scenario of Miranda and Ferdinand playing chess in Act V, Scene I of Shakespeare's The Tempest, + represented here as the "island-chess@games.shakespeare.lit" room. The characters are as follows:

      @@ -216,7 +216,7 @@ - The following affiliations are defined: +

      The following affiliations are defined:

      1. Member
      2. Owner
        3. @@ -239,10 +239,10 @@

        - Owners are allowed to do what they like (saving/loading, change match options, etc.) +

        Owners are allowed to do what they like (saving/loading, change match options, etc.) except in unmoderated matches. This match type restricts the use of owner privileges to specific room statuses. Users with no affiliation SHALL NOT enter members-only matches. - Besides that, these users have the same privileges as members. + Besides that, these users have the same privileges as members.

      Room NicknameFull JIDAffiliationGame Role
      @@ -275,11 +275,11 @@ - The ways in which a user's affiliation changes are well-defined. +

      The ways in which a user's affiliation changes are well-defined. Sometimes the change results from the user's own action (e.g., registering as a member of the match), whereas sometimes the change results from an action taken by an owner. If a user's affiliation changes, a MUG service implementation MUST change the user's affiliation to reflect the change - and communicate that to all occupants. + and communicate that to all occupants.

       @@ -762,10 +762,10 @@ - It can be useful to invite other users to a room in which one is an occupant. +

      It can be useful to invite other users to a room in which one is an occupant. To do this, a MUG client sends XML of the following form to the &ROOM; itself adding an &INVITE; element for every invitee. - (the reason is OPTIONAL and the message MUST be explicitly or implicitly of type "normal"): + (the reason is OPTIONAL and the message MUST be explicitly or implicitly of type "normal"):

      If the room creation fails because the specified room configuration options violate one or more service policies (e.g., because the password for a password-protected room is blank), - the service MUST return a error. + the service MUST return a <not-acceptable/> error.

      -

      A given deployment MAY wish to redirect users to another medium (e.g., a website) for further stages of registration, rather than allowing in-band registration. The recommended approach is to include only the element rather than the required fields or a data form in the IQ result, as well as a URL encoded using &xep0066;

      +

      A given deployment MAY wish to redirect users to another medium (e.g., a website) for further stages of registration, rather than allowing in-band registration. The recommended approach is to include only the <instructions/> element rather than the required fields or a data form in the IQ result, as well as a URL encoded using &xep0066;

      inbox - Valerian Saliou diff --git a/inbox/nsver.xml b/inbox/nsver.xml index 1039598f..7d89dd1e 100644 --- a/inbox/nsver.xml +++ b/inbox/nsver.xml @@ -13,8 +13,9 @@ Experimental Informational Standards - None - None + + + namespace &dcridland; &stpeter; diff --git a/inbox/s2s-components.xml b/inbox/s2s-components.xml index 75973f9b..e9376fe3 100644 --- a/inbox/s2s-components.xml +++ b/inbox/s2s-components.xml @@ -22,7 +22,7 @@ XEP-0114 XEP-0225 - None + comp-s2s &dcridland; diff --git a/inbox/sasl2.xml b/inbox/sasl2.xml new file mode 100644 index 00000000..555dd37b --- /dev/null +++ b/inbox/sasl2.xml @@ -0,0 +1,216 @@ + + +%ents; +]> + + +
      + Extensible SASL Profile + This document describes a replacement for the SASL profile documented in RFC 6120 which allows for greater extensibility. + &LEGALNOTICE; + XXXX + ProtoXEP + Standards Track + Standards + + XMPP Core + + + + sasl2 + &dcridland; + + 0.0.1 + 2017-02-07 + dwd + +
        +
      • Initial Revision
        • +
      +       +       +
      + + +

      While SASL provides an excellent framework that has served us well over the past 18 years, a number of shortcomings in the profile - the syntax binding to XMPP - that is in use.

      +

      This specification addresses a number of shortfalls:

      +
        +
      • Number of round trips
        • +
      • Extensibility
        • +
      • Support for second factor
        • +
      • Support for mandatory password changes
        • +
      +

      The new SASL profile documented herein is primarily a syntactic change to allow extensibility, combined with removal of the (largely) redundant stream restart, and additional results beyond total success or abject failure.

      + +

      Although initiating entities, in general, use SASL, and receiving entities offer it, the SASL specification and common parlance both use "Client " and "Server"; this specification uses Client and Server and assumes C2S links. This is not intended to preclude use of this SASL profile on S2S links. The term "SASL2" is used to mean the new SASL profile specified in this document; however the same RFC 4422 definition of SASL (and SASL profiles) applies.

      +

      Examples often use hypothetical SASL mechanisms and sub-extensions; this specification does not intend to make a position on any particular SASL mechanism, and the Mandatory To Implement mechanisms are unaffected.

      +       +       + + + +

      Servers capable of SASL2 offer a stream feature of <mechanisms/>, qualified by the "urn:xmpp:sasl:0" namespace. This in turn contains one or more <mechanism/> elements in the same namespace, and potentially other elements (for example, the <hostname/> element defined within XEP-0233).

      +

      Note that SASL2 is impossible for clients to initiate without at least one mechanism being available, and therefore MUST NOT be offered.

      +

      The feature so advertised, and its child content, SHOULD be stable for the given stream to and from attributes and encryption state, and therefore MAY be cached by clients for later connections.

      +

      The Service Name used by XMPP is unchanged from RFC 6120.

      +       + +

      In all cases, both Clients and Servers encode SASL exchanges using Base 64 encoding. This SHOULD NOT include any line wrapping or other whitespace. As the form <element/> is equivalent to <element></element>, these both indicate an empty string, which is used to indicate no data (ie, the absence of the data). In order to explicitly transmit a zero-length SASL challenge or response, the sending party sends a single equals sign character ("=").

      +       + +

      Clients, upon observing this stream feature, initiate the authentication by the use of the <authenticate/> top-level element, within the same namespace. The nature of this element is to inform the server about properties of the final stream state, as well as initiate authentication itself. To achieve the latter, it has a single mandatory attribute of "mechanism", with a string value of a mechanism name offered by the Server in the stream feature, and an optional child element of <initial-response/>, containing a base64-encoded SASL Initial Response.

      +

      On subsequent connections, if a Client has previously cache the stream feature, the Client MAY choose to send it before seeing the stream features - sending it "pipelined" with the Stream Open tag for example.

      + + SW1wcm92ZWQgZW5jYXNwdWxhdGlvbiBvZiBvcHRpb25hbCBTQVNMLUlSIGRhdGE= + + ]]> + +

      In order to provide support for other desired stream states beyond authentication, additional child elements are used. For example, a hypothetical XEP-0198 session resumption element might be included, and/or Resource Binding requests.

      + + + U0FTTC1JUiBlbmNvZGVkIGFsb25nc2lkZSBiaW5kIHJlcXVlc3Q= + + + +]]> + +       + +

      Server Challenges MAY then be sent. Each Challenge MUST be responded to by a Client in a Client Response. These are not extensible, and contain the corresponding base64 encoded SASL data:

      + + + QmFzZSA2NCBlbmNvZGVkIFNBU0wgY2hhbGxlbmdlIGRhdGE= + + + + + QmFzZSA2NCBlbmNvZGVkIFNBU0wgcmVzcG9uc2UgZGF0YQ== + + ]]> + +       + +

      At any time while authentication is in progress, neither Client nor Server sends any element (including stanzas) or other data except the top-level elements defined herein. Clients MUST NOT send whitespace, and MUST send only <response/> elements as appropriate or an <abort/> element to immediately cause an error. Servers MUST disconnect Clients immediately if any other traffic is received. Servers are similarly REQUIRED to send no whitespace, and only the <response/> and completion elements from the section below.

      +       + +

      Authentication may complete in one of three ways. It may complete successfully, in which case the client is authenticated. It may also fail, in which case the client is not authenticated and the stream and session state remain entirely unchanged.

      +

      Finally, it may have completed successfully, but further interaction is required - for example, a password change or second-factor authentication.

      + +

      If the Client is now authenticated, the Server sends a <success/> element, which contains an OPTIONAL <additional-data/> element containing SASL additional data. It also contains a <authorization-identity/> element containing the negotiated identity - this is a bare JID, unless resource binding has occurred, in which case it is a full JID.

      + + + T3B0aW9uYWwgQmFzZSA2NCBlbmNvZGVkIFNBU0wgc3VjY2VzcyBkYXRh + + juliet@montague.example/Balcony/a987dsh9a87sdh + + ]]> +

      Other extension elements MAY also be contained by the <success/> element.

      + + + T3B0aW9uYWwgQmFzZSA2NCBlbmNvZGVkIFNBU0wgc3VjY2VzcyBkYXRh + + juliet@montague.example/Balcony/a987dsh9a87sdh + + + ]]> +

      Any security layer negotiated SHALL take effect after the ">" octet of the closing tag (ie, immediately after "</success>").

      +       + +

      A <failure/> element is used by the server to terminate the authentication attempt. It MAY contain application-specific error codes, and MAY contain a textual error. It MUST contain one of the SASL error codes from RFC 6120 Section 6.5.

      + + + + This is a terrible example. + + ]]> +       + +

      A <continue/> element is used to indicate that while the SASL exchange was successful, it is insufficient to allow authentication at this time.

      +

      This can be used to indicate that the Client needs to perform a Second Factor Authentication ("2FA"), or is required to change password. These are conducted as additional SASL mechanisms. Such SASL mechanisms MUST NOT change the authorization identifier, or introduce any security layer. The authorization identifer transmitted during the subsequent <success/>, and any security layer which comes into effect after the eventual <success/>, therefore MUST be that of the first mechanism.

      +

      The element contains a <mechanisms/> element, as defined above as a stream feature, containing suitable mechanisms. It MAY contain an <additional-data/> element, as the <success/> element does.

      +

      Finally, it MAY contain a <text/> element, which can contain human-readable data explaining the nature of the step required.

      + + + T3B0aW9uYWwgQmFzZSA2NCBlbmNvZGVkIFNBU0wgc3VjY2VzcyBkYXRh + + + HOTP-EXAMPLE + TOTP-EXAMPLE + + This account requires 2FA + + ]]> +

      Clients respond with a <next-authenticate/> element, which has a single mandatory attribute of "mechanism", containing the selected mechanism name, and contains an OPTIONAL base64 encoded initial response.

      + + MkZBIG9yIHBhc3N3b3JkIGNoYW5nZSBvciBzb21ldGhpbmc= + + ]]> +       +       +       + + +

      This provides pointers and/or clarifications to the in the order and manner defined in RFC 4422, section 4.

      + +

      The service name SHALL be "xmpp", as defined by RFC 6120.

      +       + +

      Servers list mechanisms during stream features (See ) and within the <continue/> element (See ).

      +

      TODO: Neither this specification nor RFC 6120 allow clients access to the mechanism list after SASL negotiation...?

      +       + + +

      Clients initiate using the <authenticate/> top level element (See , and after any <continue/> with the <next-authenticate/> message (See ).

      +       + +

      See .

      +       + +

      See .

      +       +       + +

      If a Client specifies an authorization string which is non-empty, the identifier is normalized by treating it as a JID, and performing normalization as described in RFC 7622.

      +       + +

      Clients MAY abort unilaterally by sending <abort/> as specified in .

      +

      Servers MAY abort unliterally by sending <failure/> with the <aborted/> error code as defined in .

      +       + +

      See .

      +       + +

      Option (a) is used - any SASL Security Layer is applied first to data being sent, and TLS applied last.

      +       + +

      Although the <continue/> concept does use multiple SASL sequences, only the first SASL mechanism used is considered an authentication, and only the first can negotiate a security layer.

      +

      In particular, once <success/> has been sent by the server, any further <authenticate/> element MUST result in a stream error.

      +       +       + + +

      Relative to the SASL profile documented in RFC 6120, this introduces more data unprotected by any security layer negotiated by SASL itself.

      +       + + +

      This XEP requires no interaction with &IANA;.

      +       + + +

      None.

      +       + + +

      The author wishes to share any credit with many members of the community, including Lance Stout, Ralph Meijer, and Florian Schmaus.

      +       + +       diff --git a/inbox/sensors.xml b/inbox/sensors.xml index d661858a..0f387289 100644 --- a/inbox/sensors.xml +++ b/inbox/sensors.xml @@ -244,7 +244,7 @@ Thus, for the meta data, the node id would be UUID_meta and the data value node       -Adapter publishes device meta data: +

      Adapter publishes device meta data:

      ]]>
      Room Type
      - -
      Attribute @@ -373,11 +372,9 @@ If the meta node is configured to include payloads, the subscribers will receive A serial number or other unique identifier for the physical device
      - -
      Attribute @@ -507,13 +504,11 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation The accuracy of the values reported by this transducer

      To make it easier for agents to sort through available devices and seonsors, it is desirable for implementations to use a common set of types. The following device types are defined:

      - -
      Type @@ -610,7 +605,6 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation Other type that isn't listed above
      @@ -618,7 +612,7 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation SI conventions as shown in the The Unified Code For Units of Measurement.

      -After specifying the units of the transducer device, you can then also specify an SI scalar value as powers of 10. The following example shows how to specify a sensor in centimeters. +After specifying the units of the transducer device, you can then also specify an SI scalar value as powers of 10. The following example shows how to specify a sensor in centimeters.

      ]]> -The following example shows how to specify a sensor in kilograms. +

      The following example shows how to specify a sensor in kilograms.

      ]]> -The following example shows how to specify a sensor in kilowatt-second with a resolution to the nearest 0.1 kWh. +

      The following example shows how to specify a sensor in kilowatt-second with a resolution to the nearest 0.1 kWh.

      ]]> -If no unitScaler value is specified, then a unitScaler of 0 (aka 10**0 = 1) is assumed. +

      If no unitScaler value is specified, then a unitScaler of 0 (aka 10**0 = 1) is assumed.

      -Values for a transducer are published via the data value node: +

      Values for a transducer are published via the data value node:

      ]]> - -
      Attribute @@ -744,7 +737,6 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation The raw value as seen by the transducer. The rawValue can be used to record a non-unit converted value for record keeping (e.g. a raw ADC value before calibration).

      OPTIONAL: Instead of putting all of the transducer values into a single data value node, an adapter MAY want to break up the transducer values into multiple nodes. For example, an adapter may want to do this for reasons of security (allow some entities to subscribe/publish to transducer Y1 and a different set of entities to subscribe/publish to transducer Y2). @@ -804,7 +796,7 @@ The information in the meta node is used by consumers to determine which node th

      -Values for a transducer can also be set by publishing to the data value node. +

      Values for a transducer can also be set by publishing to the data value node.

      ]]> - -
      Attribute @@ -922,7 +913,6 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation If the adapter can verify that the raw value is an allowable value for the transducer, it SHOULD allow the raw value to take precedence over the typedValue if provided.

      Actuation takes place as a split-phase operation with an action signal (publish) followed by a completion callback (subscribed message). @@ -1153,12 +1143,11 @@ Event Node ID: 4d4335b5-4134-11e0-9207-0800200c9a66_data ]]> -

      Two things to note: +

      Two things to note:

      1. The tuple ('4d4335b5-4134-11e0-9207-0800200c9a66_data', 'tid1') uniquely identifies the motion sensor for this camera adapter.
      2. It is not relevant to the subscriber of this node (the consumer of information) whether the camera has motion detection built in or whether the adapter is capturing images from the camera and using its own methodology for determining motion.
      -

      To continue this example further, let's assume an agent is subscribed to the data value node and can also publish to the tid2 node which controls the light. In this case, an agent will receive notification that movement was sensed and can take action. @@ -1302,7 +1291,7 @@ If an adapter chooses to publish a subset of transducer data (for example, only the changed values), it is possible for consumers who are off line or recently activated to miss older values. There are a variety of ways to handle this depending on the needs of the -implementor including (but not limited to): +implementor including (but not limited to):

      • Increase the history size of the node in the xmpp server so old entries can be obtained @@ -1317,7 +1306,7 @@ Put infrequent events in their own nodes and use data value node for frequent ev Put frequent events in their own nodes and use data value node for infrequent events
      -If an implementaion chooses to put some transducers values into their own nodes +

      If an implementaion chooses to put some transducers values into their own nodes (instead of putting them all into the data value node), remember that a transducer value MUST appear in either the data value node or its own node, but not both. The meta node indicates to consumers which node they should subscribe to in order to be notified when new data is available for their chosen transducer.

      diff --git a/inbox/sift.xml b/inbox/sift.xml index 37ff3de0..52f6cd7d 100644 --- a/inbox/sift.xml +++ b/inbox/sift.xml @@ -162,10 +162,10 @@
      iq-sift
      -
      The server enables the client to sift all &IQ; stanzas or ones that match the specified criteria.
      -
      message-sift
      -
      The server enables the client to sift all &MESSAGE; stanzas or ones that match the specified criteria.
      -
      presence-sift
      +
      The server enables the client to sift all &IQ; stanzas or ones that match the specified criteria.
       +
      message-sift
      +
      The server enables the client to sift all &MESSAGE; stanzas or ones that match the specified criteria.
       +
      presence-sift
      The server enables the client to sift all &PRESENCE; stanzas or ones that match the specified criteria.
      @@ -175,14 +175,14 @@
      all
      -
      The server shall sift this kind of stanza no matter who the sender is. This is the default.
      -
      local
      -
      The server shall sift this kind of stanza only from entities associated with the same local domain as the user itself (not from remote domains).
      -
      others
      -
      The server shall sift this kind of stanza only from other entities (not from the user itself).
      -
      remote
      -
      The server shall sift this kind of stanza only from entities associated with remote domains (not from the same local domain as the user itself).
      -
      self
      +
      The server shall sift this kind of stanza no matter who the sender is. This is the default.
       +
      local
      +
      The server shall sift this kind of stanza only from entities associated with the same local domain as the user itself (not from remote domains).
       +
      others
      +
      The server shall sift this kind of stanza only from other entities (not from the user itself).
       +
      remote
      +
      The server shall sift this kind of stanza only from entities associated with remote domains (not from the same local domain as the user itself).
       +
      self
      The server shall sift this kind of stanza only from the user itself (not from other entities).
      @@ -193,10 +193,10 @@
      all
      -
      The server shall sift this kind of stanza if the recipient is the bare JID &LOCALBARE; of the user or the full JID &LOCALFULL; of the particular resource. This is the default.
      -
      bare
      -
      The server shall sift this kind of stanza only if the recipient is the bare JID &LOCALBARE; of the user.
      -
      full
      +
      The server shall sift this kind of stanza if the recipient is the bare JID &LOCALBARE; of the user or the full JID &LOCALFULL; of the particular resource. This is the default.
       +
      bare
      +
      The server shall sift this kind of stanza only if the recipient is the bare JID &LOCALBARE; of the user.
       +
      full
      The server shall sift this kind of stanza only if the recipient is the full JID &LOCALFULL; of the particular resource.
      diff --git a/inbox/spim.xml b/inbox/spim.xml index 39d1e232..a3279181 100644 --- a/inbox/spim.xml +++ b/inbox/spim.xml @@ -43,14 +43,14 @@ -

      There are various spim protection methods exist in XMPP: &xep0016;, &xep0158;, &xep0191;, &xep0268; and &xep0275;. But they may not be sufficient enough: +

      There are various spim protection methods exist in XMPP: &xep0016;, &xep0158;, &xep0191;, &xep0268; and &xep0275;. But they may not be sufficient enough:

      • &xep0016; and &xep0191; define blocking mechanism only which is not always appropriate.
      • &xep0158; interacts badly with automated software such as gateways.
      • &xep0268; implies trusted network of servers.
      • &xep0275; concentrates on ranking only.
      - Service administrators might want to deploy server-based spim recognition software to fill in the gaps. However, every automated spim recognition suffers from false positives - situations where a stanza incorrectly qualified as spim. To avoid them, a spim filter doesn't block suspicious stanza, but marks it and sends to a client in a regular manner. A client software doesn't need to interrupt a user when processing such marked stanzas: for example, it may put them silently in "SPAM" folder, so a user can look through them at any time later. Furthermore, a spim filter may take user's experience into account. When a user receives an unsolicited stanza, he or she can mark it as spim. In this case a client software sends an automatic complaint to a server-based spim filter. This specification deals with both cases. Thus, in contrast to &xep0159;, it doesn't introduce any spim blocking techniques. Also, the various spim recognition procedures that may be employed by the server are beyond the scope of this document. +

      Service administrators might want to deploy server-based spim recognition software to fill in the gaps. However, every automated spim recognition suffers from false positives - situations where a stanza incorrectly qualified as spim. To avoid them, a spim filter doesn't block suspicious stanza, but marks it and sends to a client in a regular manner. A client software doesn't need to interrupt a user when processing such marked stanzas: for example, it may put them silently in "SPAM" folder, so a user can look through them at any time later. Furthermore, a spim filter may take user's experience into account. When a user receives an unsolicited stanza, he or she can mark it as spim. In this case a client software sends an automatic complaint to a server-based spim filter. This specification deals with both cases. Thus, in contrast to &xep0159;, it doesn't introduce any spim blocking techniques. Also, the various spim recognition procedures that may be employed by the server are beyond the scope of this document.

      @@ -143,13 +143,12 @@

      A filtering entity SHOULD only add <mark/> or <report/> elements and a receiving entity SHOULD only process those elements if the corresponding stanza envolves an interaction with a human user: subscription requests, messages, conference invites, voice calls, etc. For example, it doesn't make a lot of sense to mark &xep0232; stanzas.

      -

      To avoid obvious false positives and user confusions, a filtering entity SHOULD NOT add <mark/> or <report/> elements to a stanza and a receiving entity SHOULD ignore <mark/> and <report/> elements of a stanza if: +

      To avoid obvious false positives and user confusions, a filtering entity SHOULD NOT add <mark/> or <report/> elements to a stanza and a receiving entity SHOULD ignore <mark/> and <report/> elements of a stanza if:

      • The receiving entity has the sender's subscription information of the type "both", "from" or "to".
      • The receiving entity has pending subscription to the sender, i.e. subscription of type "none" and ask='subscribe'.
      • The receiving entity has sent direct presence to the sender.
      -

      If an entity supports the spim markers, it MUST report that by including a service discovery feature of "urn:xmpp:spim-marker:0" in response to a &xep0030; information request. If an entity supports the spim reports, it MUST report that by including a service discovery feature of "urn:xmpp:spim-report:0" in response to a &xep0030; information request:

      diff --git a/inbox/sxe.xml b/inbox/sxe.xml index ec3885ee..f19c3b11 100644 --- a/inbox/sxe.xml +++ b/inbox/sxe.xml @@ -12,6 +12,7 @@ xxxx ProtoXEP Standards Track + Standards Council XMPP Core @@ -1041,4 +1042,3 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"       - diff --git a/inbox/tictactoe-mug.xml b/inbox/tictactoe-mug.xml index 92459775..97f3a8f7 100644 --- a/inbox/tictactoe-mug.xml +++ b/inbox/tictactoe-mug.xml @@ -18,6 +18,7 @@ xxxx ProtoXEP Standards Track + Standards Council XMPP Core @@ -263,29 +264,29 @@

      During the game, players change in turn, each of them MUST send only one move at a time. It MUST possess these attributes: - - - - - - - - - - - - - - - - - - - - - -
      NameTypeDescription
      'id'REQUIREDThe number of the move. First move is 1.
      'row'REQUIREDThe horizontal position of the mark.
      'col'REQUIREDThe vertical position of the mark.

      + + + + + + + + + + + + + + + + + + + + + +
      NameTypeDescription
      'id'REQUIREDThe number of the move. First move is 1.
      'row'REQUIREDThe horizontal position of the mark.
      'col'REQUIREDThe vertical position of the mark.
      xxxx ProtoXEP Standards Track + Standards Council XMPP Core @@ -133,29 +134,29 @@ Furthermore, the &MESSAGE; stanza contains a &TURN; element which in turn contains exactly one &MOVE; element qualified by 'http://jabber.org/protocol/games/tictactoe'. It MUST possess these attributes: - - - - - - - - - - - - - - - - - - - - - -
      NameTypeDescription
      'id'REQUIREDThe number of the move. First move is 1.
      'row'REQUIREDThe horizontal position of the mark.
      'col'REQUIREDThe vertical position of the mark.

      + + + + + + + + + + + + + + + + + + + + + +
      NameTypeDescription
      'id'REQUIREDThe number of the move. First move is 1.
      'row'REQUIREDThe horizontal position of the mark.
      'col'REQUIREDThe vertical position of the mark.
      -SkkdJi88C())oo +

      @@ -164,8 +164,8 @@

      Note: The text that follows assumes that implementors have - read and understood XEP-0050, password - generation algorithms described in &rfc4226; and RFC 6238, + read and understood &xep0050;, password + generation algorithms described in &rfc4226; and &rfc6238;, and randomness requirements described in &rfc4086;, and know about one-time pads and perfect secrecy.

      @@ -173,8 +173,8 @@

      Time-Based One-Time Password (TOTP) algorithm described in - RFC 6238 is an extension of the HMAC-based - One-Time Password (HOTP) algorithm defined in RFC 4226, + &rfc6238; is an extension of the HMAC-based + One-Time Password (HOTP) algorithm defined in &rfc4226;, to support the time-based moving factor. In TOTP, time reference and a time step replaces the counter in the HOTP computation. @@ -431,14 +431,14 @@

    - In each case, the Verifier MAY check Prover's JID right after +

    In each case, the Verifier MAY check Prover's JID right after receiving the first Ad-Hoc command or after a succesful verification - process. + process.

    - If Prover's JID is not approved, the Verifier SHOULD - reply with &forbidden; error message. +

    If Prover's JID is not approved, the Verifier SHOULD + reply with &forbidden; error message.

    - After the a succesful verification the Verifier can, e.g., +

    After the a succesful verification the Verifier can, e.g.,

    • start the wanted process,
    • ask access rights from additional provision servers, diff --git a/inbox/userrating.xml b/inbox/userrating.xml index 3376dbaf..edd6eb9e 100644 --- a/inbox/userrating.xml +++ b/inbox/userrating.xml @@ -55,7 +55,7 @@ - A user may obtain their own rating by sending an IQ-get with no to address and an element qualified by the ‘rating’ namespace. +

      A user may obtain their own rating by sending an IQ-get with no to address and an element qualified by the ‘rating’ namespace.

      ]]> - The server should return an IQ result stanza with element: +

      The server should return an IQ result stanza with <rating/> element:

      ]]>       - - In installations that run as chat servers, moderation of spam users can be delivered to online users and administrators. Users receiving spam from a bare JID can send an IQ stanza to the server that increases the user rating. + +

      In installations that run as chat servers, moderation of spam users can be delivered to online users and administrators. Users receiving spam from a bare JID can send an IQ stanza to the server that increases the user rating.

      JIDs that are critical to server functionality or admins should have a - permanent of -100 to indicate that they are protected. Should a + permanent <rating/> of -100 to indicate that they are protected. Should a user attempt to report a protected user, the server should send the following:

      @@ -178,7 +178,7 @@ XEP-0191 Blocking Command, or an internal implementation to prevent communication from known spammer accounts.

      -       +

      OPTIONAL.

      diff --git a/inbox/xep.dtd b/inbox/xep.dtd new file mode 120000 index 00000000..9d3e4e98 --- /dev/null +++ b/inbox/xep.dtd @@ -0,0 +1 @@ +../xep.dtd \ No newline at end of file diff --git a/inbox/xep.ent b/inbox/xep.ent new file mode 120000 index 00000000..bf005c84 --- /dev/null +++ b/inbox/xep.ent @@ -0,0 +1 @@ +../xep.ent \ No newline at end of file diff --git a/inbox/xtls.xml b/inbox/xtls.xml index 985b6b05..6ed9c808 100644 --- a/inbox/xtls.xml +++ b/inbox/xtls.xml @@ -1,6 +1,7 @@ + rfc3920bis RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-ietf-saintandre-rfc3920bis>." > %ents; ]> From 609a081f273d4d2b7c9e074bebc8c7b951242b54 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Wed, 23 Aug 2017 13:22:06 +0200 Subject: [PATCH 44/54] Add build for inbox/ --- Dockerfile | 3 ++- Makefile | 45 +++++++++++++++++++++++++++++++++++++++------ xep.xsl | 1 + 3 files changed, 42 insertions(+), 7 deletions(-) diff --git a/Dockerfile b/Dockerfile index 1b529dbb..29af9e94 100644 --- a/Dockerfile +++ b/Dockerfile @@ -4,10 +4,11 @@ FROM xmppxsf/xeps-base:latest ARG NCORES=1 -ARG TARGETS="html pdf" +ARG TARGETS="html inbox-html inbox-xml pdf" COPY *.xml xep.* *.css *.xsl *.js *.xsl Makefile /src/ COPY resources/*.pdf /src/resources/ +COPY inbox/*.xml inbox/*.ent inbox/*.dtd /src/inbox/ WORKDIR /src RUN OUTDIR=/var/www/html/extensions/ make -j$NCORES $TARGETS diff --git a/Makefile b/Makefile index 8c9773b9..cbd03489 100644 --- a/Makefile +++ b/Makefile @@ -12,6 +12,22 @@ JSTARGETS=$(OUTDIR)/prettify.js DO_XELATEX=cd $(OUTDIR); xelatex --interaction=nonstopmode -no-shell-escape "$(notdir $(basename $@)).tex" >/dev/null +xeps=$(wildcard *.xml) +proto_xeps=$(wildcard inbox/*.xml) +all_xeps=$(xeps) $(proto_xeps) + +xep_xmls=$(patsubst %.xml,$(OUTDIR)/%.xml,$(xeps)) +proto_xep_xmls=$(patsubst %.xml,$(OUTDIR)/%.xml,$(proto_xeps)) +all_xep_xmls=$(xep_xmls) $(proto_xep_xmls) + +xep_htmls=$(patsubst %.xml,$(OUTDIR)/%.html,$(xeps)) +proto_xep_htmls=$(patsubst %.xml,$(OUTDIR)/%.html,$(proto_xeps)) +all_xep_htmls=$(xep_htmls) $(proto_xep_htmls) + +xep_pdfs=$(patsubst %.xml,$(OUTDIR)/%.pdf,$(xeps)) +xep_refs=$(patsubst xep-%.xml, $(REFSDIR)/reference.XSF.XEP-%.xml, $(xeps)) +xep_examples=$(patsubst xep-%.xml, $(EXAMPLESDIR)/%.xml, $(xeps)) + .PHONY: help help: @@ -33,17 +49,30 @@ help: .PHONY: all all: html +$(OUTDIR)/inbox/%: build/inbox +build/inbox: + mkdir -p build/inbox + .PHONY: html -html: $(patsubst %.xml, $(OUTDIR)/%.html, $(wildcard *.xml)) +html: $(xep_htmls) + +.PHONY: xml +xml: $(xep_xmls) + +.PHONY: inbox-html +inbox-html: $(proto_xep_htmls) + +.PHONY: inbox-xml +inbox-xml: $(proto_xep_xmls) .PHONY: pdf -pdf: $(patsubst %.xml, $(OUTDIR)/%.pdf, $(wildcard *.xml)) +pdf: $(xep_pdfs) .PHONY: refs -refs: $(patsubst xep-%.xml, $(REFSDIR)/reference.XSF.XEP-%.xml, $(wildcard *.xml)) +refs: $(xep_refs) .PHONY: examples -examples: $(patsubst xep-%.xml, $(EXAMPLESDIR)/%.xml, $(wildcard *.xml)) +examples: $(xep_examples) .PHONY: xep-% xep-%: $(OUTDIR)/xep-%.html $(REFSDIR)/reference.XSF.XEP-%.xml $(OUTDIR)/xep-%.pdf $(EXAMPLESDIR)/%.xml; @@ -54,19 +83,23 @@ xep-%.html: $(OUTDIR)/xep-%.html ; .PHONY: xep-%.pdf xep-%.pdf: $(OUTDIR)/xep-%.pdf ; +$(all_xep_xmls): $(OUTDIR)/%.xml: %.xml + cp $< $@ + $(EXAMPLESDIR)/%.xml: xep-%.xml $(XMLDEPS) examples.xsl $(EXAMPLESDIR) xsltproc --path $(CURDIR) examples.xsl "$<" > "$@" && echo "Finished building $@" $(REFSDIR)/reference.XSF.XEP-%.xml: xep-%.xml $(XMLDEPS) ref.xsl $(REFSDIR) xsltproc --path $(CURDIR) ref.xsl "$<" > "$@" && echo "Finished building $@" -$(OUTDIR)/%.html: %.xml $(XMLDEPS) $(HTMLDEPS) +$(all_xep_htmls): $(OUTDIR)/%.html: %.xml $(XMLDEPS) $(HTMLDEPS) + mkdir -p $(OUTDIR)/inbox xmllint --nonet --noout --noent --loaddtd --valid "$<" # Check for non-data URIs ! xmllint --nonet --noout --noent --loaddtd --xpath "//img/@src[not(starts-with(., 'data:'))]" $< 2>/dev/null && true # Actually build the HTML - xsltproc --path $(CURDIR) xep.xsl "$<" > "$@" && echo "Finished building $@" + xsltproc --path $(CURDIR) --param htmlbase "$(if $(findstring inbox,$<),'../','./')" xep.xsl "$<" > "$@" && echo "Finished building $@" $(OUTDIR)/xmpp.pdf $(OUTDIR)/xmpp-text.pdf: $(OUTDIR) cp "resources/$(notdir $@)" "$@" diff --git a/xep.xsl b/xep.xsl index 5d6b2c5f..7e8c38dc 100644 --- a/xep.xsl +++ b/xep.xsl @@ -40,6 +40,7 @@ OR OTHER DEALINGS IN THE SOFTWARE. XEP-<xsl:value-of select='/xep/header/number'/>:<xsl:text> </xsl:text><xsl:value-of select='/xep/header/title' /> + From aea6f78a1a43b769c93a4978c46260e0960a55e3 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Wed, 23 Aug 2017 13:26:36 +0200 Subject: [PATCH 45/54] Generate xeplist on Docker build --- Dockerfile | 3 ++- Makefile | 6 ++++++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/Dockerfile b/Dockerfile index 29af9e94..f0c22cf7 100644 --- a/Dockerfile +++ b/Dockerfile @@ -4,10 +4,11 @@ FROM xmppxsf/xeps-base:latest ARG NCORES=1 -ARG TARGETS="html inbox-html inbox-xml pdf" +ARG TARGETS="html inbox-html inbox-xml pdf xeplist" COPY *.xml xep.* *.css *.xsl *.js *.xsl Makefile /src/ COPY resources/*.pdf /src/resources/ +COPY tools/*.py /src/tools/ COPY inbox/*.xml inbox/*.ent inbox/*.dtd /src/inbox/ WORKDIR /src diff --git a/Makefile b/Makefile index cbd03489..ee7985b6 100644 --- a/Makefile +++ b/Makefile @@ -53,6 +53,9 @@ $(OUTDIR)/inbox/%: build/inbox build/inbox: mkdir -p build/inbox +.PHONY: xeplist +xeplist: $(OUTDIR)/xeplist.xml + .PHONY: html html: $(xep_htmls) @@ -86,6 +89,9 @@ xep-%.pdf: $(OUTDIR)/xep-%.pdf ; $(all_xep_xmls): $(OUTDIR)/%.xml: %.xml cp $< $@ +$(OUTDIR)/xeplist.xml: $(wildcard *.xml) $(wildcard inbox/*.xml) + ./tools/extract-metadata.py > $@ + $(EXAMPLESDIR)/%.xml: xep-%.xml $(XMLDEPS) examples.xsl $(EXAMPLESDIR) xsltproc --path $(CURDIR) examples.xsl "$<" > "$@" && echo "Finished building $@" From 8d32a212a8b399018d4abc85203f2ca1b061cf05 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Wed, 23 Aug 2017 13:30:21 +0200 Subject: [PATCH 46/54] Remove obsolete tools --- all.sh | 56 ------- announce.py | 196 ------------------------ gen.py | 432 ---------------------------------------------------- inxep.py | 145 ------------------ 4 files changed, 829 deletions(-) delete mode 100755 all.sh delete mode 100755 announce.py delete mode 100755 gen.py delete mode 100755 inxep.py diff --git a/all.sh b/all.sh deleted file mode 100755 index 11a2a45c..00000000 --- a/all.sh +++ /dev/null @@ -1,56 +0,0 @@ -#!/bin/sh -# for all XEPs, generates HTML files and IETF-style reference, then copies XML file -# usage: ./all.sh - -## LICENSE ## -# -# Copyright (c) 1999 - 2013 XMPP Standards Foundation -# -# Permission is hereby granted, free of charge, to any person obtaining a copy -# of this software and associated documentation files (the "Software"), to deal -# in the Software without restriction, including without limitation the rights -# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell -# copies of the Software, and to permit persons to whom the Software is -# furnished to do so, subject to the following conditions: -# -# The above copyright notice and this permission notice shall be included in -# all copies or substantial portions of the Software. -# -# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR -# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, -# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE -# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER -# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, -# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN -# THE SOFTWARE. -# -## END LICENSE ## - -xeppath=/var/www/vhosts/xmpp.org/extensions - -ls xep-0*.xml > tmp1.txt -sed s/^xep-// tmp1.txt > tmp2.txt -sed s/.xml$// tmp2.txt > nums.txt -rm tmp*.txt - -while read f -do - xsltproc xep.xsl xep-$f.xml > $xeppath/xep-$f.html - xsltproc ref.xsl xep-$f.xml > $xeppath/refs/reference.XSF.XEP-$f.xml - xsltproc examples.xsl xep-$f.xml > $xeppath/examples/$f.xml - ./gen.py $f - cp xep-$f.xml $xeppath/ - ./gen.py $f -done < nums.txt - -rm nums.txt - -xsltproc xep.xsl xep-README.xml > $xeppath/README.html -xsltproc xep.xsl xep-template.xml > $xeppath/template.html - -cp *.dtd $xeppath/ -cp *.ent $xeppath/ -cp *.shtml $xeppath/ -cp *.xsd $xeppath/ - -# END diff --git a/announce.py b/announce.py deleted file mode 100755 index 14eb061b..00000000 --- a/announce.py +++ /dev/null @@ -1,196 +0,0 @@ -#!/usr/bin/env python - -# File: announce.py -# Version: 0.9 -# Description: a script for announcing XEPs -# Last Modified: 2016-10-03 -# Author: Peter Saint-Andre (stpeter@jabber.org) -# License: public domain -# HowTo: ./announce.py xepnum - -## LICENSE ## -# -# Copyright (c) 1999 - 2010 XMPP Standards Foundation -# -# Permission is hereby granted, free of charge, to any person obtaining a copy -# of this software and associated documentation files (the "Software"), to deal -# in the Software without restriction, including without limitation the rights -# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell -# copies of the Software, and to permit persons to whom the Software is -# furnished to do so, subject to the following conditions: -# -# The above copyright notice and this permission notice shall be included in -# all copies or substantial portions of the Software. -# -# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR -# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, -# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE -# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER -# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, -# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN -# THE SOFTWARE. -# -## END LICENSE ## - -# IMPORTS: -# -import glob -import os -from select import select -import smtplib -import socket -from string import split,strip,join,find -import sys -import time -from xml.dom.minidom import parse,parseString,Document - -def getText(nodelist): - thisText = "" - for node in nodelist: - if node.nodeType == node.TEXT_NODE: - thisText = thisText + node.data - return thisText - -# get the seconds in the Unix era -now = int(time.time()) - -# READ IN ARGS: -# -# 1. XEP number - -xepnum = sys.argv[1]; - -xepfile = 'xep-' + xepnum + '.xml' - -# PARSE XEP HEADERS: -# -# - title -# - abstract -# - version -# - date -# - initials -# - remark - -thexep = parse(xepfile) -xepNode = (thexep.getElementsByTagName("xep")[0]) -headerNode = (xepNode.getElementsByTagName("header")[0]) -titleNode = (headerNode.getElementsByTagName("title")[0]) -title = getText(titleNode.childNodes) -abstractNode = (headerNode.getElementsByTagName("abstract")[0]) -abstract = getText(abstractNode.childNodes) -statusNode = (headerNode.getElementsByTagName("status")[0]) -xepstatus = getText(statusNode.childNodes) -typeNode = (headerNode.getElementsByTagName("type")[0]) -xeptype = getText(typeNode.childNodes) -revNodes = headerNode.getElementsByTagName("revision") -revNode = revNodes[0] -versionNode = (revNode.getElementsByTagName("version")[0]) -version = getText(versionNode.childNodes) -dateNode = (revNode.getElementsByTagName("date")[0]) -date = getText(dateNode.childNodes) -initialsNode = (revNode.getElementsByTagName("initials")[0]) -initials = getText(initialsNode.childNodes) -remNode = (revNode.getElementsByTagName("remark")[0]) -# could be

      or

        -testRemarkNode = remNode.firstChild.nodeName -# print testRemarkNode -if (testRemarkNode == "p"): - remarkNode = (remNode.getElementsByTagName("p")[0]) - remark = getText(remarkNode.childNodes) -else: - remark = "[See revision history]" - -# what kind of action are we taking? -xepflag = "" -if (version == "0.1" or version == "0.1.0"): - xepflag = "new" -elif ((version == "1.0" or version == "1.0.0") and xeptype == "Standards Track"): - xepflag = "draft" -elif ((version == "1.0" or version == "1.0.0") and xeptype != "Standards Track"): - xepflag = "active" -elif (version == "2.0" or version == "2.0.0"): - xepflag = "final" -elif (xepstatus == "Retracted"): - xepflag = "retract" -elif (xepstatus == "Deprecated"): - xepflag = "deprecate" -elif (xepstatus == "Obsolete"): - xepflag = "obsolete" -elif (xepstatus == "Deferred"): - xepflag = "defer" - -# generate the diffs URL -if len(revNodes) > 1: - prevRevNode = revNodes[1] - prevVersionNode = (prevRevNode.getElementsByTagName("version")[0]) - prevVersion = getText(prevVersionNode.childNodes) - diffs = 'https://xmpp.org/extensions/diff/api/xep/' + xepnum + '/diff/' + prevVersion + '/vs/' + version -else: - diffs = 'N/A' - -## SEND MAIL: -# -# From: editor@xmpp.org -# To: standards@xmpp.org -# Subject: UPDATED: XEP-$xepnum ($title) -# [or "NEW..." if version 0.1] -# Body: -# Version $version of XEP-$xepnum ($title) is now available. -# Abstract: $abstract -# Changelog: $remark ($initials) -# Diff: $diffs ### no longer in use -# URL: https://xmpp.org/extensions/xep-$xepnum.html - -fromaddr = "editor@xmpp.org" -# for testing... -# toaddrs = "stpeter@jabber.org" -# for real... -toaddrs = "standards@xmpp.org" - -if xepflag == "new": - thesubject = 'NEW: XEP-' -elif xepflag == "draft": - thesubject = 'DRAFT: XEP-' -elif xepflag == "final": - thesubject = 'FINAL: XEP-' -elif xepflag == "active": - thesubject = 'ACTIVE: XEP-' -elif xepflag == "retract": - thesubject = 'RETRACTED: XEP-' -elif xepflag == "deprecate": - thesubject = 'DEPRECATED: XEP-' -elif xepflag == "obsolete": - thesubject = 'OBSOLETE: XEP-' -elif xepflag == "defer": - thesubject = 'DEFERRED: XEP-' -else: - thesubject = 'UPDATED: XEP-' -thesubject = thesubject + xepnum + ' (' + title + ')' - -versionline = 'Version ' + version + ' of XEP-' + xepnum + ' (' + title + ') has been released.' -abstractline = 'Abstract: ' + abstract -changelogline = 'Changelog: ' + remark + ' (' + initials + ')' -diffsline = 'Diff: ' + diffs -urlline = 'URL: https://xmpp.org/extensions/xep-' + xepnum + '.html' - -msg = "From: XMPP Extensions Editor <%s>\r\n" % fromaddr -msg = msg + "To: %s\r\n" % toaddrs -msg = msg + "Subject: %s\r\n" % thesubject -msg = msg + versionline -msg = msg + "\r\n\n" -msg = msg + abstractline -msg = msg + "\r\n\n" -msg = msg + changelogline -msg = msg + "\r\n\n" -msg = msg + diffsline -msg = msg + "\r\n\n" -msg = msg + urlline -msg = msg + "\r\n\n" - -server = smtplib.SMTP('localhost') -server.set_debuglevel(1) -server.sendmail(fromaddr, toaddrs, msg) -server.quit() - -# END - diff --git a/gen.py b/gen.py deleted file mode 100755 index efab8ef2..00000000 --- a/gen.py +++ /dev/null @@ -1,432 +0,0 @@ -#!/usr/bin/env python - -# File: gen.py -# Version: 0.2 -# Description: a renewed XEP compilation tool -# Last Modified: 2009 -# Author: Tobias Markmann (tm@ayena.de) -# HowTo: ./gen.py xep-####.xml - -## LICENSE ## -# -# Copyright (c) 1999 - 2010 XMPP Standards Foundation -# -# Permission is hereby granted, free of charge, to any person obtaining a copy -# of this software and associated documentation files (the "Software"), to deal -# in the Software without restriction, including without limitation the rights -# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell -# copies of the Software, and to permit persons to whom the Software is -# furnished to do so, subject to the following conditions: -# -# The above copyright notice and this permission notice shall be included in -# all copies or substantial portions of the Software. -# -# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR -# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, -# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE -# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER -# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, -# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN -# THE SOFTWARE. -# -## END LICENSE ## - -import pickle -import commands -import os -import re -import sys -import getopt -import glob -import tempfile - -from xepinfo import XEPInfo -from xeputil import getLatestXEPFilename - -from xml.dom.minidom import parse,parseString,Document,getDOMImplementation - -# for serializing inline images -import base64 -import urlparse -import urllib - -XEPPATH = "/var/www/vhosts/xmpp.org/extensions" -CONFIGPATH = "/var/local/xsf" - -verbose = False -fast = False -last_build = {} - -files_to_delete = []; - -def serializeInlineImage(output_dir, xep_nr, no, attrValue): - up = urlparse.urlparse(attrValue) - if up.scheme == 'data': - head, data = up.path.split(',') - bits = head.split(';') - mime_type = bits[0] if bits[0] else 'text/plain' - charset, b64 = 'ASCII', False - for bit in bits[1]: - if bit.startswith('charset='): - charset = bit[8:] - elif bit == 'base64': - b64 = True - - # Do something smart with charset and b64 instead of assuming - plaindata = base64.b64decode(data) - - # Do something smart with mime_type - if mime_type in ('image/png', 'image/jpeg'): - file_ext = mime_type.split('/')[1] - f = open(output_dir + '/' + 'inlineimage-' + xep_nr + '-' + str(no) + '.' + file_ext, 'wb') - f.write(plaindata) - elif up.scheme == 'http': - file_name, file_ext = os.path.splitext(up.path) - urllib.urlretrieve(attrValue, output_dir + '/' + 'inlineimage-' + xep_nr + '-' + str(no) + file_ext) - -def serializeXEPInlineImages(output_dir, xep_nr, filename): - dom = parse(filename) - imgs = dom.getElementsByTagName('img') - for (no, img) in enumerate(imgs): - serializeInlineImage(output_dir, xep_nr, no, img.attributes["src"].value) - -def getText(nodelist): - thisText = "" - for node in nodelist: - if node.nodeType == node.TEXT_NODE: - thisText = thisText + node.data - return thisText - -def executeCommand( cmd ): - error, desc = commands.getstatusoutput( cmd ) - return error, desc + "\n" + "executed cmd: " + cmd - -## creates a HTML table (for the human reader) and XML table (for bots) -class XEPTable: - def __init__(self, filename, shortXMLfilename): - self.filename = filename - self.shortXMLfilename = shortXMLfilename - - try: - self.tableFile = parse(filename) - except: - impl = getDOMImplementation() - self.tableFile = impl.createDocument(None, "table", None) - self.tableFile.getElementsByTagName("table")[0].setAttribute("class", "sortable") - self.tableFile.getElementsByTagName("table")[0].setAttribute("id", "xeplist") - self.tableFile.getElementsByTagName("table")[0].setAttribute("cellspacing", "0") - self.tableFile.getElementsByTagName("table")[0].setAttribute("cellpadding", "3") - self.tableFile.getElementsByTagName("table")[0].setAttribute("border", "1") - - header = parseString( -''' - Number - Name - Type - Status - Date -''') - self.tableFile.getElementsByTagName("table")[0].appendChild(header.getElementsByTagName("tr")[0]) - - try: - self.botsFile = parse(shortXMLfilename) - except: - impl = getDOMImplementation() - self.botsFile = impl.createDocument(None, "xeps", None) - - def save(self): - f = open(self.filename, "wb") - self.tableFile.getElementsByTagName("table")[0].normalize() - f.write(self.tableFile.toxml()) - f.close() - - f = open(self.shortXMLfilename, "wb") - self.botsFile.getElementsByTagName("xeps")[0].normalize() - f.write(self.botsFile.toxml()) - f.close() - - def setXEP(self, info): - ## set for HTML table - rows = self.tableFile.getElementsByTagName("tr") - xeprow = 0 - for row in rows: - if row.getAttribute("id") == "xep" + info.getNr(): - xeprow = row - break - - if xeprow == 0: - xeprow = self.tableFile.createElement("tr") - self.tableFile.getElementsByTagName("table")[0].appendChild(xeprow) - self.tableFile.getElementsByTagName("table")[0].appendChild(self.tableFile.createTextNode(''' -''')) - xeprow.setAttribute("id", "xep" + info.getNr()) - xeprow.setAttribute("class", "tablebody XEP-" + info.getStatus()) - else: - xeprow.setAttribute("class", "tablebody XEP-" + info.getStatus()) - while(xeprow.hasChildNodes()): - xeprow.removeChild(xeprow.firstChild) - - col = parseString('''XEP-" + info.getNr() + ''' (PDF)''') - xeprow.appendChild(col.getElementsByTagName("td")[0]) - - col = parseString("" + info.getTitle() + "") - xeprow.appendChild(col.getElementsByTagName("td")[0]) - - col = parseString("" + info.getType() + "") - xeprow.appendChild(col.getElementsByTagName("td")[0]) - - col = parseString("" + info.getStatus() + "") - xeprow.appendChild(col.getElementsByTagName("td")[0]) - - col = parseString("" + info.getDate() + "") - xeprow.appendChild(col.getElementsByTagName("td")[0]) - - ## set for bots file - xeps = self.botsFile.getElementsByTagName("xep") - xep = 0 - for xeps_xep in xeps: - if xeps_xep.getElementsByTagName("number")[0].firstChild.data == info.getNr(): - xep = xeps_xep - break - - if xep == 0: - xep = self.botsFile.createElement("xep") - self.botsFile.getElementsByTagName("xeps")[0].appendChild(xep) - self.botsFile.getElementsByTagName("xeps")[0].appendChild(self.botsFile.createTextNode(''' -''')) - else: - while(xep.hasChildNodes()): - xep.removeChild(xep.firstChild) - - child = parseString("" + info.getNr() + "") - xep.appendChild(child.getElementsByTagName("number")[0]) - - child = parseString("" + info.getTitle() + "") - xep.appendChild(child.getElementsByTagName("name")[0]) - - child = parseString("" + info.getType() + "") - xep.appendChild(child.getElementsByTagName("type")[0]) - - child = parseString("" + info.getStatus() + "") - xep.appendChild(child.getElementsByTagName("status")[0]) - - child = parseString("" + info.getDate() + "") - xep.appendChild(child.getElementsByTagName("updated")[0]) - - child = parseString("" + info.getShortname() + "") - xep.appendChild(child.getElementsByTagName("shortname")[0]) - - child = parseString("" + info.getAbstract() + "") - xep.appendChild(child.getElementsByTagName("abstract")[0]) - -def filebase( filename ): - return os.path.splitext(os.path.basename(filename))[0] - - -def checkError( error, desc): - global verbose - - if error != 0: - if verbose: - print "Error: ", desc - return False - return True - -def fileHash( filename ): - f = open(filename, "rb") - import hashlib - h = hashlib.sha1() - h.update(f.read()) - hash = h.hexdigest() - f.close() - return hash - -def loadDict( filename ): - try: - f = open(filename, "rb") - di = pickle.load(f) - f.close() - return di - except: - print "failed loading dict." - return {} - -def saveDict( filename, di ): - f = open(filename, "w") - pickle.dump(di, f) - f.close() - -def buildXHTML( file, nr ): - error, desc = executeCommand("xsltproc xep.xsl " + file + " > " + XEPPATH + "/xep-" + nr + ".html") - if not checkError(error, desc): - return False - - error, desc = executeCommand("xsltproc ref.xsl xep-" + nr + ".xml > " + XEPPATH + "/refs/reference.XSF.XEP-" + nr + ".xml") - if not checkError(error, desc): - return False - - error, desc = executeCommand("xsltproc examples.xsl xep-" + nr + ".xml > " + XEPPATH + "/examples/" + nr + ".xml") - if not checkError(error, desc): - return False - - error, desc = executeCommand(" cp xep-" + nr + ".xml " + XEPPATH + "/") - if not checkError(error, desc): - return False - return True - -def buildPDF( file, nr ): - serializeXEPInlineImages("/tmp/xepbuilder", nr, file) - - error, desc = executeCommand("xsltproc -o /tmp/xepbuilder/xep-" + nr + ".tex.xml xep2texml.xsl " + file) - if not checkError(error, desc): - return False - - error, desc = executeCommand("texml -e utf8 /tmp/xepbuilder/xep-" + nr + ".tex.xml /tmp/xepbuilder/xep-" + nr + ".tex") - if not checkError(error, desc): - return False - - #detect http urls and escape them to make them breakable - # this should match all urls in free text; not the urls in xml:ns or so..so no " or ' in front. - error, desc = executeCommand('''sed -i 's|\([\s"]\)\([^"]http://[^ "]*\)|\1\\path{\2}|g' /tmp/xepbuilder/xep-''' + nr + ".tex") - if not checkError(error, desc): - return False - - #adjust references - error, desc = executeCommand('''sed -i 's|\\hyperref\[#\([^}]*\)\]|\\hyperref\[\1\]|g' /tmp/xepbuilder/xep-''' + nr + ".tex") - if error != 0: - if verbose == 1: - print "Error: ", desc - return False - - error, desc = executeCommand('''sed -i 's|\\pageref{#\([^}]*\)}|\\pageref{\1}|g' /tmp/xepbuilder/xep-''' + nr + ".tex") - if not checkError(error, desc): - return False - - olddir = os.getcwd() - os.chdir("/tmp/xepbuilder") - - error, desc = executeCommand("xelatex -interaction=batchmode xep-" + nr + ".tex") - #if not checkError(error, desc): - # os.chdir(olddir) - # return False - - #error, desc = executeCommand("xelatex -interaction=batchmode xep-" + nr + ".tex") - #if not checkError(error, desc): - # os.chdir(olddir) - # return False - - os.chdir(olddir) - - error, desc = executeCommand("cp /tmp/xepbuilder/xep-" + nr + ".pdf " + XEPPATH + "/") - if not checkError(error, desc): - return False - - return True - -def buildXEP( filename ): - nr = re.match("xep-(\d\d\d\d).xml", filename).group(1) - xepfilepath = getLatestXEPFilename("./", nr); - if not xepfilepath: - print "getLatestXEPContent (ERROR)" - return - - files_to_delete.append(xepfilepath) - if not fast: - print "Building " + filename + ": ", - if buildXHTML( xepfilepath, nr ): - print "XHTML(OK) / ", - else: - print "XHTML(ERROR) / ", - - if buildPDF( xepfilepath, nr ): - print "PDF(OK)" - else: - print "PDF(ERROR)" - else: - print "Building " + filename + " (FAST MODE)" - - x = XEPTable(CONFIGPATH + "/extensions.xml", XEPPATH + "/xeps.xml") - xinfo = XEPInfo(xepfilepath, False) - x.setXEP( xinfo ) - x.save() - -def buildAll(): - files = glob.glob('xep-????.xml') - files.sort(key=lambda x: x.lower()) - for file in files: - buildXEP( file ) - -def makeBundle(): - print "Creating the bundle...", - executeCommand("mkdir /tmp/xepbundle") - executeCommand("cp " + XEPPATH + "/*.pdf " + "/tmp/xepbundle") - executeCommand("tar -cf /tmp/xepbundle.tar -C /tmp xepbundle") - executeCommand("pbzip2 -f -9 /tmp/xepbundle.tar") - executeCommand("mv -f /tmp/xepbundle.tar.bz2 " + XEPPATH + "/xepbundle.tar.bz2") - executeCommand("rm -rfd /tmp/xepbundle") - print "DONE" - -def usage(): - print "gen.py: generate nice XHTML and beautiful PDF out of the XEP XML files" - print "" - print "Usage:" - print "gen.py xep-####.xml" - print "" - print "Options:" - print "-v Enable verbose output for debugging." - print "-a Build all available XEPs." - print "-f Fast; means no actual compiling is done." - -def main(argv): - global verbose - global CONFIGPATH - global fast - buildall = False - - try: - options, remainder = getopt.gnu_getopt(argv, "vaf") - except getopt.GetoptError: - usage() - sys.exit(2) - - for opt, arg in options: - if opt in ('-v'): - verbose = True - elif opt in ('-a'): - buildall = True - elif opt in ('-f'): - fast = True - - if len(remainder) > 0: - try: - xep = int(remainder[0]) - xep = "xep-%04d.xml" % xep - except: - xep = remainder[0] - - executeCommand("mkdir /tmp/xepbuilder") - executeCommand("cp ../images/xmpp.pdf /tmp/xepbuilder/xmpp.pdf") - executeCommand("cp ../images/xmpp-text.pdf /tmp/xepbuilder/xmpp-text.pdf") - executeCommand("cp -r deps/* /tmp/xepbuilder/") - - executeCommand("cp xep.ent /tmp/xep.ent") - files_to_delete.append("/tmp/xep.ent") - - if buildall: - buildAll() - else: - buildXEP( xep ) - - # remove xep temporary files - for filename in files_to_delete: - executeCommand("rm " + filename) - - executeCommand("sed -e '1s///' " + CONFIGPATH + "/extensions.xml > " + XEPPATH + "/../includes/xeplist.txt") - - executeCommand("rm -rfd /tmp/xepbuilder") - - makeBundle() - - -if __name__ == "__main__": - main(sys.argv[1:]) diff --git a/inxep.py b/inxep.py deleted file mode 100755 index 883b9c5d..00000000 --- a/inxep.py +++ /dev/null @@ -1,145 +0,0 @@ -#!/usr/bin/env python - -# File: inxep.py -# Version: 0.1 -# Description: a script for announcing proto-XEPs -# Last Modified: 2004-09-14 -# Author: Peter Saint-Andre (stpeter@jabber.org) -# License: public domain -# HowTo: ./inxep.py filename approver -# (note: do not include extension!) - -## LICENSE ## -# -# Copyright (c) 1999 - 2010 XMPP Standards Foundation -# -# Permission is hereby granted, free of charge, to any person obtaining a copy -# of this software and associated documentation files (the "Software"), to deal -# in the Software without restriction, including without limitation the rights -# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell -# copies of the Software, and to permit persons to whom the Software is -# furnished to do so, subject to the following conditions: -# -# The above copyright notice and this permission notice shall be included in -# all copies or substantial portions of the Software. -# -# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR -# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, -# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE -# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER -# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, -# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN -# THE SOFTWARE. -# -## END LICENSE ## - -# IMPORTS: -# -import glob -import os -from select import select -import smtplib -import socket -from string import split,strip,join,find -import sys -import time -from xml.dom.minidom import parse,parseString,Document - -def getText(nodelist): - thisText = "" - for node in nodelist: - if node.nodeType == node.TEXT_NODE: - thisText = thisText + node.data - return thisText - -# READ in XEP filename (sans extension) - -xepname = sys.argv[1]; -if len(sys.argv) >= 3: - approver = sys.argv[2] -else: - approver = "XMPP Council" - -xepfile = 'inbox/' + xepname + '.xml' - -# PARSE XEP HEADERS: -# -# - title -# - abstract -# - version -# - date -# - initials -# - remark - -thexep = parse(xepfile) -xepNode = (thexep.getElementsByTagName("xep")[0]) -headerNode = (xepNode.getElementsByTagName("header")[0]) -titleNode = (headerNode.getElementsByTagName("title")[0]) -title = getText(titleNode.childNodes) -abstractNode = (headerNode.getElementsByTagName("abstract")[0]) -abstract = getText(abstractNode.childNodes) -statusNode = (headerNode.getElementsByTagName("status")[0]) -xepstatus = getText(statusNode.childNodes) -typeNode = (headerNode.getElementsByTagName("type")[0]) -xeptype = getText(typeNode.childNodes) -revNode = (headerNode.getElementsByTagName("revision")[0]) -versionNode = (revNode.getElementsByTagName("version")[0]) -version = getText(versionNode.childNodes) -dateNode = (revNode.getElementsByTagName("date")[0]) -date = getText(dateNode.childNodes) -initialsNode = (revNode.getElementsByTagName("initials")[0]) -initials = getText(initialsNode.childNodes) -remarkNode = (revNode.getElementsByTagName("remark")[0]) -remark = getText(remarkNode.childNodes) - -# SEND MAIL: -# -# From: editor@xmpp.org -# To: standards@xmpp.org -# Subject: Proposed XMPP Extension: XEP-$xepnum ($title) -# Body: -# The XMPP Extensions Editor has received a proposal for a new XEP. -# -# Title: $title -# -# Abstract: $abstract -# -# URL: https://xmpp.org/extensions/inbox/$xepname.html -# -# The $approver will now consider whether to accept -# this proposal as a full XEP. -# - -fromaddr = "editor@xmpp.org" -# for testing... -# toaddrs = "editor@jabber.org" -# for real... -toaddrs = "standards@xmpp.org" - -thesubject = 'Proposed XMPP Extension: ' + title -introline = 'The XMPP Extensions Editor has received a proposal for a new XEP.' -titleline = 'Title: ' + title -abstractline = 'Abstract: ' + abstract -urlline = 'URL: https://xmpp.org/extensions/inbox/' + xepname + '.html' -actionline = 'The ' + approver + ' will decide in the next two weeks whether to accept this proposal as an official XEP.' - -msg = "From: XMPP Extensions Editor <%s>\r\n" % fromaddr -msg = msg + "To: %s\r\n" % toaddrs -msg = msg + "Subject: %s\r\n" % thesubject -msg = msg + introline -msg = msg + "\r\n\n" -msg = msg + titleline -msg = msg + "\r\n\n" -msg = msg + abstractline -msg = msg + "\r\n\n" -msg = msg + urlline -msg = msg + "\r\n\n" -msg = msg + actionline -msg = msg + "\r\n\n" - -server = smtplib.SMTP('localhost') -server.set_debuglevel(1) -server.sendmail(fromaddr, toaddrs, msg) -server.quit() - -# END From 18fbef73b49236a91005744a30f864f81781c235 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Wed, 23 Aug 2017 13:47:09 +0200 Subject: [PATCH 47/54] tooling: refactor commonly used stuff into xeplib.py --- tools/deferrals.py | 57 ++++++++++++++++ tools/extract-metadata.py | 81 +++++++++------------- tools/send-updates.py | 103 +--------------------------- tools/xeplib.py | 138 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 230 insertions(+), 149 deletions(-) create mode 100755 tools/deferrals.py create mode 100644 tools/xeplib.py diff --git a/tools/deferrals.py b/tools/deferrals.py new file mode 100755 index 00000000..6674385c --- /dev/null +++ b/tools/deferrals.py @@ -0,0 +1,57 @@ +#!/usr/bin/env python3 +import xml.etree.ElementTree as etree + +from datetime import datetime, timedelta + +from xeplib import load_xepinfos, Status + + +def get_deferred(accepted): + now = datetime.utcnow().replace(hour=0, minute=0, second=0, microsecond=0) + threshold = now.replace(year=now.year - 1) + + for number, info in sorted(accepted.items()): + if info["status"] == Status.EXPERIMENTAL and "last_revision" in info: + last_update = info["last_revision"]["date"] + if last_update <= threshold: + yield info + + +def main(): + import argparse + + parser = argparse.ArgumentParser( + description="Show the XEPs which need to be changed to deferred." + ) + + parser.add_argument( + "-l", "--xeplist", + type=argparse.FileType("rb"), + default=None, + help="XEP list to use (defaults to ./build/xeplist.xml)" + ) + + parser.add_argument( + "-m", "--modify", + action="store_true", + default=False, + help="Modify the XEP files in-place." + ) + + args = parser.parse_args() + + if args.xeplist is None: + args.xeplist = open("./build/xeplist.xml", "rb") + + with args.xeplist as f: + tree = etree.parse(f) + + accepted, _ = load_xepinfos(tree) + deferred = list(get_deferred(accepted)) + + for deferred_info in deferred: + print(deferred_info["number"]) + + +if __name__ == "__main__": + main() diff --git a/tools/extract-metadata.py b/tools/extract-metadata.py index 3656a7d3..1132c2bb 100755 --- a/tools/extract-metadata.py +++ b/tools/extract-metadata.py @@ -4,6 +4,13 @@ import xml.dom.minidom import xml.etree.ElementTree as etree +from xeplib import ( + minidom_find_child, + minidom_find_header, + minidom_get_text, + minidom_children, +) + DESCRIPTION = """\ Extract a list of XEPs with metadata from the xeps repository.""" @@ -15,53 +22,29 @@ def open_xml(f): return xml.dom.minidom.parse(f) -def find_child(elem, child_tag): - for child in elem.childNodes: - if hasattr(child, "tagName") and child.tagName == child_tag: - return child - return None - - -def find_header(document): - header = find_child(document.documentElement, "header") - if header is None: - raise ValueError("cannot find
        ") - return header - - -def get_text(elem): - return "".join( - child.nodeValue - for child in elem.childNodes - if isinstance(child, (xml.dom.minidom.Text, - xml.dom.minidom.CDATASection)) - ) - - -def children(elem): - return [ - child for child in elem.childNodes - if isinstance(child, (xml.dom.minidom.Element)) - ] - - def extract_xep_metadata(document): - header = find_header(document) + header = minidom_find_header(document) - latest_revision = find_child(header, "revision") + latest_revision = minidom_find_child(header, "revision") if latest_revision is not None: - last_revision_version = get_text(find_child(latest_revision, "version")) - last_revision_date = get_text(find_child(latest_revision, "date")) - remark_el = find_child(latest_revision, "remark") + last_revision_version = minidom_get_text( + minidom_find_child(latest_revision, "version") + ) + last_revision_date = minidom_get_text( + minidom_find_child(latest_revision, "date") + ) + remark_el = minidom_find_child(latest_revision, "remark") last_revision_remark = None if remark_el is not None: - remark_children = children(remark_el) + remark_children = minidom_children(remark_el) if len(remark_children) == 1 and remark_children[0].tagName == "p": - last_revision_remark = get_text(remark_children[0]) + last_revision_remark = minidom_get_text(remark_children[0]) if last_revision_remark is not None: - initials_el = find_child(latest_revision, "initials") - last_revision_initials = initials_el and get_text(initials_el) + initials_el = minidom_find_child(latest_revision, "initials") + last_revision_initials = initials_el and minidom_get_text( + initials_el + ) else: last_revision_initials = None else: @@ -70,24 +53,26 @@ def extract_xep_metadata(document): last_revision_remark = None last_revision_initials = None - status = get_text(find_child(header, "status")) - type_ = get_text(find_child(header, "type")) - abstract = " ".join(get_text(find_child(header, "abstract")).split()) - sig_el = find_child(header, "sig") + status = minidom_get_text(minidom_find_child(header, "status")) + type_ = minidom_get_text(minidom_find_child(header, "type")) + abstract = " ".join(minidom_get_text( + minidom_find_child(header, "abstract") + ).split()) + sig_el = minidom_find_child(header, "sig") if sig_el is None: sig = None else: - sig = get_text(sig_el) - shortname = get_text(find_child(header, "shortname")) + sig = minidom_get_text(sig_el) + shortname = minidom_get_text(minidom_find_child(header, "shortname")) if shortname.replace("-", " ").replace("_", " ").lower() in [ "not yet assigned", "n/a", "none", "to be assigned", "to be issued"]: shortname = None - title = get_text(find_child(header, "title")) + title = minidom_get_text(minidom_find_child(header, "title")) - approver_el = find_child(header, "approver") + approver_el = minidom_find_child(header, "approver") if approver_el is not None: - approver = get_text(approver_el) + approver = minidom_get_text(approver_el) else: approver = "Board" if type_ == "Procedural" else "Council" diff --git a/tools/send-updates.py b/tools/send-updates.py index 454e7aaa..065e93b3 100755 --- a/tools/send-updates.py +++ b/tools/send-updates.py @@ -3,7 +3,6 @@ import configparser import getpass import itertools import email.message -import enum import os import smtplib import sys @@ -13,6 +12,8 @@ from datetime import datetime import xml.etree.ElementTree as etree +from xeplib import Status, Action, load_xepinfos + DESCRIPTION = """\ Send email updates for XEP changes based on the difference between two \ @@ -35,51 +36,6 @@ standard output are a terminal, the script interactively asks for the option \ values. If no terminal is connected, the script exits with an error instead.""" -class Status(enum.Enum): - PROTO = 'ProtoXEP' - EXPERIMENTAL = 'Experimental' - PROPOSED = 'Proposed' - DRAFT = 'Draft' - ACTIVE = 'Active' - FINAL = 'Final' - RETRACTED = 'Retracted' - OBSOLETE = 'Obsolete' - DEFERRED = 'Deferred' - REJECTED = 'Rejected' - DEPRECATED = 'Deprecated' - - @classmethod - def fromstr(cls, s): - if s == "Proto" or s.lower() == "protoxep": - s = "ProtoXEP" - return cls(s) - - -class Action(enum.Enum): - PROTO = "Proposed XMPP Extension" - NEW = "NEW" - DRAFT = "DRAFT" - ACTIVE = "ACTIVE" - FINAL = "FINAL" - RETRACT = "RETRACTED" - OBSOLETE = "OBSOLETED" - DEFER = "DEFERRED" - UPDATE = "UPDATED" - - @classmethod - def fromstatus(cls, status): - return { - Status.EXPERIMENTAL: cls.NEW, - Status.DRAFT: cls.DRAFT, - Status.ACTIVE: cls.ACTIVE, - Status.FINAL: cls.FINAL, - Status.RETRACTED: cls.RETRACT, - Status.OBSOLETED: cls.OBSOLETE, - Status.DEPRECATED: cls.DEPRECATE, - Status.DEFERRED: cls.DEFERRED, - } - - XEP_URL_PREFIX = "https://xmpp.org/extensions/" @@ -116,61 +72,6 @@ SUBJECT_NONPROTO_TEMPLATE = \ "{action.value}: XEP-{info[number]:04d} ({info[title]})" -def load_xepinfo(el): - accepted = el.get("accepted").lower() == "true" - - info = { - "title": el.find("title").text, - "abstract": el.find("abstract").text, - "type": el.find("type").text, - "status": Status.fromstr(el.find("status").text), - "approver": el.find("approver").text, - "accepted": accepted, - } - - last_revision_el = el.find("last-revision") - if last_revision_el is not None: - last_revision = { - "version": last_revision_el.find("version").text, - "date": last_revision_el.find("date").text, - "initials": None, - "remark": None, - } - - initials_el = last_revision_el.find("initials") - if initials_el is not None: - last_revision["initials"] = initials_el.text - - remark_el = last_revision_el.find("remark") - if remark_el is not None: - last_revision["remark"] = remark_el.text - - info["last_revision"] = last_revision - - sig = el.find("sig") - if sig is not None: - info["sig"] = sig.text - - if accepted: - info["number"] = int(el.find("number").text) - else: - info["protoname"] = el.find("proto-name").text - - return info - - -def load_xepinfos(tree): - accepted, protos = {}, {} - for info_el in tree.getroot(): - info = load_xepinfo(info_el) - if info["accepted"]: - accepted[info["number"]] = info - else: - protos[info["protoname"]] = info - - return accepted, protos - - def dummy_info(number): return { "status": None, diff --git a/tools/xeplib.py b/tools/xeplib.py new file mode 100644 index 00000000..5a250041 --- /dev/null +++ b/tools/xeplib.py @@ -0,0 +1,138 @@ +import enum + +import xml.dom.minidom + +from datetime import datetime + + +class Status(enum.Enum): + PROTO = 'ProtoXEP' + EXPERIMENTAL = 'Experimental' + PROPOSED = 'Proposed' + DRAFT = 'Draft' + ACTIVE = 'Active' + FINAL = 'Final' + RETRACTED = 'Retracted' + OBSOLETE = 'Obsolete' + DEFERRED = 'Deferred' + REJECTED = 'Rejected' + DEPRECATED = 'Deprecated' + + @classmethod + def fromstr(cls, s): + if s == "Proto" or s.lower() == "protoxep": + s = "ProtoXEP" + return cls(s) + + +class Action(enum.Enum): + PROTO = "Proposed XMPP Extension" + NEW = "NEW" + DRAFT = "DRAFT" + ACTIVE = "ACTIVE" + FINAL = "FINAL" + RETRACT = "RETRACTED" + OBSOLETE = "OBSOLETED" + DEFER = "DEFERRED" + UPDATE = "UPDATED" + + @classmethod + def fromstatus(cls, status): + return { + Status.EXPERIMENTAL: cls.NEW, + Status.DRAFT: cls.DRAFT, + Status.ACTIVE: cls.ACTIVE, + Status.FINAL: cls.FINAL, + Status.RETRACTED: cls.RETRACT, + Status.OBSOLETED: cls.OBSOLETE, + Status.DEPRECATED: cls.DEPRECATE, + Status.DEFERRED: cls.DEFERRED, + }[status] + + +def load_xepinfo(el): + accepted = el.get("accepted").lower() == "true" + + info = { + "title": el.find("title").text, + "abstract": el.find("abstract").text, + "type": el.find("type").text, + "status": Status.fromstr(el.find("status").text), + "approver": el.find("approver").text, + "accepted": accepted, + } + + last_revision_el = el.find("last-revision") + if last_revision_el is not None: + last_revision = { + "version": last_revision_el.find("version").text, + "date": datetime.strptime( + last_revision_el.find("date").text, + "%Y-%m-%d", + ), + "initials": None, + "remark": None, + } + + initials_el = last_revision_el.find("initials") + if initials_el is not None: + last_revision["initials"] = initials_el.text + + remark_el = last_revision_el.find("remark") + if remark_el is not None: + last_revision["remark"] = remark_el.text + + info["last_revision"] = last_revision + + sig = el.find("sig") + if sig is not None: + info["sig"] = sig.text + + if accepted: + info["number"] = int(el.find("number").text) + else: + info["protoname"] = el.find("proto-name").text + + return info + + +def load_xepinfos(tree): + accepted, protos = {}, {} + for info_el in tree.getroot(): + info = load_xepinfo(info_el) + if info["accepted"]: + accepted[info["number"]] = info + else: + protos[info["protoname"]] = info + + return accepted, protos + + +def minidom_find_child(elem, child_tag): + for child in elem.childNodes: + if hasattr(child, "tagName") and child.tagName == child_tag: + return child + return None + + +def minidom_find_header(document): + header = minidom_find_child(document.documentElement, "header") + if header is None: + raise ValueError("cannot find
        ") + return header + + +def minidom_get_text(elem): + return "".join( + child.nodeValue + for child in elem.childNodes + if isinstance(child, (xml.dom.minidom.Text, + xml.dom.minidom.CDATASection)) + ) + + +def minidom_children(elem): + return [ + child for child in elem.childNodes + if isinstance(child, (xml.dom.minidom.Element)) + ] From a455020d3a2127a756d0a58b7e3bd96e1f346d10 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Wed, 23 Aug 2017 14:08:17 +0200 Subject: [PATCH 48/54] tooling: Add tool to copy changed XEPs to the attic --- tools/archive.py | 90 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100755 tools/archive.py diff --git a/tools/archive.py b/tools/archive.py new file mode 100755 index 00000000..6e87ea9f --- /dev/null +++ b/tools/archive.py @@ -0,0 +1,90 @@ +#!/usr/bin/env python3 +import pathlib +import shutil +import sys + +import xml.etree.ElementTree as etree + +from datetime import datetime, timedelta + +from xeplib import load_xepinfos, Status + + +def main(): + import argparse + + parser = argparse.ArgumentParser( + description="Show the XEPs which need to be changed to deferred." + ) + + parser.add_argument( + "old", + type=argparse.FileType("rb"), + help="Old XEP list" + ) + + parser.add_argument( + "new", + type=argparse.FileType("rb"), + help="New XEP list" + ) + + parser.add_argument( + "-d", "--xeps-dir", + type=pathlib.Path, + default=pathlib.Path.cwd() / "build", + help="Path to the built XEPs (defaults to ./build)" + ) + + parser.add_argument( + "-a", "--attic", + type=pathlib.Path, + default=pathlib.Path.cwd() / '../xep-attic/content/', + help="Path to the attic (defaults to ../xep-attic/content/)" + ) + + args = parser.parse_args() + + with args.old as f: + old_tree = etree.parse(f) + + old_accepted, _ = load_xepinfos(old_tree) + + with args.new as f: + new_tree = etree.parse(f) + + new_accepted, _ = load_xepinfos(new_tree) + + changed = False + + for xep, new_info in new_accepted.items(): + old_version = old_accepted.get(xep, {}).get("last_revision", {}).get( + "version" + ) + new_version = new_info["last_revision"]["version"] + + if old_version == new_version: + continue + + curr_file = args.xeps_dir / "xep-{:04d}.html".format(xep) + attic_file = args.attic / "xep-{:04d}-{}.html".format(xep, new_version) + + print("XEP-{:04d}:".format(xep), old_version, "->", new_version) + + shutil.copy(str(curr_file), str(attic_file)) + changed = True + + if changed: + print( + "{}: do not forget to commit & push the attic!".format( + sys.argv[0] + ), + file=sys.stderr + ) + else: + print("{}: nothing to do".format(sys.argv[0]), + file=sys.stderr) + + +if __name__ == "__main__": + main() From 0ff93d4fa0a1c186e5092c9291e1af0fec65ab48 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Wed, 23 Aug 2017 16:33:28 +0200 Subject: [PATCH 49/54] tooling: print metadata extraction errors to stderr --- tools/extract-metadata.py | 44 ++++++++++++++++++++++++++------------- 1 file changed, 29 insertions(+), 15 deletions(-) diff --git a/tools/extract-metadata.py b/tools/extract-metadata.py index 1132c2bb..b0a8f1c8 100755 --- a/tools/extract-metadata.py +++ b/tools/extract-metadata.py @@ -1,5 +1,6 @@ #!/usr/bin/env python3 import pathlib +import sys import xml.dom.minidom import xml.etree.ElementTree as etree @@ -160,6 +161,8 @@ def main(): tree = etree.Element("xep-infos") + has_error = False + for xepfile in args.xepdir.glob("xep-*.xml"): number = xepfile.name.split("-", 1)[1].split(".", 1)[0] try: @@ -167,27 +170,38 @@ def main(): except ValueError: continue - with xepfile.open("rb") as f: - parsed = open_xml(f) + try: + with xepfile.open("rb") as f: + parsed = open_xml(f) - tree.append(make_metadata_element( - number, - extract_xep_metadata(parsed), - True, - )) + tree.append(make_metadata_element( + number, + extract_xep_metadata(parsed), + True, + )) + except Exception as exc: + has_error = True + print("{}: {}".format(xepfile, exc), file=sys.stderr) for xepfile in (args.xepdir / "inbox").glob("*.xml"): protoname = xepfile.name.rsplit(".", 1)[0] - with xepfile.open("rb") as f: - parsed = open_xml(f) + try: + with xepfile.open("rb") as f: + parsed = open_xml(f) - tree.append(make_metadata_element( - "xxxx", - extract_xep_metadata(parsed), - False, - protoname=protoname - )) + tree.append(make_metadata_element( + "xxxx", + extract_xep_metadata(parsed), + False, + protoname=protoname + )) + except Exception as exc: + has_error = True + print("{}: {}".format(xepfile, exc), file=sys.stderr) + + if has_error: + sys.exit(2) sys.stdout.buffer.raw.write(etree.tostring(tree)) From cdc3c09624d89f6c585751040e9327f40f6012f2 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Wed, 23 Aug 2017 16:55:14 +0200 Subject: [PATCH 50/54] Remove Makefile which should never have been there --- inbox/Makefile | 8 -------- 1 file changed, 8 deletions(-) delete mode 100644 inbox/Makefile diff --git a/inbox/Makefile b/inbox/Makefile deleted file mode 100644 index 2e27a1f6..00000000 --- a/inbox/Makefile +++ /dev/null @@ -1,8 +0,0 @@ -OUTDIR?=../build/ - -xeps=$(wildcard *.xml) - -.PHONY: all -all: html - -html: $(patsubst %.xml, $(OUTDIR)/%.html, $(xeps)) From 340ab90216bdad712a495cde88a21b1dbaa4c0e3 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Wed, 23 Aug 2017 16:56:01 +0200 Subject: [PATCH 51/54] Makefile: fix build/inbox creation --- Makefile | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index ee7985b6..61820e39 100644 --- a/Makefile +++ b/Makefile @@ -49,10 +49,6 @@ help: .PHONY: all all: html -$(OUTDIR)/inbox/%: build/inbox -build/inbox: - mkdir -p build/inbox - .PHONY: xeplist xeplist: $(OUTDIR)/xeplist.xml @@ -99,7 +95,10 @@ $(REFSDIR)/reference.XSF.XEP-%.xml: xep-%.xml $(XMLDEPS) ref.xsl $(REFSDIR) xsltproc --path $(CURDIR) ref.xsl "$<" > "$@" && echo "Finished building $@" $(all_xep_htmls): $(OUTDIR)/%.html: %.xml $(XMLDEPS) $(HTMLDEPS) + # we don’t put it as a dependency to avoid a rebuild due to a timestamp + # change on the directory mkdir -p $(OUTDIR)/inbox + xmllint --nonet --noout --noent --loaddtd --valid "$<" # Check for non-data URIs ! xmllint --nonet --noout --noent --loaddtd --xpath "//img/@src[not(starts-with(., 'data:'))]" $< 2>/dev/null && true From d0bbbb2d5c441b7a90a3413739f8c3284a74840e Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Wed, 23 Aug 2017 17:00:55 +0200 Subject: [PATCH 52/54] extract-metadata: make error handling cleaner --- tools/extract-metadata.py | 51 +++++++++++++++++++++------------------ 1 file changed, 28 insertions(+), 23 deletions(-) diff --git a/tools/extract-metadata.py b/tools/extract-metadata.py index b0a8f1c8..462f75f1 100755 --- a/tools/extract-metadata.py +++ b/tools/extract-metadata.py @@ -141,6 +141,15 @@ def make_metadata_element(number, metadata, accepted, *, protoname=None): return result +def parse_checked_and_print_error(xepfile): + try: + with xepfile.open("rb") as f: + return open_xml(f) + except xml.parsers.expat.ExpatError as exc: + print("{}: {}".format(xepfile, exc), file=sys.stderr) + return None + + def main(): import argparse import sys @@ -170,35 +179,31 @@ def main(): except ValueError: continue - try: - with xepfile.open("rb") as f: - parsed = open_xml(f) - - tree.append(make_metadata_element( - number, - extract_xep_metadata(parsed), - True, - )) - except Exception as exc: + parsed = parse_checked_and_print_error(xepfile) + if parsed is None: has_error = True - print("{}: {}".format(xepfile, exc), file=sys.stderr) + continue + + tree.append(make_metadata_element( + number, + extract_xep_metadata(parsed), + True, + )) for xepfile in (args.xepdir / "inbox").glob("*.xml"): protoname = xepfile.name.rsplit(".", 1)[0] - try: - with xepfile.open("rb") as f: - parsed = open_xml(f) - - tree.append(make_metadata_element( - "xxxx", - extract_xep_metadata(parsed), - False, - protoname=protoname - )) - except Exception as exc: + parsed = parse_checked_and_print_error(xepfile) + if parsed is None: has_error = True - print("{}: {}".format(xepfile, exc), file=sys.stderr) + continue + + tree.append(make_metadata_element( + "xxxx", + extract_xep_metadata(parsed), + False, + protoname=protoname + )) if has_error: sys.exit(2) From 1b15a44243d41885a0170ef6fef4efd567fddcf2 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Thu, 24 Aug 2017 07:38:13 +0200 Subject: [PATCH 53/54] XEP-0321: more editing in response to discussion on #476 --- xep-0321.xml | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/xep-0321.xml b/xep-0321.xml index 0210c352..2e055e2c 100644 --- a/xep-0321.xml +++ b/xep-0321.xml @@ -55,16 +55,16 @@

        This document addresses the following requirements:

        1. Make it possible for remote services or entities to manage user's roster by the same mechanisms that descibed in the &rfc6121;.
          2. -
        2. Provide a way for user to control which services have permission to manage their roster.
          3. +
        3. Provide a way for users to control which services have permission to manage their roster.
        -
          -
        • Remote entity — the entity that wants to modify user's roster.
          • -
        • User — the entity which roster the remote entity wants to have access to.
          • -
        • User's server — the XMPP server User connected to.
          • -
        • Roster — the list of User's contacts as defined in the &rfc6121;.
          • -
        +
        +
        Remote entity
        the entity that wants to modify user's roster.
         +
        User
        the entity which roster the remote entity wants to have access to.
         +
        User's server
        the XMPP server User connected to.
         +
        Roster
        the list of User's contacts as defined in the &rfc6121;.
         +
        From 8996b3cf964b26c1296f9fe76a92bf8c93da8c3b Mon Sep 17 00:00:00 2001 From: vanitasvitae Date: Thu, 24 Aug 2017 09:06:35 +0200 Subject: [PATCH 54/54] Update JET --- inbox/jet.xml | 242 ++++++++++++++++++++++++++++++++++++++++++++++ inbox/xep-jet.xml | 165 ------------------------------- 2 files changed, 242 insertions(+), 165 deletions(-) create mode 100644 inbox/jet.xml delete mode 100644 inbox/xep-jet.xml diff --git a/inbox/jet.xml b/inbox/jet.xml new file mode 100644 index 00000000..3e1e0642 --- /dev/null +++ b/inbox/jet.xml @@ -0,0 +1,242 @@ + + + +%ents; +]> + + +
        + Jingle Encrypted Transports + This specification defines a method that allows to use established encryption schemes like OpenPGP or OMEMO for end-to-end encryption of Jingle transports. + &LEGALNOTICE; + XXXX + ProtoXEP + Standards Track + Standards + Council + + XEP-0234 + + + + jet + + jingle + http://xmpp.org/schemas/jingle.xsd + + + jingle:errors + http://xmpp.org/schemas/jingle-errors.xsd + + + jingle + + Paul + Schaub + vanitasvitae@riseup.net + vanitasvitae@jabberhead.tk + + + 0.0.1 + 2017-06-12 + vv +

        First draft

         +         +
        + +

        Jingle Encrypted Transports (JET) strives to provide a modular and easily extensible way to wrap Jingle Transports in an additional end-to-end encryption layer. The focus of this specification lays on being modular. It should be possible to extend existing Jingle use scenarios with end-to-end encryption by simply adding a JET element to the negotiation.

        +         + +

        JET uses multiple encryption layers, so it is necessary to declare a distinct denomination for the different keys involved.

        + + + + + + + + + + + + + + + + + + + + + + + + + + +
        DesignationAbbrevationUsage
        Transport KeyTK(Symmetric) key that is used to encrypt/decrypt the bytestreams sent/received through Jingle transports. This key encrypts the data two entities want to exchange. Examples for TK can be found under "Ciphers".
        Initialization VectorIVInitialization vector that is used together with TK.
        Transport SecretTSSerialization of TK and TI.
        Envelope ElementEEOutput of an established end-to-end encryption methods when encrypting TS. Examples for such methods could be &xep0384; or &xep0374;.
        +         + +

        Lets assume Romeo wants to initiate an encrypted Jingle session with Juliet. Prior to the Jingle session initiation, an already existing, established and (ideally) authenticated end-to-end encryption session between Romeo and Juliet MUST exist. Examples for suitable encryption sessions are &xep0384; and &xep0374;. This session is needed to transfer the Transport Secret from Romeo to Juliet.

        +

        When this precondition is met, Romeo initially generates a transport key (TK) and associated initialization vector (IV). These will later be used by the sender to encrypt, and respectively by the recipient to decrypt data that is exchanged. This protocol defines a set of usable ciphers from which Romeo might choose. TK and IV are serialized to create the transport secret (TS).

        +

        Next Romeo uses her established encryption session with Juliet to encrypt TS. The resulting envelope element (EE) will be part of the Jingle session initiation as child of the JET &secret; element.

        +

        When Juliet receives Romeos session request, she decrypts EE to retrieve TS, from which she can deserialize TK and IV. Now she and Romeo can go on with the session negotiation. Once the session is established, data can be encrypted and exchanged.

        +         + +

        &xep0234; has the disadvantage, that transmitted files are not encrypted (aside from regular TLS transport encryption), which means that intermediate nodes like XMPP/proxy server(s) have access to the transferred data. Considering that end-to-end encryption becomes more and more important to protect free speech and personal expression, this is a major flaw that needs to be addressed.

        +

        In order to initiate an encrypted file transfer, the initiator includes a JET &secret; in the Jingle file transfer request.

        + + +

        In this scenario Romeo wants to send an encrypted text file over to Juliet. He chooses to use their existing &xep0384; session to do so. First, he generates a fresh AES-256 transport key and IV. TK and IV are serialized into TS which is then encrypted using Romeos OMEMO session with Juliet.

        +

        The resulting OMEMO element (EE) is sent as part of the security element along with the rest of the jingle stanza over to Juliet.

        + + + + + + 1969-07-21T02:56:15Z + This is a test. If this were a real file... + text/plain + test.txt + + 6144 + w0mcJylzCn+AfvuGdqkty2+KP48= + + + + + + + +
        + BASE64ENCODED... + BASE64ENCODED... + BASE64ENCODED... +
        + BASE64-ENCODED-ENCRYPTED-SECRET +         +         +         +         +]]>         + +

        Juliet decrypts the OMEMO element (EE) using her session with Romeo to retrieve TS from which she deserializes TK and IV. Both Juliet and Romeo then carry on with the session negotiation as described in &xep0234;. Before Romeo starts transmitting the file, he encrypts it using TK and IV. He then transmitts the encrypted file over to Juliet.

        +

        When Juliet received the file, she uses the TK and IV to decrypt the received file.

        +         + + +

        Juliet might want to request a file transfer from Romeo. This can be the case, when Romeo hosts the file. In order to do so, she sends generates TK and IV, creates TS from those and encrypts TS with an encryption method of her choice to get EE. TK and IV will be used by Romeo to encrypt the requested file before sending it to Juliet. In this example we assume, that Romeo and Juliet secured their communications using &xep0374;.

        + + + + + + w0mcJylzCn+AfvuGdqkty2+KP48= + + + + + + + + + + + + +]]> +         +         + + +

        In order to encrypt the transported bytestream, the initiator must transmit a cipher key to the responder. There are multiple options available:

        + + + + + + + + + + + + + + + + + + + + + + +
        NamespaceTypeLength (bits)ParametersSerialization
        urn:xmpp:ciphers:aes-128-gcm-nopadding:0AES128GCM/NoPadding128BitKey::96BitIV
        urn:xmpp:ciphers:aes-256-gcm-nopadding:0AES256GCM/NoPadding256BitKey::96BitIV
        +

        The column 'serialization' describes, how the key and iv are serialized. "::" means plain concatenation of byte arrays.

        +         + + +

        The initiator SHOULD NOT use the generated key TK as IV, but instead generate a seperate random IV.

        +

        Instead of falling back to unencrypted transfer in case something goes wrong, implementations MUST instead abort the Jingle session, informing the user.

        +

        IMPORTANT: This approach does not deal with metadata. In case of &xep0234;, an attacker with access to the sent stanzas can for example still see the name of the file and other information included in the <file/> element.

        +

        When using OX as encryption method, clients might want to protect against replay attacks

        +

        The responder MUST check, whether the envelope element belongs to the initiator to prevent MitM attacks

        +         + + +

        This is only a rough draft and there is still a ton of questions left to be answered. Here is a small non-exhaustive list of things I can think of:

        +
          +
        • How exactly are interrupted transfers resumed? How (long) are keys/IVs cached?
          • +
        • May it be desirable to split data into chunks?
          • +
        • Please add to this list :)
          • +
        +         + +
          +
        • Service discovery
          • +
        +         +         diff --git a/inbox/xep-jet.xml b/inbox/xep-jet.xml deleted file mode 100644 index 2640381e..00000000 --- a/inbox/xep-jet.xml +++ /dev/null @@ -1,165 +0,0 @@ - - -%ents; -]> - - -
        - Jingle Encrypted Transfers - This specification defines a method that allows file transfers via Jingle File Transfer to be end-to-end encrypted using established encryption schemes like OpenPGP or OMEMO. - &LEGALNOTICE; - XXXX - ProtoXEP - Standards Track - Standards - Council - - XEP-0234 - - - - jet - - jingle - http://xmpp.org/schemas/jingle.xsd - - - jingle:errors - http://xmpp.org/schemas/jingle-errors.xsd - - - jingle - - Paul - Schaub - vanitasvitae@riseup.net - vanitasvitae@jabberhead.tk - - - 0.0.1 - 2017-06-12 - vv -

        First draft

         -         -
        - -

        &xep0234; has the disadvantage, that transmitted files are not encrypted (aside from regular TLS transport encryption), which means that intermediate nodes like the XMPP server(s) have access to the transferred data. Considering that end-to-end encryption becomes more and more important for communications, this is a major flaw that needs to be addressed.

        -

        This document defines a method to enable two communication partners to utilize an already established secure channel (eg. an OMEMO session) to exchange an encryption key which can then be used to encrypt/decrypt the offered/requested file.

        -         - -

        In order to initiate an encrypted file transfer, the initiator includes a key-element in the jingle-request. This key-element contains an encryption key which is used to encrypt/decryt the transferred key. In both file offers and file requests, it is the initiator, which dictates this key. The key is encrypted using the encryption method of the initiators choice. The initiator and responder must establish a session beforehand.

        - - -

        In this scenario Romeo wants to send an encrypted text file over to Juliet. He chooses to use their existing OMEMO session to do so. First, he generates a fresh TODO-AES key and IV. This will later be used to encrypt and decrypt the file. In order to be transmitted, key and IV have to be serialized. Key and IV are both Base64 encoded and appended in the following form:

        - -

        This text is encrypted using the established secure encryption method. The resulting OMEMO element is sent as part of the security element along with the rest of the jingle stanza over to Juliet.

        - - - - - - 1969-07-21T02:56:15Z - This is a test. If this were a real file... - text/plain - test.txt - - 6144 - w0mcJylzCn+AfvuGdqkty2+KP48= - - - - - - - -
        - BASE64ENCODED... - BASE64ENCODED... - BASE64ENCODED... -
        - BASE64-ENCODED-ENCRYPTED-KEY -         -         -         -         -]]>         - -

        Juliet decrypts the OMEMO element using her session with Romeo to retrieve the key and IV. Both Juliet and Romeo then carry on with the session negotiation as described in &xep0234;. Before Romeo starts transmitting the file, he encrypts it using the key and IV. He then transmitts the encrypted file over to Juliet.

        -

        When Juliet received the file, she uses the decrypted key and IV to decrypt the received file.

        -         - - -

        Juliet might want to request a file transfer from Romeo. This can be the case, when Romeo hosts the file. In order to do so, she sends him a key and IV which Romeo will use to encrypt the file before sending it to Juliet. In this example we assume, that Romeo and Juliet secured their communications using &xep0374;.

        - - - - - - w0mcJylzCn+AfvuGdqkty2+KP48= - - - - - - - - - - - - -]]> -         -         - - -

        This is only a rough draft and there is still a ton of questions left to be answered. Here is a small non-exhaustive list of things I can think of:

        -
          -
        • What cipher is used to encrypt the file? Examples would be AES-GCM128/256...
          • -
        • Cipher agility? What format is used to serialize key and IV?
          • -
        • How exactly are interrupted transfers resumed? How (long) are keys/IVs cached?
          • -
        • Is it in the scope of this approach to hide metadata?
          • -
        • How are transferred files authenticated? (See OMEMO audit)
          • -
        • May it be desirable to split data into chunks?
          • -
        • Please add to this list :)
          • -
        -         -