[Standards] XEP-0375: View from Openfire

Dave Cridland dave at cridland.net
Mon Jul 11 16:06:14 UTC 2016

(Just me this time)

On 11 Jul 2016 4:46 p.m., "Sam Whited" <sam at samwhited.com> wrote:
> On Mon, Jul 11, 2016 at 10:17 AM, Dave Cridland <dave at cridland.net> wrote:
> > 1) There's a number of possible purposes to this document. We believe
> > aimed to progress the state of the art, and act as a
> > label. Does this seem right?
> That was more or less my intention, and I think also the intention of
> others when we've had discussions about renewing them in the past.

Yes, I think it's right - but it might be useful to include the aims of the
document somewhere within it.

> > 2) We note that there are a considerable number of options for servers.
> > most of the modules, it's not clear any server would aspire to Core.
Some of
> > the choices within Core versus Advanced are peculiar - why are we
> > Carbons, for example, but not MUC? All servers can provide MUC, so
> > that's not contentious to have as Core.
> Sounds reasonable, I didn't even consider MUC, oddly enough.

Yeah - something that did crop up, but I may be misinterpreting is that
nobody appeared to think much of the Core Server level. I think it might be
more useful just to have Advanced Server only. It's pretty insane to
suggest that any of the mainstream servers fail to meet Core requirements
(yet they do by this document) - they're all perfectly usable to a basic
degree, after all.

But a valid criticism of XMPP is that there's a lot of optional behaviour,
and a document that declares some of these as a basic expectation of any
server (you can, for example, rely on MUC being present, and PEP too) has a
lot of utility.

So maybe "Core" ought to be the current common platform amongst mainstream
servers, and "Advanced" the aspirational goal.

> > Can we merge IM into the Core Suite to reduce the numbers of options?
> This seems fine to me too; the reason I separated them is that I was
> hoping someone would add an "IoT" suite (or a suite for some use case
> I haven't thought of), and I figured things like carbons and the
> blocking command may not always be required there, however, it doesn't
> look like there's been a lot of interest in that, and I'm all for
> simplifying.

That's a reasonable point. I wonder if Peter Waher or Rikard Strid might
have any input here?

> > 3) While binary support of XEPs is useful as a high level overview, many
> > XEPs are more subtle than a mere yes or no. Does XEP-0198 support mean
> > resumption? Should PEP be persistent?
> >
> > We are, however keen that there are Compliance XEPs, keen to include
> > support into Openfire, and fully support a frequent update of such XEPs
> > provide momentum to the community.
> >
> > These comments are a group effort from:
> >
> > Guus der Kinderen, Dele Olajide, Marc Laporte, and Dave Cridland.
> Many thanks! I agree about the binary nature of the current suites not
> exactly matching the real world. Daniel Gultch suggested swapping out
> XEPs for "features" and just listing XEPs that can provide those
> features (eg. instead of listing 0198 listing "session resumption").
> What do you all think of this? Are there other places this might be
> helpful?

I think that's an excellent idea, throughout the document.

> Best,
> Sam
> --
> Sam Whited
> pub 4096R/54083AE104EA7AD3
> https://blog.samwhited.com
> _______________________________________________
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160711/1c899051/attachment.html>

More information about the Standards mailing list