As mentioned, this has been suggested before, but the flexibility of being able to mix-and-match XEPs means there's no simple way to do it.
At the simplest end, we try to decide on a strict subset of XEPs to be defined as "XMPP-1.0"; this will ultimately fail as nobody can agree what should and shouldn't be included (Compliance Suites revisited.) At the other end, we already have Capabilities Hashes which define the exact features a client supports; but these are neither human parsable nor comparable. So any solution would need to be somewhere in between, preferably closer to the simpler end.. One idea would be to define feature subsets, much as the compliance suties already do, and assign each one a letter; then the version can be referenced as a combination of these, e.g. XMPP-1.0-AJM. So, WRT the Compliance Suites: XMPP-1.0-A = Core Compliance: Core Client XMPP-1.0-B = Core Compliance: Advanced Client XMPP-1.0-I = IM Compliance: Core Client XMPP-1.0-J = IM Compliance: Advanced Client XMPP-1.0-M = Mobile Compliance: Core Client XMPP-1.0-N = Mobile Compliance: Advanced Client XMPP-1.0-W = Web Compliance (Core and Advanced) A very basic client would support "XMPP-1.0-A", while an advanced client that supports everything would be "XMPP-1.0-BJNW" (no need to specify A, I or M, as these are covered by B, J and N.) Additional feature subsets could easily be defined, e.g. F for Jingle File Transfer (and dependencies). Though this may be approaching cryptic, I think it's a good compromise, and any version identifier will necessarily hide a lot of detail - it's specific enough without being a hash value, and allows clients to be compared directly (this one supports M, that one doesn't). But it could quickly become unwieldy, and thereby less useful, so it must come with some restrictions: - letters represent feature subsets, not XEPs (one letter per XEP would be bad, though a particular feature subset may happen to be fully specified by a single XEP); - identifiers are restricted to a single uppercase letter (A-Z; this purposely limits their length and variability - discouraging numerous subsets, and keeping version identifiers succinct); - a version identifier lists supported feature subsets in a defined order (not necessarily alphabetical), to avoid AJNF seeming different from AFNJ. One problem will come from feature subsets changing over time, but this could be restricted until a version bump is deemed necessary, i.e. XMPP-1.1 redefines some subsets, XMPP-2.0 would be a full redefinition of A, B, and others. Thoughts?
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
