moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

reverted some changes 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2203 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-09-04 16:36:27 +00:00
parent 7595a6f4e7
commit eb758f1f0d
1 changed files with 29 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
xep-0045.xml
View File

@ -62,7 +62,7 @@
<remark>
<ul>
<li>Defined getmemberlist room configuration option</li>
<li>Added direct invitation protoocol</li>
<li>Added direct invitation protocol</li>
<li>Corrected logic regarding admission of room owner/admin when room is full</li>
<li>Defined service discovery extension field for associated LDAP group</li>
<li>Specified that room config fields can be listed in extended room information</li>
@ -1764,8 +1764,12 @@
]]></example>
</section2>
<section2 topic='Inviting Another User to a Room' anchor='invite'>
<p>It can be useful to invite another user to a room in which one is an occupant. To do this, a MUC client MUST send XML of the following form to the &ROOM; itself (the reason is OPTIONAL and the message MUST be explicitly or implicitly of type "normal"):</p>
<example caption='Occupant Sends an Invitation by Way of Room'><![CDATA[
<section3 topic='Direct Invitation' anchor='invite-direct'>
<p>A method for sending a direct invitation (not mediated by the room itself) is defined in another specification. Sending the invitation directly can help to work around communications blocking on the part of the invitee (which might refuse communication with entities not in its roster).</p>
</section3>
<section3 topic='Mediated Invitation' anchor='invite-mediated'>
<p>It can be useful to invite another user to a room in which one is an occupant. To do this, a MUC client MUST send XML of the following form to the &ROOM; itself (the reason is OPTIONAL and the message MUST be explicitly or implicitly of type "normal"):</p>
<example caption='Occupant Sends an Invitation by Way of Room'><![CDATA[
<message
from='crone1@shakespeare.lit/desktop'
to='darkcave@macbeth.shakespeare.lit'>
@ -1777,9 +1781,9 @@
</invite>
</x>
</message>
]]></example>
<p>The &ROOM; itself MUST then add a 'from' address to the &lt;invite/&gt; element whose value is the bare JID, full JID, or room JID of the invitor and send the invitation to the invitee specified in the 'to' address (the service MAY include a message body explaining the invitation or containing the reason, for the sake of older clients; in addition, the room SHOULD add the password if the room is password-protected):</p>
<example caption='Room Sends Invitation to Invitee on Behalf of Invitor'><![CDATA[
]]></example>
<p>The &ROOM; itself MUST then add a 'from' address to the &lt;invite/&gt; element whose value is the bare JID, full JID, or room JID of the invitor and send the invitation to the invitee specified in the 'to' address (the service MAY include a message body explaining the invitation or containing the reason, for the sake of older clients; in addition, the room SHOULD add the password if the room is password-protected):</p>
<example caption='Room Sends Invitation to Invitee on Behalf of Invitor'><![CDATA[
<message
from='darkcave@macbeth.shakespeare.lit'
to='hecate@shakespeare.lit'>
@ -1792,12 +1796,11 @@
<password>cauldronburn</password>
</x>
</message>
]]></example>
<p>If the room is members-only, the service MAY also add the invitee to the member list. (Note: Invitation privileges in members-only rooms SHOULD be restricted to room admins; if a member without privileges to edit the member list attempts to invite another user, the service SHOULD return a &forbidden; error to the occupant; for details, see the <link url='#modifymember'>Modifying the Member List</link> section of this document.)</p>
<p>If the invitor supplies a non-existent JID, the room SHOULD return an &notfound; error to the invitor.</p>
<p>The invitee MAY choose to formally decline (as opposed to ignore) the invitation; and this is something that the sender may want to be informed about. In order to decline the invitation, the invitee MUST send a message of the following form to the &ROOM; itself:</p>
<example caption='Invitee Declines Invitation'><![CDATA[
]]></example>
<p>If the room is members-only, the service MAY also add the invitee to the member list. (Note: Invitation privileges in members-only rooms SHOULD be restricted to room admins; if a member without privileges to edit the member list attempts to invite another user, the service SHOULD return a &forbidden; error to the occupant; for details, see the <link url='#modifymember'>Modifying the Member List</link> section of this document.)</p>
<p>If the invitor supplies a non-existent JID, the room SHOULD return an &notfound; error to the invitor.</p>
<p>The invitee MAY choose to formally decline (as opposed to ignore) the invitation; and this is something that the sender may want to be informed about. In order to decline the invitation, the invitee MUST send a message of the following form to the &ROOM; itself:</p>
<example caption='Invitee Declines Invitation'><![CDATA[
<message
from='hecate@shakespeare.lit/broom'
to='darkcave@macbeth.shakespeare.lit'>
@ -1809,8 +1812,8 @@
</decline>
</x>
</message>
]]></example>
<example caption='Room Informs Invitor that Invitation Was Declined'><![CDATA[
]]></example>
<example caption='Room Informs Invitor that Invitation Was Declined'><![CDATA[
<message
from='darkcave@macbeth.shakespeare.lit'
to='crone1@shakespeare.lit/desktop'>
@ -1822,8 +1825,9 @@
</decline>
</x>
</message>
]]></example>
<p>It may be wondered why the invitee does not send the decline message directly to the invitor. The main reason is that certain implementations MAY choose to base invitations on room JIDs rather than bare JIDs (so that, for example, an occupant could invite someone from one room to another without knowing that person's bare JID). Thus the service MUST handle both the invites and declines.</p>
]]></example>
<p>It may be wondered why the invitee does not send the decline message directly to the invitor. The main reason is that certain implementations MAY choose to base invitations on room JIDs rather than bare JIDs (so that, for example, an occupant could invite someone from one room to another without knowing that person's bare JID). Thus the service MUST handle both the invites and declines.</p>
</section3>
</section2>
<section2 topic='Converting a One-to-One Chat Into a Multi-User Conference' anchor='continue'>
<p>Sometimes it is desirable to convert a one-to-one chat into a multi-user conference. The process flow is shown in the following examples.</p>
@ -2314,6 +2318,15 @@
<error type='auth'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</message>
]]></example>
<p>In order to remove the existing subject but not provide a new subject (i.e., set the subject to be empty), the client shall send an empty &lt;subject/&gt; element (i.e., either "&lt;subject/&gt;" or "&lt;subject&gt;&lt;/subject&gt;").</p>
<example caption='Moderator Sets Empty Subject'><![CDATA[
<message
from='wiccarocks@shakespeare.lit/laptop'
to='darkcave@macbeth.shakespeare.lit'
type='groupchat'>
<subject></subject>
</message>
]]></example>
</section2>
@ -4544,7 +4557,6 @@
<li>http://jabber.org/protocol/muc</li>
<li>http://jabber.org/protocol/muc#admin</li>
<li>http://jabber.org/protocol/muc#owner</li>
<li>http://jabber.org/protocol/muc#unique</li>
<li>http://jabber.org/protocol/muc#user</li>
</ul>
</section2>