moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-22 09:12:19 -05:00
Code Issues Releases Wiki Activity

XEP-0389: fix various typos and misspellings

Browse Source
This commit is contained in:
Sam Whited 2020-04-22 10:13:29 -04:00
parent 4850b2f5a7
commit dc89a31211
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
xep-0389.xml
View File

@ -87,7 +87,7 @@
To solve these issues this specification provides a new in-band registration To solve these issues this specification provides a new in-band registration
protocol that allows servers to present the user with a series of protocol that allows servers to present the user with a series of
"challenges". "challenges".
This allows for both multi-stage proof-of-posession registration flows and This allows for both multi-stage proof-of-possession registration flows and
spam prevention mechanisms such as proof-of-work functions. spam prevention mechanisms such as proof-of-work functions.
</p> </p>
</section1> </section1>
@ -140,7 +140,7 @@
continue. continue.
</li> </li>
<li> <li>
As a server operator I want to prevent SPIM using a proof-of-posession As a server operator I want to prevent SPIM using a proof-of-possession
protocol so I present the user with a form asking for a mobile phone protocol so I present the user with a form asking for a mobile phone
number and then send a verification code to that number via SMS and show number and then send a verification code to that number via SMS and show
another form requesting the verification code. another form requesting the verification code.
@ -302,7 +302,7 @@
<p> <p>
After a challenge is received, the client replies to the challenge by After a challenge is received, the client replies to the challenge by
sending a &lt;response/&gt; element qualified by the 'urn:xmpp:register:0' sending a &lt;response/&gt; element qualified by the 'urn:xmpp:register:0'
namespace or a cancelation as defined later in this document. namespace or a cancellation as defined later in this document.
If the client sends a response, it MUST also include a payload defined by If the client sends a response, it MUST also include a payload defined by
the specific challenge type. the specific challenge type.
In the case of a jabber:x:data challenge, the payload should be a form In the case of a jabber:x:data challenge, the payload should be a form
@ -348,8 +348,8 @@
wishes to cancel the flow, it MAY respond to any IQ from the client with the wishes to cancel the flow, it MAY respond to any IQ from the client with the
cancel element and type "result". cancel element and type "result".
</p> </p>
<example caption='Server cancels rquest'><![CDATA[ <example caption='Server cancels request'><![CDATA[
<iq type="result" id="bar"> <iq type='result' id='bar'>
<cancel xmlns='urn:xmpp:register:0'/> <cancel xmlns='urn:xmpp:register:0'/>
</iq>]]></example> </iq>]]></example>
<p> <p>
@ -367,8 +367,8 @@
If the IQ based flow is being used and the server wishes to indicate success If the IQ based flow is being used and the server wishes to indicate success
it sends an empty IQ response of type "result". it sends an empty IQ response of type "result".
</p> </p>
<example caption='Server indicates success after stream negotation'><![CDATA[ <example caption='Server indicates success after stream negotiation'><![CDATA[
<iq type="result" id="bar" />]]></example> <iq type='result' id='bar' />]]></example>
</section1> </section1>
<section1 topic='Internationalization Considerations' anchor='i18n'> <section1 topic='Internationalization Considerations' anchor='i18n'>
<p> <p>
@ -387,7 +387,7 @@
Servers that allow in-band registration need to take measures to prevent Servers that allow in-band registration need to take measures to prevent
abuse. abuse.
Common techniques to prevent spam registrations include displaying CAPTCHAs Common techniques to prevent spam registrations include displaying CAPTCHAs
or requiring proof-of-posession of a valid email address or telephone number or requiring proof-of-possession of a valid email address or telephone number
by sending a unique code (e.g. an HMAC that can later be verified as having by sending a unique code (e.g. an HMAC that can later be verified as having
originated at the server) to the users email and requiring that they enter originated at the server) to the users email and requiring that they enter
the code before continuing. the code before continuing.