Page 2 of 2

Re: RDEX - Redirects Extended

Posted: 01 Jan 2014, 22:19
by Pretorian
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...

Re: RDEX - Redirects Extended

Posted: 03 Jan 2014, 17:43
by Crise
This is just a post to make the connection between klondikes proposed AT change to RDEX and the linked extension draft more obvious because all the discussion on it was on the hub. I made an editorial judgement call to remove some of the useless banter from the quote, so for a full undiluted experience please ask around in the hub ;).
[2014-01-03 01:39] <Crise> here is a crazy idea: add a QS param as part of RDEX whatever is in that (in standard query string syntax) should be forwarded to the destination as part of RF
[2014-01-03 01:39] <Pretorian> As I said, I'd prefer if AT would be outside of REGX but I'm fine after our discussion to have it in REGX if we can find a good phrasing.
[2014-01-03 01:39] <Pretorian> That's fine, I guess, too.
[2014-01-03 01:39] <Crise> leave all this tickets and tokens for another extension
[2014-01-03 01:40] <Crise> the it won't just be limited to "AT"
[2014-01-03 01:40] <Pretorian> It would be good to have a better summary of our discussions at the forum, so people wouldn't re-iterate the discussion.
[2014-01-03 01:40] <Crise> however, the potential ramifactions re this and keyp should be considered... since keyp is information tied to the original source hub but this information would be transient
[2014-01-03 01:42] <Crise> and it also means that RF will no longer match the URI client used to connect to the previous hub as well
[2014-01-03 01:43] <Crise> which muddies the definition of RF in BASE
[2014-01-03 01:43] <Pretorian> Agreed
[2014-01-03 01:45] <Crise> I think that the idea of allowing hubs to embed extra information in redirects (without every single instance needing their own extension) has some merits though
[2014-01-03 01:45] <klondike> We can always go back to the origin and pass the QS on the INF
[2014-01-03 01:46] <Crise> klondike: true enough
[2014-01-03 01:47] <Crise> but if making this more generic expands its scope while still allowing "AT" to be fully defined elsewhere and simply using this as its mechanism then I think that is worth considering
[2014-01-03 01:47] <Crise> and this way a client doesn't have to be aware of AT specifically just RDEX
[2014-01-03 01:47] <klondike> For me that's a solution that works
[2014-01-03 01:48] <Pretorian> I'm OK with that.
[2014-01-03 01:48] <klondike> So QS parameter which is passed on INF or QS passed on RF?
[2014-01-03 01:48] <Crise> and we can avoid including the behemoth that is AT is shaping up to be from being part of RDEX
[2014-01-03 01:48] <Crise> I would go with QS as an independant INF field
[2014-01-03 01:49] <Crise> see conserns re RF's definition in BASE
-----------------------------------------------------------------------------------------------
[2014-01-03 02:03] <Crise> actually, we are complicating this unnecessarily,...
[2014-01-03 02:03] <klondike> Maybe
[2014-01-03 02:03] <Crise> if QS is a query string why is it not just appended to the url in RD and/or RX
[2014-01-03 02:04] <Crise> then just have QS in INF contain that for the hub
[2014-01-03 02:04] <klondike> yeah that makes sense
[2014-01-03 02:04] <Crise> since client does not currently otherwise provide that to hub
[2014-01-03 02:04] <klondike> But would that work with old clients?
[2014-01-03 02:04] <Crise> it should
[2014-01-03 02:05] <Crise> to them query string is just noise
[2014-01-03 02:07] <klondike> okay that sounds reasonable enough for me
[2014-01-03 02:07] <klondike> What about you Pretorian?
[2014-01-03 02:10] <Pretorian> Send the same additional string to all hubs? I'm OK with that.
[2014-01-03 02:10] <Crise> not some additional string the QS for that hub
[2014-01-03 02:10] <Crise> (query string)
[2014-01-03 02:10] <Crise> because hub has no access to it presently