[Standards] XEP-0060 (and dependent ones): overwriting an item of somebody else

Dave Cridland dave at cridland.net
Tue Aug 11 09:43:51 UTC 2015

On 11 August 2015 at 00:05, Goffi <goffi at goffi.org> wrote:

> G'day,
> It seems that in XEP-0060 nothing prevent a publisher to overwrite an item
> published by somebody else (or at least it's ambiguous)
> while that may be desirable in some cases, it's pretty bad with XEP-0277
> comments.
> In XEP-0060 § 7.1.1, it's said that
> "Any entity that is allowed to publish items to a node (i.e., a publisher
> or an owner)  [...]"
>  and "The <item/> element provided by the publisher MAY possess an 'id'
> attribute, specifying a unique ItemID for the item."
> in § 7.1.2 it's said "Note: If the publisher previously published an item
> with the same ItemID, successfully processing the request means that the
> service MUST overwrite the old item with the new item and then proceed as
> follows."
> Well the ambiguous part is "the publisher": in the case of XEP-0277
> comments, the publish model if most of time "subscribers", so any
> subscriber is a publisher. It's not explicit in the XEP that the service
> should prevent a publisher to overwrite an item from an other publisher.
Agreed. I think this parallels the notes on permissions in §4.1 Table 1,
where it notes that Publishers MAY be able to retract other people's items
but SHOULD NOT allow this for Publish-Only.

> Im my opinion the following points should be modified:
> - this case should be made explicit in the XEP-0060, with e.g. a security
> warning

> - a node configuration option can be used to specify if a publisher can
> overwrite an item initially published by somebody else
I think we - probably - want to split out these two as distinct
affiliations, long-term. Buddycloud does this, having an additional
affiliation which has broad rights, compared to normal publishers which can
only publish/retract their own content.

> - if this option is present, it MUST default to false (i.e. a publisher
> can't overwrite something that he didn't publish).
This would, in turn, means that "publisher" affiliation could only retract
and re-publish their own content, whereas the new affiliation could retract
and republish any items - that is, no configuration option would be needed.

> Thanks
> Goffi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150811/713cc70d/attachment.html>

More information about the Standards mailing list