moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-28 04:02:20 -05:00
Code Issues Releases Wiki Activity

added reference to XEP-0201 and encouraged (or required) use (inclusion) of thread ids (when used)

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@601 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Ian Paterson 2007-02-16 23:33:30 +00:00
parent e642a594a8
commit 8d2a1f1737
1 changed files with 12 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
xep-0136.xml
View File

@ -425,7 +425,7 @@
<li>'start' (the UTC start time of the conversation thread, which MUST be UTC and adhere to the DateTime format specified in &xep0082;)</li>
</ul>
<p>A friendly name for the collection MAY be specified with a 'subject' attribute. Note the <link url='#security-subject'>Security Considerations</link> regarding the subject attribute.</p>
<p>The opaque thread ID of the conversation (found in the &THREAD; children of the &MESSAGE; elements whose content is stored in the collection) MAY be specified with a 'thread' attribute.</p>
<p>If an opaque thread ID (found in the &THREAD; children of the &MESSAGE; elements whose content is stored in the collection) is associated with the conversation then it MUST be specified with a 'thread' attribute. Clients SHOULD include a &THREAD; child in each &MESSAGE; element they send that is part of a conversation they expect will be archived (see &xep0201;).</p>
<p>Note: The content of &MESSAGE; elements that have different thread IDs SHOULD be archived in separate collections. The content of &MESSAGE; elements that have the same thread IDs SHOULD be archived in the same collection. The thread attribute SHOULD NOT be set to any value other than the exact content of the &THREAD; elements. If no &THREAD; elements appeared in the conversation the &lt;chat/&gt; element SHOULD have no thread attribute. Implementations SHOULD use the thread attribute for cross-referencing purposes only, within the archive each collection MUST be uniquely identified by the combination of its 'with' and 'start' attributes.</p>
<p>Each collection MAY contain &lt;note/&gt;, &lt;to/&gt; or &lt;from/&gt; elements (or &lt;EncryptedData/&gt; and &lt;EncryptedKey/&gt; elements - see <link url='#crypt'>Encryption</link>).</p>
<p>The text of each individual private note MUST be encapsulated in a &lt;note/&gt; element. The absolute time the note was created SHOULD be specified with a 'utc' attribute (which MUST be UTC and adhere to the DateTime format specified in <cite>Jabber Date and Time Profiles</cite>).</p>
@ -1182,7 +1182,7 @@
<p>When retrieving collections, it is RECOMMENDED that the client adjusts the start times of the collections it receives from server to be synchronized with the clock of the client machine.</p>
</section2>
<section2 topic='Bandwidth Considerations' anchor='impl-bandwidth'>
<p>When uploading messages using manual archiving, a client SHOULD NOT upload one message at a time on the server since this increases both bandwidth consumption and the total number of transactions. It is instead RECOMMENDED that clients upload messages only when the conversation thread <em>appears</em> to be terminated, e.g. when the user closes the chat window. If the user reopens the window and the thread continues then the client should append the new messages to the collection when the user closes the window again.</p>
<p>When uploading messages using manual archiving, a client SHOULD NOT upload one message at a time to the server since this increases both bandwidth consumption and the total number of transactions. It is instead RECOMMENDED that clients upload messages only when the conversation thread <em>appears</em> to be terminated, e.g. when the user closes the chat window. If the user reopens the window and the thread continues then the client should append the new messages to the collection when the user closes the window again.</p>
</section2>
<section2 topic='Storage Considerations' anchor='impl-storage'>
<p>Server implementations SHOULD give system administrators the option to disable support for both automated and manual archiving, since archived conversations can consume significant storage space.</p>
@ -1337,6 +1337,8 @@
<xs:element name='body' type='xs:string' minOccurs='0' maxOccurs='unbounded'/>
<xs:any processContents='lax' namespace='##other' minOccurs='0' maxOccurs='unbounded'/>
</xs:sequence>
<xs:attribute name='jid' type='xs:string' use='optional'/>
<xs:attribute name='name' type='xs:string' use='optional'/>
<xs:attribute name='secs' type='xs:nonNegativeInteger' use='optional'/>
<xs:attribute name='utc' type='xs:dateTime' use='optional'/>
</xs:complexType>
@ -1393,6 +1395,14 @@
</xs:complexType>
</xs:element>
<xs:element name='feature'>
<xs:complexType>
<xs:sequence>
<xs:element ref='default' minOccurs='0' maxOccurs='1'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='item'>
<xs:complexType>
<xs:simpleContent>
@ -1539,14 +1549,6 @@
</xs:complexType>
</xs:element>
<xs:element name='feature'>
<xs:complexType>
<xs:sequence>
<xs:element ref='default' minOccurs='0' maxOccurs='1'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>