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

cleared up confusion regarding available presence

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1847 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-05-16 03:40:03 +00:00
parent 40a0040e0b
commit 1be2d4b636
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0155.xml
View File

@ -663,7 +663,7 @@ PENDING o---------------+
</section2> </section2>
<section2 topic='Unavailable Presence' anchor='impl-unavail'> <section2 topic='Unavailable Presence' anchor='impl-unavail'>
<p>If a party receives an XMPP presence stanza of type "unavailable" from the full JID &LOCALFULL; of the other party (i.e., the resource with which it has had an active session) during a session, the receiving party SHOULD assume that the other client will still be able to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated session until it reconnects and receives "offline" messages).</p> <p>If a party receives an XMPP presence stanza of type "unavailable" from the full JID &LOCALFULL; of the other party (i.e., the resource with which it has had an active session) during a session, the receiving party SHOULD assume that the other client will still be able to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated session until it reconnects and receives "offline" messages).</p>
<p>However, the receiving party MAY assume that the other client will <em>not</em> be able to continue the session. <note>In general, if a party is not subscribing to the other party's presence then it will never assume the other party is is unable to continue a session.</note> In that case it MUST explicitly terminate the session (see <link url='#terminate'>Terminating a Session</link>) -- since its assumption could be incorrect. If after terminating the session the receiving party later receives presence of type "available" from that same resource or another resource associated with the other party and the receiving party desires to restart the session, then it MUST initiate a new session (including a newly-generated ThreadID) with the other party. It MUST NOT renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in <cite>XEP-0085</cite>.)</p> <p>However, the receiving party MAY assume that the other client will <em>not</em> be able to continue the session. <note>In general, if a party is not subscribing to the other party's presence then it will never assume the other party is is unable to continue a session.</note> In that case it MUST explicitly terminate the session (see <link url='#terminate'>Terminating a Session</link>) -- since its assumption could be incorrect. If after terminating the session the receiving party later receives available presence (i.e., a &PRESENCE; stanza with no 'type' attribute) from that same resource or another resource associated with the other party and the receiving party desires to restart the session, then it MUST initiate a new session (including a newly-generated ThreadID) with the other party. It MUST NOT renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in <cite>XEP-0085</cite>.)</p>
</section2> </section2>
<section2 topic='Mapping to SIP' anchor='impl-sip'> <section2 topic='Mapping to SIP' anchor='impl-sip'>
<p>When mapping instant messaging flows to SIP, implementations SHOULD adhere to &xmppsimple;.</p> <p>When mapping instant messaging flows to SIP, implementations SHOULD adhere to &xmppsimple;.</p>