During our implementation of caching in LoST, one of my students came
up with the following interesting issue:
Suppose that a system has cached a mapping for city=New York, state=NY
and somebody moves the client to a place within that region that has
its own mapping, e.g., a college campus. (Similar issues arise for
places where a county has one mapping, with some part, e.g., the
incorporated area, having a more specific mapping.) In those cases, a
client would notice that the address has changed, but it still matches
the old mapping, so it will not re-query.
A related problem occurs if, during a failure, a default response has
been returned.
For geo coordinates, 'donuts' and other ways to express 'all but this
area' conditions, which would trigger re-querying. This doesn't work
for civic coordinates, obviously.
There seem to be several possibilities:
(1) Don't do that. In other words, if an area knows that there are
more specific mappings, it has to be split up in some way, e.g., by
enumerating all such areas explicitly. For example, for the
unincorporated areas, the community name is part of the mapping, even
though they all share the same county-wide mapping.
This probably works for most cases, but fails for the campus example,
since the surrounding city doesn't really know about these.
(2) Mark such cases as non-cacheable. Since civic coordinates are only
used for stationary and nomadic devices, the additional query load is
rather modest. This is the safe approach.
(3) As a compromise between (1) and (2), mark mappings that are known
to be leaf nodes. For example, a campus could mark its mapping as such
since it can be pretty sure that there's nothing below that level.
That way, laptops moving within a building don't have to requery.
These could simply be marked as cacheable, so that no additional XML
tags are needed.
Henning
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit