Hi Richard, On Wed, Oct 02, 2013 at 05:47:20PM -0400, Y. Richard Yang wrote: > Hi Sebastian, > > Thanks a lot. Please see below. > On Oct 2, 2013 4:50 PM, "Sebastian Kiesel" <[email protected]> wrote: > > > > Hi Richard, all, > > > > I think for consistency, it would make sense to rename E_JSON_VALUE_TYPE > > to E_INVALID_FIELD_TYPE > > In a sense, if a query uses an invalid type (e.g., string but should be > number) when specifying the value of a field, it is an invalid field value > already. But this is a different error (can be caught by syntax without > using semantics). Hence it is good for me.
I think it is important to have a way to indicate invalid (or unsupported or unexpected) types. What happens in the future, when we define an extension document that specifies, say, using AS Numbers instead of IP addresses? This document will probably contain a mechanism through which a server can indicate that it supports ASNs. But then, what happens if the server does NOT announce this capability but the client nonetheless sends such a query? This query would be completely valid in the sense of the specifications, except for the fact that the server can't handle it. Sending "syntax error", or "invalid value" although the AS number is perfectly valid, does not seem appropriate to me. Thanks Sebastian _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
