On Fri, May 17, 2013 at 3:54 PM, Wendy Roome <[email protected]>wrote:
> By "MAY", all I meant was that "We won't insist that the client compare > the values against each other." After all, a client might just print them, > as I think the bake-off clients did. > > s/MAY/may/ :-) > Sounds good. Will take the input if no objections from others. Thanks. Richard > > - Wendy Roome > > > From: "Y. Richard Yang" <[email protected]> > Date: Fri, May 17, 2013 15:42 > To: Wendy Roome <[email protected]> > Cc: IETF ALTO <[email protected]> > > Subject: Re: [alto] Equivalence of various identifiers from an ALTO Server > > > >> A >> >> client MAY compare one ordinal value against another ordinal in the same >> response, but that's all. >> > > Why add a MAY? The current wording (Sec. 6.2) is "If the Cost Mode is > 'ordinal', the Path Cost of each communicating pair is relative to the m*n > entries." In other words, a response returns m*n entries, where each entry > is a number (ranking). The current spec does not specify that the m*n > numbers are distinct, and hence the response may contain entries with the > same value. Consider an example of two two sources (S1, S2) and three > destinations (D1, D2, D3), and a response as the following: > > S1 -> D1: 1 > S1 -> D2: 2 > S1 -> D3: 2 > S2 -> D1: 1 > S2 -> D2: 2 > S2 -> D3: 3 > > The interpretation is (~ means equivalent): > S1 -> D1 ~ S2 -> D1 > < > S1 -> D2 ~ S1 -> D3 ~ S2 -> D2 > < > S2 -> D3 > > In other words, it defines a partial ordering. Is this what you are > referring to in terms of MAY? > > Richard >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
