Hi Rich, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Richard Alimi > Sent: Wednesday, May 11, 2011 5:45 PM > To: Martin Stiemerling > Cc: Ben Niven-Jenkins; [email protected] > Subject: Re: [alto] category of resource/consumer (was: Comments on > draft-ietf-alto-reqs-08) > > 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.
I had this in mind, but this is not affecting the protocol as such, but the back end of the server. A server implementation can do this anyhow. > > 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. I'm also not particular happy about adding this and I would like to avoid it. Maritn [email protected] NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 28320 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
