[Standards] XEP-0258 and XEP-0060
ashley.ward at surevine.com
Fri Nov 18 10:52:54 UTC 2011
On 17/11/2011 21:18, "Dave Cridland" <dave at cridland.net> wrote:
>In addition, if the server has a clearance for a seperate pubsub
>service, it's going to need to decide what to do if different items
>do and do not pass the ACDF. This is tricky, because the model only
>allows for all-pass or all-fail.
That's true. It would be fine I suppose to say that if a client wishes to
publish multiple items with differing labels then they should submit these
in multiple stanzas.
>> There would also be some corner cases to think about, especially
>> discovery of nodes - e.g. should a user who isn't entitled to
>> access a
>> node know that it exists, and if not then what happens if they try
>> create a node with a conflicting id (as an error reveals
>> information about
>> the node's existence). Perhaps this sort of detail should be up to
>> server implementation?
>Ew. That's yet another problem I'd not seen.
>If a user tries to join a chatroom that they don't have clearance
>for, we hand back an error. I think you have to for nodes, too,
>that's the only logical thing to do.
>For items, though, this gets substantially nastier, since the model
>assumes that overwrite is normal, and indeed desirable, and the
>intent. So if someone writes an item with a clearance you can't see,
>how on earth is this meant to be handled?
Does it just all become a more fine grained permissions system? If you
have write access to a node but try and overwrite an item that you don't
have clearance for, then you just get a normal forbidden error.
>Finally, I'd point (back) to my Last Call comments - from back when
>the specification *did* have a PubSub section - where I pointed out
>that the catalogue work needs work to cover not only jid, but
>jid+node. Not a major change, but a change nonetheless.
I didn't realise this used to be I the spec! I've just read the old spec
(v0.9) and it's pretty much exactly what I was thinking of above (with the
<securitylabel/> within the <item/> which violates the schema for pubsub).
I guess it was removed at that time because it's actually not that easy!
I assume catalog discovery for a node would work in a similar way as the
muc room label discovery for nodes which are addressable as a kid,
otherwise I guess we would need to either add a "node" attribute to the
<catalog/> element in the label catalog request, or make it part of the
More information about the Standards