Hi Bill and All, On Thu, Jun 30, 2011 at 6:59 AM, Bill Roome <[email protected]> wrote: > I think that's a good summary of the tradeoffs. I have a mild preference > for eliminating the error code, but I can see merit in keeping it.
Okay - before changing the approach (since this general philosophy will also have implications if/when we go down the road of multiple cost types), I think it would be good to get some feedback from others in the WG to see whether they agree with it as well. Before that happens, I think I would opt for keeping the behavior of the protocol the same as it is today, but improving the text (as you outlined next...). > But if we do decide to keep the error code, then I suggest revising > Section 7.7.4.1.5 to remind people about the E_INVALID_PROPERTY_TYPE > error. Otherwise it's too easy for server & client implementors to > overlook it. Eg, change that paragraph in 7.7.1.4.5 to read: > > > If a requested property type is not valid (that is, the name is not on the > "prop-types" capability list for this service), then the ALTO server MUST > return an E_INVALID_PROPERTY_TYPE error for this request. However, if a > requested property is valid, but not defined for a particular endpoint, > then the ALTO server MUST omit that property from the response for only > that endpoint. Agreed, and this text looks good to me. Any objections from others with adopting this approach (and keeping the error code)? Thanks, Rich > > - Bill Roome > > > On 06/30/2011 01:14, "Richard Alimi" <[email protected]> wrote: > >>Hi Bill, >> >>On Wed, Jun 29, 2011 at 12:41 PM, Bill Roome <[email protected]> >>wrote: >>> Draft 8 says this about retrieving endpoint properties: >>> >>> 7.7.4.1.5. Response >>> .... >>> >>> If the ALTO Server does not define a requested property for a >>> particular endpoint, then it MUST omit it from the response >>> for only that endpoint. >>> >>> So if a client asks for a non-existent property type, >>> wouldn't it be easier just to treat it as 'undefined for >>> that endpoint', and simply ignore it, rather than requiring >>> the server to return an E_INVALID_PROPERTY_TYPE error? >>> >>> It would also be consistent with the filtered network map and >>> cost map services, because those are supposed to quietly ignore >>> invalid pids. And it would make a server marginally simpler. >>> >>> In case you didn't guess, I'm in favor of legislating errors out of >>> existence, whenever possible. >> >>Yes - simplicity is appealing :) >> >>This sounds like it might be reasonable, but I do have a concern that >>ALTO Clients might still wish to distinguish between asking for an >>invalid property and no information being available. Lets say for >>example that I configured an ALTO Client to ask for a particular >>property, but misspelled it. Every time the ALTO Client asks for the >>property's value for an endpoint, it gets nothing back. Debugging in >>this case might be less intuitive. So, operationally-speaking, it >>does sound appealing to me to be able to tell the difference between >>getting the property wrong (or not being supported) and the absence of >>information for an endpoint. That said, I do see the value in your >>suggestion - thoughts about the tradeoffs here? >> >>The main idea for ignoring invalid PIDs was because they might change >>more frequently (than the names of properties), and an ALTO Client >>still may get useful information from a partial response. >> >>Thanks, >>Rich > > > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
