Disclaimer: This document strictly represents my own opinion and not necessarily those of the W3C.

Status: The design part is not done but you should be able to read the analysis of the WebDAV PROPFIND method and the HTTP Link header field.

Light weight Property Discovery and Transport

Here are some of the pros and cons that I see regarding existing solutions including the WebDAV PROPFIND method and the HTTP Link header field for the specific problem of lightweight property discovery and transport on a resource for handling style sheets, privacy rules, etc.

In summary, the PROPFIND method is fine for complex property accesses but takes an extra RTT; the Link header field is more light weight but doesn't scale well and doesn't support link types as first class objects. Instead, here I propose using CCPP and the HTTP extension framework for a lightweight, scalable mechanism to exchange properties.

WebDAV PROPFIND Method

The PROPFIND method is fine for complex property searches but it takes an extra RTT which in my mind makes it rather heavy weight for exchanging properties like style sheets etc.

One can argue that HTTP pipelining solves this but here the problem is that the client doesn't know a priori whether the server understands it (is a HTTP/1.1 server) or not and therefore it has to wait at least 1 RTT before starting. Once the client knows, it can of course store the information and start pipelining directly next time it connects.

Also, the cost of failure can potentially be very high - most servers (although they really shouldn't) break the connection when they see a method they don't understand. That is, the real price may be to reopen a new connection and to send a new request may be 3 RTTs. Note that this is also a problem for the HTTP extension framework if using mandatory extensions.

HTTP Link Header Field

In contrast to the PROPFIND method, the HTTP Link header field can in most cases prevent a full extra RTT if the client is happy to start the layout of the page without the style information. Currently, GUI browsers don't tend to do that - they rather wait until the style information comes in. The way this would be done using pipelining is the following:

That is, the link information isn't downloaded before the full document is downloaded because of the inherent serialization. Although we have shown that it is in fact often faster to do it this way - especially if the document is compressed - clients still prefer to open multiple connections. When that happens, it is of course not just one extra RTT but 3-4.

However, there are two major disadvantages with the Link header field:

1. The link type is not a first class object (ie, it doesn't have a globally unique URI)
2. It doesn't scale very well as there may be arbitrarily many properties and the server has no clue which ones the client wants or does not want. Should it include link information for setting ACLs as well as style information?

Also, the Link header can not express complex searches on a set of properties.

CC/PP and HTTP Extension Framework

Instead of the two solutions above, I propose using a simple extension to providing the best of both worlds by:

1. providing the client with a mechanism for saying which properties it is interested in
2. making the link type a first class object

@@@Should be able to use CC/PP transport here but I am not sure what the status. Should read Taka's latest draft@@@