W3C home > Mailing lists > Public > www-archive@w3.org > April 2002

Re: Media feature considerations in HTTP

From: Graham Klyne <GK@NineByNine.org>
Date: Mon, 01 Apr 2002 16:26:01 +0100
Message-Id: <5.1.0.14.2.20020401161114.039327d0@joy.songbird.com>
To: Mark Baker <distobj@acm.org>
Cc: www-archive@w3.org, sean@mysterylights.com
At 08:57 AM 4/1/02 -0500, Mark Baker wrote:
>Hi Graham.  CCd to www-archive, not www-tag.
>
>I fear I'm not communicating very well ...
>
> > >With "Man" from RFC 2774, "Man: Content-features" means that the client
> > >is requiring that the Content-features header be understood.  If that
> > >client wanted to ask that a particular media feature, say "xmlns", be
> > >understood, it would not be able to use 2774.
> >
> > Yes, this is true.  But I don't see it as a limitation of the
> > Content-features: header field, but as inherent in the design goals
> > underlying RFC 2774.
>
>For sure, but it's not specific to RFC 2774.  RFC 2616 includes at
>least two headers that use the same referencing capability; Vary, and
>Connection.  It's really inherrent to 2616 IMO (or perhaps 822), because
>header syntax treats header content as opaque, so only the header names
>can be used as reference points for other headers.

Yes, agreed.  That is really what I was getting at with the bit of my 
message you didn't quote:  header fields are indeed a natural "unit" of 
metadata information in HTTP, but they do have their limitations.

>This isn't saying that Content-features isn't useful, it's just pointing
>out the cost of using it over using separate headers.

Again, agreed, there is a cost to bear.

The point you raised, to which I responded, was that having Vary: apply to 
the Content-features field (rather than a feature tag) somehow meant that 
Content-features could not be used for content negotiation in HTTP.  Sure, 
I accept it would require negotiation software to delve inside the header 
content.  In this respect, it's little different from RFC 2295 "Transparent 
Content Negotiation in HTTP".  Indeed, the CONNEG work was designed with a 
view to being usable for content with both HTTP web access and Email, and 
Koen Holtman who implemented RFC 2295 in Apache was at one point 
considering updating his implementation to use the CONNEG framework.

Anyway, so much for the history.  One of my reasons for pursuing this 
debate was to raise awareness that I think that there is a path to 
convergence in RDF (+OWL?) for the IETF CONNEG work and W3C CC/PP work.  I 
am involved with some proposals that we'll see RFC 2506 feature tags mapped 
into URI space.  Tnen, CC/PP will be able to use the feature tags published 
and documented for CONNEG.  The description logic work that underpins 
DAML/OIL also provides a subsumption calculatio0n that is similar to 
conneg's feature matching.  So, in time, I think there's a path to 
fine-grained content negotiation that sits neatly in the family of Web 
technologies.

#g
--


-------------------
Graham Klyne
<GK@NineByNine.org>
Received on Monday, 1 April 2002 10:24:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:17 GMT