Re: [Standards] XEP-0375: View from Openfire

[Sam Whited]

On Tue, Jul 12, 2016 at 11:56 AM, Dave Cridland  wrote:
> Well, the goal is (one assumes) interoperability and functionality, so we
> need both features and specifications, but the features need to be quite
> specific. "MUC", for example, seems right, since a (mythical) client
> supporting MIX won't interoperate with XEP-0045.

Yah, that makes sense. I've gone ahead and merged for now since this
is still experimental and changing, but I'll figure out a better way
to format it or just make MIX a footnote. I still feel compelled to
use this as a chance to promote it, but since we don't have a "MIX
with MUC bridge" spec yet, for interoperabilities sake I suppose it
makes sense to not reference it here.

—Sam

-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0375: View from Openfire

[Sam Whited]

On Tue, Jul 12, 2016 at 11:35 AM, Dave Cridland  wrote:
> I'm suggesting we have to have MUC specifically. If a server can implement
> any specification they like for any of these features, then Skype qualifies.

It's not any spec they want, it's any spec we list.

If it really is MUC only, then maybe we should go back to doing these
XEP based instead of feature based (or a mix of the two? That feels
confusing, but I do think there are some where it makes a lot more
sense to list a feature and not a specific implementation).

—Sam



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0375: View from Openfire

[Dave Cridland]

On 12 July 2016 at 17:31, Sam Whited  wrote:

> On Tue, Jul 12, 2016 at 11:23 AM, Dave Cridland  wrote:
> > Sure, we do. But nobody can implement MIX right now, so it's a waste of
> time
> > trying to put it into a Compliance Suite as anything more than a mention
> > that we're expecting it to be in the next revision, perhaps.
>
> It's already in there, so I don't see it as a waste of time, that's a
> sunk cost :)
>
>
I didn't mean *your* time... :-)


> If someone came out with a server that only supported MIX (and not
> MUC) tomorrow, I would see no reason not to call them compliant since
> they support group chat (which is the "feature" that MIX/MUC are
> listed under), so I see no reason why we shouldn't include it unless
> we're suggesting that you really do *have* to have MUC specifically
> and not just "group chat"?
>
>
I'm suggesting we have to have MUC specifically. If a server can implement
any specification they like for any of these features, then Skype qualifies.


> —Sam
>
>
>
> --
> Sam Whited
> pub 4096R/54083AE104EA7AD3
> https://blog.samwhited.com
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0375: View from Openfire

[Sam Whited]

On Tue, Jul 12, 2016 at 11:23 AM, Dave Cridland  wrote:
> Sure, we do. But nobody can implement MIX right now, so it's a waste of time
> trying to put it into a Compliance Suite as anything more than a mention
> that we're expecting it to be in the next revision, perhaps.

It's already in there, so I don't see it as a waste of time, that's a
sunk cost :)

If someone came out with a server that only supported MIX (and not
MUC) tomorrow, I would see no reason not to call them compliant since
they support group chat (which is the "feature" that MIX/MUC are
listed under), so I see no reason why we shouldn't include it unless
we're suggesting that you really do *have* to have MUC specifically
and not just "group chat"?

—Sam



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0375: View from Openfire

[Dave Cridland]

On 12 July 2016 at 17:10, Sam Whited  wrote:

> On Tue, Jul 12, 2016 at 11:01 AM, Dave Cridland  wrote:
> > Not *all* Final XEPs are going to be in Core in a Compliance Suite,
> simply
> > because we might not have a compliance suite covering, say, IoT yet. And
> > maybe there'll be exceptions to the XEP states (XEP-0054 is Historical,
> yet
> > I'd argue it's Core), but we should be examining mismatches.
>
> I'd argue there are two other types of XEPs: Those that are widely
> used that we should discourage further use of (eg. XEP-0153 is one of
> these and therefore should not be in the compliance suites in my
> mind).
>
>
Sure, though it's Historical/Active so a little different. I'm not actually
sure it's something we should discourage, mind.

If an Active (or Final) XEP is considered to be discouraged, then we should
move it to Deprecated (or wherever Final XEPs go to die). The Compliance
Suite would, hopefully, reflect that, rather than be the canonical source.


> > - MIX doesn't (yet) belong here.
>
> And those that are experimental and don't have many features, but that
> we want to strongly encourage people develop and start working on like
> MIX. These should be in the compliance suites (but only if there are
> other alternatives available, such as 0045 in this example) in my
> opinion.
>

Sure, we do. But nobody can implement MIX right now, so it's a waste of
time trying to put it into a Compliance Suite as anything more than a
mention that we're expecting it to be in the next revision, perhaps.


>
> —Sam
>
>
>
>
> --
> Sam Whited
> pub 4096R/54083AE104EA7AD3
> https://blog.samwhited.com
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0375: View from Openfire

[Sam Whited]

On Tue, Jul 12, 2016 at 11:01 AM, Dave Cridland  wrote:
> Not *all* Final XEPs are going to be in Core in a Compliance Suite, simply
> because we might not have a compliance suite covering, say, IoT yet. And
> maybe there'll be exceptions to the XEP states (XEP-0054 is Historical, yet
> I'd argue it's Core), but we should be examining mismatches.

I'd argue there are two other types of XEPs: Those that are widely
used that we should discourage further use of (eg. XEP-0153 is one of
these and therefore should not be in the compliance suites in my
mind).

> - MIX doesn't (yet) belong here.

And those that are experimental and don't have many features, but that
we want to strongly encourage people develop and start working on like
MIX. These should be in the compliance suites (but only if there are
other alternatives available, such as 0045 in this example) in my
opinion.

—Sam




-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0375: View from Openfire

[Guus der Kinderen]

That makes sense. I'm not against having a core as well as an advanced
definition in principle. Dave's suggestion to take XEP status as a guide to
what goes where sounds like a good rule of thumb, at the very least.
On 12 Jul 2016 17:02, "Dave Cridland"  wrote:



On 12 July 2016 at 15:55, Guus der Kinderen 
wrote:

> Perhaps we shouldn't mention MIX at all in this particular compliance
> suite. The MIX specification isn't definitive by a long shot, and although
> there are some early implementations, it hardly qualifies for something to
> be compliant with nowadays. I'd save it for the next editions of the
> complicance suite specification.
>
> I'd like to see the "core server" specifications to be removed completely.
> As it stands, it's of little use, and I doubt if there are server
> implementations that strive to be "core", but not "advanced".
>
>
I think we have four levels of XEP, from an XSF point of view.

- XEPs that are widely implemented, and client developers could consider
hard fails if the support is not present. I'm not recommending refusing to
connect if, for example, XEP-0313 access to personal archives is not
available, but (within this example) a client might be written to consider
its absence as exceptional, rather than attempting to degrade terribly
gracefully. (Note: MAM here is *just* an example). I'd expect these
specifications to be Final, incidentally, so maybe we don't have many of
these right now (and that's an issue we should address). This is basically
"Core" in my mind.

- XEPs that it is the consensus of the Standards SIG that implementations
should aspire to support at this point in time. These would be
specifications we believe are ready (and I would expect these to be Draft -
and if they're Experimental, we should be working hard to move them on).
This is basically "Advanced" in my mind.

- XEPs that are promising, but not there yet. These are Experimental.

- XEPs that we've dropped. These are Deferred, Deprecated, etc.

Not *all* Final XEPs are going to be in Core in a Compliance Suite, simply
because we might not have a compliance suite covering, say, IoT yet. And
maybe there'll be exceptions to the XEP states (XEP-0054 is Historical, yet
I'd argue it's Core), but we should be examining mismatches.

Given all this rambling:

- I do think there's a place for Core, and it's not aspirational.
- MIX doesn't (yet) belong here.

Dave.

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0375: View from Openfire

[Dave Cridland]

On 12 July 2016 at 15:55, Guus der Kinderen 
wrote:

> Perhaps we shouldn't mention MIX at all in this particular compliance
> suite. The MIX specification isn't definitive by a long shot, and although
> there are some early implementations, it hardly qualifies for something to
> be compliant with nowadays. I'd save it for the next editions of the
> complicance suite specification.
>
> I'd like to see the "core server" specifications to be removed completely.
> As it stands, it's of little use, and I doubt if there are server
> implementations that strive to be "core", but not "advanced".
>
>
I think we have four levels of XEP, from an XSF point of view.

- XEPs that are widely implemented, and client developers could consider
hard fails if the support is not present. I'm not recommending refusing to
connect if, for example, XEP-0313 access to personal archives is not
available, but (within this example) a client might be written to consider
its absence as exceptional, rather than attempting to degrade terribly
gracefully. (Note: MAM here is *just* an example). I'd expect these
specifications to be Final, incidentally, so maybe we don't have many of
these right now (and that's an issue we should address). This is basically
"Core" in my mind.

- XEPs that it is the consensus of the Standards SIG that implementations
should aspire to support at this point in time. These would be
specifications we believe are ready (and I would expect these to be Draft -
and if they're Experimental, we should be working hard to move them on).
This is basically "Advanced" in my mind.

- XEPs that are promising, but not there yet. These are Experimental.

- XEPs that we've dropped. These are Deferred, Deprecated, etc.

Not *all* Final XEPs are going to be in Core in a Compliance Suite, simply
because we might not have a compliance suite covering, say, IoT yet. And
maybe there'll be exceptions to the XEP states (XEP-0054 is Historical, yet
I'd argue it's Core), but we should be examining mismatches.

Given all this rambling:

- I do think there's a place for Core, and it's not aspirational.
- MIX doesn't (yet) belong here.

Dave.
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0375: View from Openfire

[Guus der Kinderen]

Perhaps we shouldn't mention MIX at all in this particular compliance
suite. The MIX specification isn't definitive by a long shot, and although
there are some early implementations, it hardly qualifies for something to
be compliant with nowadays. I'd save it for the next editions of the
complicance suite specification.

I'd like to see the "core server" specifications to be removed completely.
As it stands, it's of little use, and I doubt if there are server
implementations that strive to be "core", but not "advanced".

- Guus

On 12 July 2016 at 15:04, Kevin Smith  wrote:

>
> > On 12 Jul 2016, at 13:49, Ralph Meijer  wrote:
> >
> > On 2016-07-12 05:11, Sam Whited wrote:
> >> I've tried to address some of this feedback here:
> >>
> >> https://github.com/xsf/xeps/pull/206
> >>
> >> I think the only thing I left out was getting rid of the IM compliance
> >> suites (in case any of the IoT crowd chime in).
> >>
> >> I also added MIX as a possible provider of "Group Chat" and merged the
> >> web compliance suites into a single item, making BOSH and Websockets
> >> interchangeable. More suggestions for web-friendly features would be
> >> appreciated from web client authors (maybe they're similar to mobile
> >> concerns?).
> >>
> >> Let me know what you think. It could probably use a bit of description
> >> about what the providers column means now; I envision a comma as being
> >> an OR as in "MUC or MIX".
> >
> > Although I strongly believe in the prospects of what MIX will bring to
> > the table, to me, it doesn't make sense to put in any reference to MIX
> > at this point in time. The point of this suite is to get
> > interoperability between a wide array of client and server
> > implementations so that things Just Work™. MIX is nowhere near mature
> > enough that this is achievable within 2016.
>
> I think that’s right. I think a note about MIX might be well-placed, but
> not as part of the compliance tables.
>
> /K
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0375: View from Openfire

[Kevin Smith]

> On 12 Jul 2016, at 13:49, Ralph Meijer  wrote:
> 
> On 2016-07-12 05:11, Sam Whited wrote:
>> I've tried to address some of this feedback here:
>> 
>> https://github.com/xsf/xeps/pull/206
>> 
>> I think the only thing I left out was getting rid of the IM compliance
>> suites (in case any of the IoT crowd chime in).
>> 
>> I also added MIX as a possible provider of "Group Chat" and merged the
>> web compliance suites into a single item, making BOSH and Websockets
>> interchangeable. More suggestions for web-friendly features would be
>> appreciated from web client authors (maybe they're similar to mobile
>> concerns?).
>> 
>> Let me know what you think. It could probably use a bit of description
>> about what the providers column means now; I envision a comma as being
>> an OR as in "MUC or MIX".
> 
> Although I strongly believe in the prospects of what MIX will bring to
> the table, to me, it doesn't make sense to put in any reference to MIX
> at this point in time. The point of this suite is to get
> interoperability between a wide array of client and server
> implementations so that things Just Work™. MIX is nowhere near mature
> enough that this is achievable within 2016.

I think that’s right. I think a note about MIX might be well-placed, but not as 
part of the compliance tables.

/K

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0375: View from Openfire

[Ralph Meijer]

On 2016-07-12 05:11, Sam Whited wrote:
> I've tried to address some of this feedback here:
> 
> https://github.com/xsf/xeps/pull/206
> 
> I think the only thing I left out was getting rid of the IM compliance
> suites (in case any of the IoT crowd chime in).
> 
> I also added MIX as a possible provider of "Group Chat" and merged the
> web compliance suites into a single item, making BOSH and Websockets
> interchangeable. More suggestions for web-friendly features would be
> appreciated from web client authors (maybe they're similar to mobile
> concerns?).
> 
> Let me know what you think. It could probably use a bit of description
> about what the providers column means now; I envision a comma as being
> an OR as in "MUC or MIX".

Although I strongly believe in the prospects of what MIX will bring to
the table, to me, it doesn't make sense to put in any reference to MIX
at this point in time. The point of this suite is to get
interoperability between a wide array of client and server
implementations so that things Just Work™. MIX is nowhere near mature
enough that this is achievable within 2016.

-- 
ralphm
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0375: View from Openfire

[Sam Whited]

I've tried to address some of this feedback here:

https://github.com/xsf/xeps/pull/206

I think the only thing I left out was getting rid of the IM compliance
suites (in case any of the IoT crowd chime in).

I also added MIX as a possible provider of "Group Chat" and merged the
web compliance suites into a single item, making BOSH and Websockets
interchangeable. More suggestions for web-friendly features would be
appreciated from web client authors (maybe they're similar to mobile
concerns?).

Let me know what you think. It could probably use a bit of description
about what the providers column means now; I envision a comma as being
an OR as in "MUC or MIX".

Best,
Sam
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0375: View from Openfire

[Dave Cridland]

(Just me this time)

On 11 Jul 2016 4:46 p.m., "Sam Whited"  wrote:
>
> On Mon, Jul 11, 2016 at 10:17 AM, Dave Cridland  wrote:
> > 1) There's a number of possible purposes to this document. We believe
it's
> > aimed to progress the state of the art, and act as a
marketing/procurement
> > 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.
In
> > 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
mandating
> > Carbons, for example, but not MUC? All servers can provide MUC, so
surely
> > 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
full
> > support into Openfire, and fully support a frequent update of such XEPs
to
> > 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-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0375: View from Openfire

[Sam Whited]

On Mon, Jul 11, 2016 at 10:17 AM, Dave Cridland  wrote:
> 1) There's a number of possible purposes to this document. We believe it's
> aimed to progress the state of the art, and act as a marketing/procurement
> 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.

> 2) We note that there are a considerable number of options for servers. In
> 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 mandating
> Carbons, for example, but not MUC? All servers can provide MUC, so surely
> that's not contentious to have as Core.

Sounds reasonable, I didn't even consider MUC, oddly enough.

> 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.

> 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 full
> support into Openfire, and fully support a frequent update of such XEPs to
> 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?

Best,
Sam



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0375: View from Openfire

[Dave Cridland]

Folks,

We've been discussing the Compliance suite over the past few hours in
person, and we've some general comments.

1) There's a number of possible purposes to this document. We believe it's
aimed to progress the state of the art, and act as a marketing/procurement
label. Does this seem right?

2) We note that there are a considerable number of options for servers. In
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
mandating Carbons, for example, but not MUC? All servers can provide MUC,
so surely that's not contentious to have as Core.

Is it worth removing Core Server?

Can we merge IM into the Core Suite to reduce the numbers of options?

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 full
support into Openfire, and fully support a frequent update of such XEPs to
provide momentum to the community.

These comments are a group effort from:

Guus der Kinderen, Dele Olajide, Marc Laporte, and Dave Cridland.
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___