On 06/02/2011 12:36 AM, XMPP Extensions Editor wrote: > Version 0.4 of XEP-0277 (Microblogging over XMPP) has been released. > > Abstract: This specification defines a method for microblogging over XMPP. > > Changelog: Added microblog informations feature, ID innacurracy fixed, > urn:xmpp:inbox support added, new commenting namespaces, first comment > marker, security considerations added. (vs) > > Diff: http://xmpp.org/extensions/diff/api/xep/0277/diff/0.3/vs/0.4 > > URL: http://xmpp.org/extensions/xep-0277.html > >
The revision of document has disappointed me... 1. The "2.7 Attaching files to a post" point. I don't really understand how client should to serve the files. I think that we should to use XEP-135 to do that. I don't understand why to use rel="self" instead of rel="related" for a link to a file (rel="self" identifies a resource equivalent to the containing element which is obviously false. Please correct me if I wrong) 2. The "3. Comments" point. 2.1. "Romeo's client MIGHT add a element to the PubSub item." It's not clear what element might Romeo's client to add. 2.2. "If the comment to publish is the first item of the node, the client MAY add a "link" element, with the "rel=start" attribute." Why only for first? How to determine if it first? What if the comment will be retracted? The spec doesn't clarify what href should be added with the link. I use rel="start" as identify of the post to what whole replies node is related. I mean to the post which have <link rel="replies"> to this pubsub node with comments. In this way client can always determine a thread to what comment is related even if it receive an xmpp-link to some comment and not for an original post. 2.3. There are one possible attack to a comments node. If some entity will publish post with link rel="replies" to a comments node for another post then users can be confused with actual content of the post to which they replying. I assume to add cross references links to both post and replies node metadata and oblige client to check if links correspond to one another. 3. The "5. Microblog informations" point. Why to make more and more new entities? I mean why we need the new node "urn:xmpp:microblog:0:informations"? Why can't we use the "urn:xmpp:microblog:0" node itself? How to store metadata for replies nodes this way? 4. The "6. Notifications" point is the most strange for me. Why to send notification when commenting on node? I mean we already have replies node to which anyone can subscribe and receive usual notifications. I understand that it's impossible to do that when replies node is not used. But how can I determine to which users I should send my notifications? If I constantly attached to the network I can see all thread and all comments but if I use different resources and often switch between them then all this schema will fail. Some things that not related to new revision: 5. Retrieve offline items. I don't know how it possible to retrieve items that was sent while my client was in offline or the priority of my client was not highest. I think that we should add possibility to retrieve items from a node with timestamp or just a query that allow to check if there was items since the moment and how many. 6. We have no possibility to retrieve count of items in a node easily. I know about metadata for a node but I don't think that this is really easy way to retrieve such a basic information. (I don't know how it will be efficient for server side) -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
