But if we take off our lawyer hats, and look at RFC 7285
as an agreement between friends, rather than a formal
contract between adversaries, then I think it is reasonable
to say that if the ordinal mode costs do not preserve the
order of the numerical costs, then that server is wrong.
Similarly, a router is allowed to drop packets, and I do
not think there is any formal requirement that it cannot
drop *every* packet. So theoretically you could glue eight
jacks to a block of hardwood and market it as a router.
Maybe you could avoid getting charged for fraud. Just don't
expect anyone to buy more than one! :-)
And looking at it from a real-world perspective, the
whole concept is irrelevant. The only reason for defining
ordinal mode is to allow a server to hide the numerical
costs. For example, if the numerical costs to three PIDs are
10, 11 and 100, a client can deduce that the middle pid is
close. If the costs are 10, 99 and 100, a client can deduce
that the middle pid is distant. If the ordinal costs are
1,2,3, a client cannot deduce anything other than 1 is
better than 2 is better than 3.
So if a server offers numerical costs, there is no
advantage for it to also offer ordinal mode costs.
And if numerical costs are available, there is no
advantage to a client to use ordinal costs. Maybe if the
client could assume the ordinal costs are 1,2,3,… -- but the
So in practice, no server will offer both numerical &
ordinal mode for the same metric.
That means a formal compliance test should only require
one mode or the other, but not both. However, keep the
interop simple, unless someone objects, I suggest we require
and it can verify that ordinal cost values are
consistent with the order of the known numerical
is a reasonable validation. An issue is that RFC7285
specifies only that "An ALTO server MUST support at least
one of the following modes: numerical and ordinal." I
believe that RFC7285 chose to not specify the consistency
between the two modes. Hence, this is beyond compliance,
right? Hence, I feel that separating RFC7285-conforming
and beyond can be helpful.