moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 15:18:51 -05:00
Code Issues Releases Wiki Activity

1.22

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@741 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-04-10 19:38:10 +00:00
parent 99a8719023
commit 3db71d4909
1 changed files with 26 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
xep-0045.xml
View File

@ -49,6 +49,12 @@
</schemaloc>
<registry/>
&stpeter;
<revision>
<version>1.22</version>
<date>2007-04-10</date>
<initials>psa</initials>
<remark><p>Updated delayed delivery reference to reflect advancement of XEP-0203 to Draft and deprecation of XEP-0091.</p></remark>
</revision>
<revision>
<version>1.21</version>
<date>2006-09-13</date>
@ -61,7 +67,7 @@
<li>Specified use of &lt;not-acceptable/&gt; error if room configuration options cannot be processed or violate service policies.</li>
<li>Made explicit that roomnicks must not consist only of spaces.</li>
<li>Moved all service discovery use cases into dedicated section.</li>
<li>Changed jabber:x:delay support from SHOULD to MUST.</li>
<li>Changed urn:xmpp:delay support from SHOULD to MUST.</li>
<li>Clarified that _whois room configuration option specifies room type.</li>
<li>Defined XEP-0128 room information fields for discussion logs, associated pubsub node, and contact JID.</li>
<li>Specified that changing role to moderator upon affiliation change to admin or owner is recommended, not required.</li>
@ -1373,9 +1379,9 @@
to='hecate@shakespeare.lit/broom'
type='groupchat'>
<body>Thrice the brinded cat hath mew'd.</body>
<x xmlns='jabber:x:delay'
<x xmlns='urn:xmpp:delay'
from='crone1@shakespeare.lit/desktop'
stamp='20021013T23:58:37'/>
stamp='2002-10-13T23:58:37'/>
</message>
<message
@ -1383,9 +1389,9 @@
to='hecate@shakespeare.lit/broom'
type='groupchat'>
<body>Thrice and once the hedge-pig whined.</body>
<x xmlns='jabber:x:delay'
<x xmlns='urn:xmpp:delay'
from='wiccarocks@shakespeare.lit/laptop'
stamp='20021013T23:58:43'/>
stamp='2002-10-13T23:58:43'/>
</message>
<message
@ -1393,12 +1399,12 @@
to='hecate@shakespeare.lit/broom'
type='groupchat'>
<body>Harpier cries 'Tis time, 'tis time.</body>
<x xmlns='jabber:x:delay'
<x xmlns='urn:xmpp:delay'
from='hag66@shakespeare.lit/pda'
stamp='20021013T23:58:49'/>
stamp='2002-10-13T23:58:49Z'/>
</message>
]]></example>
<p>Discussion history messages MUST be stamped with extended information qualified by the 'jabber:x:delay' namespace (see &xep0091;) to indicate that they are sent with delayed delivery and specify the times at which they were originally sent. The 'from' attribute SHOULD be the full JID of the original sender in non-anonymous rooms, but MUST NOT be in semi-anonymous rooms (the 'from' attribute SHOULD be set to the room JID in semi-anonymous rooms). The service SHOULD send all discussion history messages before delivering any "live" messages sent after the user enters the room.</p>
<p>Discussion history messages MUST be stamped with &xep0203; information qualified by the 'urn:xmpp:delay' namespace to indicate that they are sent with delayed delivery and to specify the times at which they were originally sent. (Note: The 'urn:xmpp:delay' namespace defined in <cite>XEP-0203</cite> supersedes the older 'jabber:x:delay' namespace defined in &xep0091;; until the status of <cite>XEP-0091</cite> is changed to Obsolete, implementations SHOULD include both datetime formats.) The 'from' attribute SHOULD be the full JID of the original sender in non-anonymous rooms, but MUST NOT be in semi-anonymous rooms (where the 'from' attribute SHOULD be set to the JID of the room itself). The service SHOULD send all discussion history messages before delivering any "live" messages sent after the user enters the room.</p>
</section3>
<section3 topic='Managing Discussion History' anchor='enter-managehistory'>
<p>A user MAY want to manage the amount of discussion history provided on entering a room (perhaps because the user is on a low-bandwidth connection or is using a small-footprint client). This MUST be accomplished by including a &lt;history/&gt; child in the initial presence stanza sent when joining the room. There are four allowable attributes for this element:</p>
@ -1764,9 +1770,9 @@
to='darkcave@macbeth.shakespeare.lit'
type='groupchat'>
<body>Thrice the brinded cat hath mew'd.</body>
<x xmlns='jabber:x:delay'
<x xmlns='urn:xmpp:delay'
from='crone1@shakespeare.lit/desktop'
stamp='20040929T01:54:37'/>
stamp='20040929T01:54:37Z'/>
</message>
<message
@ -1774,9 +1780,9 @@
to='darkcave@macbeth.shakespeare.lit'
type='groupchat'>
<body>Thrice and once the hedge-pig whined.</body>
<x xmlns='jabber:x:delay'
<x xmlns='urn:xmpp:delay'
from='wiccarocks@shakespeare.lit/laptop'
stamp='20040929T01:55:21'/>
stamp='20040929T01:55:21Z'/>
</message>
]]></example>
<p>Note: Use of the <cite>Delayed Delivery</cite> protocol enables the room creator to specify the datetime of each message from the one-to-one chat history (via the 'stamp' attribute), as well as the JID of the original sender of each message (via the 'from' attribute). The room creator SHOULD send the complete one-to-one chat history before inviting additional users to the room, and SHOULD also send as history any messages appearing in the one-to-one chat interface after joining the room and before the second person joins the room; if the one-to-one history is especially large, the sending client may want to send the history over a few seconds rather than all at once (to avoid triggering rate limits). The service SHOULD NOT add its own delay elements (as described in the <link url='#enter-history'>Discussion History</link> section of this document) to prior chat history messages received from the room owner.</p>
@ -1850,7 +1856,7 @@
to='wiccarocks@shakespeare.lit/laptop'
type='groupchat'>
<body>Thrice the brinded cat hath mew'd.</body>
<x xmlns='jabber:x:delay'
<x xmlns='urn:xmpp:delay'
from='crone1@shakespeare.lit/desktop'
stamp='20040929T01:54:37'/>
</message>
@ -1860,7 +1866,7 @@
to='wiccarocks@shakespeare.lit/laptop'
type='groupchat'>
<body>Thrice and once the hedge-pig whined.</body>
<x xmlns='jabber:x:delay'
<x xmlns='urn:xmpp:delay'
from='wiccarocks@shakespeare.lit/laptop'
stamp='20040929T01:55:21'/>
</message>
@ -3112,7 +3118,7 @@
<li><p>Once the service receives the completed configuration form from the initial room owner (or receives a request for an instant room), the service MUST "unlock" the room (i.e., allow other users to enter the room) and send an IQ of type "result" to the room owner. If the service receives a cancellation, it MUST destroy the room.</p></li>
</ol>
<p>The protocol for this workflow is shown in the examples below.</p>
<p>First, the Jabber user MUST send presence to the room, including and empty &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc' namespace (this is the same stanza sent when seeking to enter a room).</p>
<p>First, the Jabber user MUST send presence to the room, including an empty &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc' namespace (this is the same stanza sent when seeking to enter a room).</p>
<example caption='Jabber User Creates a Room and Signals Support for Multi-User Chat'><![CDATA[
<presence
from='crone1@shakespeare.lit/desktop'
@ -4329,7 +4335,7 @@
</form_type>
]]></code>
</section3>
<section3 topic='muc#register FORM_TYPE' anchor='registrar-formtype-submission'>
<section3 topic='muc#request FORM_TYPE' anchor='registrar-formtype-request'>
<code caption='Registry Submission'><![CDATA[
<form_type>
<name>http://jabber.org/protocol/muc#request</name>
@ -4521,7 +4527,9 @@
<number>104</number>
<stanza>message</stanza>
<context>Configuration change</context>
<purpose>Inform occupants that a non-privacy-related room configuration change has occurred</purpose>
<purpose>
Inform occupants that a non-privacy-related room configuration change has occurred
</purpose>
</statuscode>
<statuscode>
<number>110</number>
@ -4569,7 +4577,7 @@
<number>210</number>
<stanza>presence</stanza>
<context>Entering a room</context>
<purpose>Inform user that the service has assigned or modified the occupant's roomnick</purpose>
<purpose>Inform user that service has assigned or modified occupant's roomnick</purpose>
</statuscode>
<statuscode>
<number>301</number>