- From: Graham Klyne <GK@NineByNine.org>
- Date: Mon, 01 Apr 2002 16:26:01 +0100
- 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 UTC