[Standards-JIG] RE: Gateways

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Fri Mar 18 08:34:23 UTC 2005

Hi Matthias,

So, in short, you are saying that a Gateway may offer support for vCard
queries. And it may use different mechanisms to access (if the remote
network supports it) or generate (from cached data) the vCard information.

This is fine with me, and in my opinion is a desirable feature of a gateway.

There may nevertheless be certain cases where it will be difficult to
produce a scalable implementation. We may if you wish take this further

My only comment: this is one possible way to get access to this information.
And in this method, the client application is active and has to issue a
request to the gateway to retrieve the data. To make it simple, there is
also a case for this data to be pushed to the client application. This is an
equally valid method. Only the underlying application requirement has to
push the implementation design to use one or the other method. There will be
cases where querying for data will work fine, whereas in other cases pushing
the data will work better.

Although vcard-temp support by XMPP is far from perfect, it exists today. We
are supporting and using it in many different ways in our products. The XMPP
protocol already provides a comprehensive support for pushing the kind of
information provided by the GW directly to the client application. It just
lacks this tiny addition to cover most of what we can bridge to today.

As a provider of XMPP based platforms, I have to give end users the
flexibility to choose the most adequate solution to their business problem
without adding any constraint linked to the underlying protocol. 

(And to make it equally short, I was taken abreast by the heat generated on
the thread, knowing that I couldn't care less how it's called in the
supporting document/protocol implementation ;)



-----Original Message-----
Hi Jean-Louis,

Jean-Louis Seguineau schrieb am 2005-03-17 15:00:19:
> Do you mean the gateway would use the vCard protocol format to convey the
> information, or do you mean the gateway would create a vCard entry for a
> remote user?

The gateway should if possible try to query the information to create
the vcard response when the vcard is requested. Sure this only works if
the information can be requested at this time.
If the information is part of the presence of the other user and
presences are only pushed at the foreign network and can't be queried,
then the gateway has to cache the presences for gatewayed users. - Not
only to generate vcards ... it would already be necessary to be able to
respond to presence probe queries.

> I have no particular objection to using the the vCard protocol format, can
> you elaborate if this is your idea?
> As to the second option, I do not believe this is either practical
> being hosted in many cases outside the firewall will have to use some in
> band update protocol - vCard probably - to create the entry, and will have
> to handle the vCard requests from an XMPP client, which makes it a
> sophisticated gateway) nor very scalable (in a large distributed
> implementation the vCard storage will grow exponentially)

I think, the vcards shouldn't be stored whenever possible but created on
demand. If this is not possible ... indeed it has to be cached but only
for the users using the gateway at this time and probably the cached
information would have to be kept in this case anyway.

(Again: this message does not comment on how "nicks" - or how you would
call what is discussed - should be made available to Jabber. It just
comments on how I'd implement vcard support in a gateway from the
XMPP/Jabber world to another IM system. Well I don't comment because I
don't completely like any of the suggestes solutions so far and don't
have something that I'd like either.)

Tot kijk

More information about the Standards mailing list