Subject: [alto] Is E_INVALID_PROPERTY really needed?

From: Bill Roome <[email-masked]>
Date: Wed, 29 Jun 2011 15:41:39 -0400

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.

	- Bill Roome

---

From: Richard Alimi <[email-masked]>
Date: Wed, 29 Jun 2011 22:14:36 -0700

Hi Bill,

> 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-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Bill Roome <[email-masked]>
Date: Thu, 30 Jun 2011 09:59:16 -0400

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