Subject: Re: [alto] Is E_INVALID_PROPERTY really needed?

From: Richard Alimi <[email-masked]>
Date: Sun, 3 Jul 2011 10:45:38 -0700

Hi Bill and All,

On Thu, Jun 30, 2011 at 6:59 AM, Bill Roome <[email-masked]> 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-masked]> wrote:
>
>>Hi Bill,
>>
>>On Wed, Jun 29, 2011 at 12:41 PM, Bill Roome <[email-masked]>
>>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
>
>
>