[Standards-JIG] JEP-163 (SPPS) comments

Joe Hildebrand hildjj at gmail.com
Mon Jan 30 21:20:58 UTC 2006


>> For all three of these, I think the "MUST allow" should be "SHOULD  
>> allow", to account for other potential access controls that the  
>> server may know.  One example might be ethical boundaries enforced  
>> by a policy engine.
> Can you give an example? I'm keen on spps staying as simple and  
> well defined as possible and only allowing doubt where absolutely  
> necessary.

Hal nailed it in his reply.

>> Is there a way to get notified of new nodes, perhaps by calling  
>> the bare jid a collection node, and subscribing with subscription  
>> type nodes?
> Why is this interesting? Entity caps could be used to signal new  
> features I think, meaning the creation of nodes shouldn't need to  
> be signalled.

As Maciek alluded to, Entity caps are a client-side thing, and SPPS  
is server-side.  There's no way to get notified of a new node's worth  
of presence for a person without allowing collection subs.

>> As for security considerations, the attack modes seem to be based  
>> on from address spoofing, which we've got handled.  It might be  
>> worth pointing out that ACL's SHOULD be recalculated whenever an  
>> applicable roster item is modified, to ensure coherency.
> I'm not sure what you mean, is this the same as saying ACLs must be  
> verified for every push? If so, I agree.

Hm.  It's a perf question which of them you use.  Maybe just an  
admonition to recalculate whenever "needed", up to and including for  
each push and subscribe.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1883 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060130/e588eef5/attachment.bin>


More information about the Standards mailing list