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

typos

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1696 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-02-22 09:51:08 +00:00
parent e37ce1e77c
commit 1da2b4246e
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
xep-0115.xml
View File

@ -228,7 +228,7 @@
<li>It must be possible to write a XEP-0045 server implementation that passes the given information along.</li>
<li>It must be possible to publish a change in capabilities within a single presence session.</li>
<li>Server infrastructure above and beyond that defined in <cite>XMPP Core</cite> and <cite>XMPP IM</cite> must not be required for this approach to work, although additional server infrastructure may be used for optimization purposes.</li>
<li>The defined mechanism must not be limited to clients but must be usable be servers, components, and other network entities.</li>
<li>The defined mechanism must not be limited to clients but must be usable by servers, components, and other network entities.</li>
</ol>
</section1>
@ -484,7 +484,7 @@
</query>
</iq>
]]></example>
<p>If a server supports the <link url='#optimization'>Server Optimization</link> functionality, it MUST also return a feature of <strong>'http://jabber.org/protocol/caps#optimize'</strong> in response to service discovery information requests.</p>
<p>If a server supports the <link url='#impl-optimize'>Caps Optimization</link> functionality, it MUST also return a feature of <strong>'http://jabber.org/protocol/caps#optimize'</strong> in response to service discovery information requests.</p>
<example caption="Service discovery information request"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
id='disco3'
@ -513,14 +513,14 @@
</section2>
<section2 topic='Caching' anchor='impl-cache'>
<p>It is RECOMMENDED for an application that processes entity capabilities information to cache associations between the verification string and discovered identity+features within the scope of one presence session. This obviates the need for extensive service discovery requests within a session.</p>
<p>It is RECOMMENDED for an application to cache associates across presence sessions. However, since this obviates the need for extensive service discovery requests at the beginning of a session, such caching is strongly encouraged, especially in bandwidth-constrained environments.</p>
<p>It is RECOMMENDED for an application to cache associations across presence sessions, since this obviates the need for extensive service discovery requests at the beginning of a session (this is especially helpful in bandwidth-constrained environments).</p>
</section2>
<section2 topic='Directed Presence' anchor='impl-presence'>
<p>If two entities exchange messages but they do not normally exchange presence (i.e., via presence subscription), the entities MAY choose to send directed presence to each other, where the presence information SHOULD be annotated with the same capabilities information as each entity sends in presence broadcasts. Until and unless capabilities information has been received from another entity, an application MUST assume that the other entity does not support capabilities.</p>
</section2>
<section2 topic='Caps Optimization' anchor='impl-optimize'>
<p>A server that is managing an connected client's presence session MAY optimize presence notification traffic sent through the server by stripping off redundant capabilities annotations. Because of this, receivers of presence notifications MUST NOT expect an annotation on every presence notification they receive. If the server performs caps optimization, it MUST ensure that the first presence notification each subscriber receives contains the annotation. The server MUST also ensure that any changes in the caps information (e.g., an updated 'ver' attribute) are sent to all subscribers.</p>
<p>If a connected client determines that its server supports caps optimization, MAY choose to send the capabilities annotation only on the first presence packet, as well as whenever its capabilities change.</p>
<p>If a connected client determines that its server supports caps optimization, it MAY choose to send the capabilities annotation only on the first presence packet, as well as whenever its capabilities change.</p>
</section2>
</section1>