On Tue, Mar 19, 2013 at 1:44 PM, Wendy Roome <[email protected]>wrote:
> 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. > I don't have a strong feeling about this. On one hand, I don't see the need to add this, but on the other hand we already do a similar thing with the list of source and destination PIDs (we assume defaults if they aren't specified). > 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 > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
