[Standards] XEP-0375: View from Openfire

Dave Cridland dave at cridland.net
Tue Jul 12 16:56:15 UTC 2016


On 12 July 2016 at 17:42, Sam Whited <sam at samwhited.com> wrote:

> On Tue, Jul 12, 2016 at 11:35 AM, Dave Cridland <dave at cridland.net> 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).
>
>
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.

Where I thought the use of features made more sense than the simple spec
reference were cases where we wanted to stipulate, for example, "Persistent
PEP", or "PEP, but you're allowed to reconfigure nodes", and so on. (PEP is
a minimum, and I'm not sure that minimum is very advanced anymore). Can a
client rely on having multiple items available for '84 storage? If we're
encouraging Bookmarks support in clients, is that '49 based or PEP?

Merely saying XEP-0163 is more useful than no specification at all, but
there's a lot of permissible variance within the optional parts of these
specs, and if the purpose of the XEP is, in part, to set realistic
expectations and aspirations, we need to nail down some of those MAYs (and,
possibly, review them in the spec).

As an example, we might have "Avatars" and "XEP-0084", and a note that many
existing clients support only XEP-0153; but XEP-0084 is considerably
preferred where PEP nodes are persistent. (And I do think this spec could
benefit from some informative text explaining the choices).


> —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/20160712/076832fb/attachment.html>


More information about the Standards mailing list