[Standards] Intra-Jid Private State

Dave Cridland dave at cridland.net
Thu Jan 22 11:42:43 UTC 2009

On Thu Jan 22 07:39:44 2009, Remko Tronçon wrote:
> > Attached is part of a solution to the (largely unstated) problem.
> Apart from the spelling mistakes, I like it so far.
Spellling mistakes? As iff.

> > 1) A refinement on the remote control ad-hoc commands to send  
> only some
> > pending messages. (Not really essential, but might be nice).
> Actually, a real protocol (based on ad-hoc RC) will probably be  
> better here.
I'm not sure I follow - surely we can use XEP-0050 here, and just  
define an ad-hoc command that has the precise properties we need?

> > 2) A mechanism Kev proposed for raising priority dynamically  
> relative to
> > other resources based on user activity (as opposed to current  
> practise,
> > which is lowering it due to use inactivity without looking at  
> other
> > clients).
> Ok.
> I like that the private state thingy is independent of the dynamic
> priority approach. Both are interesting solutions in their own  
> right,
> and complement each other very well.
Right - if Kev's dynamic priority thing works out (and I think it  
should), then misdirected messages should be quite rare - they'd only  
happen post "lock on".

> I guess the third missing part is a XEP that specifies the 'awaiting
> messages' profile of intra-jid status formally, and describes hints  
> on
> how clients might behave. For example, whenever a client detects  
> user
> action (e.g. mouse movement), it automatically fetches the awaiting
> messages from other clients and displays them.
I'm intending to formally define the Missing Messages bit within this  
XEP, I just wanted to get this much out, to try to avoid the  
accusations that I've not made any such proposal.

> There's also the question on whether it makes sense to provide more
> intra-jid state for 'awaiting messages'. For example, a remote  
> client
> could change the icon of a contact in a roster if it knew there were
> messages awaiting for it in another client, and would fetch them  
> when
> clicked; this would mean that the intra-jid state could specify
> awaiting messages per contact. The (probably better) alternative is
> that the client pulls this information if it wants it (which would
> move it to the RC protocol). This in turn raises the question:  
> should
> there be a 'peek message' command (on top of the 'fetch message'
> command), which would allow all clients to display pending messages  
> in
> open chat dialogs without owning the message?

Good question. I think the answer is probably yes - we have a command  
which says "Gimme messages [from X] [and mark 'em read]".

BTW, I keep on reading "intra-jid" as "infra dig" for some bizarre  

Don't ask me why.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list