Subject: Re: [alto] New error format in draft 20

From: Wendy Roome <[email-masked]>
Date: Wed, 09 Oct 2013 13:42:12 -0400

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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 9 Oct 2013 14:13:51 -0400

Hi Wendy,

Good comment! Please see below.

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

> sources.  But that's not very helpful.
The thinking is "field" : "srcs", and "value" :
"the_one_wrong_address_as_string"

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

> {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,
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Wendy Roome <[email-masked]>
Date: Wed, 09 Oct 2013 14:47:46 -0400

Ah! That makes sense. I suggest adding the following to the end of that
paragraph in {8.5.2} :

"The "value" key must have a JSONString value. If the invalid value isn't a
string, the server must convert it to a string. If the server includes the
"value" key, it must also include the "field" key."

- Wendy Roome

From:  "Y. Richard Yang" <[email-masked]>
Date:  Wed, October 9, 2013 14:13
To:  Wendy Roome <[email-masked]>
Cc:  IETF ALTO <[email-masked]>
Subject:  Re: [alto] New error format in draft 20

---

From: Wendy Roome <[email-masked]>
Date: Wed, 09 Oct 2013 15:13:18 -0400

Actually that needs more explanation than just what I wrote before. How
about this:

If the server includes the "value" field, it must also specify "field" with
the name of the field. The "value" field is always a JSON string.

If the invalid value is a string, "value" is that string. If the invalid
value is a number, "value" must be the invalid number as a string.

If the invalid value is a subfield, the server must set "field" to the
subfield name and "value" to the invalid subfield value, converting it to a
string if needed. For example,  if the "cost-mode" subfield of the
"cost-type" field is invalid mode "foo", the server should set "value" to
"foo", and "field" to "cost-mode", not "cost-type".

If an element of a JSON array has an invalid value, the server sets "value"
to the value of the invalid element, as a string, and "field" to the name of
the array. An array element of the wrong type (e.g., a number in what is
supposed to be an array of strings) is an invalid value error, not an
invalid type error. The server sets "value" to the string version of the
incorrect element, and "field" to the name of the array.

I think that covers all bases.

- Wendy Roome

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 9 Oct 2013 16:56:31 -0400

Hi Wendy,

On Wed, Oct 9, 2013 at 3:13 PM, Wendy Roome <[email-masked]>wrote:

> If the server includes the "value" field, it must also specify "field"
> with the name of the field. The "value" field is always a JSON string.
>
>
Yes.

> "foo", and "field" to "cost-mode", not "cost-type".
An example used in the discussions will say:

"field" : "cost-type.cost-mode"
"value" : "foo"

The reason for the "." subfield structure is to avoid future cases of
ambiguous subfield name, for example, two fields with different names, but
both have a subfield with the same name. We do not have any two subfields
with the same name in the current design, but future extensions might and
hence cause problem for the general structure. For the "." notation to be
valid, we need to avoid "." in field names. What do you think?

> If an element of a JSON array has an invalid value, the server sets
> "value" to the value of the invalid element, as a string, and "field" to
> the name of the array.
>

Yes.

> An array element of the wrong type (e.g., a number in what is supposed to
> be an array of strings) is an invalid value error, not an invalid type
> error. The server sets "value" to the string version of the incorrect
> element, and "field" to the name of the array.
>
>
This will lead to your next email: invalid value or invalid type. I will
reply in the next email.

> I think that covers all bases.
Indeed.

Richard

---

From: Wendy Roome <[email-masked]>
Date: Thu, 10 Oct 2013 10:35:37 -0400

Good point! I was relying on the fact that our field names are unique for
now, but there's no guarantee it will stay that way. So yes, set "field" to
the full path, and ban "." from field names.

 But the path should go all the way to the root dictionary.  Eg, for a bad
mode,

   "field": "meta.cost-type.cost-mode"
   "value": "foo"

or for a bad IP address in an endpoint cost request,

   "field": "endpoints.srcs"
   "value": "ipv4:a.b.c"

- Wendy

Date:  Wed, October 9, 2013 16:56

> string if needed. For example,  if the "cost-mode" subfield of the "cost-type"
> field is invalid mode "foo", the server should set "value" to "foo", and
> "field" to "cost-mode", not "cost-type".
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 11 Oct 2013 21:20:22 -0400

Hi Wendy,

>    "field": "meta.cost-type.cost-mode"
Good point. We will revise the sentence slightly to clarify this.

Thanks!

Richard