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='[email protected]/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?
