<p dir="ltr">(Just me this time)</p>
<p dir="ltr">On 11 Jul 2016 4:46 p.m., "Sam Whited" <<a href="mailto:sam@samwhited.com">sam@samwhited.com</a>> wrote:<br>
><br>
> On Mon, Jul 11, 2016 at 10:17 AM, Dave Cridland <<a href="mailto:dave@cridland.net">dave@cridland.net</a>> wrote:<br>
> > 1) There's a number of possible purposes to this document. We believe it's<br>
> > aimed to progress the state of the art, and act as a marketing/procurement<br>
> > label. Does this seem right?<br>
><br>
> That was more or less my intention, and I think also the intention of<br>
> others when we've had discussions about renewing them in the past.<br>
></p>
<p dir="ltr">Yes, I think it's right - but it might be useful to include the aims of the document somewhere within it.</p>
<p dir="ltr">> > 2) We note that there are a considerable number of options for servers. In<br>
> > most of the modules, it's not clear any server would aspire to Core. Some of<br>
> > the choices within Core versus Advanced are peculiar - why are we mandating<br>
> > Carbons, for example, but not MUC? All servers can provide MUC, so surely<br>
> > that's not contentious to have as Core.<br>
><br>
> Sounds reasonable, I didn't even consider MUC, oddly enough.<br>
></p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">So maybe "Core" ought to be the current common platform amongst mainstream servers, and "Advanced" the aspirational goal.</p>
<p dir="ltr">> > Can we merge IM into the Core Suite to reduce the numbers of options?<br>
><br>
> This seems fine to me too; the reason I separated them is that I was<br>
> hoping someone would add an "IoT" suite (or a suite for some use case<br>
> I haven't thought of), and I figured things like carbons and the<br>
> blocking command may not always be required there, however, it doesn't<br>
> look like there's been a lot of interest in that, and I'm all for<br>
> simplifying.<br>
></p>
<p dir="ltr">That's a reasonable point. I wonder if Peter Waher or Rikard Strid might have any input here?</p>
<p dir="ltr">> > 3) While binary support of XEPs is useful as a high level overview, many<br>
> > XEPs are more subtle than a mere yes or no. Does XEP-0198 support mean<br>
> > resumption? Should PEP be persistent?<br>
> ><br>
> > We are, however keen that there are Compliance XEPs, keen to include full<br>
> > support into Openfire, and fully support a frequent update of such XEPs to<br>
> > provide momentum to the community.<br>
> ><br>
> > These comments are a group effort from:<br>
> ><br>
> > Guus der Kinderen, Dele Olajide, Marc Laporte, and Dave Cridland.<br>
><br>
> Many thanks! I agree about the binary nature of the current suites not<br>
> exactly matching the real world. Daniel Gultch suggested swapping out<br>
> XEPs for "features" and just listing XEPs that can provide those<br>
> features (eg. instead of listing 0198 listing "session resumption").<br>
> What do you all think of this? Are there other places this might be<br>
> helpful?<br>
></p>
<p dir="ltr">I think that's an excellent idea, throughout the document.</p>
<p dir="ltr">> Best,<br>
> Sam<br>
><br>
><br>
><br>
> --<br>
> Sam Whited<br>
> pub 4096R/54083AE104EA7AD3<br>
> <a href="https://blog.samwhited.com">https://blog.samwhited.com</a><br>
> _______________________________________________<br>
> Standards mailing list<br>
> Info: <a href="http://mail.jabber.org/mailman/listinfo/standards">http://mail.jabber.org/mailman/listinfo/standards</a><br>
> Unsubscribe: <a href="mailto:Standards-unsubscribe@xmpp.org">Standards-unsubscribe@xmpp.org</a><br>
> _______________________________________________<br>
</p>