[Standards] Fwd: Minutes 2014-04-23
-- Forwarded message -- From: Kevin Smith Date: Fri, May 2, 2014 at 2:45 PM Subject: Re: Minutes 2014-04-23 To: XMPP Council On Thu, Apr 24, 2014 at 9:58 AM, Kevin Smith wrote: > Room logs: http://logs.xmpp.org/council/2014-04-23/ > > 1) Roll call. > Lance, Philipp, Matt, Kev present. Tobias absent. > > 2) http://xmpp.org/extensions/inbox/signing-forms.html > Accept as Experimental > > No objection from Lance. Others have a fortnight to object. Temporarily -1 on the basis that I don't think the preamble with links to opinion pieces on blogs is appropriate. Not objecting to the proposal itself, but I'm not at all convinced that use of this for IBR would be a good idea. > 3) http://xmpp.org/extensions/inbox/rayo-clustering.html > Accept as Experimental > > Lance/Philipp to post their objections to the council/standards lists. I'd like my position to count as -1 for the moment, but I might change my mind if a convincing argument is made on-list why clustering should be standardised. /K
Re: [Standards] Proposed XMPP Extension: Rayo Clustering
The idea is that implementations of gateways and nodes may be completed independently. There certainly is a requirement for Supplier A's gateway to be used with Supplier B's nodes, however. This requires the protocol between nodes and gateways to be specified. It is intended that nodes might additionally be used in heterogeneous clusters, but I admit there is not an urgent requirement for this. On 2 May 2014 10:29, Kevin Smith wrote: > On Fri, Apr 18, 2014 at 5:10 PM, XMPP Extensions Editor > wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Rayo Clustering > > Question for the authors, because it's not clear to me. > > We have tended to shy away from standardising clustering protocols, as > these are perceived as being an implementation detail, rather than > needed for interop between different implementations; is the purpose > of this proposal that independent implementations will be run in a > heterogeneous cluster, and if so how likely is this to happen? > > /K >
Re: [Standards] Proposed XMPP Extension: Rayo Clustering
On Fri, Apr 18, 2014 at 5:10 PM, XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > Title: Rayo Clustering Question for the authors, because it's not clear to me. We have tended to shy away from standardising clustering protocols, as these are perceived as being an implementation detail, rather than needed for interop between different implementations; is the purpose of this proposal that independent implementations will be run in a heterogeneous cluster, and if so how likely is this to happen? /K
Re: [Standards] Proposed XMPP Extension: Buddycloud Channels
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 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 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 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/>/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?
[Standards] Fwd: Minutes 2014-04-30
FYI -- Forwarded message -- From: Kevin Smith Date: Fri, May 2, 2014 at 9:17 AM Subject: Minutes 2014-04-30 To: XMPP Council Room logs: http://logs.xmpp.org/council/2014-04-30/ 1) Roll call Kev, Lance, Philipp, Tobias, Matt present 2) http://xmpp.org/extensions/inbox/buddycloud-channels.html Accept as experimental? General concern expressed over using the names of existing projects in branding of XEPs. Lance/Fippo -1 pending removal of Buddycloud branding, then no objection Kev -1 for Buddycloud branding and still needs to check technical content Tobias/Matt to reply on-list within a fortnight 3) Date of next meeting 2014-05-07 15:00Z Fippo sends apologies 4) Any other businses Reminder for Council to vote on outstanding items. Peter would like reviews of http://datatracker.ietf.org/doc/draft-ietf-stox-groupchat/ Discussion of companies using urn:xmpp URIs. Fini
