XEP-0045: Typo and whitespace fixes

This commit is contained in:
Sam Whited 2016-12-03 10:18:14 -06:00
parent ff0ef6d212
commit 337e41f925
1 changed files with 47 additions and 40 deletions

View File

@ -45,6 +45,14 @@
</schemaloc>
<registry/>
&stpeter;
<revision>
<version>1.27.1</version>
<date>2016-12-03</date>
<initials>XEP Editor: ssw</initials>
<remark>
<p>Editorial typo and whitespace fixes.</p>
</remark>
</revision>
<revision>
<version>1.27</version>
<date>2016-10-29</date>
@ -52,7 +60,6 @@
<remark>
<ul>
<li>Clarify behavior on MUC join.</li>
<li></li>
</ul>
</remark>
</revision>
@ -1173,39 +1180,39 @@
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/muc#roominfo</value>
</field>
<field var='muc#roominfo_description'
<field var='muc#roominfo_description'
label='Description'>
<value>The place for all good witches!</value>
</field>
<field var='muc#roominfo_changesubject'
<field var='muc#roominfo_changesubject'
label='Occupants May Change the Subject'>
<value>true</value>
</field>
<field var='muc#roominfo_contactjid'
<field var='muc#roominfo_contactjid'
label='Contact Addresses'>
<value>crone1@shakespeare.lit</value>
</field>
<field var='muc#roominfo_subject'
<field var='muc#roominfo_subject'
label='Current Discussion Topic'>
<value>Spells</value>
</field>
<field var='muc#roomconfig_changesubject'
<field var='muc#roomconfig_changesubject'
label='Subject can be modified'>
<value>true</value>
</field>
<field var='muc#roominfo_occupants'
<field var='muc#roominfo_occupants'
label='Number of occupants'>
<value>3</value>
</field>
<field var='muc#roominfo_ldapgroup'
<field var='muc#roominfo_ldapgroup'
label='Associated LDAP Group'>
<value>cn=witches,dc=shakespeare,dc=lit</value>
</field>
<field var='muc#roominfo_lang'
<field var='muc#roominfo_lang'
label='Language of discussion'>
<value>en</value>
</field>
<field var='muc#roominfo_logs'
<field var='muc#roominfo_logs'
label='URL for discussion logs'>
<value>http://www.shakespeare.lit/chatlogs/coven/</value>
</field>
@ -1213,7 +1220,7 @@
label='Maximum Number of History Messages Returned by Room'>
<value>50</value>
</field>
<field var='muc#roominfo_pubsub'
<field var='muc#roominfo_pubsub'
label='Associated pubsub node'>
<value>xmpp:pubsub.shakespeare.lit?;node=the-coven-node</value>
</field>
@ -1449,7 +1456,7 @@
</error>
</presence>
]]></example>
<p>If the user has connected using a MUC client (as indicated on joining the room by inclusino of the MUC extension), then the service MUST allow the client to enter the room, modify the nick in accordance with the lockdown policy, and include a status code of "210" in the presence broadcast that it sends to the new occupant.</p>
<p>If the user has connected using a MUC client (as indicated on joining the room by inclusion of the MUC extension), then the service MUST allow the client to enter the room, modify the nick in accordance with the lockdown policy, and include a status code of "210" in the presence broadcast that it sends to the new occupant.</p>
<example caption="Service Sends New Occupant's Presence to New Occupant"><![CDATA[
<presence
from='coven@chat.shakespeare.lit/thirdwitch'
@ -1848,7 +1855,7 @@
</tr>
</table>
</section3>
</section2>
<section2 topic='Occupant Modification of the Room Subject' anchor='subject-occupant'>
@ -2212,7 +2219,7 @@
<ol start='1'>
<li>Creates a new multi-user chatroom</li>
<li>Sends history of the one-to-one chat to the room (this is purely discretionary; however, because it might cause information leakage, the client ought to warn the user before doing so)</li>
<li>Sends an invitation to the second person and the third person, including a &lt;continue/&gt; element (optionally including a 'thread' attribute).</li>
<li>Sends an invitation to the second person and the third person, including a &lt;continue/&gt; element (optionally including a 'thread' attribute).</li>
</ol>
<p>Note: The new room SHOULD be non-anonymous and MAY be an instant room as specified in the <link url='#createroom-instant'>Creating an Instant Room</link> section of this document.</p>
<p>Note: If the one-to-one chat messages included a &THREAD; element, the person who creates the room SHOULD include the ThreadID with the history messages, specify the ThreadID in the invitations as the value of the &lt;continue/&gt; element's 'thread' attribute, and include the ThreadID in any new messages sent to the room. Use of ThreadIDs is RECOMMENDED because it helps to provide continuity between the one-to-one chat and the multi-user chat.</p>
@ -2615,7 +2622,7 @@
to='hag66@shakespeare.lit/pda'
type='unavailable'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='member'
<item affiliation='member'
jid='hag66@shakespeare.lit/pda'
role='none'/>
<status code='110'/>
@ -2630,7 +2637,7 @@
to='hag66@shakespeare.lit/pda'
type='unavailable'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='member'
<item affiliation='member'
jid='hag66@shakespeare.lit/pda'
role='none'/>
<status code='110'/>
@ -2641,7 +2648,7 @@
to='crone1@shakespeare.lit/desktop'
type='unavailable'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='member'
<item affiliation='member'
jid='hag66@shakespeare.lit/pda'
role='none'/>
</x>
@ -2651,7 +2658,7 @@
to='wiccarocks@shakespeare.lit/laptop'
type='unavailable'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='member'
<item affiliation='member'
jid='hag66@shakespeare.lit/pda'
role='none'/>
</x>
@ -3004,9 +3011,9 @@
<x xmlns='jabber:x:data' type='form'>
<title>Voice request</title>
<instructions>
To approve this request for voice, select
To approve this request for voice, select
the &quot;Grant voice to this person?&quot;
checkbox and click OK. To skip this request,
checkbox and click OK. To skip this request,
click the cancel button.
</instructions>
<field var='FORM_TYPE' type='hidden'>
@ -3292,7 +3299,7 @@
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='none'
jid='hag66@shakespeare.lit'>
<reason>Not so worthy after all!</reason>
<reason>Not so worthy after all!</reason>
</item>
</query>
</iq>
@ -3482,7 +3489,7 @@
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item nick='thirdwitch'
role='moderator'>
<reason>A worthy witch indeed!</reason>
<reason>A worthy witch indeed!</reason>
</item>
</query>
</iq>
@ -3532,7 +3539,7 @@
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item nick='thirdwitch'
role='participant'>
<reason>Not so worthy after all!</reason>
<reason>Not so worthy after all!</reason>
</item>
</query>
</iq>
@ -3643,7 +3650,7 @@
<instructions>
To approve this registration request, select the
&quot;Allow this person to register with the room?&quot;
checkbox and click OK. To skip this request, click the
checkbox and click OK. To skip this request, click the
cancel button.
</instructions>
<field var='FORM_TYPE' type='hidden'>
@ -4472,7 +4479,7 @@
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='admin'
jid='hecate@shakespeare.lit'>
<reason>Not so worthy after all!</reason>
<reason>Not so worthy after all!</reason>
</item>
</query>
</iq>
@ -4649,7 +4656,7 @@
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='none'
jid='wiccarocks@shakespeare.lit'>
<reason>Not so worthy after all!</reason>
<reason>Not so worthy after all!</reason>
</item>
</query>
</iq>
@ -4871,7 +4878,7 @@
<section2 topic='Information Leaks' anchor='security-leaks'>
<p>The "roominfo" data form used in extended service discovery can result in information leaks, e.g., the current discussion topic (via the "roominfo_subject" field). The same is true of service discovery items (disco#items) requests from outside the room (which could be used to discover the list of room occupants).</p>
<p>Implementations and deployments are advised to carefully consider the possibility that this information might be leaked, and to turn off information sharing by default for sensitive data.</p>
<p>Implementations and deployments are advised to carefully consider the possibility that this information might be leaked, and to turn off information sharing by default for sensitive data.</p>
</section2>
<section2 topic='Anonymity' anchor='security-anon'>
@ -5023,7 +5030,7 @@
Multi-User Chat (MUC) room or admin approval
of user registration requests.
</desc>
<field
<field
var='muc#register_allow'
type='boolean'
label='Allow this person to register with the room?'/>
@ -5061,7 +5068,7 @@
<name>http://jabber.org/protocol/muc#request</name>
<doc>XEP-0045</doc>
<desc>
Forms enabling voice requests in a
Forms enabling voice requests in a
Multi-User Chat (MUC) room or admin
approval of such requests.
</desc>
@ -5206,11 +5213,11 @@
<field
var='muc#roominfo_ldapgroup'
type='text-single'
label='An associated LDAP group that defines
room membership; this should be an LDAP
Distinguished Name according to an
implementation-specific or
deployment-specific definition of a
label='An associated LDAP group that defines
room membership; this should be an LDAP
Distinguished Name according to an
implementation-specific or
deployment-specific definition of a
group.'/>
<field
var='muc#roominfo_logs'
@ -5388,7 +5395,7 @@
<stanza>presence</stanza>
<context>Removal from room</context>
<purpose>
Inform user that he or she is being removed from the room
Inform user that he or she is being removed from the room
because of an affiliation change
</purpose>
</statuscode>
@ -5397,7 +5404,7 @@
<stanza>presence</stanza>
<context>Removal from room</context>
<purpose>
Inform user that he or she is being removed from the room
Inform user that he or she is being removed from the room
because the room has been changed to members-only and the
user is not a member
</purpose>
@ -5407,7 +5414,7 @@
<stanza>presence</stanza>
<context>Removal from room</context>
<purpose>
Inform user that he or she is being removed from the room
Inform user that he or she is being removed from the room
because the MUC service is being shut down
</purpose>
</statuscode>
@ -5423,7 +5430,7 @@
<example caption='Join Action: IRI/URI'><![CDATA[
xmpp:coven@chat.shakespeare.lit?join
]]></example>
<p>The application MUST either present an interface enabling the user to provide a room nickname or populate the room nickname based on configured preferences or nickname discovery.</p>
<p>The application MUST either present an interface enabling the user to provide a room nickname or populate the room nickname based on configured preferences or nickname discovery.</p>
<example caption='Join Action: Resulting Stanza'><![CDATA[
<presence to='coven@chat.shakespeare.lit/thirdwitch'>
<x xmlns='http://jabber.org/protocol/muc'/>
@ -5586,7 +5593,7 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld
<li><p>A MUC service MAY choose to make available a special in-room resource that provides an interface to administrative functionality (e.g., a "user" named "ChatBot"), which occupants could interact with directly, thus enabling admins to type <tt>'/command parameter'</tt> in a private message to that "user". Obviously this kind of implementation would require the service to add a 'ChatBot' user to the room when it is created, and to prevent any occupant from having the nickname 'ChatBot' in the room. This might be difficult to ensure in some implementations or deployments. In any case, any such interface is OPTIONAL.</p></li>
<li><p>A MUC service MAY choose to discard extended presence information that is attached to a &PRESENCE; stanza before reflecting the presence change to the occupants of a room. That is, an implementation MAY choose to reflect only the &lt;show/&gt;, &lt;status/&gt;, and &lt;priority/&gt; child elements of the presence element as specified in the XML schema for the 'jabber:client' namespace, with the result that presence "changes" in extended namespaces (e.g., gabber:x:music:info) are not passed through to occupants. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
<li><p>A MUC service MAY choose to discard extended information attached to a &MESSAGE; stanza before reflecting the message to the occupants of a room. An example of such extended information is the lightweight text markup specified by &xep0071;. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
<li><p>A MUC service MAY choose to "lock down" room nicknames (e.g., hardcoding the room nickname to the bare JID of the occupant). If so, the service MUST treat the locked nickname as a reserved room nickname and MUST support the protocol specified in the <link url='#reservednick'>Discovering Reserved Room Nickname</link> section of this document.</p></li>
<li><p>A MUC service MAY choose to "lock down" room nicknames (e.g., hardcoding the room nickname to the bare JID of the occupant). If so, the service MUST treat the locked nickname as a reserved room nickname and MUST support the protocol specified in the <link url='#reservednick'>Discovering Reserved Room Nickname</link> section of this document.</p></li>
</ol>
<section3 topic='Allowable Traffic' anchor='impl-service-traffic'>
@ -6033,7 +6040,7 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld
</xs:documentation>
</xs:annotation>
<xs:import
<xs:import
namespace='jabber:x:data'
schemaLocation='http://www.xmpp.org/schemas/x-data.xsd'/>