QS - Query String for Hubs in INF

[Crise]

The discussion surrounding RDEX and the proposed addition of "AT" parameter (by klondike) to it resulted in the following proposition being formed to replace it and most future additions like it.

Code: Select all

=== QS - Query String for Hubs in INF
This extension adds a new INF field QS sent to hubs containing the query string portion of the URI, and optionally any fragment, used to connect to it. This is done to address the fact that existing RF field in INF contains query string of the previous hub URI, if any, but hubs have no access to their own query string and thus no ability to deduce the fully qualified URI used to connect to them.

With this extension the query string portion of the URI may be used, within reason, to relay small amounts of information from a hub to the hub (for example during a redirect) if necessary. It should be noted that since the query string a user used to connect to a hub can be considered unhelpful to other clients on the hub it is at each hubs own discretion whether to filter this field out of outgoing INF broadcasts to other users.

If used in a hub to hub communication, the QS field should not be considered a fully qualified communication channel between two hubs but merely an additional tool to facilitate such co-operation.
[options="autowidth"]
|=====
|QS |The query string portion of the URI client used to connect to the hub, including an optional fragment.
|=====

The text presented above is proposed as a starting point and not necessarily anything final. Comments are appreciated.

[Crise]

Code: Select all

=== QS - Query String for Hubs in INF
This extension adds a new INF field QS sent to hubs containing the query string portion of the URI, and optionally any fragment, used to connect to it. This is done to address the fact that existing RF field in INF contains query string of the previous hub URI, if any, but hubs have no access to their own query string and thus no ability to deduce the fully qualified URI used to connect to them.

With this extension the query string portion of the URI may be used, within reason, to relay small amounts of information from a hub to the hub (for example during a redirect) if necessary. However, since the query string a client used to connect to a hub can be considered unhelpful to other clients on the hub it is at each hubs own discretion whether to filter this field out of outgoing INF broadcasts to its users or not.

If used in a hub to hub communication, the QS field should not be considered a fully qualified communication channel between two hubs but merely an additional tool to facilitate such co-operation. It is at clients own discretion whether a query string received from another hub should be considered discardable after it has been used at least once, unless another supported extension requires otherwise. Query strings from direct user input should not be automatically discarded by the users client.
[options="autowidth"]
|=====
|QS |The query string portion of the URI client used to connect to the hub, including an optional fragment.
|=====

Above makes slight edits to the original text based on discussion from the hub. Notable addition concerning query strings received from other hubs and query strings resulting from user input has been added.

[klondike]

[quote="Crise"]

Code: Select all

=== QS - Query String for Hubs in INF
This extension adds a new INF field QS sent to hubs containing the query string portion of the URI, and optionally any fragment, used to connect to it. This is done to address the fact that existing RF field in INF contains query string of the previous hub URI, if any, but hubs have no access to their own query string and thus no ability to deduce the fully qualified URI used to connect to them.

With this extension the query string portion of the URI may be used, within reason, to relay small amounts of information from the URL provider to the destination hub (for example during a redirect) if necessary. However, since the query string a client used to connect to a hub can be considered unhelpful to other clients on the hub it is at each hubs own discretion whether to filter this field out of outgoing INF broadcasts to its users or not.

If used in a hub to hub communication, the QS field should not be considered a fully qualified communication channel between two hubs but merely an additional tool to facilitate such co-operation. Query strings from direct user input should not be automatically discarded by the users client. But, hub provided strings provided by the hub have a maximum expected lifetime on client side depending on the first character of the variable.

The maximum lifetime of hub provided variables is defined by the first character of the parameter. As of now, the following lifetimes are defined:
* . (dot) This is used for parameters that MUST be discarded after being properly sent to the hub once. These parameters shouldn't be placed on permanent storage.
* _ (underscore) This is used for parameters that MUST be discarded before program termination. The main expectancy from the hub is that these parameters will never be written to permanent storage but may be sent more than one time.
* [a-zA-Z0-9] (alphanumerical characters) This is used for parameters that can be kept as long as desired. 
Any starting character not defined is reserved for future use and shouldn't be used.

Parameters MUST be ordered from left to right in the URL so longest duration will come first, this means that parameters starting by alphanumerical characters will be the leftmost followed by those starting by underscore and then those starting by a dot. This is to simplify lifetime handling of parameters.

Finally, the client is expected to send the parameters at least once as long as they haven't passed their lifetime and, at his own discretion more times as long as the maximum lifetime of the parameter is respected.
[options="autowidth"]
|=====
|QS |The query string portion of the URI client used to connect to the hub, including an optional fragment.
|=====

Lifetime examples:
.example=aaa This parameter should be discarded as soon as it is sent once or when it needs to be placed to permanent storage.
_example=aaa This paramenter can be discarded after being sent once but must be discarded if it needs to be placed to permanent storage.
example=aaa This parameter can be discarded after being sent once but can be kept forever.

The main change was setting hub provided maximum lifetimes for parameters, also some wording to make it clearer.

[poy]

- I am having trouble understanding the purpose of lifetime prefixes. Are there example use cases that may help me out? Aren't QS parameters only going to be sent once anyway?

- How does one escape the first character of a parameter if it clashes with a lifetime prefix (dot or underscore)?

- I dislike the requirement that parameters have to be specifically ordered. This could mean some shuffling to be done on the client side before sending the string. Besides, I would prefer if one could trust that the advertized query string was really the one actually used to connect to the hub.

- Because this is an INF parameter, hubs unaware of this extension are going to dispatch the query string to other connected clients. Possible solutions, ordered by preference:
1) Use a different ADC command, eg QUE.
2) Specify that the QS parameter must be sent in an H-type INF.
3) Make this a named ADC extension and only send QS parameters when the hub supports the extension.

[Crise]

- I am having trouble understanding the purpose of lifetime prefixes. Are there example use cases that may help me out? Aren't QS parameters only going to be sent once anyway?

See the RDEX discussion on "AT", one time use tokens that make no sense to be stored in f.ex. favorite hub urls. So it is a more specific guideline to client (similar to the more generic variant, that relies on extensions making use of QS to specify lifetime, that I amended in the second post).

Personally I am not really for or against explicit life time management in this regard. However, I think specified by use case is a simpler thing to do (not like explicit management of it is going to help non supporting clients in any way f.ex.). The fact temporary parameters specifically ordered is just to mitigate issues with clients only aware of KEYP f.ex. and who parse the query string liberally, which I think is important to consider (ie. the whole ordering thing exists so that the position of keyp remains roughly equivalent and to generally simplify parsing). The benefit with explicit management is obviously that it keeps stored URI's cleaner even for clients that are not aware of every instance where query string is used (but are aware of this extension).

Regarding escaping, that seems like a non issue to me, since the name of a parameter is completely free form with no notable limitations otherwise (ie. want to name a permanent parameter ".something" tough luck). The life time prefixes are compatible with only known documented use of query string that predates this anyways, so imo. if prefixes are the way to go then I see no reason to make it more complicated than it needs to be, let the ones that come after this just deal with the fact that it exists,

- Because this is an INF parameter, hubs unaware of this extension are going to dispatch the query string to other connected clients. Possible solutions, ordered by preference:
1) Use a different ADC command, eg QUE.
2) Specify that the QS parameter must be sent in an H-type INF.
3) Make this a named ADC extension and only send QS parameters when the hub supports the extension.

Don't like 1 a whole lot for just one string, which one would think usually is an opaque string to clients anyways. 2 seems like a very reasonable suggestion. Although, in this instance reality is that most hubs actually do not broadcast unknown fields adchpp being one of two specification following hub software that I am aware of (Not saying that it is an argument one way or another, just a fun fact).

This was supposed to be a really simple extension, to make "AT" possible without including it in RDEX specifically and thus limiting the mechanism to just that one use case. Looks like it is turning into anything but that. This is really not much of an extension in itself anyways, more of an utility one so that it doesn't need to be completely redefined for each possible use case (thus limiting clients awareness of it).

[poy]

I thought the only purpose of this proposal was to let hubs know of the query string clients have used to connect.

It seems it instead encompasses any message that sends URLs? My intuition tells me this is getting out of hand...

I have read the RDEX discussion related to AT and I don't see what it has to do with a query string at all. The information carried by AT is known by the hub beforehand so it can be sent as it wishes, without putting it in the params of an URL. That's like embedding JSON in XML.

This was supposed to be a really simple extension, to make "AT" possible without including it in RDEX specifically and thus limiting the mechanism to just that one use case. Looks like it is turning into anything but that. This is really not much of an extension in itself anyways, more of an utility one so that it doesn't need to be completely redefined for each possible use case (thus limiting clients awareness of it).

This is how we always procede and I hope it stays that way. Always strive for perfection!

[klondike]

I thought the only purpose of this proposal was to let hubs know of the query string clients have used to connect.

It is.

It seems it instead encompasses any message that sends URLs? My intuition tells me this is getting out of hand...

More like any message sending URLs you expect the hub to be aware of. Mainly to prevent parameters to be kept on clientside forever and ever.

You asked for some examples so:
* Single use parameters: for client authentication (for example to another not trusted hub of the network when a hub is saturated allowing maybe override of limitation policies temporarily).
* Session parameters: for temporary session keeping (something similar to session cookies on HTTP), specially when a PID can't be used due to misconfiguration of clients.
* Permanent parameters: well, this is self explanatory, be able to provide keyp when redirecting for example.

[poy]

You asked for some examples so:
* Single use parameters: for client authentication (for example to another not trusted hub of the network when a hub is saturated allowing maybe override of limitation policies temporarily).
* Session parameters: for temporary session keeping (something similar to session cookies on HTTP), specially when a PID can't be used due to misconfiguration of clients.
* Permanent parameters: well, this is self explanatory, be able to provide keyp when redirecting for example.

These are decent use cases; but in all of these examples, my remark still applies:

I have read the RDEX discussion related to AT and I don't see what it has to do with a query string at all. The information carried by AT is known by the hub beforehand so it can be sent as it wishes, without putting it in the params of an URL. That's like embedding JSON in XML.

Why not send these pieces of information with regular ADC mechanisms (new param in the QUI message)?

[Crise]

These are decent use cases; but in all of these examples, my remark still applies:

I have read the RDEX discussion related to AT and I don't see what it has to do with a query string at all. The information carried by AT is known by the hub beforehand so it can be sent as it wishes, without putting it in the params of an URL. That's like embedding JSON in XML.

Why not send these pieces of information with regular ADC mechanisms (new param in the QUI message)?

Short version, why reinvent the wheel for everything when you can only do it once. Meaning that "AT" started off as QUI parameter and then sent as part of RF to hub (or as an independent INF field). Both of these approaches has their problems. For instance embedding it in RF muddies the BASE definition of it and sending it as an INF field means that whenever a new "piece of information" such as AT is invented the limited pool of field names is reduced on not one but two commands (of which INF already uses a significant portion of, at least of the ones that make sense semantically, I would rather not see field names like T0 - T9 for different tokens for example).

The query string exists as part of the URI, why not make use of it for what it was intended for?