Hello, I've collected some feedback off-list, removed the 'returntoken' element and have a git repo tracking the changes now:
https://op-co.de/tmp/xep-pars.html https://op-co.de/tmp/xep-pars.xml https://github.com/ge0rg/proto-xeps/commits/master One feedback I received was a strong objection to this XEP because in an ideal world it would better be implemented on the server-side. While I agree with the principal idea to make this a server (or rather account) feature, my stance is as follows: 1. The proposed wire protocol (xmpp: URI extension and <presence> extension) can be used in the same way irregardless of whether the feature is terminated in a client or on the user's server. 2. In the real world (as opposed to our imagination as the XSF) it takes years for all servers to roll out a new XEP, and this feature can be rolled out as a client-only implementation overnight, with little additional complexity and an immediate benefit to new XMPP users. 3. Even when implemented at the server side, this needs client support. Romeo's client needs to query its server to obtain the token / invitation link, before it can send it OOB. (Or alternatively, to inform the server about a client-generated token, which is probably not really better). My opinion is that making this a server feature actually has some benefits, i.e. Romeo's server can create both the xmpp: URI and an opaque HTTPS URI hosted on itself, only containing an invitation token. As we can assume that the web server can access the XMPP server's internal data structures (or communicate in some other way), Romeo's server can translate the example URI https://montague.net/i/deadbead into the N-tuple ([email protected], 'deadbeef', 'Romeo Montague', 2016-06-26), thus presenting a landing page with the full information, while preventing easy manipulation of the URI parameters. I would propose putting the interaction between Romeo's client and his server into an additional XEP. This would include a mechanism for the client to query for new invitation links (possibly also to remove earlier ones), and a notion where the server is responsible for auto-approving subscription requests that contain a valid token (as seen from the server perspective). Kind regards, Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: Digital signature
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
