Rich, Martin, Please see inline.
On 11 May 2011, at 16:44, Richard Alimi wrote: > Comment inline with most of the textual discussion omitted... > > On Wed, May 11, 2011 at 1:44 AM, Martin Stiemerling > <[email protected]> wrote: > > ... > >>> >>> I can see that an ALTO server may want to return different responses >>> depending on the category of resource (or possibly more precisely the >>> category of consumer) and we don't want to preclude that, e.g. >>> returning a different response to a P2P client than it would to a CDN. >> >> The assumption until now was really focused on the p2p use case and not on >> the CDN use case. However, I can see that in the CDN use case, an ALTO >> server may return a different response for CDN. For P2P on the other hand, >> we definitely do not want to identify the resource category. >> >> Adding the possibility to identify the category of resource to the ALTO >> requirements would require a WG consensus IMHO. >> >> The requirements would read along these lines: >> (a) that the ALTO protocol MUST NOT require the specific resource to be >> accessed to be included in ALTO requests. >> (b) that the ALTO protocol SHOULD allow to specify the resource to be >> accessed to be included in ALTO requests. >> >> (a) rules out the requirement to have it in all requests, while (b) allows >> the protocol to have such a capability. > > For the sake of completeness, I'll offer another one which was demoed > (by Juniper) in the running code show. They allowed an ALTO Server to > internally contain multiple "views" (read: set of maps), and it would > serve maps based on the requesting client. The client could be > determined by requesting IP address, supplied credentials, additional > HTTP headers, etc. This avoids us defining any additional > identifiers, or classifying applications into any particular types in > the protocol specification. > > An early implementation of the P4P work used multiple views which were > advertised by the server. It was up to the client to determine > whether they wished the default one, or wished to select a different > one. Before we go to far down the line of resource identifiers I think Martin may have misinterpreted what I meant slightly. I was never thinking about including resource identifiers in ALTO. I was thinking of the multiple views scenario described above, e.g. an ALTO server "knows" (somehow) the client is a P2P client and gives it the P2P map which may expose different costs between the same endpoints (or even different sets of end points) to the CDN map for example. I see know need to include categories of individual resources, but returning different maps based on the category of client/consumer (e.g. P2P client or CDN client, etc.) should not be precluded. Having said that I don't think that the category of resource client needs including in the protocol either. I do think the original wording of the requirement could be improved though. Apologies for sending you off on a tangent. Ben > > There are some reservations about including a resource identifier in > ALTO. In particular, we need to find a way to name it that allows > this must work under different applications that exist today and in > the future. There are ways to do it, but I'm just mentioning that this > does open a can of worms (the DECADE WG is an example of this, and I'm > sure there are others). > > Yes, you proposed this as a SHOULD so we probably aren't bound to put > this in the base protocol, but it would need to be worked out at some > point. > > Rich > >> >> Martin >> >> >> [email protected] >> >> NEC Laboratories Europe - Network Research Division >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London >> W3 6BL | Registered in England 2832014 >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto >> _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
