[JDEV] message extensions thoughts

Patrick McCuller patrick at kia.net
Sun Aug 1 22:28:32 CDT 1999


	Who's interested in discussing message extensions?

	My understanding of message extensions is that they give clients a way to
stuff additional information in a message sent to another client through
Jabber. This is only really useful to a client if both the sending and
receiving clients:

1) support the specific message extension (receipts, hashes, contact
exchange, etc.)
2) agree on where and how to put the relevant information in a message
extension <ext></ext>


	Again this leads directly to feature negotiation, which Jeremie's previous
document, http://www.jabber.org/developers/archive/9904/msg00022.html seems
to put into the category of profiles. In this way, a user's server stores
information about a user in a user profile. The profile is then queried to
determine what features a client has.

	Users may use many different clients. A Windows or Java client at the
office, perhaps, Palm client on the road, XWindows at home. Each client
would be required to upload all of its extension feature support into the
user's profile as soon as the user logs in. This would make 'high read low
write' Jabber server backends less feasible (LDAP, for instance, though
that's just an example.)

	Also, a user may wish to configure his client such that it offers features
only to certain users, or a group of users. The client might  disavow
features in the same way. ('I will not send receipts to nor accept receipts
from Bob.')  That would not really be possible if the client is required to
upload its extension support to the user's profile, but the client could
always ignore those features. Again that might not work well, especially if
the feature would alter the very content of the message: end to end
encryption for instance.  (My public key is in my profile, and PK supporting
clients send me encrypted messages: disabling that feature on my client for
those users means that I will be unable to read their messages. This is
probably not an issue but maybe it should be explored.)


	So having established through the user profile that a
Client->Server->Client feature (as opposed to Client->Client, which may have
a totally orthogonal protocol) is supported by Client B, they still need to
agree on the location and content of the extension in the <ext>, an XML
document fragment if I recall Jer correctly. Is it time to start discussing
a standardization on a few simple extensions, such as message ordering?


Patrick


> -----Original Message-----
> From: owner-jdev at jabber.org [mailto:owner-jdev at jabber.org]On Behalf Of
> Jeremie
> Sent: Friday, July 30, 1999 5:19 PM
> To: jdev at jabber.org
> Subject: RE: [JDEV] existing protocol questions
>
>
> > 	Jer, thanks for answering questions 1-4 so quickly  :)
>
> No prob, sometimes it takes me a week, sometimes only a few minutes, *g*.
>
> > 	About message <ext></ext> : why not structure extensions
> internally as an
> > XML document in a CDATA field? My reasoning is this: if the
> extended data is
> > structured, then clients will be less likely to trample on each
> other.  For
> > instance:
> >
> > Client A likes to send receipts, so it stuffs a 'message ID' which is
> > essentially a hash of the last message received into the <ext>
> of the first
> > response it sends to Client B.  Client B, however, expects
> <timestamp> or
> > <favorite color> or goodness knows what. As a result, the secure hash is
> > totally inappropriate and neither side really knows why.
>
> Actually, I don't think I really documented it anywhere, but my intention
> for the <ext></ext> field was to have an XML tree stuck within it, so each
> client would have their own tag space to do whatever they wanted, for
> example:
>
> <ext><JavaObjID><id>2134</id><id>76345</id></JavaObjID></ext>
>
> Each client would be restricted to use their own tag names containing
> their own data.
>
> > 	This leads into feature negotiation, which you mentioned
> previously, but
> > perhaps it is time to get back to that discussion.
>
> Some feature negotiation will be part of the info/query proposal, I'll
> post more detail next week :)
>
> Jer
>
>




More information about the JDev mailing list