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
<fi...@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='jul...@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?
