On 5/17/11 10:30 AM, Dave Cridland wrote: > On Tue May 17 02:14:06 2011, XMPP Extensions Editor wrote: >> Changelog: Modified stream features to incorporate versioning, thus >> removing the need for an <errors/> child element; clarified a few >> points in the text. (psa) > > Interoperable implementations of dialback using <errors/> child element > to indicate this capability exist; is there any reason to change the > namespace at this point aside from aesthetics?
The concern that Jack Erwin raised with me is that putting child
elements in stream features will lead people to expect more of the same,
such as:
<stream:features>
<dialback xmlns='urn:xmpp:features:dialback'>
<errors/>
<dna/>
<advanced-piggybacking/>
<some-future-feature/>
</dialback>
</stream:features>
That seems like a bad path to go down. Much better, I think, to use a
mechanism we already have: protocol versioning, such as the following
for old-style RFC3920 dialback (mythically version zero of the feature
but we use stream headers instead), dialback-with-errors, some future
dialback-with-dna, etc.:
<stream:features>
<dialback xmlns='urn:xmpp:features:dialback:0'/>
</stream:features>
<stream:features>
<dialback xmlns='urn:xmpp:features:dialback:1'/>
</stream:features>
<stream:features>
<dialback xmlns='urn:xmpp:features:dialback:2'/>
</stream:features>
> To be specific, I see no behavioural changes introduced that nessecitate
> a change in namespace, and the only change in the wire protocol is the
> changed stream feature.
From RFC 3920 to XEP-0220 we've introduced dialback errors. That seems
worthy of revving the stream feature.
However, if you meant that version 0.10 of XEP-0220 did not introduce
any changes to the wire protocol for server dialback in comparision to
version 0.9, then you are correct.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
