[Standards] Proposed XMPP Extension: Buddycloud Channels
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:
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.
to='juliet at capulet.lit/BuddycloudApp' should be '/balcony'
id='info2' should be 'info1'
shouldn't there also be a disco#items feature?
> 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.
> - 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
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
table 5: s/channel read/Channel read/
> of other social products
of many social products? This is not buddycloud vs others.
> 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.
> Buddycloud clients follow
> 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