[Standards] Microblogging: XEP-0277 and beyond

Sergey Dobrov binary at jrudevels.org
Thu Sep 1 18:22:30 UTC 2011

On 09/01/2011 03:21 AM, Justin Karneges wrote:
> On Wednesday, August 31, 2011 11:32:53 AM Sergey Dobrov wrote:
> IMO, the commenting approach described in XEP-277 is too simple and rather
> uninspired (full disclaimer: I work at a company whose sole product is
> commenting).  Commenting is similar, but not identical to microblogging, and
> the two deserve separate specs.  Probably the commenting section in XEP-277
> should be exchanged with a pointer to XEP-303.

I reviewed the XEP-303 and I'm sorry that I did not that before since it 
has some really significant notices, so I'll do some notes below and 
maybe you are right with a pointer to XEP-303.

> Anyway, are you saying that all of the functional requirements of XEP-303
> could be extracted out into separate smaller "reusable" extensions that
> implementors of generic XEP-60 servers might embrace?  Really ejabberd might
> add an extension that mirrors VCards content in Atom entries?  I guess in
> theory that would be cool, but it seems a bit on the dreamy side.

I meant that common cases should be in XEP-60 or some other XEPs that 
will describe some specific node behavior. For example, I don't sure 
that this is ok to include filters into the node name (why to url quote 
these?), but it can be useful to determine some queries protocol which 
can be inserted in the request of items, so we can use generic pubsub 
nodes without some functionality.

Then, my questions about XEP-303:

1) Why to use three nodes? Info node can be replaced by some item with 
some constant id. about necessity of activity node I don't understood at 
all, why to have it?

2) Why to use Activity Streams here? I totally misunderstanding why to 
have such complication since commenting behavior totally get into simple 
Atom format.

3) You have filter parameter by parent id but have no any mechanism to 
represent such relations. But this mechanism is already defined in XEP-277.

4) atom:id MUST be an URI.

5) Again, why to url encode a node name? 

More information about the Standards mailing list