[Council] VOTE: JEP-0013 (POP3 Handling of Offline Messages)

David Waite mass at akuma.org
Thu Jan 17 23:40:38 CST 2002


(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
proposals?

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.

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

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 just know my personal habits; if I correspond with someone via IM and
discover they went offline before reading my message, I usually end up
sending at least one more message to them to clarify the context of the
first message, and possibly more to provide the information which would have
been stated over the conversation.

There are plenty of pros and cons to providing this threading information,
the biggest con being that it would increase the amount of data sent to the
user in receiving their offline message list. I am more curious of your
thoughts on this.

-David Waite

----- 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
> once.
>
> 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
> http://foundation.jabber.org/jeps/jep-0013.html.
>
> As always, please reply to all so that the JEP author (Craig Kaes) may be
> included in the discussion.
>
> Peter
>
> --
> Peter Saint-Andre
> email+jabber: stpeter at jabber.org
> web: http://www.saint-andre.com/
>
> _______________________________________________
> Council mailing list
> Council at jabber.org
> http://mailman.jabber.org/listinfo/council
>




More information about the Council mailing list