[Standards-JIG] Re: Summary of roster proposal points
richard at dobson-i.net
Wed Sep 8 09:06:33 UTC 2004
>> There you go, if you still cannot see how it can work together then I
>> suggest you email me off list (as well as anyone else who would like more
> I would definitely appreciate you explaining in detail exactly how this
> work. If it indeed can work, I'll implement it in PyMSNt, but how to do it
> needs to be documented somewhere, right now it's unclear how JEP0093 can
> made to fit this problem.
> That is, it has to work with all clients (even if they don't support
> so presence subscribe must be used as a backup), and the client needs to
> which contacts have already been authorised.
> I guess you could just specify that the transport MUST NOT send the any
> unauthorised contact in a JEP0093 packet, that way the client would be
> to assume that any contacts sent can be added automatically.
Yup exactly right, what JEP-0093 provides is the capability for the client
to know which contacts to auto-add, but it also has the benefit of also
working for clients which support JEP-0093 but not your slightly more user
friendly implementation by allowing the user to add all the existing
contacts in one go, rather than having to accept lots of subscription
>> Yes but such an ACL system would be useful I would think with other
>> protocols, making the ACL more of a generic ACL system where roster
>> rights is just one of the many resources it could manage access to, IMO
>> work on such a system would be very benefical to jabber.
> Just curious, what other things could it be used for?
Practically any protocol where it needs some form of access control
management, remote roster management is just one.
>> Your idea of separate lists in interesting but IMO is not really needed
>> certainly as far as transports is concerned is not really the right way
>> go about it. But yes the real issue is the ACL mechanism here, that we
>> it as extensible as possible and try to solve all of our needs for remote
>> roster manipulation.
> Yes. It definitely needs to be flexible as you say. Hopefully we can do
> without providing the user with an overly complicated data form that they
> must submit =P
> That's always the tricky bit, mixing power & flexibility with ease of use.
Of course, there are several ways we can make the UI for controlling the ACL
nice and easy, by providing several ways to editing it, the best way to
build a nice interface is to provide a native control protocol, but there is
no reason you cannot also provide data forms too so that clients without
native support can still manipulate the ACL, even if it isnt quite as user
> Once again, please do explain exactly how I can use the existing JEP0093
> support in clients to make the gateways work as seamlessly as they would
> my proposal. The part I'm most unclear on is what happens when a client
> ignores the JEP0093 packet (because it doesn't understand it), and how the
> gateway can know to send presence subscribes. If it sends the presence
> subscribes and the JEP0093 push at the same time, then there's no point in
> sending the JEP0093 at all.
Well if a client ignores the JEP-0093 stanza they will simply get prompted
with all the subscription requests, the best way to implement this would be
to send out the JEP-0093 packet before any subscriptions, then have a delay
of say 30 seconds before you actually send all the pending subscriptions or
start sending all of them out when you receive your last subscription
request from the client indicating that they have finished adding the
contacts that were in the JEP-0093 packet.
More information about the Standards