[Social] XEP-0277 (Microblogging over XMPP) Feedback

Ralph Meijer jabber.org at ralphm.ik.nu
Sat Jul 17 01:07:25 CDT 2010

Moving this to social at xmpp.org, to catch a bigger crowd. Please reply
there. For reference, the thread start:


Comments below. 

On Fri, 2010-07-16 at 22:35 +0200, Guus der Kinderen wrote:
>         Thanks. Every XEP I have seen includes a schema section. RFC
>         4287 defines
>         the ATOM schema but it is not clear the ATOM schema should
>         match the schema
>         for XEP-0277. I am guessing it does, but if different people
>         guess
>         differently then interoperability goes out the window. In fact
>         this has
>         happened already during interoperability testing. Without a
>         schema it is
>         also not clear that ATOM format is what MUST be used - the
>         text doesn't seem
>         to be clear on this although the examples use ATOM style. I
>         would suggest
>         modifying the XEP to say that ATOM is the format that MUST be
>         used for the
>         item and include the complete schema if possible.
> Not only is the XEP not clear on at least one common denominator
> (ATOM), but it explicitly specifies that other formats are acceptable
> (although it does not strictly define these). 
> I would not like to depend solely on ATOM (as Stephen suggests) as I'm
> still not comfortable with using ATOM to generate new microblog
> entries (I do like it for publishing existing/just created entries
> though). The comment in the XEP related to clients having to
> generate IDs forms the basis of my dislike. I find this
> requirement unneeded (from the feature-perspective, I agree that is is
> required by the ATOM spec) and confusing.
> Also, the ATOM based examples appear to be wrong. I've voiced these
> and similar concerns in an older discussion thread, here:
> http://mail.jabber.org/pipermail/standards/2010-May/023480.html -
> Stephen, given your experience, I'd like to hear your comments on that
> discussion.

I think these issues mostly arise from the context in which the Atom
Syndication Format [5] was created. The assumption here is that
everything is HTTP based, entries are authoritatively published/hosted
on a website. From that point of view, it makes sense to require
particular fields and require the author to include a stable id. The
specification is quite rigid in that respect. For blogging software or
other publishing mechanisms where Atom is just generated for
consumption, and the Atom is not used for creating the entries, this is
reasonably easy to achieve.

However, if you start to use the Atom format for creating or adjusting
entries, it could make sense to allow offering incomplete entries.
Fields like atom:id, atom:updated and even atom:author could be
generated on the server side. The Atom Publishing Protocol (RFC 5023)
[4] does hint in that direction in section 9.2 (Creating Resources with
POST), by suggesting that the server is free to modify such fields after
submission. Unfortunately it doesn't mention a possibility to provide
incomplete Atom entries (e.g. only atom:title and atom:content) that the
server completes before storing/publishing.

Guus mentions in his earlier message the requirement for a title. I want
to make clear here that while the Atom Syndication Format does require
the existence of particular elements (Section 4.1.2 The "atom:entry"
Element), like atom:title, it does NOT require text fields to have a
non-empty value (Section Providing Textual Content). I do agree
that it debatable where a microblog entry's text should reside, but do
lean towards atom:content. The feeds of status.net and Twitter, for
example, seem to put it both in the title and the content element.

Another thing we should consider is Activity Streams [1]. Besides
sending around entries for social objects themselves, another direction
is sending around entries for the events around them: 'ralphm posted a
new entry', where the actual item is included as activity data. Activity
Streams also use the Atom format, with a bunch of extensions. The
specification grandfathers 'regular' Atom entries with 'Implied
Activity' [2].

The Buzz Rest API uses Activity Streams and if you look at their
documentation [3], you can see that they too assume incomplete Atom
entries when POSTing. In fact they even ignore fields, if they are

  Note: You don’t have to supply the standard atom:id, atom:author, or
  atom:updated elements; the server creates those in response to your
  POST request. These elements will be ignored if present.

In general I think consuming Atom entries should be done quite
liberally. Maybe bis versions of the Atom specifications could make some
more room for them to ease the minds of the schema purists.

As for requiring Atom, this does seem to be the format the whole
microblogging/activity community is gravitating towards. I can imagine
situations where you could use another or custom format when submitting
an entry. The server could interpret this to make a proper Atom entry
out of that, like suggested in the Atom Publishing Protocol, but I
consider that outside of the scope of this specification.

[1] http://activitystrea.ms/
[2] http://activitystrea.ms/spec/1.0/atom-activity-01.html#impliedpost
[3] http://code.google.com/apis/buzz/v1/using_rest.html
[4] http://www.atomenabled.org/developers/protocol/atom-protocol-spec.php
[5] http://www.atomenabled.org/developers/syndication/atom-format-spec.php


More information about the social mailing list