A PID name doesn't mean much without the corresponding map-vtag. So I
suggest adding a map-vtag parameter to the following ALTO messages:
1. In Section 7.7.4.1 -- Endpoint Property -- add a "map-vtag" field to
the server's response {7.7.4.1.5}. E.g.
object {
JSONString map-vtag; [OPTIONAL]
EndpointProps [TypedEndpointAddr]<0..*>;
...
} InfoResourceEndpointProperty;
The server supplies that if the client asked for the "pid" property. It's
the tag for those pid names, of course.
2. In Section 7.7.3.2 -- Filtered Cost Map -- add a map-vtag field to the
client's request message {7.7.3.2.3}. Eg,
object {
CostMode cost-mode;
CostType cost-type;
JSONString map-vtag; [OPTIONAL]
JSONString constraints<0..*>; [OPTIONAL]
PIDFilter pids; [OPTIONAL]
} ReqFilteredCostMap;
This is the tag for the network map the client used when selecting those
pids. If that doesn't match the current tag, then the pid definitions have
changed substantially, and the pid names aren't what the client thinks
they are. Hence the server should reject the request. This means adding a
new error code to {7.4.3}, say E_INVALID_MAP_VTAG.
The client can omit the vtag if the request doesn't have any pid names.
- Bill Roome
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
