[mobile] [Fwd: Brussels report]

Peter Saint-Andre stpeter at stpeter.im
Tue Feb 10 21:23:16 CST 2009


Re-send.

-------- Original Message --------
Subject: Brussels report
Date: Tue, 10 Feb 2009 14:09:02 +0100
From: Peter Saint-Andre <stpeter at stpeter.im>
To: mobile at xmpp.org

At the XMPP Summit yesterday, we had a discussion about mobile
optimizations. Here is a brief summary.

1. When you log into your account on a mobile device, you probably don't
want to receive a flood of offline messages. XEP-0013 solves this
problem and might be what we need. At the summit I mentioned that the
protocol feels ugly to me, but I've looked at it again just now and it
seems fine. It might help if people on this list could review the spec,
because all of the really old XEPs are a bit out of date and might be
unclear or incomplete (e.g., lacking satisfactory security sections).

2. XEP-0198 (Stream Management) is needed for mobile environments. In
fact the group had consensus that long-lived TCP connections are better
than BOSH for mobile devices (where magic happens to handle TCP), but
that XEP-0198 would improve the situation by adding things like fast
reconnect. Here again reviews would be appreciated so that we can figure
out what features are missing. I will make this spec a priority over the
next few weeks.

3. Roster versioning would help on the initial communications flood when
you log in. We have this in XEP-0237 but it needs to be generalized to
also handle service discovery results (see also XEP-0230!) and perhaps
pubsub results. Another priority for me.

4. Fabio Forno proposed that it would be great if when logging in you
could retrieve only part of your roster (e.g, you might have a special
"Mobile" or "VIP" group in your roster to save on bandwidth usage -- I
know I would do that!). I called this "Roster Views". We envisioned it
happening something like this:

- open the stream, negotiate TLS + SASL, and get a resource

- discover whether your server supports roster views

- send IQ-get for roster but specify a group (or more than one group):

<iq type='get'>
  <query xmlns='jabber:iq:roster'>
    <group>VIPs</group>
    <group>Friends</group>
  </query>
</iq>

- server sends you only those contacts:

<iq type='result'>
  <query xmlns='jabber:iq:roster'>
    <item jid='bigboss at example.com'>
      <group>VIPs</group>
    </item>
    <item jid='bestbuddy at example.org'>
      <group>Friends</group>
    </item>
    <item jid='mysweetie at example.net'>
      <group>Friends</group>
    </item>
  </query>
</iq>

- send presence, which the server broadcasts only to the group(s) you
retrieved

It might also be desirable to remove a group from your current view. I
suppose we could do that via an IQ-set:

<iq type='set'>
  <query xmlns='jabber:iq:roster'>
    <group>VIPs</group>
  </query>
</iq>

<iq type='result'/>

As a result the server would send unavailable presence from your JID to
the people in the group you have disabled in your roster view.

(Hey, I just realized that this is a more flexible solution to
invisibility!)

5. Compression is good. In fact it is very good (Fabio reported great
results from experiments with Lampiro), so use it. However, to use TLS
compression the initiator needs to offer SSLv3 or above during the TLS
handshake. Some clients and servers offer SSLv2 and that prevents the
use of compression. File bug reports to improve the situation. :)

6. We talked about a feature for hushing the session (also discussed at
FOSDEM 2008). The behavior would be something like this:

- hush the session

- your server stops sending you inbound presence and also inbound PEP
notifications (the guidelines in XEP-0226: Message Stanza Profiles might
help here; perhaps it stores "offline" anything that doesn't match the
IM profile in XEP-0226)

- your server probably replies on your behalf to things like service
discovery requests, version requests, and other inconsequential IQs (we
would need to define guidelies here)

- however, your server continues to pass along inbound messages, phone
calls, and other significant communications (where guidelines for what
counts as "significant" are yet to be defined, or are left up to the
service)

When you unhush (wake up your device by accepting an incoming call,
engaging in a chat session, or whatever), your server would take that
opportunity to send you the last presence updates and PEP notifications
it has received from people in your roster (which might be limited using
roster views as described above).

We did not reach consensus on what the hush protocol would look like.
The only consensus was that I would write a proposal. :) So I will do
that, but probably after I get a chance to clean up XEPs 198 and 237.

So to summarize, I think that our mobile story is improving. We have a
lot of the pieces in place or in progress, but we need to put some time
and energy into finishing what's not yet completed and then getting
everything deployed. The relevant spec work will be a priority for me
over the next few weeks.

/psa

[ written en route from Brussels, delivery times may vary :) ]


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/mobile/attachments/20090211/208decc7/attachment.bin 


More information about the mobile mailing list