[Standards] XEP-0060: return ItemID in IQ-result?

Joe Hildebrand hildjj at gmail.com
Wed May 14 23:19:32 UTC 2008


I like it.  I actually thought that was the way it was supposed to work the
whole time. :)


On 5/14/08 4:50 PM, "Peter Saint-Andre" <stpeter at stpeter.im> wrote:

> When you publish an item to a pubsub node and the ItemID is generated by
> the service, you don't know what the ItemID is unless you subscribe to
> the node (which I grant is typical for publishers) and you can correctly
> correlate the payload with what you published. While the IQ-result tells
>  you that the item has been published, you don't know necessarily the
> ItemID. It seems reasonable that the service MAY return the ItemID to
> you, as in the following flow:
> 
> <iq type='set'
>     from='hamlet at denmark.lit/blogbot'
>     to='pubsub.shakespeare.lit'
>     id='publish1'>
>   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
>     <publish node='princely_musings'>
>       <item>
>         <entry xmlns='http://www.w3.org/2005/Atom'>
>           <title>Soliloquy</title>
>           <summary>
> To be, or not to be: that is the question:
> Whether 'tis nobler in the mind to suffer
> The slings and arrows of outrageous fortune,
> Or to take arms against a sea of troubles,
> And by opposing end them?
>           </summary>
>           <link rel='alternate' type='text/html'
>                 href='http://denmark.lit/2003/12/13/atom03'/>
>           <id>tag:denmark.lit,2003:entry-32397</id>
>           <published>2003-12-13T18:30:02Z</published>
>           <updated>2003-12-13T18:30:02Z</updated>
>         </entry>
>       </item>
>     </publish>
>   </pubsub>
> </iq>
> 
> <iq type='result'
>     from='pubsub.shakespeare.lit'
>     to='hamlet at denmark.lit/blogbot'
>     id='publish1'>
>   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
>     <publish node='princely_musings'>
>       <item id='ae890ac52d0df67ed7cfdf51b644e901'/>
>     </publish>
>   </pubsub>
> </iq>
> 
> Is this needed or desirable? This would not be required, but optional
> for the service.
> 
> Peter





More information about the Standards mailing list