RE: New Requirements Draft

On Wed, 27 Aug 1997, Yaron Goland wrote:

> I do not have see why that requires any special support through accept
> headers. This sort of functionality can equally be supported through
> properties which reference the various printing types.

Yaron - You seem so preoccupied with accept headers. But it's not
the accept headers that are the issue, it's indeed the properties
of the resource variants (properties here for the moment explicitly
taken as a general concept and not in the sense of the webdav
protocol, which I will write in upper case in this mail).

For example, a resource can have the property that it is
written in a language (or several languages). This property can
be sent along with the resource in the HTTP protocol using the
Content-Language HTTP header.

The HTTP protocol defines the relation between the accept headers
in the client request and the properties of the resources that
get sent back (expressed in headers, inside the resource, or
just implicitly).

That these two things (the properties as expressed in response
headers and the accept headers) can be separated is very nicely
show in the Apache implementation of negotiation. Apache first
uses a very simple naming scheme convention to find all possible
variants. It then calculates, for each variant, what the
Content-language (and other) headers would look like, by using
subrequest. The negotiation logic together with the Accept headers
then decides which variant to serve.


The WEBDAV protocol, ideally [maybe this is difficult, and will
get postponed, or turns out to be impossible, and will therefore
never get realized], defines a link between the actual properties
of the document (as visible when they get served) and the
formal PROPERTIES that the WEBDAV protocol allows to associate
to a resource.

Whether the property of the actual document is expressed on the
server through a file extension, in a separate file, in a database,
or each and all of these, different for every directory, is
absolutely a server configuration issue. A lot of aspects of
what exact resource should be served for what accept headers
is also a server configuration issue.

But as WEBDAV has PROPERTIES, and as HTTP serves documents
with certain properties, and several of these properties
have very defined ways of being expressed in the HTTP protocol,
we have to see that these two work together.

As the HTTP protocol contains a Last-Modified header, and
WEBDAV most probably also has a PROPERTY (or something
else) that contains the same information, we want them
to really be the same. In case WEBDAV doesn't have such
a PROPERTY, it definitely should have one. If the WEBDAV
protocol leaves this undefined, such that every WEBDAV
client can call this property whatever it wants, we don't
gain interoperability.

As the HTTP protocol contains a Content-Language header,
likewise the WEBDAV protocol should have something like
a LANGUAGE PROPERTY, and these should match, i.e. I should
get the appropriate value back in a Content-Language
header which I have set in the LANGUAGE property.

I agree that defining a long list of features that include
everything everybody would ever want to use, including
printer resolutions and so on, is rather difficult, and
definitely shouldn't be part of the WEBDAV core specification.
But TCN, which you have mentionned in another mail, didn't
mainly get delayed because of this problem.

Also, the general difficulty of this problem must not
detract us from defining correspondences between
WEBDAV PROPERTIES and resource properties as they
show up in response headers. If there is a well-defined
way in the HTTP protocol that identifies the language(s)
of a document that is being served, there should be a
very well defined way in WEBDAV to tell the server what
that language(s) are. It may not even be necessary that
every server supports this, but those that do should do
so in an uniform way. This has absolutely nothing to do
with variants.

For variants, the only additional support we need is to
be able to collect several variants under a generic name,
and to be able to ask the server about the name it wants
to give to a specific variant.

Regards,	Martin.

Received on Thursday, 28 August 1997 09:08:02 UTC