On Thu, May 16, 2013 at 4:51 PM, Ben Niven-Jenkins <[email protected]>wrote:
> Can we mandate the vtag has the equivalent properties of a strong etag in > HTTP? i.e. if an alto service is provided by multiple servers then those > servers must ensure that vtags are consistent across servers/versions? > A problem I see is how to indicate to an ALTO Client the set of servers that are consistent: Because they are linked in one entry of one IRD, have the same DNS prefix (security problem?), signed using the same certificate, ...? Any thought? Richard > If not we could have the equivalent of weak and strong vtags and in the > case of weak the client would expect the same server (IP & port) to return > consistent vtags but if it connected to another server it would have to > re-retrieve the entire cost map if it wanted to compare it to a filtered > cost map from the same (2nd) server. > > (BTW I'm not sure you can compare a filtered costmap against a full cost > map if the costs are ordinal) > > Ben > > On 15 May 2013, at 17:45, Richard Alimi <[email protected]> wrote: > > One question that Wendy brought up was: "if one resource directory can > refer to a different resource directory which may live at a different > server or administrative domain, when is it safe for an ALTO Client to > conclude that a cost metric means the same thing?" A particular example > here is the full cost map and filtered cost map. If the client fetched the > full cost map with the 'routingcost' cost metric, and then later wanted to > use a more refined query, then presumably the client should be able to > assume that the values in the filtered cost map (also with the > 'routingcost' cost metric) mean the same thing. > > A similar thing holds for version tags. If the client finds a cost map > with version tag '1234', under what conditions should it declare that it > matches the version tag for a particular network map? Similar to the cost > map example above, both may come from a different server or administrative > domain. > > To resolve this ambiguity, we are proposing to add the following to > Section 8.3.1: > > "The meanings of identifiers used in resources discovered via an entry > point to an ALTO Server (i.e., by the ALTO Discovery Protocol) SHOULD be > consistent with each other. In particular, a particular values for a > different cost maps of the same cost metric should be comparable, and the > version tag for a cost map should be comparable to the version tag for the > network map on which it was based, even if the two maps are provided by a > different server." > > I hope the intent here is clear. Admittedly, this is probably not a crisp > enough statement to put in the draft yet, but suggestions on improving it > would be appreciated. > > Thanks, > Rich > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
