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.
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.
- 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
