[Council] VOTE: JEP-0013 (POP3 Handling of Offline Messages)
ckaes at jabber.com
Fri Jan 18 15:55:24 CST 2002
David Waite wrote:
> (no vote quite yet)
> A few questions:
> 1. Could it be pointed out that XDB is not required for use of the main
> namespace? I understand it is an addition in a particular implementation of
> offline retrieval, but it appears it would be possible to implement this (in
> what perhaps would be a sub-optimal manner) using the existing XDB
> mechanisms. This might be desireable for XDB modules which do not implement
> the new XDB stamping action. More importantly though, the ability to store
> the data is not limited to XDB, and there have been a few next-generation
> data storage and retrieval systems kicked around to fix some of the
> limitations of XDB. Perhaps this could be separated out into two separate
Yup. This makes sense. FWIW, I tried to keep my references to a
"storage layer" vague (see section 2.1), but apparently not vague enough
(Section 3 should have not mentioned XDB.) I did not mean to exclude
any non-XDB storage mechanism in the required changes section. More
> 2. With the XDB separation in mind, there isn't a reason that the
> http://www.jabber.com/xdbuid namespace needs to be referenced at all within
> this spec. The uid attribute can be within the jcs:offline:pop namespace.
> This would save a slight bit of bandwidth.
Again, agreed. This makes sense. (Not so much the bandwidth argument
but together with #1, it keeps the offline-pop functionality
encapsulated.) Then the xdb enhancements (xdbid) would be translated
into a jcs:offline:pop:uid by the offline:pop handler. Given that the
uid _can_ be handled by the offline-pop handler and not the storage
layer, these really should be two separate jeps.
> 3. Have you considered some sort of IQ set to the server to disable the
> initial flushing of offline messages on presence available? If the server
> does not affirm support, the client knows it does not support this
> pop3-style handling. However, if a client does not send this IQ, they get
> legacy behavior. This might fix the compatibility problem described in
> section 2.4
I would consider this a hack and not in the nice sense of the word ;-).
What we really need is a protocol for client feature negotiation. Else,
I'd need to send an IQ for each and every feature I want to use.
> 4. I do not know the behavior of the 'thread' value of messages in current
> clients when communicating with an offline user. However, this might be
> useful for navigating these offline messages in some environments. Normally
> IM communication does not not have the same "brain dump" quality that email
> does - an IM message is just a piece in a larger conversation, rather than
> being a summary of all thoughts on a subject.
I don't see how this fits into pop very well. Maybe as subject? I
think the average user can piece together that the five messages you
sent within 10 seconds of each other are related without a thread
identifier. Let's keep the headers small.
> ----- Original Message -----
> From: "Peter Saint-Andre" <stpeter at jabber.org>
> To: <council at jabber.org>
> Cc: <ckaes at jabber.com>
> Sent: Wednesday, January 16, 2002 10:36 AM
> Subject: [Council] VOTE: JEP-0013 (POP3 Handling of Offline Messages)
>>OK, now the fun begins. I have received a standards-track JEP for more
>>advanced handling of offline messages, similar to POP3 handling of email
>>messages rather than the current Jabber model of receiving all messages at
>>This JEP proposes the addition of two namespaces: 'jcs:offline:pop' for IQ
>>gets and replies between the client and the server, and 'xdbid:uid' for
>>the storage, retrieval, and removal of messages stored in XDB. Note that
>>neither of these proposed namespaces begins with the 'jabber:' prefix. So
>>assuming that this JEP is accepted as a draft protocol, it raises a
>>question about the naming of standard namespaces. Because this JEP
>>describes a working implementation that is supported both in a Jabber
>>server (the commercial one maintained by Jabber Inc.) and in Jabber
>>clients that are written to interact with that server, forcing a change to
>>the proposed namespaces would introduce non-trivial migration issues. On
>>the other hand, because the 'jabber:*' namespaces are reserved, a working
>>implementation could not have been created using (in this instance) a
>>namespace such as 'jabber:iq:offline:pop'. I see two solutions if this
>>JEP is accepted:
>>1. Accept the protocol changes with the proviso that the namespaces be
>>changed to begin with the 'jabber:' prefix, thus introducing migration
>>issues for the implementation (and, in my opinion, discouraging the
>>submission of future protocol enhancements).
>>2. Accept the protocol changes and add the proposed namespaces to a list
>>of accepted namespaces. Currently we do not have such a list, but creating
>>one and adding these namespaces to it would merely say (in this instance)
>>"if you want to do POP3-like handling of offline messages, this is the
>>accepted way to do it".
>>Personally I lean towards option #2 but I think it's important that we
>>have this discussion. Another option, mentioned to me by Dizzy, would be
>>to have developers provisionally request a 'jabber:*' namespace when they
>>are in design mode (concurrent with submitting a JEP) and "lease" that
>>namespace until the JEP is finalized and the implementation is created.
>>Unfortunately this would introduce uncertainties into the development
>>process ("what if our lease runs out and we have to change the namespace
>>to something other than 'jabber:*'"?), which again (IMHO) would discourage
>>the submission of protocol enhancements.
>>In any case, please vote +1, 0, or -1 (with reasons) to move this JEP
>>along the standards track from proposed to draft. The JEP is available at
>>As always, please reply to all so that the JEP author (Craig Kaes) may be
>>included in the discussion.
>>email+jabber: stpeter at jabber.org
>>Council mailing list
>>Council at jabber.org
More information about the Council