[Standards] LAST CALL: XEP-0220 (Server Dialback)

Peter Saint-Andre stpeter at stpeter.im
Wed Aug 21 19:07:56 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/21/13 12:06 PM, Philipp Hancke wrote:
> Am 21.08.2013 19:51, schrieb Peter Saint-Andre:
>> On 8/21/13 11:47 AM, Philipp Hancke wrote:
>>> Am 21.08.2013 18:01, schrieb Peter Saint-Andre: [...]
>>>>> Digging out my print copy i found some notes regarding
>>>>> stream compression and session managment in 2.1.1 (after
>>>>> example 3).
>>>> 
>>>> Really old thread alert. :-)
>>> 
>>> Old enough that my print copy which I recently dug out is
>>> starting to fall apart :-) [...]
>>>> I propose that we make the following change to XEP-0220 in
>>>> Section 2.1.1:
>>>> 
>>>> OLD Naturally, the Initiating Server can also enable or
>>>> negotiate other stream features at this point, such as Stream
>>>> Compression [9] and Stream Management [10].
>>>> 
>>>> NEW Naturally, the Initiating Server can also enable or
>>>> negotiate other stream features at this point.
>>> 
>>> I'd actually expect stream features to be negotiated before any
>>> real stanzas flow, not mid-session and such text might allow
>>> this.
>> 
>> This = mid-session stream feature negotiation?
> 
> Yes. Basically I would expect all stream feature negotiation to
> happen immediately in response to <stream:features/>. Not after
> doing something else (like dialback).

Well, we can't negotiate everything at once. :-) So you might
negotiate Feature1 and then Feature2. And dialback is weird because it
predates the whole stream features framework.

> I do not think that the receiving server would enforce such a rule 
> however. And we have just removed two features that would have
> required a stream restart, which is certainly a bad idea
> mid-session, so no objection from me.

I definitely agree about mid-session feature negotiation and stream
restarts.

> [...]
>>> http://xmpp.org/rfcs/rfc6120.html#streams-negotiation-flowchart
>>>
>>> 
doesn't return from DONE
>> 
>> Erratum reports are always welcome. ;-)
> 
> No, I think that the flowchart makes sense. We might want to keep
> this discussion in mind for 6120bis though.

Agreed! Not that I'm looking forward to that work (although I think
the eventual diff will be relatively small -- certainly a lot smaller
than the changes between 3920 and 6120).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSFRAMAAoJEOoGpJErxa2prEIP/iggyCRYvAp6Vv5sypHfvI2w
gMCzl6SIxulwesNwdp/6/dT2Y3aJ8JRrNX2AuH7LbDt9Zh+HUbKhyPlnRdAdkf6R
b8eN+fnLg9j9GCIHNPJ+7Ty2lpVbzBBaoI09YQ8dl+mli+2LZz+h9Q3XBgOIqkBR
dDNhRcnEGi1v1n09PGmab7xoFImbwlg2+AIXW58k0diOPkotwCmfIgbIlXy834pc
wwRX4hMCgFaDDB5nCktlXF77Yd6UL1RCZTqacHmw97OQQu34Kn7Eo62MxuuucGTB
KVFckTMrWidx1J6XsDjwVlF1z8xX2noIaey+0tWkGSlrXXP1jqhlkuEV4Xt7/40u
EP86qjZMqKL3cU/nXpWMSHaXSnpYBWnyyTcrLTmsDzU9WFiTu2JVdo0UOLWzDjBu
7wGjUDMDydnmBTbwpAucyHD8MtOujBFoVLwmDQwatXxolGLzaea+walV5OWX4udm
LJb2d+ggShcMrUN1a878ePBNj1gV2aQ4BJmS+Ov4aRsbA0iRSltR/FLFJqZqgetj
1/hjh0PhsbxQcE0qA47Exdrh7cucZDYLEyi4jJJOBxtxapBRljhrhzWLjAWUDSrq
EI16BdzPdsfmohA443RfB3+NQ1PELnQCsreWnzbFICRqVRyHM+V/lOQFRcrKvkuL
/3bTaC6lPiKX6RIrdHhg
=RIAI
-----END PGP SIGNATURE-----



More information about the Standards mailing list