Added "Usability Considerations", removed actual XMPP client, some text editing.
If the "preauth" parameter is present, the processing client is supposed
@@ -136,12 +142,12 @@ xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;name=Romeo%20Montague
- As Romeo doesn't know Juliet's JID in advance, he needs to use an out-of-band method (like e-mail, QR codes or NFC) to transmit the invitation link to Juliet. While these methods allow transmission of xmpp: URIs, there is no mechanism to ensure that Juliet actually has a client installed that can open the URI. One way to solve this problem is to present Juliet with a web-based landing page that contains the following elements: There are multiple options where such a landing page could be hosted: A possible screen representation of the landing page would be: When Juliet opens the xmpp: URI (or the according client-supported
landing page URI) in her client, the client should perform the usual
roster addition action, i.e. display a dialog allowing to edit the entry
@@ -237,27 +243,28 @@ https://yax.im/i/romeo/montague.net/1tMFqYDdKhfe2pwp/Romeo+Montague
If Juliet's server support pre-approval, it will automatically handle the
+ If Juliet's server supports pre-approval, it will automatically handle the
incoming subscription request and issue a roster push. Otherwise, Juliet's
client will receive the subscription request: Juliet's client SHOULD check the subscription request sender JID against
- the whitelist, and either automatically approve the request or display an
- according notification to Juliet. Juliet's client MUST ensure that the sender JID is contained in the
+ auto-approval whitelist before automatically approving the request.
+ Otherwise, it has to fallback to the normal subscription approval
+ process. An implementation of this protocol MUST allow for a "graceful
degradation" to the manual subscription approval process. If a client
receives a malformed or unknown 'preauth' token, it MUST ignore it and act
as if no preauth token was contained. When sending a pre-authenticated subscription request, the contact's
client MUST NOT expect an immediate successful approval. If the user's
issuing client is currently offline, or if the token has expired, a manual
@@ -265,26 +272,6 @@ https://yax.im/i/romeo/montague.net/1tMFqYDdKhfe2pwp/Romeo+Montague
same mechanism as before to indicate an unidirectional subscription.
If a user is logged in with multiple clients, some of their clients will
- receive a subscription request with an unknown token. In this case, a client
- MAY delay the user notification for a short time, to allow another logged-in
- client to automatically handle the subscription request. Some mobile device platforms allow an app to register itself as a
- handler for cetain URIs. This allows an XMPP client to register for xmpp:
- URIs, but also to redirect handling of cetain HTTP/HTTPS URIs. A mobile
- client SHOULD register for the associated landing page URIs and properly
- handle the contained invitations. For example, the yaxim client should
- register a handler for https://yax.im/i/*, and present
- the "Add to roster" dialog if such a link is opened. A client MAY register
- for the landing page URIs of other providers after obtaining the
- operators' approval.
- The invitation link that is generated by Romeo's client is considered a
- personal invitation link for a single person. This, and the fact that the
- link can only be used once, should be indicated by the client to Romeo.
- A Monkey-in-the-Middle attacker who gains access to the invitation link
can manipulate its fields or redeem the link themselves. However, this is
@@ -351,6 +332,47 @@ https://yax.im/i/romeo/montague.net/1tMFqYDdKhfe2pwp/Romeo+Montague
equal to the JID, to prevent impersonation attacks. If a user is logged in with multiple clients, some of their clients will
+ receive a subscription request with an unknown token. In this case, a client
+ MAY delay the user notification for a short time, to allow another logged-in
+ client to automatically handle the subscription request. Some mobile device platforms allow an app to register itself as a
+ handler for cetain URIs. This allows an XMPP client to register for xmpp:
+ URIs, but also to redirect handling of cetain HTTP/HTTPS URIs. A mobile
+ client SHOULD register for the associated landing page URIs and properly
+ handle the contained invitations. For example, the JuicyXMPP client should
+ register a handler for https://juicyxmpp.example/i/*, and present
+ the "Add to roster" dialog if such a link is opened. A client MAY register
+ for the landing page URIs of other providers after obtaining the
+ operators' approval.
+ By default, Romeo's client should generate personal invitation links
+ that can only be redeemed once, and only for a limited time. This fact
+ SHOULD be indicated by the client UI to Romeo. If a client allows customization of the validity time or the number of
+ uses for a given invitation token, it SHOULD provide clear language
+ to inidcate that. When a new contact is added automatically by the client, it SHOULD
+ indicate this fact to the user, and allow the user to rename / group
+ the contact appropriately. One possible way to achieve this is by
+ putting all auto-added contacts into a special roster group, and by
+ automatically removing this group on the first manual edit of the
+ contact. In this case, the roster group should be named by the client according
+ to the user's locale settings. However, this approach might lead to
+ different clients using different group names, resulting in multiple
+ roster groups with the same goal. This document requires no interaction with &IANA;.