From 8f061f2253101224f59accec1e1ad88a23106ab7 Mon Sep 17 00:00:00 2001
From: Ian Paterson <ian.paterson@clientside.co.uk>
Date: Fri, 20 Oct 2006 10:57:41 +0000
Subject: [PATCH] 0.10 RC2 specified offline request handling

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@118 4b5297f7-1745-476d-ba37-a9c6900126ab
---
 xep-0155.xml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xep-0155.xml b/xep-0155.xml
index a409dea8..9d4d439f 100644
--- a/xep-0155.xml
+++ b/xep-0155.xml
@@ -29,7 +29,7 @@
     <version>0.10</version>
     <date>2006-10-20</date>
     <initials>ip</initials>
-    <remark><p>Enhanced implementation notes; added AMP note.</p></remark>
+    <remark><p>Specified handling of offline requests.</p></remark>
   </revision>
   <revision>
     <version>0.9</version>
@@ -170,8 +170,8 @@
   </amp>
 </message>
     ]]></example>
-    <p>The contact's server delivers the request to the contact's most available resource (which in the examples below happens to be "balcony").</p>
-    <p>In any response to the request, the contact's client MUST mirror any 'id' attribute and &THREAD; value so that the user's client can correctly track the response.</p>
+    <p>The contact's server delivers the request to the contact's most available resource (which in the examples below happens to be "balcony"). If no resource is available (and no <cite>Advanced Message Processing</cite> rule included in the request specifies otherwise) then the server MAY store the request for later delivery. In this case, if the contact is interested only in an immediate chat session when it eventually receives the request, it SHOULD initiate a new chat session negotiation (including a newly-generated ThreadID) instead of responding to the user's request. Note: Sending any response to the user's original request would leak presence information since it would divulge the fact that the contact had been offline rather than just ignoring the user.</p>
+    <p>In any response to the user's request, the contact's client MUST mirror any 'id' attribute and &THREAD; value so that the user's client can correctly track the response.</p>
     <p>If the contact's client does not support one of the default values or if the contact has disabled its support (as for Chat State Notifications and XHTML formatting in the example below), and the client can still accept the request, then it MUST set that field to a value that it can support.</p>
     <p>In the example below we assume that Juliet accepts the chat and specifies that she prefers to speak Italian with Romeo:</p>
     <example caption="Contact accepts offer and specifies parameters"><![CDATA[