Subject: Re: [alto] ALTO cost-ids & lookup tables

From: Wendy Roome <[email-masked]>
Date: Wed, 20 Mar 2013 13:21:51 -0400

There have been several proposals for combining the cost type and mode into
a cost-id structure, and (possibly) naming those cost-ids in a dictionary in
the IRD. In the heat of the discussion, I've lost track of exactly what's
currently on the table. But here are a few observations:

At first I was strongly in favor of naming the cost-ids in a lookup table,
and using those cost-id names in request/response messages. But now that I
think about it, I don't think lookup tables or names are necessary. Yes,
they might help some, but the cost-id proposal works nicely on its own,
without a lookup table.

BTW, cost-ids make it much easier to express a multi-cost. Otherwise we'd
have to deal with separate arrays of types & modes, worry about whether they
have the same cardinality, etc. So I see that as a good justification for
adding cost-ids.

But if we don't use cost-id names in filtered map requests, and the client
has to spell-out the full cost-id, then we should define what happens if the
client omits the mode or type.  Here are my suggestions:

* Add a new E_INVALID_COST_ID error code, meaning that the uri does not
support the requested type/mode combination, or that the type or mode names
are invalid.

* Drop E_INVALID_COST_MODE & E_INVALID_COST_TYPE; E_INVALID_COST_ID takes
their place.

* If a client specifies 'type' but omits 'mode' in a cost-id, and if that
uri only supports one mode for the requested type, use that mode. Otherwise
return an E_JSON_FIELD_MISSING error.

* If a client specifies 'mode' but omits 'type' in a cost-id, and if that
uri only supports one type for the requested mode, use that type. Otherwise
return an E_JSON_FIELD_MISSING error.

* If a client omits both type & mode, or omits the cost-id completely, and
if that uri only supports one cost-id, use that cost-id. Otherwise return an
E_JSON_FIELD_MISSING error.

      - Wendy Roome

---

From: Richard Alimi <[email-masked]>
Date: Thu, 21 Mar 2013 00:52:52 -0700

On Wed, Mar 20, 2013 at 10:21 AM, Wendy Roome <[email-masked]>wrote:

> There have been several proposals for combining the cost type and mode
> into a cost-id structure, and (possibly) naming those cost-ids in a
> dictionary in the IRD. In the heat of the discussion, I've lost track of
> exactly what's currently on the table. But here are a few observations:
>
> think about it, I don't think lookup tables or names are necessary.
>

I think the benefit is that it makes the IRD somewhat more concise and
elegant.  I don't think we have strong technical reasons for that aspect
though.

> Yes, they might help some, but the cost-id proposal works nicely on its
> own, without a lookup table.
>
> have to deal with separate arrays of types & modes, worry about whether
> they have the same cardinality, etc. So I see that as a good justification
> for adding cost-ids.
>

I'd agree with this.

> has to spell-out the full cost-id, then we should define what happens if
> the client omits the mode or type.
>

Currently in the Filtered Cost Map request, we state that cost mode and
cost type are required fields.  What would be the motivating factors behind
making them optional?

>   Here are my suggestions:
> if that uri only supports one cost-id, use that cost-id. Otherwise return
> an E_JSON_FIELD_MISSING error.
>

>       - Wendy Roome
>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>
>