A few comments and questions on the new error reporting.
* For code = E_INVALID_FIELD_VALUE, what is the JSON type of the "value"
field"? Seems like it should be the type of the field with the bad value.
But that means "value" has a polymorphic type. That's not impossible to
handle, but so far we're avoided that. That also implies that if the
server returns "value", the server MUST set "field" the name of the
offending field, so the client knows what type to expect for "value".
* What happens when a field is partially invalid? Eg, consider an endpoint
cost request with 6 src endpoints. "srcs" is a properly formed JSON array,
but one string is an invalid address (poorly formed, bad type prefix,
whatever). What does the server return? Seems like the logical thing would
be to return field=srcs, with value set to the JSON array with all 6
sources. But that's not very helpful.
* Similarly, for the endpoint property request, what does the server
return if the client requests an undefined property name?
* Interesting inconsistency: for a filtered network map request,
{10.3.1.6} says that the server should ignore unknown PID names. Eg,
that's not an error. But invalid addresses or property names are errors.
As you may recall, my default design paradigm is to legislate errors out
of existence by ignoring them whenever possible. So I'd support quietly
ignoring invalid addresses and prop names, the same way we ignore invalid
PID names.
- Wendy Roome
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
