Hello, Pubsub specifications often refers to the Atom format as a payload. Nevertheless, there are some confusing things that makes it hard to understand how to map atom to pubsub in some cases that are outside of the specifications. The reason I want to solve them is in XEP-277 which I need to update to implement some of must have feature into my microblogging platform.
Here I suggest to discuss these problems. The hardest problem here is how to map atom:id (http://tools.ietf.org/html/rfc4287#page-19) element to the pubsub item id and closely connected to it problem with the "Update" post feature. The problem is that we have two different entry id fields and it very important to understand which means what to make protocol useful. I see two possible ways here: 1) pubsub item id identifies the concrete revision of an item. Thus, if we have to update the item then we just post a new item to the node with the same atom:id and another pubsub id. Benefit here is that if we link from another place to this item (for example, in the <in-reply-to>) then it will be a link to this concrete revision and will never confuse with other revisions. Another benefit is that we can to track any changes to the entry since all of them are stored in the node. But this option has one strong disadvantage: we have no way to group these entries to make it possible, for example, to retract the entry entirely with all of it's revisions. I have no idea how we can solve the issue yet. 2) pubsub item id = atom:id. Thus, if we have to update the item then we just update the item. :) Possibly, we need to refuse to use atom:id in payload at all since it's confusing to have two identities that means the same thing. How to address the entry then? Thanks for your attentions, I hope that I was clear enough. Have a good weekend, btw. :) -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
