[standards-jig] NEW: XMPP/Jabber MIME Type (JEP-0081)

Rachel Blackman rcb at ceruleanstudios.com
Tue Apr 22 06:38:42 UTC 2003


> I am confused... is mailto: uri seen as some kind of aesthetic failure?
> 
> Does this mean that you now have to setup the mime-type on the web
> server and force the user to go through the save as/open with thousand
> click to send a jabber message??   
> 
> So I need to be thwaped with the clue bat and have it explained to me
> why several files and much effort for the user is preferable to 
> 
> <a href="xmpp:juliet at capulet.com">Message Me</a>

As I gather, the idea is that since it would take time to get browsers to
support the 'XMPP' service ID for URI's, you add a MIME type.  Since every
browser out there can have a 'mime-type' mapped to an application...
witness how you can click on an MP3 and have it start playing in WinAmp
under Windows or XMPP (the MP3 player, not the XML protocol!) under Linux
or whatever.  So the idea being that you bind this MIME type to your Jabber
client and voila...

However, I think this is partly a fallacy.  Under Windows and (I believe)
Macintosh, it's possible to add new services for URIs easily enough; I've
admittedly not looked at Mozilla in a while, but I would be surprised if
they have no way to add new services to URI.  

I don't think that the MIME type is useless, and it does definitely have a
place (especially if you want to package several commands, like a 'buddy
list' of existing people on a project, as an attachment to an e-mail
message which you only have to open to add all of them), but I think saying
it's necessary because the xmpp: URI stuff will take time to get adopted is
a bit of an incorrect statement. :)

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillian.cc/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030421/fad4cd06/attachment.sig>


More information about the Standards mailing list