On Wed, Sep 21, 2011 at 10:36 AM, Richard Alimi <[email protected]> wrote: > On Wed, Sep 21, 2011 at 9:46 AM, Bill Roome <[email protected]> > wrote: >> 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. > > Right - there should be handling in the existing protocol for what > happens with PIDs that no longer exist (they are ignored). But the > rest of your argument still stands... > >> >> 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. > > I'd be interested to hear others' opinions here, but I'll note a > couple of additional things: > > (1) In the model you propose, this is basically turning what is today > a "soft failure" condition where the client gets partial and perhaps
Small but important correction: ".. the client may apply partial and perhaps..." > older information back (and is given the opportunity to immediately > detect it and correct it) into a "hard failure" condition, where the > client gets no information at all. > (2) Maybe its a philosophical difference, but I sort of assume that > clients parsing maps understand what the version tag means (since it > is communicated as a sibling to the cost map and cost type, and not > hidden anywhere). Do you think this is a matter of protecting clients > from not obeying the protocol? Or something else? > >> >> >>>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. > > Agree - but this gives the server the ability to provide a different > URI than what is in the directory, perhaps one that explicitly refers > to the relevant vtag. I mentioned this as a more general mechanism > that could solve the problem without adding a specific parameter to > the request. > >> >> 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. > > Agree that that would be messier :) It isn't what I intended to convey. > >> >> >>>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. > > Okay - I didn't mean to convey that what you proposed wasn't > "rest-ful" and I dont want to get bogged down into the religious > argument :) I only meant to imply that being REST-ful (and passing > around links) gives us an additional/alternate way. > > Rich > >> >> >>>* 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
