[Standards] Proposed XMPP Extension: Buddycloud Channels

edhelas edhelas at movim.eu
Fri May 2 10:43:33 UTC 2014


Hi everyone,

I've review quickly the XEP and I have a couple of little comment to 
make :)

1. Section 6.3 
(http://xmpp.org/extensions/inbox/buddycloud-channels.html#item-payload) 
I see a list of actions (especially the threading and referencing one) 
that look like the Section 2.5 of the XEP-0277 ( 
http://xmpp.org/extensions/xep-0277.html#reply and 
http://xmpp.org/extensions/xep-0277.html#repeat). We must try to avoid 
different implementation specification for Atom management between the 
XEPs. 

Here I propose to clean the Atom management of the 0277 and the 
Buddycloud XEP and create an "Atom Management" XEP which define clearly 
how we can handle this kind of things between all the Atom entries that 
we found on the XMPP servers.

2. The rating section 
(http://xmpp.org/extensions/inbox/buddycloud-channels.html#item-rating) 
should be separated from the rest. This XEP deals with a new way to 
organize and fetch the items and should not consider the content of the 
items.

3. The recent items 
(http://xmpp.org/extensions/inbox/buddycloud-channels.html#items-recent) 
should be also separated from this XEP, it's more a Pubsub issue than a 
"Buddycloud" issue. We need to define a global way to get all the items 
from all the suscribed node since a specific moment.

4. What is the improvement between 
http://xmpp.org/extensions/inbox/buddycloud-channels.html#items-delete 
and http://xmpp.org/extensions/xep-0060.html#publisher-delete ?

5. Is there a particular reason to put the name of a XMPP client/server 
in a XEP ? I mean maybe we can find a more "neutral" title than 
"BuddyCloud…". 

Regards,

Jaussoin Timothée aka edhelas

On mer., avril 30, 2014 at 1:23 , Philipp Hancke 
<fippo at goodadvice.pages.de> wrote:
>> URL: http://xmpp.org/extensions/inbox/buddycloud-channels.html
>> 
>> The XMPP Council will decide in the next two weeks whether to accept 
>> this proposal as an official XEP.
> 
> some notes I wrote down while reviewing it:
> 
> section 1:
> s/inter-operate/interoperate/?
> 
> section 2:
> s/. find the/./
> 
> > Use a disco#items query against the XMPP service for the remote
> > Buddycloud domain.
> 
> remote domain? The remote buddycloud domain is not known yet.
> 
> > If no answer is returned (perhaps the remote site doesn't run a full
> > XMPP service) the Buddycloud service should proceed to use the DNS
> > discovery method.
> 
> I don't think you should concern yourself with entities that don't 
> respond to <iq type=get/> in the manner required by the spec. If that 
> is common, make it an implementation note.
> 
> example 4:
> to='juliet at capulet.lit/BuddycloudApp' should be '/balcony'
> id='info2' should be 'info1'
> shouldn't there also be a disco#items feature?
> 
> 
> section 3:
> > Upon connection to the buddycloud server a user should send a
> > register stanza.
> 
> This is rather vague. After logging in to the xmpp server, requesting 
> the roster and sending initial presence?
> 
> > The register request creates the user's personal channels on first 
> use
> 
> What happens if the user repeats this request subsequently? Does it 
> have to?
> 
> example 6 lacks some indentation.
> 
> 
> section 4:
> > - using disco-info with the node specified - using XEP-0060 5.4
> > Discover Node Metadata
> 
> can you add an appropriate <a href=''/> please?
> 
> > set Not sure what goes here?
> 
> that's a question implementors will ask you :-)
> 
> > minimum setting/optional recommended fallbacks
> 
> Same here.
> 
> s/changable/changeable/ -- readonly?
> 
> > Channel owners and moderators can also set the default affiliation
> > for the channel
> 
> And also the access model as described in table 3?
> 
> 
> > To kickstart Buddycloud starts with some well known and used nodes.
> > It is recommended that new nodes are announced publicly on the XSF
> > standards mailing list and an informal registry will be kept.
> 
> Ah, no. You want to provide an initial submission to the registrar 
> and a section for that.
> 
> /user/<jid>>/status node: any reason for not using XEP-0107? At least 
> the format.
> 
> table 5: s/channel read/Channel read/
> 
> 
> section 5.2:
> > of other social products
> 
> of many social products? This is not buddycloud vs others.
> 
> section 6.3:
> > according to & atom; standards and optionally making use of & 
> thread;
> > and & review ; extensions.
> 
> I think something went wrong with the entities here. Same for
> & xep0060 ; in 6.3..1 (and somehow there is an extra colon)
> 
> The indent in 6.3.2 is weird, also in several other places. Not sure 
> what went wrong there.
> 
> section 7:
> > Buddycloud clients follow
> 
> Conforming clients?
> 
> section 10.1:
> > This is done by running the server discovery process and confirming
> > the same XMPP component name.
> 
> Erm... can you explain this a little more?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140502/0489cd1f/attachment.html>


More information about the Standards mailing list