moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -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
protocol that allows servers to present the user with a series of
"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.
</p>
</section1>
@ -140,7 +140,7 @@
continue.
</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
number and then send a verification code to that number via SMS and show
another form requesting the verification code.
@ -302,7 +302,7 @@
<p>
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'
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
the specific challenge type.
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
cancel element and type "result".
</p>
<example caption='Server cancels rquest'><![CDATA[
<iq type="result" id="bar">
<example caption='Server cancels request'><![CDATA[
<iq type='result' id='bar'>
<cancel xmlns='urn:xmpp:register:0'/>
</iq>]]></example>
<p>
@ -367,8 +367,8 @@
If the IQ based flow is being used and the server wishes to indicate success
it sends an empty IQ response of type "result".
</p>
<example caption='Server indicates success after stream negotation'><![CDATA[
<iq type="result" id="bar" />]]></example>
<example caption='Server indicates success after stream negotiation'><![CDATA[
<iq type='result' id='bar' />]]></example>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>
@ -387,7 +387,7 @@
Servers that allow in-band registration need to take measures to prevent
abuse.
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
originated at the server) to the users email and requiring that they enter
the code before continuing.