[Standards-JIG] Re: Summary of roster proposal points
rcb at ceruleanstudios.com
Thu Sep 9 08:54:34 UTC 2004
>> As I recall, -93 doesn't support any particular logic on whether or
>> to display an 'add user to roster' request. I know I would go
>> nuts if I were forced to approve all, urm, 190 or so AIM contacts I
>> have on my combined AIM rosters... but if a roster contact is sent in
>> message from another user, it probably should have an approval
> 1. You can get all roster items to be imported in one jabber:x:roster
> message and therefore you only have to accept one import dialog.
Okay, granted. I still cringe at the idea of making any sort of sane
import dialog for 193 contacts (because I will guarantee you there will
be someone out there will will want to accept only 187 of those 193
contacts). But I can accept this logic.
> 2. It is up to your client to decide which jabber:x:roster messages
> to be accepted by the user and which don't. If the client knows that
> you just registered a transport, it could auto-accept the
> jabber:x:roster message generated by this transport.
Yes, I agree. I just think this behavior should be more explicitly
stated, rather than left up to whim and chance. Don't get me wrong,
client authors are responsible people, but we've already seen slightly
divergent implementations of JEPs due to not specifying behavior
clearly enough. Of the JEP-0071 implemtnations out there, I've seen
some which couldn't deal with what each other generated because so many
things were RECOMMENDED rather than REQUIRED elements.
Just saying it might be worth adding something like:
A client supporting this specification SHOULD treat each
block as a single import, and display only a single dialog for it. A
client supporting this implementation MAY forego the display of an
dialog altogether and simply accept all contacts if the stanza
the jabber:x:roster block is in an iq stanza of type 'reply'.
...and thus voila, we've defined that if the jabber:x:roster block
comes in reply to the jabber:iq:register to a transport, the client can
choose to just accept them all automatically. Clear, easy optional
behavior, and when it's okay to do it. This /also/ tells the transport
authors that if they want to use jabber:x:roster, they should put it
into the reply stanza to the registration, and the client can handle it
automatically, rather than sending a message stanza or something
afterwards. That's all I meant. :)
Rachel 'Sparks' Blackman -- sysadmin, developer, mad scientist
"If it is not broken, give me five minutes to redesign it!"
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
More information about the Standards