[Standards] Proposed XMPP Extension: Buddycloud Channels

Philipp Hancke fippo at goodadvice.pages.de
Wed Apr 30 11:23:49 UTC 2014


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



More information about the Standards mailing list