XEP-0100 and roster/legacy contact list sync

Hello, list!

I'm reading XEP-0100: Gateway Interaction and trying to understand the
options with regard to legacy contact list/roster synchronization from
the point of view of the gateway author.

If I understand correctly, the gateway may or may not push legacy
contacts to the user's client for them to be added to the user's
roster:

"The gateway MAY initiate adding of the legacy contact list items to
the user's Jabber roster."

In practice, though, user may later add legacy contacts via <presence
to={contact <at> gateway} type="subscribe"/>, and that will have the
side-effect of changing his roster.  So, to avoid having only part of
one's legacy contact list in the roster, it's best for the gateway to
always "initiate adding of the legacy contact list items to the user's
Jabber roster".

(XEP-0100 also says that this shouldn't be done by 'sending a presence
stanza of type "subscribed" from legacy contact's JID' but by roster
item exchange.  From what I see, it's usually done by sending presence
stanzas of type "subscribe", which again when accepted will cause
roster changes as a side effect.)

Now, assuming that user and gateway want to do their best to keep the
Jabber roster and legacy contact list in sync, what happens if user
adds a legacy contact through a legacy client (thus without the
gateway's knowledge)?  When user connects again via Jabber, is the

Re: XEP-0100 and roster/legacy contact list sync

"Massimiliano Mirra" <iolgzc102 <at> sneakemail.com> writes:

> Now, assuming that user and gateway want to do their best to keep the
> Jabber roster and legacy contact list in sync, what happens if user
> adds a legacy contact through a legacy client (thus without the
> gateway's knowledge)?  When user connects again via Jabber, is the
> gateway supposed to notice that a new legacy contact is available, and
> push it to the user (using one of above methods)?

Yes.  Maybe this can be seen as a special case of section 5.1.

> Alternately, assuming neither the gateway nor the user are interested
> in synchronization, is it acceptable for the gateway to send no
> <presence type="subscribe" from={contact <at> gateway}/> from legacy
> contacts nor roster item exchange packets, but just ordinary <presence
> from={contact <at> gateway}/>, and not affect user's roster at all?

More or less.  Some (most?) clients will not display presence from
contacts not in the user's roster, but sending such presence is
explicitly mentioned in the RFC 3921, section 5.1.4.

--

-- 
Magnus
JID: legoscia <at> jabber.cd.chalmers.se

Re: XEP-0100 and roster/legacy contact list sync

On Dec 1, 2007 9:28 PM, Magnus Henoch mange-at-freemail.hu |jdev2|
<...> wrote:
> "Massimiliano Mirra" <iolgzc102 <at> sneakemail.com> writes:
>
> > Now, assuming that user and gateway want to do their best to keep the
> > Jabber roster and legacy contact list in sync, what happens if user
> > adds a legacy contact through a legacy client (thus without the
> > gateway's knowledge)?  When user connects again via Jabber, is the
> > gateway supposed to notice that a new legacy contact is available, and
> > push it to the user (using one of above methods)?
>
> Yes.  Maybe this can be seen as a special case of section 5.1.

Thanks, Magnus.  I guess that would be straightforward for an internal
server component, which has access to the user's roster.  Any idea
about how an external component might do the same without caching the
contact list?  (I don't see how that would be possible, but it
wouldn't be the first time I miss the obvious.)

Massimiliano

--

-- 
Massimiliano Mirra
http://sameplace.cc
http://hyperstruct.net

Re: XEP-0100 and roster/legacy contact list sync

Re: XEP-0100 and roster/legacy contact list sync

"Massimiliano Mirra" <iolgzc102 <at> sneakemail.com> writes:

> Thanks, Magnus.  I guess that would be straightforward for an internal
> server component, which has access to the user's roster.  Any idea
> about how an external component might do the same without caching the
> contact list?  (I don't see how that would be possible, but it
> wouldn't be the first time I miss the obvious.)

A random idea: if the legacy server provides some kind of versioning of
the contact list (ICQ does), the transport could save just the last
version/date that was synced to the Jabber roster.  If there's a newer
version on the legacy service, the transport can just send "subscribe"
stanzas for _all_ contacts; the user's server will weed out the ones
that already have subscription (section 5.1.6 of RFC 3921).

--

-- 
Magnus
JID: legoscia <at> jabber.cd.chalmers.se

Re: XEP-0100 and roster/legacy contact list sync

Re: XEP-0100 and roster/legacy contact list sync

Magnus Henoch <mange <at> freemail.hu> writes:

> A random idea: if the legacy server provides some kind of versioning of
> the contact list (ICQ does), the transport could save just the last
> version/date that was synced to the Jabber roster.  If there's a newer
> version on the legacy service, the transport can just send "subscribe"
> stanzas for _all_ contacts; the user's server will weed out the ones
> that already have subscription (section 5.1.6 of RFC 3921).

This won't work for _removing_ contacts, though...

--

-- 
Magnus
JID: legoscia <at> jabber.cd.chalmers.se

Extension field types for jabber:x:data

Hi guys,

I've spent a sad weekend lounging around the XEPs looking for a possible
solution to a niggle I've got.

Basically, I'm in the process of writing an client/server suite that
implements a sort of MVC architecture over XMPP.

In terms of the suite, XMPP makes sense for me since it handles the
point to point nicely, authentication and discovery... All I really need
to concentrate on are the specifics of my application server environment
without faffing around with a new protocol suite (isn't re-use nice).

I would ideally love to stick to existing XEPs that are in play or
proposed now.

While there is an XEP in the process for validation of form data
[XEP-0122] and presentation/layout at client side [XEP-0141], there is a
definite lack of useful field types in terms of my application for Data
Forms at the presentation layer.

I suppose an example might help explain:

One thing I need to communicate to my client is specific widget types. I
have fields within views in my application that need to reference models
and as such need a specific type of widget displayed on the form for
this purpose.

Over the wire, the data will be transmitted as an integer or some other
field type, however to the end-user, being able to display a widget
which has a search button next to it, which executes a different form,
will be of value.

Additionally, there are other nuances that I would like to handle like
opening another window/dialogue etc.

So my questions is thus:

Is there an XEP I'm missed that defines a protocol in this regard?

If not, would it be worth me submitting any protocol implementation that
I come up with, or would this not fall under the pervue of XEPs and be
more of a custom protocol?

Kind regards

--

-- 
Richard

Re: XEP-0100 and roster/legacy contact list sync

Dnia 02-12-2007, N o godzinie 00:59 +0100, Magnus Henoch pisze:
> A random idea: if the legacy server provides some kind of versioning
> of the contact list (ICQ does), the transport could save just the last
> version/date that was synced to the Jabber roster.  If there's a newer
> version on the legacy service, the transport can just send "subscribe"
> stanzas for _all_ contacts; the user's server will weed out the ones
> that already have subscription (section 5.1.6 of RFC 3921).

It does not even need to know anything had change.

In my transport I do this kind of synchronization (resubscribe to all
the users legacy contacts) every time a user logs in.
It's quick, simple and solves many problems related to presence mapping.

--

-- 
  /\_./o__ Tomasz Sterna
 (/^/(_^^'  Xiaoka.com
._.(_.)_  XMPP: smoku <at> xiaoka.com

Re: XEP-0100 and roster/legacy contact list sync

Tomasz Sterna wrote:
> It does not even need to know anything had change.
>
> In my transport I do this kind of synchronization (resubscribe to all
> the users legacy contacts) every time a user logs in.
> It's quick, simple and solves many problems related to presence mapping

In mine the transport is more deeply integrated than most and just 
directly manipulates the users roster (although only the items it owns, 
i.e. contacts at that transport), I find its far more user friendly that 
way and results in a far more seemless experience without any 
subscription request dialogs and whatnot popping up and confusing the users.

Richard