[Standards] Re: compliance levels for 2008
rcb at ceruleanstudios.com
Sat May 5 04:34:25 UTC 2007
> I've got a few issues that I think need being brought up:
> 1 - Avatars. It's a feature users expect, and a client without them
> can't even be considered a toy these days. None of these client specs
> talk about Avatars. This is something that needs to at least be in the
> Intermediate spec.
Fair enough, though right now we still have no 'preferred' avatar
spec. People seem to have de-facto settled on the iChat method,
which is fine and all but then it should be made the official answer
to avatars. Arguably, we need to push forward a standard, single
avatar spec and then make it part of it.
> 2 - Rich Messaging. It's no secret that I don't like the XHTML
> spec, and
> I think requiring it is a mistake. Our new client, for example, uses
> Rich Text messaging. We may swap this out with HTML messaging at some
> point in the future, but it will probably never be XHTML as defined by
> the XEP.
Sorry, Chris, but there are not enough exclamation points available
on the Internet to express how strongly I feel on a '-1!' here.
Honestly, I've yet to hear anyone make an actual /good/ argument for
allowing pure HTML or whatever through. No offense, but it generally
comes down to, 'I already have a full HTML parser and renderer from
somewhere else embedded in here, and ZOMG NOW I CAN PASTE MY GOOGLE
HOMEPAGE IN WITH WIDGETS!' or something similar. It may have nifty-
factor, but it makes it godawful hard on anyone who doesn't just have
IE or Gecko embedded as their renderer to have to implement an entire
As someone who does NOT have an entire HTML parser embedded in their
client, I am utterly uninterested in trying to write a completely
fault-tolerant parser that takes all the quirks and foibles of open-
ended HTML. I mean, for crying out loud, when I design a website, I
frequently have to make 3 different versions to account for different
browsers. With open-ended HTML messages over XMPP, everything else
aside... the image of 'oh, sorry, that embedded SVG emoticon only
renders on XMPP clients that support CSS3' makes me weep.
Sure, it's convenient to take pasted-in HTML to your input control
and not have to edit it. But by that logic, since I have my own
custom internal markup language on Trillian -- one we share among all
mediums -- why can't I just send that across the wire? Sure, a lot
of the data would make no sense to anyone else, but, hey, it's
convenient for ME not to have to re-parse that data back and forth
Or how about the Adium folks? Over on Mac OS X, hey, any coder can
easily dump NSAttributedString -- which is available system-wide, and
is basically what any input control will generally be giving you! --
into UTF-32 RTF with about one line of code. Thus, clearly, the
native markup (from the point of view of a Mac OS X author) should be
UTF-32 RTF, (obviously with support for the Cocoa font-handling
extensions for kerning and stuff, because those are cool)! After
all, that's the convenient one. And why should we favor Windows
authors? Join the cult of Mac!
More seriously, since every XMPP client is /guaranteed/ by the nature
of XMPP to have an XML parser, the stricter grammar of XHTML makes
much more sense. After all, you KNOW that every client at least has
the technology to parse it. Yes, it's a bit annoying for a client
author to have to take whatever they got in their native editing
field, and turn it into XHTML.
Of course, it's equally unrealistic to assume every single tag in the
world will be supported, so you need to define a subset...
Hey, look, we have something darn similar to XHTML-IM. ;)
Now, my (admittedly somewhat vehement) objections aside... I *can*
see a case for defining additional sets of XHTML-IM functionality --
XHTML-IM tables, XHTML-SVG, etc., which can be independently
negotiated -- but just allowing any old HTML opens too many doors.
re-write 'page' contents, allowing embeddable AJAX messages? Etc.
The whole idea of XMPP is 'complex servers, simple clients.'
Requiring any client author who wants to be able to send bold, italic
and underline -- or font colors -- to either embed some third-party
HTML tool (IE, Gecko, Webkit, etc.) or reinvent the HTML wheel (a
full-time project in and of itself) seems counter-intuitive to that.
> 6 - We should require an XML Debug Window of some sort. Tie it to a
> standard Keystroke (Exodus, Pandion, and our new Communicator all use
> F12), so that it's practical to have a debug session with someone.
> should be in the Basic Spec.
This is arguable. First of all, your average user doesn't really
generally care about XML Debug Windows, and I think it's a mistake to
put it into the compliance specs.
Besides which, I don't have an F12 key on my cellular phone
keyboard... but I do have an XMPP client. Is that client now no good
simply because of the fact that, well, my cellular phone lacks an F12
key? And if you want to get picky, so does my (ancient) Sony Vaio
> 7 - We should require clients to support Start-TLS streams. This is an
> optional thing in the RFC, but clients really need to support it. This
> should be in the Basic Spec.
This much, I suppose I can agree with. Realistically, SSL libraries
are available even for portable phones these days.
> I would also, for BASIC clients, require:
> - An Install and uninstall mechanism that works with the target O/S
> - A means to quickly and easily report a bug against the client.
To me these seem outside the scope of the compliance/interoperability
specification. These specifications don't really define local
interface... and frankly, they really shouldn't.
Now, I like to think any author out there would be sensible about all
this, but... c'mon. I mean, on OS X, the install/uninstall mechanism
is 'drop the app into your Applications folder' or 'move the app from
the folder to the Trash can.'
As for 'report a bug,' that's something which is great, but again, it
should not be up to the XMPP compliance testers to go test and judge
the usability of a client or server dev's bug-tracking system.
I admit to some self-interest here. We use a Bugzilla-based bug/
ticket interface at Cerulean, and I'm not honestly sure anyone in
their right mind would call Bugzilla 'quick' or 'easy' to do anything
beyond the basics in! ;)
> I would include for Intermediate Clients:
> - A means to upgrade the client from one version to another.
Again, beyond the scope of XMPP itself, I think.
If we start defining how clients should work outside of their use of
XMPP, we're getting into a grey area. Should we legislate whether or
not passwords are encrypted where they're stored on disk? Must all
passwords be stored outside of filesystem files (i.e., registry on
Windows, Keychain on OS X) to keep them less easily pilfered? Etc.
Now, if there was an XMPP method for 'Version Notifications from
Pubsub,' and we required every client dev to run an XMPP pubsub
server (or at least publish a node on some public pubsub server), I
could see /that/ being a requirement in some spec. :)
> - File transfer. Come on guys! :)
*sits in the corner and waves her, now rather tattered, flag* I've
said this several times, but...
Is /anyone/ else bothered by the fact that we have two mutually-
incompatible file-transfer methods? :)
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/
More information about the Standards