W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1999

RE: WEBDAV: IETF 44 Brief Summary

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Mon, 22 Mar 1999 16:16:13 -0800
To: gstein@lyra.org
Cc: WEBDAV WG <w3c-dist-auth@w3.org>
Message-ID: <002501be74c2$5ca44720$d115c380@galileo.ics.uci.edu>
Hi Greg,

I'm cc'ing the list on this, since I'm sure many people will be interested
in the answer.

> Jim Whitehead wrote:
> >...
> > Jim Whitehead led a discussion on registering property schemas, which
> > highlighted the issue of whether DAV properties should be
> registered on a
> > per-property, or per-schema basis.  Finally, there was a brief
> discussion on
> > moving DAV access control forward.
> Can you elaborate a bit here? Were people interested in a registry?
> Since we now have a client (IE5) that is using "unknown" properties, I
> was thinking it was time to start that registry we had bandied about a
> while back. I'm interested in people's general view on that.

Sorry this was so brief -- WG chairs are required to produce a brief summary
of their WG's meeting, in addition to a full set of minutes for the meeting.
So, there will be better minutes int he future.

People were interested in a registry, but there was concern on two points:

1) There are two views of property reuse.  One view (which I held prior to
the meeting) was that properties can be individually reused, and hence it
might be reasonable to pluck out the "author" property from the Dublin Core
and use it without using the rest of the Dublin Core properties.  The other
view is that even individual properties are bound into a schema definition,
and cannot readily be unbundled from the rest of their schema.

Based on this, it probably makes sense to register properties as schemas,
rather than as individual properties (which was my view on this).

2) There was also concern that DAV properties may not exist independently of
other protocol elements, and hence registering just properties may not be
enough.  For example, it is possible to define a long-time-duration RPC
mechanism using properties. For example, client A stores a request in a
property, then waits.  Next, client B retrieves the request from the
property, executes the request, then stores the result back in the property.
Later, client A goes back to retrieve the result.  In such a case,
registering the property isn't sufficient, since what is really going on is
a protocol.

None of these suggest to me that creating a property registry is a bad idea,
just that it may be more subtle than it originally seemed, and the
granularity of registration is probably a whole schema.

- Jim
Received on Monday, 22 March 1999 19:29:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:19 UTC