Hi Wendy, Good comment! Please see below.
On Wed, Oct 9, 2013 at 1:42 PM, Wendy Roome <[email protected]>wrote: > 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". > > Good comment! The thought was that "value" is a JSONString of the relevant wrong value specified in the request, as your good example below suggested. You are definitely right that if "value" is specified, "field" should be specified as well. > * 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. > > The thinking is "field" : "srcs", and "value" : "the_one_wrong_address_as_string" > * Similarly, for the endpoint property request, what does the server > return if the client requests an undefined property name? > > "field": "properties" and "value" : "name_of_the_unspecified_properties" Below is a list of all requests. We can see two types of fields: array or non-array. If it is an array, the "value" field is a String of the one wrong element of the array. network map filtering: object { PIDName pids<0..*>; [AddressType address-types<0..*>;] } ReqFilteredNetworkMap; cost map filtering: object { CostType cost-type; [JSONString constraints<0..*>;] [PIDFilter pids;] } ReqFilteredCostMap; object { PIDName srcs<0..*>; PIDName dsts<0..*>; } PIDFilter; endpoint properties: object { EndpointPropertyType properties<1..*>; TypedEndpointAddr endpoints<1..*>; } ReqEndpointProp; endpoint cost: object { CostType cost-type; [JSONString constraints<0..*>;] EndpointFilter endpoints; } ReqEndpointCostMap; object { [TypedEndpointAddr srcs<0..*>;] [TypedEndpointAddr dsts<0..*>;] } EndpointFilter; > * Interesting inconsistency: for a filtered network map request, > {10.3.1.6} Which version of 10.3.1.6? I think you mean 11.3.1.6 in the newest version: "If the input parameters contain a PID name (yry note: as a value in the "pids" field) that is not currently defined by the ALTO Server, the ALTO Server MUST behave as if the PID did not appear in the input parameters." You are right that we do have Section 8.3.8 ( http://datatracker.ietf.org/doc/draft-ietf-alto-protocol/?include_text=1) which states generally that unknown fields should be ignored. Hence, we do not have E_UNKNOWN_FIELD error. My thinking is that if a field in a request is known but the value is clearly wrong and there is no explicit specification in the document to states that a wrong value should be ignore, the server returns E_INVALID_FIELD_VALUE. What do you think? Richard 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 >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
