Hi Bill, I do think your proposal would suffice, but I think it would be good to look at how this relates to how we do this with the Cost Map already. For example, the current mode is that when you ask for the full Cost Map, the server tells you the version tag. If it doesn't match the Network Map you've already got, then you need to request a new Network Map. Shouldn't the same work for Filtered Cost Maps and Endpoint Properties*?
If that doesn't suffice and we really wanted to do this the REST-ful way, the right solution would probably be to have the server return the response (which includes the map-vtag), but let it also return a URI for the Network Map that provides information on those PIDs (presumably with the correct vtag). Removing explicit versioning information from requests I think is something that being REST-ful lets us avoid. * That said.. endpoint property responses with PIDs need to return their map-vtag (regardless of the outcome of this discussion). So noted. :) Rich On Tue, Sep 20, 2011 at 10:54 AM, Bill Roome <[email protected]> wrote: > 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 > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
