[standards-jig] Re: thoughts on POP3 Offline (JEP-0013)

Craig Kaes ckaes at jabber.com
Wed Nov 13 18:30:50 UTC 2002


I like this approach, Jean-Louis.  It meets about 95% of the need and 
all of your need.  For installations controlling both server and client, 
it is sufficient.  The case I'd like to be able to handle with feature 
negotiation that falls through the cracks in your approach is this:

1)  I have a client that supports POP3 offline.
2)  I'm connecting to a server that doesn't support POP3 offline.
3)  I do not ever want to be flooded with offline messages.

I do like the simplicity of your approach but it just can't handle a 
case like this -- I'd like the option to see a dialogue like "Only flood 
offline supported on server -- set presence to available anyway?"

A non-feature-negotiation patch to this would be to just send the header 
request from the client before sending initial presence.  If it errors, 
it must be unsupported....

--C

Jean-Louis Seguineau/EXC/TEC wrote:

>Peter,
>
>I do not totally aggree with your statement quote:
>  
>
>>   Without the ability to query a given client for feature sets,
>>   POP3-like offline message handling is incompatible with the
>>   existing offline model.
>>    
>>
>
>We have implemented a very simple model that allow both offline message
>handling to work together without resorting to the full feature negitiation>
>The offline message retrieval is triggered by the initial presence a client
>is sending to the server. If you ad an extension to the presence message,
>then the client has a way to advertise its support for a given namespace.
>The client sends the following snippet (this is an extract of our
>implementation of the offline management, hence the different namspace, but
>it can easily be converted):
>
><presence>
>
><show>Chat</show>
>
><status>Here I am again.</status>
>
><x xmlns='xmpp:x:omm'/>
>
>        </presence>
>
>and the server is answering with an headline message such as
>
><message type='headline' to='user at domain'>
>
><subject>Offline messages</subject>
>
><body>You have 4 offline messages waiting</body>
>
><x xmlns='xmpp:x:omm'>
>
><item jid='contact1 at domain' count='3'/>
>
><item jid='contact2 at domain'/>
>
></x>
>
>          </message>
>
>from then on you are back to using the normal iq to handle the rest of the
>dialog. This is a generic solution that allow to catter for offline
>managemet aware client and the old generation.
>
>--jean louis
>
>----- Original Message -----
>  
>
>>Date: Mon, 11 Nov 2002 13:15:59 -0600 (CST)
>>From: Peter Saint-Andre <stpeter at jabber.org>
>>To: standards-jig at jabber.org
>>Subject: [standards-jig] thoughts on POP3 Offline (JEP-0013)
>>Reply-To: standards-jig at jabber.org
>>
>>Based on discussions held in the last Council meeting [1], I've thought
>>some more about JEP-0013 (POP3 Handling of Offline Messages) [2]. Here are
>>some tentative suggestions:
>>
>>1. It would be good to bring the namespace into line with the newer
>>conventions (e.g., "http://jabber.org/protocol/offline").
>>
>>2. It would be good for a user to receive more information in the headers.
>>Specifically, the subject and thread might be useful.
>>
>>3. Section 2.4 (Compatibility) says the following:
>>
>>   Without the ability to query a given client for feature sets,
>>   POP3-like offline message handling is incompatible with the
>>   existing offline model.
>>
>>This was true when the JEP was written but is no longer accurate given
>>the existence of JEP-0020 (Feature Negotiation) [3]. I suggest that
>>handling of offline messages is a fine example of feature negotiation. It
>>might work as follows:
>>
>>Step 1. User logs in but does not send presence.
>>
>>Step 2. User asks if the offline namespace is supported.
>>
>><iq type='get' to='myserver' id='a1'>
>>  <query xmlns='jabber:iq:disco'/>
>></iq>
>>
>>Step 3. Server replies in the affirmative.
>>
>><iq type='result' from='myserver' to='me at myserver/foo' id='a1'>
>>  <query xmlns='jabber:iq:disco'>
>>    ...
>>    <feature type='http://jabber.org/protocol/offline'/>
>>    ...
>>  </query>
>></iq>
>>
>>Step 4. User asks if pop3 handling of offline messages is supported.
>>
>><iq type='get' id='a2'>
>>  <query xmlns='jabber:iq:negotiate'>
>>    <feature type='http://jabber.org/protocol/offline'>
>>      <option>pop3</option>
>>    </feature>
>>  </query>
>></iq>
>>
>>Step 5. Server replies in the affirmative.
>>
>><iq type='result' from='myserver' to='me at myserver/foo' id='a2'/>
>>
>>Step 6. User retrieves headers as shown in Example 1 of the JEP.
>>
>>And so on from there.
>>
>>4. David Waite suggested retrieving offline messages via disco. I played
>>around with this some but it would seem to require that at some point in
>>the process every message is a JID (e.g., me at myserver/indox/some-uid)
>>which is sub-optimal IMHO.
>>
>>Thoughts?
>>
>>Peter
>>
>>[1] log at
>>
>>    
>>
>http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-11-
>08.html
>  
>
>>[2] http://www.jabber.org/jeps/jep-0013.html
>>
>>[3] http://www.jabber.org/jeps/jep-0020.html
>>
>>--
>>Peter Saint-Andre
>>Jabber Software Foundation
>>http://www.jabber.org/people/stpeter.php
>>
>>    
>>
>
>
>_______________________________________________
>Standards-JIG mailing list
>Standards-JIG at jabber.org
>http://mailman.jabber.org/listinfo/standards-jig
>
>  
>






More information about the Standards mailing list