[standards-jig] jabber for mobile devices

Peter Saint-Andre stpeter at jabber.org
Tue Feb 24 21:34:25 UTC 2004


It seems to me that much of this addressed by a few things:

1. setting the compression bit in TLS

2. partial roster fetches (seems like a worthy idea)

3. privacy lists

The XHTML concern is addressed in JEP-0071 -- if you don't want XHTML,
don't advertise that you do. The other client must not send you XHTML if
you don't want it.

/psa

On Fri, Jan 16, 2004 at 03:46:39PM +0100, Matthias Wimmer wrote:
> Hi SEN!
> 
> SEN schrieb am 2004-01-16 15:49:57:
> > Please make a new JEP for mobile devices.
> > Server MUST support  this:
> 
> You can not force any server to be upgraded to support anything. That's
> a general rule on the internet.
> Also I don't think it is something that MUST be supported, for example
> there are also servers only serving intranet clients for which the
> message size is not very important.
> There are even other tunings a server could make for mobile clients,
> e.g. disabling keep alives, compressing data when using TLS. Other
> interesting features might include getting presences without fetching
> the roster first, ...
> 
> > (if not mobile have error with parsing (msg is lost) or bufferoverflow...)
> > JEP - for message size control.
> 
> A mobile device would be able to keep the beginning of a stanza while
> ignoring the rest (only counting the depth of the XML nesting without
> really parsing it - I know it's ugly but would work with existing
> systems). The beginning of the stanza would be enough to generate an
> error reply informing the sender of the problem.
> 
> > Client can send <iq id="1001" type="msglen" size="10000" ></iq>
> 
> A type value of "msglen" is not allowed. The proper way would be
> something like:
> 
> <iq id="1001" type="set">
>   <query xmlns="http://jabber.org/protocol/size">
>     <maxsize>10000</maxsize>
>   </query>
> </iq>
> 
> > all incoming messages (while for messages only)  will break by this
> > size... size in bytes for <body> part.
> > or optional message return to sender whith error msg...
> 
> The only thing that seems as a adequate reaction to me is returning an
> error. I don't think a server should ever try to modify existing parts
> of a message.
> 
> > **************  XHTML ON/OFF *****************
> > choosing with incude or not XHTML to message
> > <iq id="1001" type="xhtml" on="no" ></iq>
> 
> That's really something that should not be filtered by the server but
> agreed upon with the sender of the messages. If XHTML content should not
> be delivered there is no need to transport it through the complete
> Jabber network and then dropping it.
> 
> > ************** VCARD choose any field *************
> > Client may get only field that it need...
> > Client send:
> 
> Let's see how long we keep the vCard format at all. ;)
> 
> I think more interesting would be the possibility to just fetch parts of
> your roster, e.g. only your friends. - Or not fetching the roster at all
> but still geting presences. This would be enough to show which users are
> online. The mobile client might then fetch the nickname for each new
> user that gets online from the server.
> 
> 



More information about the Standards mailing list