[standards-jig] Small Footprint Clients and Authentication

Richard Dobson richard at dobson-i.net
Thu May 29 22:48:34 UTC 2003


J2ME does have quite a low file size limit on most mobiles, since more and
more popular phones are coming out with the capability to run native C++
symbian applications wouldnt an XMPP clients be better suited to be a native
C++ symbian app than the restricted J2ME?

The phones that I know of that run native C++ apps are the Nokia 3650 and
the Nokia 7650 (only because I investgated them before I bought my 3650),
there must be more than these, now I realise these do not represent a large
portion of the smart phones available but phones like the 3650 are becoming
rather popular over here in the UK.

So maybe you dont need to worry so much about the J2ME size limit and just
leave the things that wont fit out and create native C++ versions with a
much fuller feature set, which will hopefully give people more incentive to
get better phones which support your much improved client.

Richard

----- Original Message ----- 
>From: "Tijl Houtbeckers" <thoutbeckers at splendo.com>
To: <standards-jig at jabber.org>
Sent: Thursday, May 29, 2003 5:55 PM
Subject: Re: [standards-jig] Small Footprint Clients and Authentication


> Peter Saint-Andre <stpeter at jabber.org> wrote on 29-5-2003 18:35:19:
>
> >I see several issues here:
> >
> >1. There are no SASL-aware servers to test against. SASL-aware servers
> >will not be widespread on the Jabber network for some time to come. But
> >we want to do compliance testing rather soon, and it's unrealistic to
> >expect clients to do only SASL authentication when SASL-aware servers
> >are not available (or widely available). In fact, this would break the
> >network and would render our compliance testing meaningless.
>
> First of all, I have no objection to edigest being a new non-SASL
> standard. I always say choice is good. Yes, in standards too! Not when
> you have two standards that to do exact same thing, wich is not really
> the case here.
>
> However, the arguments used up to here are a complete reversal of the
> outcome of the IBB discussion. I think the two situations are very
> comparable. Go with a mechanism that is unsupported in the real world,
> but what will be the future standard (in the case of IBB the standards
> were/are(!) still not here, and SASL is very well defined by now I
> asume), or go with a mechanism that works now, does the job, and
> requires significantly less updating in clients.
>
> We all know the outcome of the IBB discussion, I don't particulary
> agree with it and will have to go down the non-standards path for now
> (because I work with small footprint devices, exactly your argument
> below) but it is pretty clear what the council seems to think on this!
>
> However, I still think this next argument is more important..
>
> >2. The argument has been made to me that small-footprint clients can do
> >jabber:iq:auth but not SASL. I don't know whether that is true or not.
> >It may be immaterial given the facts outlined in point #1.
>
> but, even though I work with (very) small footprint devices I can't
> really give an answer here (yet) because of the limited resources of my
> devices I use plaintext authentication when space is really restricted.
> That already means I can't do SASL and won't be able to do so for years
> to come in many devices. However, I don't use digest or edigest in this
> case either, so it's less relevant for the edigest discussion.
>
> It is however very relevant for the iq:auth vs. SASL discussion. I'm
> not very up to date on SASL yet, but from what I've read here it
> *requires* support for MD5. This would mean that once iq:auth will be
> deprecated the requirments to implement jabber will be significantly
> greater. Ofcourse, most future new phones will have improved
> capabilities, though in the near future a lot of low-end models will
> receive the same limited capabilities as I'm talking about now, and
> they will be around for years. Furthermore, I'd like to point out
> phones are not the only market for small-footprint devices, there's the
> embedded market for example.
>
> As I already noted in another post, a lot of phones that come in the
> market have an improved API for more secure methods of authenticating
> (for example out of band HTTPS), but I can't think of one API extension
> in wich I will be able to use MD5. Even *if* with updated storage
> capabilities I could squeeze an MD5/SASL implementation combined with a
> jabber messenger into the device, that doesn't mean I wouldn't rather
> spend that space on other things, or leave it free for other
> applications.
>
> I'll see if I can find some time in the next days to provide some
> examples on how much spaces these methods (and an estimate of SASL)
> would approximaltly take up in J2ME, and post some device-specs to go
> along with them.
>
> >3. Both jabber:iq:auth and jabber:iq:register should be reviewed every
> >six months by the Jabber Council for possible deprecation (please see
> >Section 8 of JEP-0001 for details). I think they cannot be deprecated
> >now but should be deprecated in the future. Exactly when they will be
> >deprecated will be up to the Jabber Council, but I would expect that
> >this will not happen for another 12 to 18 months, depending on how
> >quickly the transition to SASL-aware servers occurs.
>
> In any case, small-footprint devices will be around for years. And in
> 12-28 months there will most likely still be new simulair small-
> footprint devices coming onto the market.
>
> >4. The addition of the "edigest" method is intended to move the old
> >jabber:iq:auth protocol closer to the level of password security (in
> >storage) provided by MD5. It is not really even a new method, but a
> >better implementation of the existing digest method. I think JEP-0078
> >won't be deprecated for at least 18 months, and I also think that
> >people using this method don't particularly want their passwords to be
> >stored in the clear all that time (they should not have been stored
> >that way since 1999 either, but that is another issue).
>
> As noted, edigiest is not meant to deprecate normal digest. You really
> should see it as just an alternative method.




More information about the Standards mailing list