On 09/21/2011 11:46, "Richard Alimi" <[email protected]> wrote:
>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*? There's a significant difference. For the full map request, the client doesn't give PID names. After the client gets the cost map, the client can issue a network map request to find out what those PIDs mean. But with a filtered request, the client asks about specific PIDs. That implies the client knows what endpoints are in those PIDs. If the network map has changed, the costs might be meaningless. Or those PID names might not even exist any more. So I think that whenever a client gives PID names to the server (which is inherently in a POST request), the client must also give the vtag for the map from which it got those PIDs. The server rejects the request if that's stale. Otherwise we'll have to rely on the client verifying that the vtag in the filtered cost map response matches the vtag in the client's copy of the network map. If not, the client must get the revised map, figure out the new PID names, and if they're different, send a new cost map request. A client can certainly do that, but I'm afraid many will forget. >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). Do you mean the URI for the full network map? That's easy enough, although the client can just as easily get that from the resource directory. Or did you mean a URI that only gives the definitions of the PIDs in the client's request? That would be a lot messier to implement. The filtered cost map service is a post-mode request, so the server can't create a restful uri for it. >Removing explicit versioning >information from requests I think is something that being REST-ful >lets us avoid. Okay, I'm afraid I don't understand that. Why would adding a vtag parameter to the filtered map request make it non-rest-ful? Here's the way I look at it. Whenever the vtag changes, the PID definitions change. So a PID name isn't fixed or absolute; its definition depends on some hidden state. That means simple PID names are non-rest-ful, doesn¹t it? A "rest-ful" PID name would have to be qualified with the vtag -- say 'vtag/PID'. A name like that is invarient -- the CIDR definition never changes. So it seems to me that adding a vtag parameter to the request would make the request rest-ful, when it wasn't rest-ful before. >* That said.. endpoint property responses with PIDs need to return >their map-vtag (regardless of the outcome of this discussion). So >noted. :) > >Rich _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
