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 client cannot.
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 both modes.
and it can verify that ordinal cost values are consistent with the order of the known numerical values.
This 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.