Re: Media feature considerations in HTTP

At 07:21 AM 3/28/02 -0500, Mark Baker wrote:
> > >Also, a reason to be careful of feature tags is that they circumvent
> > >reification in HTTP header assertions.  For example, if I wanted to say
> > >that the negotiated content varied by some attribute that was expressed
> > >as a feature tag rather than as an HTTP header, I cannot use the HTTP
> > >Vary header.
> >
> > ?  I'd suggest just use "Vary: Content-features".  This header was 
> designed
> > exactly *for* use in content negotiation.
>
>Yes, but "Vary: Content-features" can only, I think, be interpreted to
>mean that the content varies with *all* media features, not any
>particular one.  Information very useful to HTTP intermediaries is being
>lost because it's been encapsulated such that it cannot be referred to by
>other headers.

That's why the header field *content* is designed to allow finer grained 
description.  Header fields have a flat structure that will always make it 
difficult to achieve arbitrary levels of description granularity based on 
them alone.  Ultimately, if you want arbitrary cross-referencing at 
arbitrary levels of granularity, I think you need something like 
RDF.  (And, FWIW, I have proposed an XML-based form for RFC822-like 
messages that maps reasonable neatly onto RDF -- copy at 
http://www.ninebynine.org/IETF/Messaging/draft-klyne-message-rfc822-xml-02.txt)

>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.

Further, the "matching" algorithm for the content of Content-features: 
fields has been designed to operate without requiring knowledge of the 
individual feature tags used.  See RFC 2533 and RFC 2703:

   http://www.rfc-editor.org/rfc/rfc2533.txt
   http://www.rfc-editor.org/rfc/rfc2703.txt

#g


-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Monday, 1 April 2002 06:27:32 UTC