moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 02:02:16 -05:00
Code Issues Releases Wiki Activity

XEP-0379: Capitalized All Captions

Browse Source
This commit is contained in:
Georg Lukas 2017-02-16 11:34:59 +01:00
parent c794c3a933
commit 04221c838f
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
xep-0379.xml
View File

@ -136,7 +136,7 @@ xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;name=Romeo+Montague
</section2>
<section2 topic='Out-of-band transmission and presentation of the link' anchor='link_transmission'>
<section2 topic='Out-of-band Transmission and Presentation of the Link' anchor='link_transmission'>
<p>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 <strong>xmpp:</strong> URIs, there is no mechanism to ensure that Juliet actually has a client installed that can open the URI.</p>
<p>One way to solve this problem is to present Juliet with a web-based landing page that contains the following elements:</p>
<ul>
@ -189,7 +189,7 @@ https://juicyxmpp.example/i/#romeo@montague.net?preauth=1tMFqYDdKhfe2pwp;name=Ro
</section2>
<section2 topic='Subcription request to the user by the link receiver (new contact)' anchor='link_transmission'>
<section2 topic='Subcription Request to the User by the Link Receiver (New Contact)' anchor='link_transmission'>
<p>When Juliet opens the <strong>xmpp:</strong> 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
@ -251,14 +251,14 @@ https://juicyxmpp.example/i/#romeo@montague.net?preauth=1tMFqYDdKhfe2pwp;name=Ro
</section2>
</section1>
<section1 topic='Business Rules' anchor='rules'>
<section2 topic='Fallback to manual process' anchor='rules_fallback'>
<section2 topic='Fallback to Manual Process' anchor='rules_fallback'>
<p>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.</p>
</section2>
<section2 topic='No expectaion of immediate approval' anchor='rules_expectation'>
<section2 topic='No Expectaion of Immediate Approval' anchor='rules_expectation'>
<p>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
@ -327,14 +327,14 @@ https://juicyxmpp.example/i/#romeo@montague.net?preauth=1tMFqYDdKhfe2pwp;name=Ro
</section2>
</section1>
<section1 topic='Usability Considerations' anchor='usability'>
<section2 topic='Use of multiple clients' anchor='rules_multiclient'>
<section2 topic='Use of Multiple Clients' anchor='rules_multiclient'>
<p>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.</p>
</section2>
<section2 topic='Opening the landing page in an app' anchor='rules_multiclient'>
<section2 topic='Opening the Landing Page in an App' anchor='rules_multiclient'>
<p>Some mobile device platforms allow an app to register itself as a
handler for cetain URIs. This allows an XMPP client to register for <strong>xmpp:</strong>
URIs, but also to redirect handling of cetain HTTP/HTTPS URIs. A mobile