There are two typical mechanisms to register an account on an XMPP server:
+The IBR mechanism is much more convenient for users, but also opens up + the server to abuse, e.g. due to the mass-registration of spam bot + accounts. Captchas, while heavily impacting well-intentioned users, are + not a reliable mechanism to prevent abuse. This specification allows to + restrict the IBR mechanism by requiring a registration token, e.g. for + giving users access to a private server, without exposing their password + to the server administrator.
+This specification is part of a series of documents aiming at improving + user onboarding:
+While this specification is designed to work together with &xep0401;, it + can be used with invitation tokens obtained by any other mechanism. XMPP + URIs can then be used out-of-band to deliver the invitation to a new user.
+A client that obtains such an XMPP URI should allow the user to register + an XMPP account with the server that generated the URI.
+A client that implements this specification needs to understand the + &xep0147; specification, to make use of the register query + action and the preauth parameter. Three URI formats + are defined.
+An invitation to register an account can contain a specific XMPP + address (with a pre-defined user account name) to be registered. A + client should populate the address field in the IBR dialog with this + address and disallow changing the address.
+xmpp:juliet@example.com?register;preauth=TOKEN
+ An invitation to register an account can contain just the server domain + to register on. A client should populate the address field in the IBR + dialog with this domain and allow entering the desired account name.
+xmpp:example.com?register;preauth=TOKEN
+ A contact invitation with a registration token (&xep0379;) might + indicate that the token can also be used to register an account on that + server (ibr=y). If the receiving client already has an account + configured, it may skip account registration and simply add the contact + as defined in XEP-0379. The client may also register a new + account on the domain of the proposed contact, allowing the user to + enter the desired account name.
+xmpp:romeo@example.com?roster;preauth=TOKEN;ibr=y
+ While a registration URI is an indication that the respective server + supports Pre-Authenticated IBR, a URI might be manipulated and is not + guaranteed to be reliable.
+Therefore, when performing the account creation, the client needs to + ensure that the server supports the Pre-Authenticated IBR protocol, as denoted by + the <register xmlns='urn:xmpp:invite'> + stream feature:
+In order to allow invited users to register on a server, the + registration processs as defined in &xep0077; needs to be extended. The + invited user's client needs to connect to the server and check that the + invitation stream feature + (<register xmlns='urn:xmpp:invite'>) is present. + After that, the client initiates the registration flow by sending the + preauth token to the server:
+Upon receiving the preauth request, the server must validate that the + token is acceptable for account registration. However, single-use tokens + MUST NOT be considered used until the actual registration has succeeded. +
+In addition, if the token has an expiration time, it MUST only be + checked at this point. Subsequent actions performed by the client during + the current session that require a valid token MUST NOT be rejected due + to token expiry. +
+If the token is acceptable, the server responds with success, and + indicates the client may now proceed with account registration: +
+If the token provided by the client was unknown, invalid or expired, the + server should return an appropriate error to the client:
+In the success case, the client proceeds with registration as defined in + &xep0077;. If the token is rejected by the server, the client still MAY + attempt to perform IBR if the server allows that.
+If a username was specified when creating an invitation token, the + server SHOULD NOT create an account on the server until the invitee + actually registers it with the corresponding token. + The server MUST reserve the username at least until the corresponding + token expires.
+If the invitee opens an invitation URI with ibr=y and + chooses to create a new account, the client SHOULD pre-fill the + inviter JID's domain part as the new account's domain. The client MAY + provide a mechanism to enter or choose a different server, though.
+See security considerations in &xep0379;.
+This document requires no interaction with &IANA;.
+This document only makes use of the XMPP URI elements defined in + &xep0401;
+REQUIRED for protocol specifications.
+Reword note about how to handle LMC in cases where it is not clear that all recipients support it.
It is expected that clients will not send message corrections to clients that do not support them, as non-supporting clients will render these as duplicate (corrected) messages. There may be environments (particularly within a &xep0045; MUC room) where it is unknown whether some or all recipients support this extension, and implementors could choose to allow or disallow sending in such cases, as is appropriate for the intended deployments. It is suggested that when the support of recipients is not known a sending client will make the user aware of the potential for duplicate messages to be interpreted by the recipients.
+Message corrections sent to clients that do not support them will be rendered as duplicate (corrected) messages. In most Instant Messaging environments (particularly within a &xep0045; room, but also with a recipient having multiple clients using &xep0280; and &xep0313;) it is unknown whether some or all receiving devices support this extension. It is suggested that a client should always allow sending corrections, but may make the user aware of the potential for duplicate messages to be interpreted by the recipients. In restricted environments, implementors could choose to allow or disallow sending in such cases, as is appropriate for the intended deployments.
When a user indicates to the client that he wants to correct the most recently sent message to a contact, the client will resend the corrected message with a new id, and with the replace payload refering to the previous message by id. The receiving client then treats the newly received payloads as completely replacing all payloads of the original message.
diff --git a/xep-0352.xml b/xep-0352.xml index 3502747a..46e67ac1 100644 --- a/xep-0352.xml +++ b/xep-0352.xml @@ -10,7 +10,7 @@Correct example caption
Some use cases require the originating entity, e.g. a client, to generate the stanza ID. In this case, the client MUST use the &origin-id; element extension element qualified by the 'urn:xmpp:sid:0' namespace. Note that originating entities often want to conceal their XMPP address and therefore the &origin-id; element has no 'by' attribute.
-Fix various typos
- MIX Join and Leave communication goes through the clients server. The full specification of client interaction with the client's server is specified in MIX-PAM. This specification shows the protocol between the user's server and the MIX server and sets out behaviour of the MIX server. + MIX Join and Leave communication goes through the client's server. The full specification of client interaction with the client's server is specified in MIX-PAM. This specification shows the protocol between the user's server and the MIX server and sets out behaviour of the MIX server.
- A user MAY specify a nick when joining the channel. Channels MAY have mandatory nicks, which is default behavior. Therefore it will generally be necessary to include a nick when joining an channel. If nick is missing on a channel where nick is mandatory, the join MUST be rejected. Other error cases are dealt with below with the nick management commands. Where a nick is specified, the join will only complete if the nick is accepted. The nick used MUST be reported back in the join result. + A user MAY specify a nick when joining the channel. Channels MAY have mandatory nicks, which is default behavior. Therefore it will generally be necessary to include a nick when joining a channel. If nick is missing on a channel where nick is mandatory, the join MUST be rejected. Other error cases are dealt with below with the nick management commands. Where a nick is specified, the join will only complete if the nick is accepted. The nick used MUST be reported back in the join result.
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, the user's server sends a MIX "leave" command to the channel, as specified in MIX-PAM. The leave command is encoded as a <leave/> child element of <iq/> element. The <leave/> element is qualified by the 'urn:xmpp:mix:core:1' namespace. The following example shows a leave request to a MIX channel.
+Users generally remain in a channel for an extended period of time. In particular the user remains as a participant of 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, the user's server sends a MIX "leave" command to the channel, as specified in MIX-PAM. The leave command is encoded as a <leave/> child element of <iq/> element. The <leave/> element is qualified by the 'urn:xmpp:mix:core:1' namespace. The following example shows a leave request to a MIX channel.
Fix various typos
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.
+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 returns 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.
Fix various typos
Invitation by reference, as described in the previous section, is a convenient approach to invite a user to join a channel that the user has permission to join. This section describes the approach used when the inviter has permission to grant rights for the invitee to become a channel participant. This might be because the inviter is an administrator of the channel or the channel or if the inviter is a channel participant and the channel allows invitation by participants (this channel capability is controlled by the channel configuration variable 'Participation Addition by Invitation from Participant'). Invitation by reference is used to avoid cluttering the allowed node with JIDs of users who are invited to join, but do not accept the invitation. - When a channel participant(the inviter) invites another user (the invitee) to join a channel, the following sequence of steps is followed: + When a channel participant (the inviter) invites another user (the invitee) to join a channel, the following sequence of steps is followed:
- 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:misc: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:misc:0' namespace. <invite/> contains an <invitation/> child element, which contains <inviter/>, <invitee/>, <channel/> and <token/> child elements.
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.
Fix misspelling of 'whose'
The following changes were made to the Compliance Suites since &xep0423;:
+ To be considered XMPP A/V calling compliant, all features from the core + compliance category must be met, as well as all features in this suite. +
+| Feature | +Core Server | +Core Client | +Advanced Server | +Advanced Client | +Providers | +
|---|---|---|---|---|---|
| Call Setup | +N/A | +&yes; | +N/A | +&yes; | +&xep0167;, &xep0353; | +
| Transport | +N/A | +&yes; | +N/A | +&yes; | +&xep0176; | +
| Encryption | +N/A | +&yes; | +N/A | +&yes; | +&xep0320; | +
| STUN/TURN server discovery | +&yes; | +&yes; | +&yes; | +&yes; | +&xep0215; | +
| Quality and Performance improvements | +N/A | +&no; | +N/A | +&yes; | +&xep0293;, &xep0294;, &xep0338;, &xep0339; | +
This section outlines the protocol specifications that are relevant for