Re: RDEX - Redirects Extended
Posted: 01 Jan 2014, 22:19
I won't address the whole "oh my god, we might lose users". We can't forever prevent stupid hubowners from being stupid...
1) Protocol/port vs full URI: The latter is always better because it is actually complete. It does not rely on in-text replacements and juggling around with RX addresses. If you want to add protection in the client, it is possible to do so with checking whether the address is correct or not for instance. Also, I generally would pull up a "This site wants to change stored information, are you sure you want to allow that?" or some scheme.
2) A FCC is used to a) signal intent with functionality and b) filter out content to users based on that FCC. b) allows e.g. F-type messages which are highly useful (especially for the hub). In this case, the hub can, yes, filter clients in two categories whether they support or does not support RDEX. I don't have an opinion here; if you want a FCC, then it's not really a problem.
3) Lack of RP from the hub for clients means... Just exactly what is does for now. It is not really the clients that should do the protection here... It'll otherwise mean that it'd be impossible to move clients from e.g. a non-secure environment to a secure one...
4) RP0 from hub, well, given that there is no redirect command (from a client), I don't really see that as an issue... Just don't allow +redirect or whatever?
5) Sorry, I don't understand the point of the token. What extra data are you giving that is useful? All of the use cases can be achieved without it, no?
6) The LR flag means that clients cannot choose the sequence themselves, which is, I think, one of the better points with RX. E.g., the client may prefer a secure environment over a less secure one; the hub owner might not realize that their order is highly important. Such petty details is easier to let the clients decide. Instead, I think a suggestion in the spec that would make sense would be to have something akin to "Implementations may choose the order, but a left-to-right order is preferred."
7) Hex vs base 10? ... ADC uses integers for everything else, and so this extension should also do so... If clients want to convert to hex in their implementation to simplify internal parsing or whatever, then that's up to them...
1) Protocol/port vs full URI: The latter is always better because it is actually complete. It does not rely on in-text replacements and juggling around with RX addresses. If you want to add protection in the client, it is possible to do so with checking whether the address is correct or not for instance. Also, I generally would pull up a "This site wants to change stored information, are you sure you want to allow that?" or some scheme.
2) A FCC is used to a) signal intent with functionality and b) filter out content to users based on that FCC. b) allows e.g. F-type messages which are highly useful (especially for the hub). In this case, the hub can, yes, filter clients in two categories whether they support or does not support RDEX. I don't have an opinion here; if you want a FCC, then it's not really a problem.
3) Lack of RP from the hub for clients means... Just exactly what is does for now. It is not really the clients that should do the protection here... It'll otherwise mean that it'd be impossible to move clients from e.g. a non-secure environment to a secure one...
4) RP0 from hub, well, given that there is no redirect command (from a client), I don't really see that as an issue... Just don't allow +redirect or whatever?
5) Sorry, I don't understand the point of the token. What extra data are you giving that is useful? All of the use cases can be achieved without it, no?
6) The LR flag means that clients cannot choose the sequence themselves, which is, I think, one of the better points with RX. E.g., the client may prefer a secure environment over a less secure one; the hub owner might not realize that their order is highly important. Such petty details is easier to let the clients decide. Instead, I think a suggestion in the spec that would make sense would be to have something akin to "Implementations may choose the order, but a left-to-right order is preferred."
7) Hex vs base 10? ... ADC uses integers for everything else, and so this extension should also do so... If clients want to convert to hex in their implementation to simplify internal parsing or whatever, then that's up to them...