[Standards-JIG] Re: Summary of roster proposal points

Rachel Blackman 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 
>> not
>> to display an 'add user to roster' request.  I know I would go 
>> slightly
>> 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 
>> a
>> message from another user, it probably should have an approval
>> dialogue.
> 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 
> have
>    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...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://mail.jabber.org/pipermail/standards/attachments/20040909/9448b0c9/attachment.sig>

More information about the Standards mailing list