LAST CALL: XEP-0386 (Bind 2)
This message constitutes notice of a Last Call for comments on XEP-0386. Title: Bind 2 Abstract: This specification provides a single-request replacement for several activities an XMPP client needs to do at startup. URL: https://xmpp.org/extensions/xep-0386.html This Last Call begins today and shall end at the close of business on 2024-04-01. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
"Needed" is a strong word, but it is useful to have everything enabled at once.
2. Does the specification solve the problem stated in the introduction and requirements?
Yes
3. Do you plan to implement this specification in your code? If not, why not?
I have imlemented this for xmpp.js already
4. Do you have any security concerns related to this specification?
No
5. Is the specification accurate and clearly written?
Yes
On Mon, 18 Mar 2024 at 08:59, Daniel Gultsch <daniel@gultsch.de> wrote:
This message constitutes notice of a Last Call for comments on XEP-0386.
Title: Bind 2 Abstract: This specification provides a single-request replacement for several activities an XMPP client needs to do at startup.
URL: https://xmpp.org/extensions/xep-0386.html
This Last Call begins today and shall end at the close of business on 2024-04-01.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Yes. As well as making session initialization generally easier and more performant (by reducing round-trips and the associated logic), it is a big part of closing the unfriendly race condition we have between carbons and MAM ( https://docs.modernxmpp.org/client/protocol/#race-during-login ).
2. Does the specification solve the problem stated in the introduction and requirements?
Yes.
3. Do you plan to implement this specification in your code? If not, why not?
Yes, I have implemented it in Prosody.
4. Do you have any security concerns related to this specification?
No.
5. Is the specification accurate and clearly written?
I hope so :) Regards, Matthew
On Mon, Mar 18, 2024 at 9:59 AM Daniel Gultsch <daniel@gultsch.de> wrote:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Yes
2. Does the specification solve the problem stated in the introduction and requirements?
Yes
3. Do you plan to implement this specification in your code? If not, why not?
Yes I have implemented this in Conversations.
4. Do you have any security concerns related to this specification?
No
5. Is the specification accurate and clearly written?
Yes
On 18/03/2024 09.59, Daniel Gultsch wrote:
This message constitutes notice of a Last Call for comments on XEP-0386.
Title: Bind 2 Abstract: This specification provides a single-request replacement for several activities an XMPP client needs to do at startup.
URL: https://xmpp.org/extensions/xep-0386.html
This Last Call begins today and shall end at the close of business on 2024-04-01.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Yes.
2. Does the specification solve the problem stated in the introduction and requirements?
Yes.
3. Do you plan to implement this specification in your code? If not, why not?
No immediate plans, due the lack of resources on my end. However, it is consensus that SASL2 and Bind2 are the frontier of current XMPP stream/session establishment and hence are, or at least will become, highly relevant. And the fundamental design of both is solid and incorporates our experience with the current design.
4. Do you have any security concerns related to this specification?
No major concerns. However, I wonder if stable resource identifiers are a sensible concept security wise. It seems sensible to be able to restrict direct access to an end-device via unstable resource identifiers.
5. Is the specification accurate and clearly written?
Just some small remarks: - § 6. Superfluous '.' at the end of the sentence. - Mentions of XEPs within the document should be linked references. Thanks for working on Bind2. - Florian
participants (4)
-
Daniel Gultsch -
Florian Schmaus -
Matthew Wild -
Stephen Paul Weber