[Standards] Proto-XEP: Pre-Authenticated Roster Subscription

Georg Lukas georg at op-co.de
Sun Jun 12 12:16:45 UTC 2016


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 (romeo at montague.net, '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 ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160612/af70330b/attachment.sig>


More information about the Standards mailing list