Re: What is CONTENT?

[Barron Housel <housel@cisco.com>]

On ext:  Practically speaking a lot of software keys off of
the extension.  However, technically speaking it doesn't have to be
meaningful -- i.e., an extension of "sue" could mean "jpeg" if the content-type
so indicated.  We could all agree to formalize this; however, I'm
concerned that other content issues (e.g., language) may affect the choice
as well.
On typed domain names: Are we overloading domain names excessively? 
The DNS proximity schemes require the domain name to map to a specific
location (e.g., http://rtp.cisco.com/employee/... vs http://www.cisco.com/employee. 
The later DNS could resolve to multiple locations: san jose, rtp, ...). 
Adding content type may be a never ending story.  Is there potential
here for a DNS admin nightmare?
Barron

Hilarie Orman wrote:

Some hint as to the content-type class is often included in the extension
field, isn't it?  We've got

 protocol   http://
 hostname components  x.y.z...2ld.tld
 filename components  /a/b/c/.../z.ext
 and parameters &this&that&theotherthing

That's a lot of freedom to encode whatever it is that's important.  But,
what I'm having trouble understanding is whether or not this is
merely an intra-CDN issue or an inter-CDN issue.  I think the crux
of the question is whether or not a vertical ("virtual", "aggregation")
access point can expect to understand the encoding and choose
a surrogate based on that and the information it may have
received from its subsidiary CDN's about available surrogates.

Hilarie

>>> deleuze@ActiVia.net 11/13/00 01:12PM >>>

> From: Fred Douglis <douglis@research.att.com>

> >Hilarie raises an interesting question: Does the "Direction System" need
> >to parse the http headers to get more information in order to direct the
> >request to a correct surrogate?
>
> This should probably be supported, though everything we've done so far
> at just the DNS level has not done that -- instead, one would have
> to embed that sort of info in the DNS name, e.g. images.foo.com versus
> streaming.foo.com.

I think the direction system clearly needs some information about the type
of data to be delivered:

 - a given machine cannot provide all kinds of service.  Thus, a CDN may
   have to include content specific surrogates (e.g. one for static web, one
   for dynamic web, another for streaming...)  The direction system would
   need content type information to choose the surrogate.

 - moreover, a CDN can provide different reach and/or scale to different
   traffic types (e.g. streaming probably needs more reach than web).

DNS based redirection works for any present or future application, even if
proprietary.

Although people often make a 'content-aware'/'DNS-based' partition of the
direction systems, DNS based redirection can also be content-aware.  It's
simply a matter of including the content type in the domain name.  This is
actually already widely in use today (most web servers are named
'www.something.tld').

Such 'typed domain names', can be useful for a CDN direction system but even
more for a direction peering system, where content type information must be
exchanged.

Such a name space would need to be agreed upon by all peerings CDNs.

--
Dr. Christophe Deleuze          Christophe.Deleuze@ActiVia.net
ActiVia Networks                http://www.activia.net