I think that's a deployment decision. Hostname+Port would be a reasonable suggestion for a starting/default position IMO (i.e load balanced servers must be consistent and an implementation may want to offer the ability to relax that to domain prefix or something else). Ben
On 17 May 2013, at 20:47, "Y. Richard Yang" <[email protected]> wrote: > > 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
