I think the PID property is different. The protocol defines what PIDs are and how to determine how to map an endpoint to a PID. So it's hard to imagine an ALTO server that couldn't determine the PID for an IP address.
As for the default cost type, how about this: If the client doesn't specify a Cost Type, and if that uri only supports one type, return that type. If the uri supports more than one type, default to "routingcost". And if "routingcost" isn't one of the types supported by that uri, return the "MISSING FIELD" error. BTW, thanks for the complement! - Wendy Roome From: "Y. Richard Yang" <[email protected]> Date: Tue, March 19, 2013 16:20 To: Wendy Roome <[email protected]> Cc: <[email protected]> Subject: Re: [alto] minor inconsistency in draft 14 > Related question: Do we really need to require that all ALTO servers support a > Cost Type named 'routingcost'? Suppose I have an ALTO server that provides a > custom Cost Type to a select group of authorized clients. None of those > clients need 'routingcost'. Why must my server support a Cost Type that no > client will ever use? This argument can apply to other components of the spec as well. For example, the current spec includes that the "pid" Endpoint property must be supported and one can come with a customized deployment case where pid is not used. 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? Thanks for your always good comments! Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
