Hi everyone,<div><br></div><div>I've review quickly the XEP and I have a couple of little comment to make :)</div><div><br></div><div>1. Section 6.3 (<a href="http://xmpp.org/extensions/inbox/buddycloud-channels.html#item-payload ">http://xmpp.org/extensions/inbox/buddycloud-channels.html#item-payload</a>) I see a list of actions (especially the threading and referencing one) that look like the Section 2.5 of the XEP-0277 ( <a href="http://xmpp.org/extensions/xep-0277.html#reply" style="font-family: sans-serif;">http://xmpp.org/extensions/xep-0277.html#reply</a> and <a href="http://xmpp.org/extensions/xep-0277.html#repeat">http://xmpp.org/extensions/xep-0277.html#repeat</a>). We must try to avoid different implementation specification for Atom management between the XEPs. </div><div><br></div><div>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.</div><div><br></div><div>2. The rating section (<a href="http://xmpp.org/extensions/inbox/buddycloud-channels.html#item-rating">http://xmpp.org/extensions/inbox/buddycloud-channels.html#item-rating</a>) 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.</div><div><br></div><div>3. The recent items (<a href="http://xmpp.org/extensions/inbox/buddycloud-channels.html#items-recent">http://xmpp.org/extensions/inbox/buddycloud-channels.html#items-recent</a>) 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.</div><div><br></div><div>4. What is the improvement between <a href="http://xmpp.org/extensions/inbox/buddycloud-channels.html#items-delete">http://xmpp.org/extensions/inbox/buddycloud-channels.html#items-delete</a> and <a href="http://xmpp.org/extensions/xep-0060.html#publisher-delete">http://xmpp.org/extensions/xep-0060.html#publisher-delete</a> ?</div><div><br></div><div>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…". </div><div><br></div><div>Regards,</div><div><br></div><div>Jaussoin Timothée aka edhelas<br><br>On mer., avril 30, 2014 at 1:23 , Philipp Hancke <email@example.com> wrote:<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;"><blockquote>URL: <a href="http://xmpp.org/extensions/inbox/buddycloud-channels.html">http://xmpp.org/extensions/inbox/buddycloud-channels.html</a>
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.
firstname.lastname@example.org/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 the format.
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?</div></blockquote></div>