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

1.5pre19: Council feedbaack from Kevin Smith

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1651 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-02-04 18:20:43 +00:00
parent 4d15d5f0c0
commit 930fb40f7e
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
xep-0115.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>Entity Capabilities</title>
<abstract>This document defines an XMPP protocol extension for broadcasting and dynamically discovering client, device, or generic entity capabilities. In order to minimize network impact, the transport mechanism is standard XMPP presence broadcast (thus forestalling the need for polling related to service discovery data), the capabilities information can be cached either within a session or across sessions. and the format has been kept as small as possible.</abstract>
<abstract>This document defines an XMPP protocol extension for broadcasting and dynamically discovering client, device, or generic entity capabilities. In order to minimize network impact, the transport mechanism is standard XMPP presence broadcast (thus forestalling the need for polling related to service discovery data), the capabilities information can be cached either within a session or across sessions, and the format has been kept as small as possible.</abstract>
&LEGALNOTICE;
<number>0115</number>
<status>Draft</status>
@ -34,8 +34,8 @@
<jid>jajcus@jabber.bnet.pl</jid>
</author>
<revision>
<version>1.5pre18</version>
<date>in progress, last updated 2008-01-29</date>
<version>1.5pre19</version>
<date>in progress, last updated 2008-02-04</date>
<initials>jjh/psa</initials>
<remark>
<ul>
@ -224,7 +224,7 @@
<li>Clients must be able to participate even if they support only &xmppcore;, &xmppim;, and <cite>XEP-0030</cite>.</li>
<li>Clients must be able to participate even if they are on networks without connectivity to other XMPP servers, services offering specialized XMPP extensions, or HTTP servers.<note>These first two requirements effectively eliminated <cite>XEP-0060</cite> as a possible implementation of entity capabilities.</note></li>
<li>Clients must be able to retrieve information without querying every entity with which they communicate.</li>
<li>Since presence is normally broadcasted to many contacts, the byte size of the proposed extension must be as small as possible.</li>
<li>Since presence is normally broadcast to many contacts, the byte size of the proposed extension must be as small as possible.</li>
<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>
@ -513,10 +513,10 @@
</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 OPTIONAL 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 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>
</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 broadcasted presence. Until and unless capabilities information has not been received from another entity, an application MUST assume that the other entity does not support capabilities.</p>
<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>