poy wrote:- 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).