On Fri, 2006-11-03 at 10:53 +0100, Olivier Goffart wrote: > My opinion is that we should continue on the Jabber format (XEP-0038), which > is already implemented by several client. Technically, this format looks good > to me. What i don't like is the fact it is too related to jabber (it's name, > some default values, ...) > But that format is a good base.
Yeah, it's not bad at all. Here are the things I'd like to see addressed: 1. The abuse of xml:lang for protocols is unacceptably horrible. That attribute, as its prefix indicates, is from the XML namespace and nobody should be adding values except the XML specification. XEP-0038 says in 4.3.1, "The xml:lang attribute allows for two-letter language codes, dialects, and custom "languages" to define foreign IM protocols, for example." However, the XML specification that they link to says, "The values of the attribute are language identifiers as defined by [IETF RFC 3066], Tags for the Identification of Languages, or its successor; in addition, the empty string may be specified." It does note that "(Productions 33 through 38 have been removed.)", so maybe something has been removed that XEP-0038 was previously using. Additionally, the idea of treating protocols as languages is just nasty. It needs to be a protocol attribute instead. 2. I'd like an optional description element added to the <icon> element. 3. For future-proofing, we should add a version attribute to <icondef>. 4. I'm a little concerned about the requirement to NOT unpack the smiley theme. I don't know how transparent it's going to be to access a .zip file all the time. However, it's probably not that bad, so I'm not *too* worried about this. I'm in favor of abandoning the start of a spec I'd written (in another e-mail on this thread) and switching to addressing these issues in XEP-0038/JEP-0038. Olivier, Matt, and others: Do you have any other issues with -0038 than what I've outlined above? Do you object to any of my desired changes (1, 2, and 3)? If not, I'd like to take this discussion to standards-jig and see if we can get those issues addressed, and then I'm ready to add this support to Gaim. Richard
signature.asc
Description: This is a digitally signed message part
_______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
