[Standards-JIG] JEP-163 (SPPS) comments
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
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...
Size: 1883 bytes
Desc: not available
More information about the Standards