- From: Martin J. Dürst <mduerst@ifi.unizh.ch>
- Date: Thu, 28 Aug 1997 15:06:36 +0200 (MET DST)
- To: Yaron Goland <yarong@microsoft.com>
- cc: "'Judith Slein'" <slein@wrc.xerox.com>, w3c-dist-auth@w3.org
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