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