[Standards] UPDATED: XEP-0220 (Server Dialback)
stpeter at stpeter.im
Tue May 17 20:00:06 UTC 2011
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.
> 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:
> 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.
So let's talk about solutions.
1. Child elements as in 0.9:
3. More features:
Given that dialback errors are indeed a feature unto themselves (albeit
compatible with RFC3920-dialback), #3 might be the best approach.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards