Re: [Standards] XEP-0305: XMPP Quickstart

[Florian Schmaus]

On 22.09.2015 17:52, Peter Saint-Andre -  wrote:
> XEP-0305 was originally written to satisfy some requirements among a
> team that had concerns about the number of round trips needed to
> establish an XMPP session. That team no longer exists. As the author, I
> also have serious reservations about the spec, not limited to the issue
> that Thijs Alkemade recently raised: https://github.com/xsf/xeps/issues/69
> 
> Therefore I am seriously considering a request to change the state of
> this document to Retracted.
> 
> Before doing so, I would like to know if anyone on this list has
> implemented this quickstart method, or is seriously considering such an
> implementation.

Although I also suffer from XMPP's multiple round trips at login, I
don't think the Quickstart approach is a good one. It is error prone and
has interesting corner cases, as Thijs's PR shows. And it is also not
easy to implement for clients and servers: I was looking into
implementing this in Smack and Openfire and found that it would require
fundamental modifications. Of course, it could be possible that it is
easier to implement if someone adds Quickstart support right from the
start to its XMPP stack, or that some other existing XMPP stacks make it
easier to add Quickstart support.

The solution I have in mind is *Quickresume*: Based on xep198, servers
simply hand out a secure token which clients can use to quickly resume a
stream by just sending a single TLS-secured Quickresume Nonza to the
server. The TLS handshake is done right away, no starttls involved. Of
course this still means multiple roundtrips for the initial login, but I
don't think this is a problem nowadays. I've some more technical notes
about this here, in case someone is interested. I also wanted to
(Proto)XEP this, but was not able to allocate the time yet.

- Florian




signature.asc
Description: OpenPGP digital signature

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

[Florian Schmaus]

On 26.08.2015 17:59, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on XEP-0352 
> (Client State Indication).
> 
> Abstract: This document defines a way for the client to indicate its 
> active/inactive state.
> 
> URL: http://xmpp.org/extensions/xep-0352.html
> 
> This Last Call begins today and shall end at the close of business on 
> 2015-09-07.
> 
> 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?
Yes.

> 4. Do you have any security concerns related to this specification?
No.

> 5. Is the specification accurate and clearly written?
I'd like to see https://github.com/xsf/xeps/pull/44 merged.

- Florian



signature.asc
Description: OpenPGP digital signature

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

[Kurt Zeilenga]

> On Aug 26, 2015, at 8:59 AM, XMPP Extensions Editor  wrote:
> 
> This message constitutes notice of a Last Call for comments on XEP-0352 
> (Client State Indication).
> 
> Abstract: This document defines a way for the client to indicate its 
> active/inactive state.
> 
> URL: http://xmpp.org/extensions/xep-0352.html
> 
> This Last Call begins today and shall end at the close of business on 
> 2015-09-07.
> 
> 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?

seems useful.

> 2. Does the specification solve the problem stated in the introduction and 
> requirements?

seems so.

> 3. Do you plan to implement this specification in your code? If not, why not?

as part of this last call, I implemented this in M-Link, so yes.

> 4. Do you have any security concerns related to this specification?

not beyond what is stated.

> 5. Is the specification accurate and clearly written?

yes.

> 
> Your feedback is appreciated!

[Standards] UPDATED: XEP-0359 (Unique and Stable Stanza IDs)

[XMPP Extensions Editor]

Version 0.2.1 of XEP-0359 (Unique and Stable Stanza IDs) has been released.

Abstract: This specification describes unique and stable IDs for stanzas.

Changelog: [See revision history] (fs)

Diff: http://xmpp.org/extensions/diff/api/xep/0359/diff/0.2/vs/0.2.1

URL: http://xmpp.org/extensions/xep-0359.html

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

[Peter Saint-Andre -]

On 9/22/15 11:48 AM, Florian Schmaus wrote:

On 26.08.2015 17:59, XMPP Extensions Editor wrote:

This message constitutes notice of a Last Call for comments on XEP-0352 (Client 
State Indication).

Abstract: This document defines a way for the client to indicate its 
active/inactive state.

URL: http://xmpp.org/extensions/xep-0352.html

This Last Call begins today and shall end at the close of business on 
2015-09-07.

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?

Yes.


4. Do you have any security concerns related to this specification?

No.


5. Is the specification accurate and clearly written?

I'd like to see https://github.com/xsf/xeps/pull/44 merged.


I'd love to see some list discussion about that suggestion. :-)

The proposed text is:

###

XMPP requires stanzas to be processed in order as per  10.1. 
Especially "If the server's processing of a particular request could 
have an effect on its processing of subsequent data it might receive 
over that input stream..., it MUST suspend processing of subsequent data 
until it has processed the request.". As a result, all actions triggered 
by a CSI nonza sent to the server must happen before processing further 
requests from the same client to the server.


For example: A client sends a CSI active nonza, followed by an XMPP Ping 
request to the server. The server first changes the CSI state to active 
and flushes all eventually queued stanzsa. After the state has been 
restored to 'active' and all resulting stanzas have been put on the 
wire, the server sends the pong.





type='get'>

  




type='result'/>




###

Thoughts?

Peter

--
Peter Saint-Andre
https://andyet.com/

Re: [Standards] XEP-0305: XMPP Quickstart

[Randy Turner]

Does this mean that the original concern about session establishment were 
unfounded? Or does it mean that a more efficient session establishment could 
not be found?

Randy

> On Sep 22, 2015, at 11:52 AM, Peter Saint-Andre -   
> wrote:
> 
> XEP-0305 was originally written to satisfy some requirements among a team 
> that had concerns about the number of round trips needed to establish an XMPP 
> session. That team no longer exists. As the author, I also have serious 
> reservations about the spec, not limited to the issue that Thijs Alkemade 
> recently raised: https://github.com/xsf/xeps/issues/69
> 
> Therefore I am seriously considering a request to change the state of this 
> document to Retracted.
> 
> Before doing so, I would like to know if anyone on this list has implemented 
> this quickstart method, or is seriously considering such an implementation.
> 
> Thanks!
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://andyet.com/
> 

[Standards] XEP-0305: XMPP Quickstart

[Peter Saint-Andre -]

XEP-0305 was originally written to satisfy some requirements among a 
team that had concerns about the number of round trips needed to 
establish an XMPP session. That team no longer exists. As the author, I 
also have serious reservations about the spec, not limited to the issue 
that Thijs Alkemade recently raised: https://github.com/xsf/xeps/issues/69


Therefore I am seriously considering a request to change the state of 
this document to Retracted.


Before doing so, I would like to know if anyone on this list has 
implemented this quickstart method, or is seriously considering such an 
implementation.


Thanks!

Peter

--
Peter Saint-Andre
https://andyet.com/