[Standards] Re: compliance levels for 2008

[Rachel Blackman]

> 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  
HTML parser.

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  
into XHTML-IM!

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.   
Do you need a Javascript client model?  Should Javascript be able to  
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.  
> This
> 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  
laptop.

> 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/