W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: HTTP 1.1 document terminology.

From: Koen Holtman <koen@win.tue.nl>
Date: Tue, 30 Apr 1996 00:48:26 +0200 (MET DST)
Message-Id: <199604292248.AAA02828@wsooti04.win.tue.nl>
To: jg@w3.org
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
jg@w3.org:
>
[....]
>        2) I like Tim's term of "generic resource" for a resource that
>you can do content negotiation against (and I incorporated some words
>of his into the terminology section below), rather than Roy's
>suggestion of group resource.

While the terms `generic/specific resource' would work, the words that
explain them are totally inappropriate for the 1.1 spec.  I guess you
took them from a research-like paper, where Tim explored a continuum
between totally specific and totally generic resources.  Such a
continuum does _not_ exist for 1.1 resources.  Generic or specific is
a binary property for 1.1 resources, and a property that is orthogonal
to variance through time.  In summary, Tim's words would totally
confuse the reader.  The edits suggested by John Franks improve the
text somewhat, but even with these edits it stays confusing.

Also, sentences like `(a little like a Platonic ideal)' and `When we
discuss electronic resources, an interesting fact is that a small
number of dimensions of genericity emerge.' do not belong in a
protocol specification.

[...]
>   I'll go with "specific resource" unless
>someone argues me out of it or suggests a better term.  Similarly, if
>someone has a bit of blinding insight for a better term, please speak
>up now.

I am using "plain resource" to denote "non-generic resource" in my
draft of the next content negotiation internet draft.

Using "plain resource" has two advantages:

  - "plain" is short
  - "plain" implies things like `the simple case', `the normal case',
    `the thing we started out with (the kind provided by 1.0 servers)',
    `the case without the special rules', which are all implications
    we want to make.

Is this blinding enough?


>variant
>-------
>An specific resource that is a member of at least one generic
>resource.  Sometimes called a resource variant.  Note that the set of
>variants of a generic resource may change over time as well.

This `variant' is not the kind of variant referred to in the 1.1
caching section.  There, a variant is an entity bound to a varying
resource as I defined it in the Vary header section.  This kind of
variant that is identified by a tuple (URI,variant-ID), it does not
(necessarily) have its own URI: this variant is _not_ a resource
(unless a resource is something which is not always identified by a
URI).  The truth about the relation between variants and resources is
complicated, and is revealed with gory graphical detail in the text
included below.

I have been working on the next version of the content negotiation
internet draft.  I hope I will get it finished before the web
conference, but cannot guarantee that I will, as contributing fixes to
the 1.1 draft is higher on my priority list.

I include some parts of my draft of the content negotiation
terminology/overview section below.  Read it for the terminology
explanations, not for the terms themselves, I plan to adjust them to
the 1.1 terminology once this terminology is known.  Feel free to
steal text you can use.  You do not need to steal from 3.4 below: 1.1
does not need to distinguish between opaque and transparent resources,
and 1.1 can ignore the extra level of indirection between a
transparent resource and its variants.

A table:

 1.1-02 text          New 1.1 terminology  Terminology in my text below

   resource             resource             resource 
   varying resource     generic resource     varying resource
   non-varying res.     specific resource    plain resource
   variant              resource entity      variant 
     <not mentioned>    variant              alternate
   entity               entity               entity
   transparent c. n.    content negotiation  transparent c.n.
   opaque c.n.          <not taken into      opaque c.n.
                         account?>

Koen.

-------snip--------

[Note: this text has not been proof-read by me yet!]


3.2 Variants and entities

   variant

        A particular representation, rendition, encoding, or
        presentation of a piece of information.  Varying resources have
        multiple variants associated with them.  Plain resources have
        only one variant.  A variant is a container of data.  The
        contents of the variant may be updated over time.

   entity

        A piece of data, usually representing the contents of a variant
        at a given point in time, transferred in a HTTP transaction.  An
        entity is transferred as metainformation in the form of entity
        headers and content in the form of an entity body.


3.3 Resources and negotiation

   resource

        A network information repository or service, residing on an
        origin server, that can be identified by a URI.  In this
        specification, resources are active parties in the
        communication.  Our sentence `the resource X returns Y' would be
        `if a request is made on the resource X, the server returns Y'
        in the terminology of [1].

   This specification divides all resources into classes as follows:

                  -- plain resources
                /
               /
     resources
               \                         -- opaque resources
                \                      /
                  -- varying resources 
                                       \
                                         -- transparent resources


   Opaque and transparent resources are collectively called varying
   resources.  At any given moment in time, a resource is either a plain
   resource, an opaque resource, or a transparent resource.  Resources
   can change their class, but it is not expected that this will occur
   often.

   HTTP/1.1 [1] defines the distinction between plain and varying
   resources. This specification defines the additional distinction
   between opaque and transparent resources.  HTTP/1.1 defines minimal
   caching behavior for all varying resources.  This specification
   defines additional, optional, caching behavior for transparent
   resources.

   plain resource

        A resource which is not a varying resource.  A plain resource
        only has one variant associated with it, and will return either
        this variant, or an error message for every request.  Resources
        which have no associated variants, but instead return
        redirection (301, 302, 303) type responses, are also called
        plain resources.  Plain resources are called non-varying
        resources in [1].  Traditional HTTP/1.0 servers only provide
        plain resources.

   varying resource

        A varying resource has multiple variants associated with it, all
        of which are representations of the content of the resource.  If
        a GET or HEAD request on a varying resource is received, the
        server will try to select one variant as the one best matching
        the request.  This selection process is called content
        negotiation.  If a resource is varying, this has an important
        effect on cache management, particularly for caching proxies
        which service a diverse set of user agents.

   negotiated resource

        synonym for varying resource

   content negotiation

        The process by which the best variant is selected when a GET or
        HEAD request is made on a varying resource.  Selection is based
        on a matching of the properties of the variants to the
        capabilities of the requesting user agent.  Content negotiation
        may not always succeed in finding the best variant, for example
        because none of the variants are acceptable to the user agent.
        In this case, a 3xx (redirection) or 4xx (client error) type
        response can be generated.  

   There are two types of content negotiation: opaque negotiation and
   transparent negotiation.

   opaque negotiation

        With opaque negotiation, the selection of the best
        variant is done by an algorithm located at the origin
        server, and unknown to the proxies and user agents involved.
        Selection is based on the contents of particular header fields
        in the request message, or on other information pertaining to
        the request, like the network address of the sending client.

   A typical example of opaque negotiation would be the selection of a
   text/html response in a particular language based on the contents of
   the Accept-Language request header field.  A disadvantage of opaque
   negotiation is that the request headers may not always contain enough
   information to allow for selection.  If the Accept header

            Accept: text/*: q=0.3, text/html, */*: q=0.5

   is sent in a request on a varying resource which has a video/mpeg and
   a video/quicktime variant, the selection algorithm in the origin
   server will either have to make a default choice, or return an error
   response which allows the user to decide on further actions.

   opaque resource

        A resource which is opaquely negotiated. Opaque resources always
        include a Vary header every 2xx class response.


3.4 Transparent resources and transparent negotiation

   A transparent resource does not directly `contain' variants.  Instead,
   a transparent resource binds to multiple alternate resources, which
   in turn `contain' variants.  

   An example is a resource http://x.org/intro, which uses negotiation
   to provide a paper about x.org:

    resource                      alternates                variants
    --------                      ----------                --------

                           -----  plain resource ---------- variant 1
                         /      http://x.org/paper.html.notables
                        /
    transparent resource -------  plain resource ---------- variant 2
    http://x.org/paper  \       http://x.org/paper.html.tables
                         \
                           -----  plain resource ---------- variant 3
                                http://x.org/paper.ps

   In this example, the transparent resource http://x.org/paper has
   three different alternates and three different variants.  Note that
   there is a one-to-one mapping between alternate URIs and variants.

   An alternate resource can be a plain resource or an opaque resource,
   but can never be a transparent resource itself.

   alternate resource

        A resource bound to by a transparent resource.  An alternate
        resource is either a plain resource or an opaque resource, but
        can never be a transparent resource itself.

   best alternate resource

        The alternate resource best matching to the user agent
        preferences for the request.  If none of the alternates can be
        handled by the user agent, the request does not have a best
        alternate resource.

   transparent negotiation

        With transparent negotiation, the selection of the best
        alternate resource is done by a distributed algorithm which can
        perform computation steps in the origin server, in proxies, or
        in the user agent.  Transparent negotiation guarantees that, if
        the user agent supports the transparent negotiation algorithm
        and is correctly configured, the request will always correctly
        yield either the best alternate resource, or an error message
        indicating that none of the alternates bound to the resource can
        be handled by the user agent.

   transparent resource

        A resource which is transparently negotiated.  A transparent
        resource binds to multiple alternate resources, which together
        contain all variants available for the transparent resource.
        Transparent resources always include an Alternates header in
        every 2xx and 3xx class response.  This Alternates header
        describes  the alternate resources bound to the transparent
        resource.

   A more complicated example is a resource http://x.org/intro, which
   uses negotiation to provide introductory information about x.org:

    resource                      alternates                variants
    --------                      ----------                --------

                           -----  plain resource ---------- variant 1
                         /      http://x.org/intro.mpeg
                        /
    transparent resource -------  plain resource ---------- variant 2
    http://x.org/intro  \       http://x.org/intro.quicktime
                         \
                          \                          ------ variant 3
                           \                       /       
                             ---  opaque resource   ------- variant 4
                                http://x.org/intro.html
                                                   \
                                                     ------ variant 5

   In this example, the transparent resource http://x.org/intro has
   three different alternates and five different variants.  It is not
   expected that opaque alternate resources like the
   http://x.org/intro.html above will be used often.  

   An opaque alternate resource could be useful, for example, to
   opaquely negotiate around bugs in the HTML rendering code of certain
   user agents.  The resource http://x.org/intro.html above would use an
   opaque algorithm located at the origin server, which looks at the
   User-Agent request header to select a html variant which will render
   without triggering bugs.  If variant 4 is returned when
   http://x.org/intro is accessed, this will be the result of
   transparent negotiation, which selected http://x.org/intro.html as
   the best alternate, followed by opaque negotiation, which selected
   variant 4 as the best variant.

   Note that use of opaque resources is not necessary to negotiate on
   features, rather than bugs, of HTML rendering engines.  The feature
   negotiation facilities of transparent negotiation allow for
   negotiation on HTML rendering features with greater flexibility and
   efficiency.

[End of text]
Received on Monday, 29 April 1996 15:57:08 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:53 EDT