On Tue, Mar 19, 2013 at 2:10 PM, Scharf, Michael (Michael) < [email protected]> wrote:
> > My understanding of the decision that an ALTO Server must > > provide "routingcost" is also related with the design of > > allowing default. For example, CostMapCapability can be empty > > and implies "routingcost". One analogy one might or may not > > like is that TLS (RFC5246) defines that > > TLS_RSA_WITH_AES_128_CBC_SHA is mandatory. But we can imagine > > that there is no mandatory and hence allows TLS negotiation > > to fail. But I agree with you that removing the so far MUST > > supported cost type and endpoint property will not impact > > interop in the sense that the protocol still works, and a > > conforming ALTO Server may just not returning any > > information. What do you and others think? > > Another option would be to replace the term "routingcost" by something > that does not specifically refer to a way how to determine that cost. For > instance, "defaultcost"? > > But I don't have a strong preference here. > I slightly prefer 'routingcost' because what we're actually conveying is the cost from the provider's point of view for routing traffic from a source to a destination. Of course, we've intentionally left the actual metric only loosely specified. 'defaultcost' (to me, anyways) seems to convey something like "I'm going to tell you the cost is X because I don't know any better". > Michael > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
