[Standards] Microblogging: XEP-0277 and beyond

Sergey Dobrov binary at jrudevels.org
Thu Sep 1 19:10:37 UTC 2011

On 09/02/2011 01:22 AM, Sergey Dobrov wrote:
> 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?
> ("comments?order=-created&parent_ids=1%2C5a%2Co19g%2C")
I forgot about one thing: I think that this is unnecessary to validate a 
sender on server side. That is why: I wrote a blog importer from the 
juick.com microblogging service to my implementation of the XEP-277 
based service and when it imports comments it uses fake JIDs but the 
service sends publisher attribute so it can be validated who exactly 
sent a comment but it's also possible to make such imports or another 
pretty things. So I think that validation is unnecessary but publisher 
attribute usage must be clarified more strictly in the XEP-60.

More information about the Standards mailing list