On 12 July 2016 at 17:42, Sam Whited <s...@samwhited.com> wrote: > On Tue, Jul 12, 2016 at 11:35 AM, Dave Cridland <d...@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-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
