18 Mar
2024
18 Mar
'24
2:59 a.m.
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(a)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!
18 Mar
18 Mar
8:15 a.m.
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
11:36 a.m.
On Mon, 18 Mar 2024 at 08:59, Daniel Gultsch <daniel(a)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(a)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
19 Mar
19 Mar
7:41 a.m.
On Mon, Mar 18, 2024 at 9:59 AM Daniel Gultsch <daniel(a)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
22 Mar
22 Mar
2:46 a.m.
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(a)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
58
days inactive
62
days old
4 comments
4 participants
participants (4)
-
Daniel Gultsch -
Florian Schmaus -
Matthew Wild -
Stephen Paul Weber