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 > > - Bill Roome > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
