[JDEV] Discussion of transports?

[maqi at jabberstudio.org]

On Wed, 24 Sep 2003, Robert Norris wrote:

[for the interested, links to "roster push by s10n subscribed packet":]

- Andrew & Rob's discussion
http://www.jabber.org/chatbot/logs/conference.jabber.org/jdev/2003-09-23.html
(search for "presence type")

- "Bug" in jabberd2
http://www.jabberstudio.org/pipermail/jabberd/2002-December/000411.html

- "Transports&contacts" thread on jdev in January 2003
http://article.gmane.org/gmane.network.jabber.devel/17874
(this is almost the same as the current thread)

> I've been thinking about allowing (with certain restrictions) entities
> to set and get a users roster. This (by itself) would require no client
> changes. Basically, a transport could do normal roster get/set
> operations (just like a client)

If this was handled by extension of "subscribed" presence, it even would
be more or less backwards compatible with jabberd14. But of course if it
breaks XMPP...

>  - It allows transports to override the normal Jabber roster semantics.

As Andrew said, the normal roster semantics is to *add new* contacts but
we *import existing* contacts here. It's simply a thing that does not
occur with Jabber-only usage.

>  - Suitable access controls are required. Obviously, it won't do to
>    allow anyone to change anyone elses roster. One thought we had is to
>    restrict operations based on the transport JID (domain) - ie, the
>    transport can only set roster items of its own users, and when a
>    roster is retrieved, it only receives items for its own users.

(Roster retrieval would be indeed great and solve a great deal of hassle I
described in http://article.gmane.org/gmane.network.jabber.devel/20097 :-)

>  - It seems that some sort of opt-in mechanism is required, whereby
>    users can authorise certain remote entities to modify their roster.
>    However, this requires client support, unless someone can think of
>    something better (one hackish idea we had was to make it based on
>    whether or not you've subscribed to a server (domain only) - if you
>    have, then they can play).

One can combine these ideas - no opt-in required if domain already added
to roster, opt-in required if not. Registering with the transport (and the
following s10n exchange) means "I want to use the transport's services and
let the transport do what it needs to" I think.

Regards