Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Montag, 15. Januar 2018 09:47:28 CET Kevin Smith wrote: > On 15 Jan 2018, at 09:31, Dave Cridland wrote: > > On 15 Jan 2018 07:02, "Jonas Wielicki" > > wrote:> > > On Sonntag, 14. Januar 2018 13:53:53 CET Tedd Sterr wrote:

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On 15 Jan 2018, at 09:31, Dave Cridland wrote: > On 15 Jan 2018 07:02, "Jonas Wielicki" > wrote: > On Sonntag, 14. Januar 2018 13:53:53 CET Tedd Sterr wrote: > > As someone intending to develop a new modern client, I think a

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On 15 Jan 2018 07:02, "Jonas Wielicki" wrote: On Sonntag, 14. Januar 2018 13:53:53 CET Tedd Sterr wrote: > As someone intending to develop a new modern client, I think a sensible (and > useful) suggestion would be to add something along the lines of "Legacy >

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Sonntag, 14. Januar 2018 13:53:53 CET Tedd Sterr wrote: > As someone intending to develop a new modern client, I think a sensible (and > useful) suggestion would be to add something along the lines of "Legacy > Considerations." This could be inserted either as an additional row in each > of the

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

As someone intending to develop a new modern client, I think a sensible (and useful) suggestion would be to add something along the lines of "Legacy Considerations." This could be inserted either as an additional row in each of the 2.x tables as necessary, or as a new section 2.5. That way 0084

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Samstag, 13. Januar 2018 13:52:56 CET Evgeny Khramtsov wrote: > You're right here. Seems like we need clients to be able to read > vCards. However, for Private XML this is not needed at all. Except that proper private PEP still lacks server support in many deployments. So again clients will

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

Fri, 12 Jan 2018 22:28:19 + Kevin Smith wrote: > I would almost certainly implement -49, in order to have interop with > the vast majority of currently deployed stuff, and as a server dev I > would absolutely certainly implement 49 - probably as one of the > first

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On 12 Jan 2018, at 09:04, Daniel Gultsch wrote: > I see the compliance suite as a list of XEPs that should be > implemented if you want to create a modern day instant messenger. Indeed, and I think this includes useful interop, not with long-abandoned software but with the

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

I see the compliance suite as a list of XEPs that should be implemented if you want to create a modern day instant messenger. It is not a guideline on what crude hacks you have to do if you want to be compatible with some random multi protocol messenger that hasn't been updated in a decade. There

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On 11 Dec 2017, at 17:23, Holger Weiß wrote: > > * Kevin Smith [2017-12-11 17:16]: >> On 11 Dec 2017, at 16:44, Holger Weiß wrote: >>> * Kevin Smith [2017-12-11 15:34]: 84 allows you to

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

* Kevin Smith [2017-12-11 17:16]: > On 11 Dec 2017, at 16:44, Holger Weiß wrote: > > * Kevin Smith [2017-12-11 15:34]: > >> 84 allows you to publish multiple versions of an avatar, each of which > >> goes to its own item

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On 11 Dec 2017, at 16:44, Holger Weiß wrote: > > * Kevin Smith [2017-12-11 15:34]: >> 84 allows you to publish multiple versions of an avatar, each of which >> goes to its own item within the node, which would require multiple >> items. > > It

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

* Kevin Smith [2017-12-11 15:34]: > 84 allows you to publish multiple versions of an avatar, each of which > goes to its own item within the node, which would require multiple > items. It says the user "publishes avatar data for 'image/png' content-type to data node and

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On 7 Dec 2017, at 08:31, Jonas Wielicki wrote: 84 is listed as N/A for server, but I think it’s possible for a server satisfying its requirements to not meet the requirements of 84 (someone tell me if I’m wrong). >>> >>> What requirements? That definitely

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Mittwoch, 6. Dezember 2017 18:58:32 CET Kevin Smith wrote: > On 6 Dec 2017, at 18:47, Sam Whited wrote: > > On Wed, Dec 6, 2017, at 12:12, Kevin Smith wrote: > >> I think 49 needs to be in there for servers - it’s widely needed to make > >> clients useful. > > > > What is

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On 6 Dec 2017, at 18:47, Sam Whited wrote: > > Thanks for the feedback; I'll address some of it below, however, I think > we should leave any changes for next year since the last call ended > before this feedback was submitted. Ah, but Council term ended so we have a new LC

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

Thanks for the feedback; I'll address some of it below, however, I think we should leave any changes for next year since the last call ended before this feedback was submitted. On Wed, Dec 6, 2017, at 12:12, Kevin Smith wrote: > I think 49 needs to be in there for servers - it’s widely needed to

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On 1 Nov 2017, at 16:47, Jonas Wielicki wrote: > > On Montag, 16. Oktober 2017 18:38:46 CET Jonas Wielicki wrote: >> This message constitutes notice of a Last Call for comments on >> XEP-0387. >> >> Abstract: >> This document defines XMPP protocol compliance levels for

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

I appreciate all of the discussion around the component protocol. I'm still pretty torn on which direction is right, but for now I've decided that this isn't important enough to block progress on. I am going to leave it in and ask the council for a vote (I already did actually, sorry, sent this

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On November 15, 2017 at 03:59:46, Ruslan N. Marchenko (m...@ruff.mobi) wrote: > > > On 14.11.2017 22:37, Sam Whited wrote: > > > > What do the server devs here think? > > > > > To be fair this protocol is implemented in majority(?) of existing xmpp > server implementations so the burden is zero. >

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On 15 November 2017 at 08:59, Ruslan N. Marchenko wrote: > > > On 14.11.2017 22:37, Sam Whited wrote: >> >> >> What do the server devs here think? >> >> > To be fair this protocol is implemented in majority(?) of existing xmpp > server implementations so the burden is zero. > The

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On 14.11.2017 22:37, Sam Whited wrote: What do the server devs here think? To be fair this protocol is implemented in majority(?) of existing xmpp server implementations so the burden is zero. The question is rather - what is the future vision for this component protocol? It considered as

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

Someone just pointed out to me that the compliance suties were still referencing RFC 6122. I have updated them to reference RFC 7622 and the new version will be published soon. —Sam On Wed, Nov 1, 2017, at 10:47, Jonas Wielicki wrote: > On Montag, 16. Oktober 2017 18:38:46 CET Jonas Wielicki

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

> On 14 Nov 2017, at 21:37, Sam Whited wrote: > >> On Tue, Nov 14, 2017, at 12:06, Dave Cridland wrote: >> So arguing over whether it's a Core, Advanced, or neither feature >> seems a bit pointless - except that it means XEP-0387 may reflect >> neither the current reality

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Tue, Nov 14, 2017, at 12:06, Dave Cridland wrote: > So arguing over whether it's a Core, Advanced, or neither feature > seems a bit pointless - except that it means XEP-0387 may reflect > neither the current reality nor any particular desirable future. I think the distinction between

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On 14 November 2017 at 18:48, Diane Trout wrote: > On Tue, 2017-11-14 at 18:06 +, Dave Cridland wrote: >> But it's also a compromise without effect - every existing >> implementation fo S2S I can find, excepting Microsoft Lync, supports >> XEP-0114 "accept" components. >> >>

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Tue, 2017-11-14 at 18:06 +, Dave Cridland wrote: > But it's also a compromise without effect - every existing > implementation fo S2S I can find, excepting Microsoft Lync, supports > XEP-0114 "accept" components. > > So arguing over whether it's a Core, Advanced, or neither feature > seems

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On 14 November 2017 at 17:57, Sam Whited wrote: > On Tue, Nov 14, 2017, at 11:18, Diane Trout wrote: >> XEP-0114 could reasonably be considered an advanced feature, so maybe >> it doesn't need to be a requirement for the "core server". > > That sounds reasonable to me and I'm

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Tue, Nov 14, 2017, at 11:18, Diane Trout wrote: > XEP-0114 could reasonably be considered an advanced feature, so maybe > it doesn't need to be a requirement for the "core server". That sounds reasonable to me and I'm inclined to go make the change. Dave, Arc? —Sam

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

> > I could go either way on this; if anything I'm leaning slightly > towards > removing it. However, so far everyone else seems to be in favor of > keeping it, is there anyone else in support of removing it? > XEP-0114 could reasonably be considered an advanced feature, so maybe it doesn't

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On 13 November 2017 at 23:50, Sam Whited wrote: > On Mon, Nov 13, 2017, at 14:03, Arc Riley wrote: >> The question is whether a server implementation should be considered >> modern >> and complete if it does not implement XEP-0114, and I've made what I >> believe are strong

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Mon, Nov 13, 2017, at 14:03, Arc Riley wrote: > The question is whether a server implementation should be considered > modern > and complete if it does not implement XEP-0114, and I've made what I > believe are strong arguments as to why XEP-0114 should not be considered > mandatory. I could

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Thu, Nov 9, 2017 at 11:13 PM, Kim Alvefur wrote: > > But perhaps this one? > https://xmpp.org/extensions/xep-0355.html > XEP-0355 is not included in the last call 2018 compliance suite. The issue I raised was over XEP-0114. The question is whether a server implementation

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Thu, Nov 09, 2017 at 10:26:37PM -0800, Arc Riley wrote: > However, XEP-0114 does not cover the ability to have an external > process add support for a new XEP. [...], but AFAIK that protocol > has never been documented in a XEP - certainly not this one. But perhaps this one?

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Thu, Nov 9, 2017 at 5:00 PM, Diane Trout wrote: > Also a better justification for the component protocol is that it > allows people to develop reasonably portable new features like xep 363. > https://github.com/siacs/HttpUploadComponent I agree with you that being able to

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

> I'd rather focus on getting a successor, possibly xep0255, out of the > door. And if we see that major components (spectrum2 comes to my > mind) > and servers support the successor, we could consider removing xep0114 > from the compliance suite. But not before that has happened. This seems

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On 09.11.2017 23:54, Arc Riley wrote: On Thu, Nov 9, 2017 at 12:30 PM, Florian Schmaus > wrote: Fact is, if you would implement a new XMPP server without xep114, you would miss a lot of fun. I haven't run an XMPP component since the

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Thu, Nov 9, 2017 at 12:30 PM, Florian Schmaus wrote: > A component protocols allows components to piggyback on the > s2s capabilities of the XMPP server. And s2s is not trivial to implement > (Dialback, SASL EXTERNAL, possibly BIDI, …). Therefore a component > protocol

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On 09.11.2017 20:10, Arc Riley wrote: > Correct me if I'm wrong, but I remember the primary purpose of component > protocol was to multihome gateways and other services (eg, MUC) on a > single XMPP server which bound to the S2S port. Without this, you'd > either need an XMPP reverse proxy (which

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

Correct me if I'm wrong, but I remember the primary purpose of component protocol was to multihome gateways and other services (eg, MUC) on a single XMPP server which bound to the S2S port. Without this, you'd either need an XMPP reverse proxy (which component protocol almost is, almost) or one IP

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On 09.11.2017 02:07, Arc Riley wrote: > Since XEP-0114 is historical and its purpose predates SRV records, I'm > wondering why it was included in the suite for server compliance? Because it is still the de-facto standard how you plug in external components into your XMPP server. :) And what do

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Wed, Nov 8, 2017, at 19:07, Arc Riley wrote: > Since XEP-0114 is historical and its purpose predates SRV records, I'm > wondering why it was included in the suite for server compliance? As far as I can tell it is still widely used for transports, plugins, etc. so it seemed worth including. I'm

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

Since XEP-0114 is historical and its purpose predates SRV records, I'm wondering why it was included in the suite for server compliance? On Tue, Nov 7, 2017 at 11:41 AM, Sam Whited wrote: > > > On Wed, Nov 1, 2017, at 11:50, Dave Cridland wrote: > > On 1 November 2017 at

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Wed, Nov 1, 2017, at 11:50, Dave Cridland wrote: > On 1 November 2017 at 17:14, Sam Whited wrote: > > On Wed, Nov 1, 2017, at 11:47, Jonas Wielicki wrote: > >> On Montag, 16. Oktober 2017 18:38:46 CET Jonas Wielicki wrote: > >> > This message constitutes notice of a Last

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Wed, Nov 1, 2017, at 11:47, Jonas Wielicki wrote: > On Montag, 16. Oktober 2017 18:38:46 CET Jonas Wielicki wrote: > > This message constitutes notice of a Last Call for comments on > > XEP-0387. What would folks think about changing the title of these compliance suites to "2018" and then

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Montag, 16. Oktober 2017 18:38:46 CET Jonas Wielicki wrote: > This message constitutes notice of a Last Call for comments on > XEP-0387. > > Abstract: > This document defines XMPP protocol compliance levels for 2017. > > This Last Call begins today and shall end at the close of business on >

[Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

This message constitutes notice of a Last Call for comments on XEP-0387. Abstract: This document defines XMPP protocol compliance levels for 2017. This Last Call begins today and shall end at the close of business on 2017-10-30. Please consider the following questions during this Last Call and