On 5/17/11 12:04 PM, Dave Cridland wrote: > On Tue May 17 18:55:22 2011, Peter Saint-Andre wrote: >> On 5/17/11 11:51 AM, Dave Cridland wrote: >> >> > Versioning is *nearly* always the wrong thing to do. >> >> http://mail.jabber.org/pipermail/standards/2008-September/019763.html > > In the message you quote, I continued: > > """ > Our namespace versioning is not versioning of the protocol in this > sense, because that would imply that "urn:xmpp:features:dialback:0" is a > subset of "urn:xmpp:features:dialback:1", whereas no such assertion > exists - the two are entirely unrelated from a protocol standpoint, and > any similarity is merely in the familial sense - they're likely to have > both been specified in the same document at different times. > > But - crucially - no compatibility is asserted; indeed the precisely > opposite assertion is made: the two protocols are mutually incompatible. > """ > > This matches what I originally proposed in the message of mine you have > cited above: > > """ > urn:xmpp:protoname:1 > > That last portion we'll treat as a version number. Any time we cause > incompatibility between versions of the XEP, we update it. (Note, > that's not "every new XEP"). > """ > > Note use of the word "incompatibility". The use of the term "version" > is, I agree, confusing, but my point here is that by changing the > namespace version number, we're actually both signalling, and causing, > an incompatible variant of the protocol.
Not necessarily incompatible in all ways, but perhaps in some.
> I don't think the variants of dialback in discussion here are
> incompatible within the subset currently defined.
Point taken.
So let's talk about solutions.
1. Child elements as in 0.9:
<stream:features>
<dialback xmlns='urn:xmpp:features:dialback'>
<errors/>
</dialback>
</stream:features>
2. Versioning:
<stream:features>
<dialback xmlns='urn:xmpp:features:dialback:1'>
<errors/>
</dialback>
</stream:features>
3. More features:
<stream:features>
<dialback-errors xmlns='urn:xmpp:features:dialback:errors'/>
</stream:features>
Given that dialback errors are indeed a feature unto themselves (albeit
compatible with RFC3920-dialback), #3 might be the best approach.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
