[Standards] UPDATED: XEP-0277 (Microblogging over XMPP)

Valérian Saliou valerian.saliou at vanaryon.eu
Wed Jun 1 22:55:17 UTC 2011


I will try to reply to your answers/suggestions ;)

1. In the microblogging XEP we wanted to define a simple way to share
some files. But I never heard of the XEP-0135, will read it as soon as
possible. Anyway, by looking at it quickly, it gives me some ideas about
how we could manage photo albums/file albums to extend XMPP social

2.1. It is actually clear: there is an example after this text.

2.2. Mhh, maybe I did not understand you when you suggested us this.
Were you talking of the parent microblog item of a comment node, in case
of re-using the comment node somewhere else? Or to identify the original
comment node parent if the parent was repeated by some users in their
own microblog?

2.3. I don't really see where the security leak is. The microblog owner
publishes an entry linking to a comment node, and the client retrieves
it if there is a link to it. Or maybe you mean, avoid re-using a comment
node URI in another microblog post by a nasty microblog item publisher?

3. I really think it makes things much simpler and clearer by separating
the content itself from the informations, so that the owner can purge
its microblog node without any meta-infos lost.

4. The notifications, as defined in the XEP, can be sent to the node's
owner (you can retrieve who the owner is with a pubsub query), and all
the comment publishers. By the way, the parent microblog item publisher
might be also notified.

5. I studied this case before. There is a solution with the <set
xmlns='http://jabber.org/protocol/rsm'> element, to say the server "Hey,
I just want the items published after the item with the ID=XX" (see the
Pubsub XEP for that), but its usage is not clearly described and it is
not implemented in XMPP servers like ejabberd.

6. Related to Pubsub XEP, I remember some mails were exchanged about
this "Pubsub item count" during the last month, right?

Best regards,

Valérian Saliou,
Jappix founder

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
> 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.

More information about the Standards mailing list