DLV - maxAge usage and lastLocationTime conflicts

[james-emerson]

According to r1.2+ YAML
maxAge=0 means a fresh calculation is requested by the client. If the system is not able to provide the fresh location, an error 422 with code LOCATION_VERIFICATION.UNABLE_TO_FULFILL_MAX_AGE is sent back.

maxAge=0 was implemented to address an issue as described in Issue #184:
Since 'maxAge' has a minimum value of 60 secs, using 'maxAge' is not a good way for a client to ask for such "real time" location verification

Since maxAge=0 was implemented, there is no way to ensure a fresh record with 'maxAge=1,5,10,100,etc'
Requests that include maxAge=1,5,10,100,etc will show an incorrect lastLocationTime making maxAge=1,5,10,100,etc useless.

minimum: 60 was removed since r1.2+ YAML

Since minimum: 60 is removed then it would appear that maxAge=0 is no longer needed.

If maxAge=0 is no longer required/useful because minimum: 60 is removed then:

• maxAge=0 should be removed from the spec.

If maxAge=0 still has a valid use case, to ensure 'real-time':

• An additional request parameter should be added - nocache or similar - so that maxAge=1,5,10,100,etc & lastLocationTime can become usable again.

[javier-carrocalabor]

My understanding is that using maxAge=0 is in fact implicitly using your nocache. In this case you, as an API client, are forcing the MNO to work with the location at that very moment, so the MNO will have to actively locate the device at that moment.
If you make a request using maxAge>0, you let the MNO decide whether using the last known location available in the network elements, or even keeping using real time (fresh) calculation. Using the last known location can be much faster than real time calculation. And, depending on how much active the device has been in the network in the last minutes (data sessions/connections, calls, mobility), that last known location may vary from several seconds to tens of minutes, or more. This is why the range [1, ] is there, allowing the client choose the tolerable age according to their use cases. So, at the end, if the API client does not need to work with a very recent location, this can enable to have a faster response.
This said, it's true that using, e.g., maxAge=[0-10], is almost the same, as a few seconds perhaps don't make a difference, but it depends on the use case.

[javier-carrocalabor]

One more point regarding the case when maxAge > 0 is what happens if the MNO cannot meet this requirement. For example: suppose the API client requests a location with a maximum age of 120 seconds (meaning the location can be up to 120 seconds old and does not need to be freshly calculated). If the MNO retrieves the last known location and finds that it is actually 240 seconds old, the API should respond with a 422 error, as specified in the spec:

The client may optionally include a maxAge indication. If the location information known to the server is older than the specified maxAge or not known at all, an error with code 422 LOCATION_VERIFICATION.UNABLE_TO_FULFILL_MAX_AGE is sent back, independently of the verification result.

[javier-carrocalabor]

Please, @james-emerson, did this address your questions? Let us know if you need any further clarification.

[james-emerson]

@javier-carrocalabor thank you for the explanations.

Regarding maxAge=0 I have another question about your response:
In this case you, as an API client, are forcing the MNO to work with the location at that very moment, so the MNO will have to actively locate the device at that moment.
If for example, I use maxAge=0 and there is no fresh location available (but there is an older, few mins location available) then what is returned?
A. Last known location
or;
B. 422 LOCATION_VERIFICATION.UNABLE_TO_FULFILL_MAX_AGE

If it is B then that makes maxAge=0 use problematic because I would always have to make 2 API requests to get the last known location:
maxAge=0 AND maxAge=X

The preference from a customer perspective would be to always get a result back, even if the data is a bit old. To illustrate:

• Request maxAge=0 and fresh data is available then: return fresh data
• Request maxAge=0 and no fresh data is available and there is some old data then: return old data
• Request maxAge=0 and no fresh data is available and there is no old data then: return 422 LOCATION_VERIFICATION.UNABLE_TO_FULFILL_MAX_AGE
• Request maxAge=X and lastLocationTime < (currentTime - X) then: return 422 LOCATION_VERIFICATION.UNABLE_TO_FULFILL_MAX_AGE

Then these two parts in the spec should be combined and reworded accordingly:

* The client may optionally include a `maxAge` indication. If the location information known to the server is older than the specified `maxAge` or not known at all, an error with code `422 LOCATION_VERIFICATION.UNABLE_TO_FULFILL_MAX_AGE` is sent back, independently of the verification result.


 * **Max Age**: Maximum age of the location information which is accepted for the location verification (in seconds).
    * Absence of maxAge means "any age" is acceptable for the client. In other words, this is like maxAge=infinite. In this case the system will still return lastLocationTime, if available.
    * maxAge=0 means a fresh calculation is requested by the client. If the system is not able to provide the fresh location, an error with code `422 LOCATION_VERIFICATION.UNABLE_TO_FULFILL_MAX_AGE` is sent back.

[james-emerson]

@javier-carrocalabor please confirm that this discussion also applies to Device Location Retrieval API
Then we would need to do the same changes there.

[javier-carrocalabor]

I can see your point. However, the spec was written understanding that, when the API client sets maxAge=0, it signals that real-time location verification by the network is absolutely essential for the use case, and any outdated location data, regardless of how recent, is unacceptable.
If your application can accept location information that isn’t captured at the exact moment of the request (which would be the "subcases" you are proposing), you simply should specify a maxAge greater than zero to allow for more flexibility. If you are requesting maxAge=0 meaning "try real-time but I tolerate some age", you would be asking the Network to do a work that is not really necessary, and it would be better to request, for example, just maxAge<a few seconds.
I see your point from the client point of view, but the spec tries to find a balance with the MNOs point of view as well.
This reflects the intended vision for the maxAge parameter up to version 2.0.0. Any change to that vision would likely require a new version of the API, I guess. And yes, it would also apply to the Retrieval API.

[james-emerson]

@javier-carrocalabor thank you, this now addresses my questions. We have the information that we need to implement this API and expose the relevant options to our customers.