Subject: PropReg: Probing for Property-Registration Requirements

From: "Dennis E. Hamilton" <[email-masked]>
Date: Thu, 4 Oct 2001 22:57:10 -0700

Me again!

I have been lurking (well, cowering) while wondering exactly what is called
for in terms of WebDAV Property Registrations.  Although my search for
relevant materials in the WebDAV archives is incomplete, here is how it
looks to me:

A.	IDEAS FOR SOLUTIONS

1.	There are ideas about how to store information about properties.
2.	There are ideas and some effort on how to store property information in a
database or similar collection.
3.	There are ideas about marshalling property values that might have
crossover to the description of property values.

There are also ideas about constraints on property registration (e.g., it
should be simple, not require central authority, etc.). There are also
existing metadata description, interchange, and repository standards which
might have to be accommodated in some way.

B.	WHAT PROBLEM IS SUPPOSED TO BE SOLVED?

What I haven't found is the community thinking on *WHY* one would register
properties, what would be registered, and who would use it (people and
machines), and for what.  That is, what problem(s) is property registration
intended to solve, and is there consensus on the problem set?

I invite discussion at this level before going too far into formulating an
approach.

C.	A REQUIREMENTS SURVEY

Here are survey questions.  I've sketched characteristics of a property
registration scheme in terms of end-to-end use (registrant to user).  Please
say what you consider required and what you consider unnecessary, along with
any other thoughts you have.  I will distill a requirements sketch from the
responses and echo the key ideas for further consideration and refinement.

I am not being rigorous about requirements versus constraints and solutions.
I haven't looked for metrics on satisfaction of requirements.  I'm probing
for informal use cases as a point of departure for now.

-	-	-	THE QUESTIONS   	-	-	-

D.	REGISTERING A WEBDAV PROPERTY

1.	Registration identifies the property and the authoritative source of
further information?  The source is located by URI?  The source is located
by non-Internet means?  Is it necessary to associate a property with some
authority over its definition?  The authoritative source and the property
are identified independently?

2.	Does the registration make available a definition of the property?  Is
the definition amenable to human use?  Mechanical usage?  Both?  In
combination?  What purpose is served by making the definition available?

3.	Is the registration information submitted to third parties for retention
and retrieval by anyone who chooses to discover the established use of the
identified property?  Might it be found on WebDAV servers that support the
property?

4.	What groups of people (by rôle) are required to be able to create and
submit/register property-registration information?  (This is distinct from
being able to configure a server and/or client to support such a property.)

E.	USING REGISTRATION INFORMATION

1.	Are property registrations intended to be useable by clients while
interacting with a DAV server that supports a particular property?

2.	If a property can be set by a client (even if live), does the property
registration provide
	a.	format conditions (syntax) for the value of the property?
	b.	descriptive or other information with regard to the semantics of the
value?
	c.	indication of interdependencies with other properties?
	I think the key question is how far should the property description go to
equip a knowledgeable person, in conjunction with flexible client software,
to be able to specify a value for the property that (i) will be accepted by
the server and (ii) is appropriate in the context of the semantics of the
property?

3.	Is it important to provide, in the registration information,
customization descriptive presentations for users who are competent in
different native languages?

4.	How important is it to have the property-registration information provide
sufficient information so that an user can intelligibly interpret a value
for that property as presented by a flexible client?  (By flexible is meant
a client that allows use of properties other than ones it was specifically
designed to accommodate.)

5.	What groups of people (by rôle) are required to be able to find and use
property-registration information?

6.	Is property registration information to be attractive for configuration
of a server to support the property (apart from mapping to an implementation
and recognizing that no DAV server is required to support such an approach)?

F.	INTERCHANGE OF PROPERTY-REGISTRATION INFORMATION
	[This seems to be all about constraints.  Ah well ...]
	a.	Should the property-registration information be in a structured,
mechanically-processable form?
	b.	Must the property-registration information be easily rendered for human
comprehension and review?
	c.	Should property registrations be a resource type for storage in DAV
itself?  An existing resource type?
	d.	How easy must it be to carry the property-registration information in
plain text, in files, and in simple serial data streams?  Embedded in
structured information?

-- Dennis

Dennis E. Hamilton
AIIM DMware Technical Coordinator
------------------
mailto:[email-masked]  tel. +1-206-932-6970
http://www.dmware.org           cel. +1-206-779-9430
     ODMA Support http://www.infonuovo.com/odma

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 5 Oct 2001 11:39:18 +0200

Hi,

below is a formalized version of the allprop extension we discussed some
weeks ago (to include ACL/deltaV properties that would not be reported
otherwise). The intent is to have a working paper that

a) can be developed for RFC2518++,

b) can be used for documentation purposes.

Julian

--

Network Working Group                                         J. Reschke
Internet-Draft                                                S. Eissing
Expires: April 5, 2002                                        greenbytes
                                                         October 5, 2001

  Including additional properties in WebDAV PROPFIND/allprop requests
                draft-reschke-webdav-allprop-include-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 5, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   Recent specifications extending the Web Distributed Authoring
   Protocol (WebDAV) restrict the set of properties returned
   automatically upon a PROPFIND/allprop request.  This specification
   defines a method to add specific properties to the set of properties
   returned upon PROPFIND/allprop.

   Distribution of this document is unlimited.  Please send comments to
   the Distributed Authoring and Versioning (WebDAV) working group at
   [email-masked][1], which may be joined by sending a message
   with subject "subscribe" to [email-masked][2].

Reschke & Eissing         Expires April 5, 2002                 [Page 1]

Internet-Draft       WebDAV PROPFIND/allprop/include        October 2001

   Discussions of the WEBDAV working group are archived at URL: http://
   lists.w3.org/Archives/Public/w3c-dist-auth/.

Table of Contents

   1.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Extensions to PROPFIND/allprop . . . . . . . . . . . . . . . .  5
   3.1 Example for PROPFIND/allprop/include with extended server  . .  5
   3.2 Example for PROPFIND/allprop/include with non-extended server   7
   4.  Changes to WebDAV DTD  . . . . . . . . . . . . . . . . . . . .  9
   5.  Compatibility Considerations . . . . . . . . . . . . . . . . . 10
   6.  Internationalization Considerations  . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  Copyright  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  Intellectual Property  . . . . . . . . . . . . . . . . . . . . 14
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16

Reschke & Eissing         Expires April 5, 2002                 [Page 2]

Internet-Draft       WebDAV PROPFIND/allprop/include        October 2001

1. Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Reschke & Eissing         Expires April 5, 2002                 [Page 3]

Internet-Draft       WebDAV PROPFIND/allprop/include        October 2001

2. Introduction

   Recent specifications extending the "Web Distributed Authoring
   Protocol" (WebDAV, [RFC2518]) like "Versioning Extensions to WebDAV"
   [deltaV] and "WebDAV Access Control Protocol" [ACL] restrict the set
   of properties returned automatically upon a PROPFIND/allprop request
   in order to avoid the expensive computation of properties that the
   client in many cases isn't interested in.

   However, this change from the behaviour defined in WebDAV can lead to
   situations where clients need to perform two requests to retrieve all
   properties they are interested in (one using PROPFIND/allprop, then
   PROPFIND/prop enumerating the new properties that weren't reported
   upon the first request).  This specification defines a backward-
   compatible extension to add specific properties to the set of
   properties returned upon PROPFIND/allprop, thus saving at least one
   PROPFIND request.

Reschke & Eissing         Expires April 5, 2002                 [Page 4]

Internet-Draft       WebDAV PROPFIND/allprop/include        October 2001

3. Extensions to PROPFIND/allprop

   The "allprop" version of PROPFIND is extended to take an optional
   <include> element (with namespace-URI "DAV:").  When present, it
   contains a set of property names that shall be reported in addition
   to those properties that the server usually would return upon
   PROPFIND/allprop.

3.1 Example for PROPFIND/allprop/include with extended server

    >>Request

      PROPFIND  /container/front.html HTTP/1.1
      Host: www.foo.bar
      Depth: 1
      Content-Type: text/xml
      Content-Length: xxxx

      <?xml version="1.0"?>
      <propfind xmlns="DAV:">
        <allprop/>
        <include>
          <checked-in/>
          <checked-out/>
        </include>
      </propfind>

    >>Response

      HTTP/1.1 207 Multi-Status
      Content-Type: text/xml
      Content-Length: xxxx

      <?xml version="1.0"?>
      <multistatus xmlns="DAV:">
        <response>
          <href>http://www.foo.bar/container/front.html<href>
          	<propstat>
             <prop>
               <R:bigbox xmlns:R="http://www.foo.bar/boxschema/">
               	<R:BoxType>Box type B</R:BoxType>
               </R:bigbox>
               <creationdate>1997-12-01T18:27:21-08:00</creationdate>
               <displayname>Example HTML resource</displayname>
               <getcontentlength>4525</getcontentlength>
               <getcontenttype>text/html</getcontenttype>
               <getetag>zzyzx</getetag>
               <getlastmodified>Monday, 12-Jan-98 09:25:56
GMT</getlastmodified>

Reschke & Eissing         Expires April 5, 2002                 [Page 5]

Internet-Draft       WebDAV PROPFIND/allprop/include        October 2001

               <resourcetype/>
               <supportedlock>
                 <lockentry>
                   <lockscope><exclusive/></lockscope>
                   <locktype><write/></locktype>
                 </lockentry>
                 <lockentry>
                   <lockscope><shared/></lockscope>
                   <locktype><write/></locktype>
                  </lockentry>
                </supportedlock>
                <checked-in>

<href>http://www.foo.bar/versions/container/front.html-1</href>
                </checked-in>
             </prop>
             <status>HTTP/1.1 200 OK</status>
           </propstat>
           <propstat>
             <prop>
               <checked-out/>
             </prop>
             <status>HTTP/1.1 404 NOT FOUND</status>
           </propstat>
        </response>
      </multistatus>

   In this example, the server has recognized the extension element
   <include> and included the DAV: properties <checked-in> and <checked-
   out> (as defined in [deltaV]).

Reschke & Eissing         Expires April 5, 2002                 [Page 6]

Internet-Draft       WebDAV PROPFIND/allprop/include        October 2001

3.2 Example for PROPFIND/allprop/include with non-extended server

    >>Request

      PROPFIND  /container/front.html HTTP/1.1
      Host: www.foo.bar
      Depth: 1
      Content-Type: text/xml
      Content-Length: xxxx

      <?xml version="1.0"?>
      <propfind xmlns="DAV:">
        <allprop/>
        <include>
          <checked-in/>
          <checked-out/>
        </include>
      </propfind>

    >>Response

      HTTP/1.1 207 Multi-Status
      Content-Type: text/xml
      Content-Length: xxxx

      <?xml version="1.0"?>
      <multistatus xmlns="DAV:">
        <response>
          <href>http://www.foo.bar/container/front.html<href>
          	<propstat>
             <prop>
               <R:bigbox xmlns:R="http://www.foo.bar/boxschema/">
               	<R:BoxType>Box type B</R:BoxType>
               </R:bigbox>
               <creationdate>1997-12-01T18:27:21-08:00</creationdate>
               <displayname>Example HTML resource</displayname>
               <getcontentlength>4525</getcontentlength>
               <getcontenttype>text/html</getcontenttype>
               <getetag>zzyzx</getetag>
               <getlastmodified>Monday, 12-Jan-98 09:25:56
GMT</getlastmodified>
               <resourcetype/>
               <supportedlock>
                 <lockentry>
                   <lockscope><exclusive/></lockscope>
                   <locktype><write/></locktype>
                 </lockentry>
                 <lockentry>
                   <lockscope><shared/></lockscope>

Reschke & Eissing         Expires April 5, 2002                 [Page 7]

Internet-Draft       WebDAV PROPFIND/allprop/include        October 2001

                   <locktype><write/></locktype>
                  </lockentry>
                </supportedlock>
             </prop>
             <status>HTTP/1.1 200 OK</status>
           </propstat>
        </response>
      </multistatus>

   In this case the <include> element was simply ignored.  The client
   can detect this situation by checking for the presence of the
   requested properties and will have to issue an additional PROPFIND/
   prop request (to retrieve the missing properties).

Reschke & Eissing         Expires April 5, 2002                 [Page 8]

Internet-Draft       WebDAV PROPFIND/allprop/include        October 2001

4. Changes to WebDAV DTD

   <!ELEMENT propfind ((allprop, include+) | propname | prop) >
   <!ELEMENT include ANY >

   Note that the WebDAV DTD is informal only and cannot be used to
   validate request or response bodies (due to the inability to properly
   work with XML namespaces).

Reschke & Eissing         Expires April 5, 2002                 [Page 9]

Internet-Draft       WebDAV PROPFIND/allprop/include        October 2001

5. Compatibility Considerations

   This specification introduces a new child element for the <propfind>
   element, defined in Section 4.  Old servers will ignore this element
   (see [RFC2518], chapter 14).  Clients can detect this situation as
   outlined in Section 3.2.

   Clients not aware of this specification will not be affected at all,
   because they will never use the new <include> element in PROPFIND
   requests.

Reschke & Eissing         Expires April 5, 2002                [Page 10]

Internet-Draft       WebDAV PROPFIND/allprop/include        October 2001

6. Internationalization Considerations

   This proposal builds on [RFC2518], and inherits its
   internationalizability.

Reschke & Eissing         Expires April 5, 2002                [Page 11]

Internet-Draft       WebDAV PROPFIND/allprop/include        October 2001

7. IANA Considerations

   This proposal does not introduce any new IANA considerations, since
   it does not specify any new namespaces (in the general sense), but
   merely uses existing ones.

Reschke & Eissing         Expires April 5, 2002                [Page 12]

Internet-Draft       WebDAV PROPFIND/allprop/include        October 2001

8. Copyright

   To be supplied by the RFC Editor.

Reschke & Eissing         Expires April 5, 2002                [Page 13]

Internet-Draft       WebDAV PROPFIND/allprop/include        October 2001

9. Intellectual Property

   To be supplied by the RFC Editor.

Reschke & Eissing         Expires April 5, 2002                [Page 14]

Internet-Draft       WebDAV PROPFIND/allprop/include        October 2001

References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2518]  Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
              Jensen, "HTTP Extensions for Distributed Authoring --
              WEBDAV", RFC 2518, February 1999.

   [deltaV]   Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J.
              Whitehead, "Versioning Extensions to WebDAV", ID draft-
              ietf-deltav-versioning-18, September 2001, <http://
              www.webdav.org/deltav/protocol/draft-ietf-deltav-
              versioning-18.htm>.

   [ACL]      Clemm, G., Hopkins, A., Sedlar, E. and J. Whitehead,
              "WebDAV Access Control Protocol", ID draft-ietf-webdav-
              acl-06, June 2001, <http://www.webdav.org/acl/protocol/
              draft-ietf-webdav-acl-06.htm>.

   [1]  <mailto:[email-masked]>

   [2]  <mailto:[email-masked]?subject=subscribe>

Authors' Addresses

   Julian F. Reschke
   greenbytes GmbH
   Salzmannstrasse 152
   Muenster, NW  48159
   Germany

   EMail: [email-masked]

   Stefan Eissing
   greenbytes GmbH
   Salzmannstrasse 152
   Muenster, NW  48159
   Germany

   EMail: [email-masked]

Reschke & Eissing         Expires April 5, 2002                [Page 15]

Internet-Draft       WebDAV PROPFIND/allprop/include        October 2001

Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Reschke & Eissing         Expires April 5, 2002                [Page 16]

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 5 Oct 2001 17:45:48 +0200

Hi,

due to the recent discussion on the ACL list, I have done a comparison of
PROPFIND, (ACL/deltaV) REPORT and (DASL) SEARCH. My conclusions are:

- There are three methods with partly overlapping features: PROPFIND
(defined in RFC2518), REPORT (defined in the soon-to-appear deltaV RFC) and
SEARCH (expired draft).
REPORT and SEARCH seem to be almost identical in features -- both just
define frameworks into which query/report grammars can be plugged in.
- There doesn't seem to be anything in the DASL framework that couldn't be
done with REPORT. In fact, query grammar (REPORT) discovery seems to have a
more elegant solution.

Proposal: drop work on DASL. Instead define an (extensible) equivalent of
DAV:basicseach, with the following additional features:

- discovery of searchable properties
- discovery of supported constructs in the grammar
- better signaling of execution errors (non-searchable properties, not
recognized grammar constructs)
- definition of a mandatory subset of query grammar features

Publish this as separate RFC, or possibly move it into RFC2518++.

(the actual tabular comparison is attached as HTML).

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 5 Oct 2001 17:55:58 +0200

(sorry: wrong attachment)

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Julian Reschke
> Sent: Friday, October 05, 2001 5:46 PM
> To: [email-masked]; WebDAV Working Group
> Subject: REPORT vs SEARCH
>
>
> Hi,
>

---

From: "Jim Whitehead" <[email-masked]>
Date: Fri, 5 Oct 2001 10:25:32 -0700

Julian Reschke writes:
> (defined in RFC2518), REPORT (defined in the soon-to-appear
> deltaV RFC) and SEARCH (expired draft).
> done with REPORT. In fact, query grammar (REPORT) discovery seems
> to have a more elegant solution.

My view on the distinction between the three methods (PROPFIND, SEARCH,
REPORT) is as follows:

* PROPFIND is useful when the client knows exactly which properties, on
which resources, it wants to retrieve. It is also useful for discovering
what properties are defined on a resource.

* SEARCH is useful when the client knows what property values it wishes to
retrieve, but it cannot compute ahead of time the set of resources for which
it wants those property values. While the client could just retrieve the
properties from all resources, and then perform a comparison in-memory, this
is *extremely* inefficient from a network resources standpoint. SEARCH can
perform an unconstrained number of different kinds of searches on the
server, and so it is very difficult for the server to optimize specific,
frequently-occurring searches.

* REPORT is useful when the protocol designers can predict that a specific
search will be very useful, and will occur frequently. This allows a server
to optimize the performance of these queries. Additionally, REPORT allows
complex search semantics to be defined that might not be expressable using
SEARCH. But, REPORT was never desgined to accommodate a wide range of fairly
unconstrained queries (such as those expressable using SQL).

In my view, each of these methods has its niche, and each has value.  As a
result, I favor:

a) continued development on the DASL specification. Lisa Dusseault has
volunteered to edit this specification, and I'm expecting a new draft from
her in the near future.

b) the addition of specialized REPORTs into protocol specifications, as
needed.

> Proposal: drop work on DASL.

I think this is a bad idea.  A general purpose search mechanism is necessary
to unlock the value of properties.

 Instead define an (extensible) equivalent of
> Publish this as separate RFC, or possibly move it into RFC2518++.

These look like a useful set of requirements for DASL.

- Jim

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 5 Oct 2001 19:39:02 +0200

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Jim
> Whitehead
> Sent: Friday, October 05, 2001 7:26 PM
> Subject: RE: [ACL] REPORT vs SEARCH
>
>
> Julian Reschke writes:
> ...
>

Yes, that is why I proposed to make DAV:basicsearch a REPORT.

> These look like a useful set of requirements for DASL.

I think you partly missed my point.

Both REPORT and SEARCH define frameworks for pluggable query grammars /
reports. I really can't see where the distinction between reports and
searches you made is reflected in the specs.

However, the framework for REPORT is already there (almost in RFC form), and
I think it's technically superior (regarding discovery of query grammars /
reports). So my proposal is to drop the DASL *framework* and re-use the one
used in REPORT, and to update / modify DAV:basicsearch to become a report.
By dropping the requirement to define a framework for SEARCH, we save a lot
of time that can be invested much better on the actual DAV:basicsearch
grammar.

If you disagree, I'd like to understand why we need the SEARCH framework
when we already have REPORT.

Regards, Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Fri, 5 Oct 2001 11:18:25 -0700

Thank you Dennis for taking the lead on the issue of property registration.
Your set of questions is excellent -- they made me think about several
issues I hadn't considered before, and do a good job of exposing the
complexity of property registration.

Let me take a whack at answering these questions to get discussion rolling.

> further information?

Yes to both. Registration identifies the property (its "name", which
includes its "namespace") and the human organization or person to contact
for further information.

>  The source is located by URI?  The source is located
> by non-Internet means?

Since *people*, often working within some organization, define properties, I
would expect the contact information to be a person, and their
organizational affiliation at the time they defined the property.

> Is it necessary to associate a property with some

I think it would be a good thing to identify which person or organization
has change control over the properties. In the case of a standards
development organization (SDO), it may be the case that a specific working
group developed a property, but the SDO as a whole has change control (since
the WG may go away long before the end of the lifetime of the property).

> 2.	Does the registration make available a definition of the
> property?  Is the definition amenable to human use?  Mechanical usage?
> Both?  In combination?  What purpose is served by making the definition
available?

In my view, the ultimate purpose of the registration is to enhance
interoperability of these properties. There are multiple consumers of
property information: system designers, end users, and computational agents
(i.e., programs, such as a client or server implementation). A good
definition satisfies all consumers.

There are a couple of aspects to each property definition:

* A human-readable description of the property contents ("what" does the
property contain?")
  ("The property will record the address of the copyright holder of the
resource")

* A human-readable description of some expected uses of the property ("why"
might someone use this property)

* The machine-readable syntax of the property. This includes the XML DTD, as
well as the syntax of the contents of each XML element and attribute used.
  ("The property MUST start with an <address> XML element, defined with the
following DTD, with the following sub-elements (and their definition) ...").

* The semantics and standard schemas used for the contents of the property.
  ("For addresses in the United States, the <state> XML element MUST have a
value that corresponds to one of the postal state codes defined in ...")
  ("The value of this field is unconstrained...")

* Is the property live or dead? Writeable or protected? ("how" does a client
interact with this property?)

* Does the property form part of a protocol?
  ("typically a client should write property X, then read property Y...")

It is my opinion that the current state of the art is not far enough
advanced that providing *only* a machine-readable definition of a property
is sufficient. That is, while a definition in a language like RDF Schema
would be helpful, if available, such a definition does not, by itself,
provide sufficient information to a client developer to understand and use
that property.

> 3.	Is the registration information submitted to third parties
> for retention and retrieval by anyone who chooses to discover the
> established use of the identified property?  Might it be found on
> WebDAV servers that support the property?

Registraion information should be submitted to an organization that is
expected to be long-lived (~25+ years) and that has, as part of their
mission, archival storage.

Property registration information should be retrievable by anyone on the
Internet without fee. Unless previously copyrighted, people submitting
property information should make it available under standard IETF copyright
policy.

Patents and copyrights that apply to properties themselves, or to the
contents of properties, should be noted in the registration of the property.

Just as most HTTP servers do not have a copy of RFC 2616 available on the
server, there should be no expectation that servers implementing a specific
property will have a copy of the registration information on that server.

> 4.	What groups of people (by rôle) are required to be able to
> create and> submit/register property-registration information?
> (This is distinct from being able to configure a server and/or
> client to support such a property.)

Anyone should be able to submit property registration information.

It woould be useful to have a low-overhead vetting process, to ensure that
property registrations are of reasonable quality, and address all issues.
MIME types in the vnd. tree are sent to a mailing list, and typically
receive feedback within a few days. The entire registration process
typically takes under two weeks.

> interacting with a DAV server that supports a particular property?

No.

> 2.	If a property can be set by a client (even if live), does
> the property registration provide
> equip a knowledgeable person, in conjunction with flexible client
> software, to be able to specify a value for the property that
> (i) will be accepted by the server and (ii) is appropriate in the
> context of the semantics of the property?

It should provide sufficient information that a developer, working from the
property description alone, can implement a client or server using the
property, and have reasonable assurance that their implementation will
interoperate with other implementations of the same property.

It should also provide sufficient information that an expert end-user, when
presented with the value of this property, can understand it.

> different native languages?

Well, in general I think we need to provide more guidance on i18n of
properties.

The best approach here would be to develop a specification giving guidance
on how to handle some common i18n scenarios with properties, and then have
the property registration identify which of the common mechanisms it is
using.

> 4.	How important is it to have the property-registration
> information provide sufficient information so that an user can
> intelligibly interpret a value for that property as presented
> by a flexible client?  (By flexible is meant a client that allows
> use of properties other than ones it was specifically designed
> to accommodate.)

It would be nice if the property registration gave some suggestions on how a
user interface should present the value of the property. This is especially
useful for properties with RDF values.

I believe the property registration should describe the property well enough
that an expert end-user can understand the value of the property. I'm shying
away from a more expansive definition that would be sufficient for "most"
end-users, since this might involve giving background tutorials on the
nature of metadata itself, background on the nature of the problem the
metadata schema is addressing, etc.

> 5.	What groups of people (by rôle) are required to be able to
> find and use property-registration information?

All developers and end-users should be able to find and use property
registration information, if they desire. However, the presentation of
property registration information should not be a requirement on
implementations.

I liken this to the RFC series. Developers are by far the primary consumers
of the specifications. But, it is often the case that sophisticated
end-users and students have an interest in reading the specifications to
have a deep understanding of the techology. Certainly no HTTP browser
provides the ability to read the HTTP specifications.

> 6.	Is property registration information to be attractive for
> configuration of a server to support the property (apart from
> mapping to an implementation and recognizing that no DAV server
> is required to support such an approach)?

Server configuration strikes me as out-of-scope, since it will vary widely
by server.

> 	a.	Should the property-registration information be in
> a structured, mechanically-processable form?

I view this as a bonus, not a requirement.

> 	b.	Must the property-registration information be
> easily rendered for human comprehension and review?

Yes. I view humans as the primary, and most important consumers of the
registration information.

> 	c.	Should property registrations be a resource type
> for storage in DAV itself?  An existing resource type?

I see no need to define a new MIME type, or DAV resource type for these
registrations.

> plain text, in files, and in simple serial data streams?
> Embedded in structured information?

I view this as being very unimportant.

- Jim

---

From: "Jim Whitehead" <[email-masked]>
Date: Fri, 5 Oct 2001 11:55:42 -0700

> searches you made is reflected in the specs.

Many design considerations never make it into specifications.

> However, the framework for REPORT is already there (almost in RFC
> form)

For the case of DAV:basicsearch, this doesn't count for much.  The
definition of the "SEARCH" method is not the difficult part of DASL. The
core complexity comes from specifying the search grammar, and  correctly
specifying how to do an i18n ordering of search results. These complexities
are these whether you use REPORT or SEARCH.

>, and I think it's technically superior (regarding discovery
> of query grammars / reports).

Huh?

REPORT tells you what reports are available via DAV:supported-report-set.

DASL tells you what search grammars are available via the DASL response
header.

These are equivalent in expressive power.

> So my proposal is to drop the DASL *framework* and  re-use the one

This isn't a shift of framework, it's a shift of marshalling mechanism,
REPORT vs. SEARCH, DAV:supported-report-set vs. OPTIONS and the DASL header.

> when we already have REPORT.

While I will freely admit that you *could* marshall DAV:basicsearch using
REPORT, here are my reasons for why I think you should have both REPORT and
SEARCH:

- Reports have very specialized and limited query specifications. Search
grammars are expected to be much more complex (DAV:basicsearch, XML query,
Z39.50, etc.)

- Reports have a reasonable expectation of being specified in XML. Queries
submitted using SEARCH may not be.

- Error reporting mechanisms for REPORT may not be appropriate for SEARCH.
In particular, it may not be safe to assume that returning an XML tag in the
body is OK for all search grammars, yet this is the current case for REPORT.

- REPORT is currently limited to using the Depth mechanism for scoping.
While this is also the current case for DASL, I believe that DASL will need
to provide a definition for how to perform a "server"-wide search.
Separating the two will free DASL to develop better scoping rules.

- Some queries grammars using DASL may not even require DAV extensions to be
present. For example, XML query via DASL should reasonably work against both
HTTP+DAV+DASL servers and plain HTTP+DASL servers. REPORT is intimately tied
to the DAV object model (it requires properties).

Basically, these all boil down to a separation of concerns argument. By
separating REPORT and SEARCH, you allow each to more precisely meet their
respective requirements.

- Jim

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 5 Oct 2001 21:19:11 +0200

> [mailto:[email-masked]]On Behalf Of Jim Whitehead
> Sent: Friday, October 05, 2001 8:56 PM

Not really.

a) DASL defines an HTTP header, so it occupies a token in the HTTP
namespace, while DAV:supported-report-set is only visible to clients
issueing WebDAV requests (so we don't unnecessarily occupy a place in
somebody else's namespace),

b) The way OPTIONS is defined in DASL, you can't use the header information
to *directly* identify which grammars available. The way it's defined for
DAV:basicsearch *only* works because DAV: happens to be the prefix and the
namespace name at the same time. Given a DASL header of

<http://www.greenbytes.de/tech/webdav/simplepropertyseach>

what is the name of the grammar (so how do you *generally* split the
namespace from the grammar name?).

> REPORT vs. SEARCH, DAV:supported-report-set vs. OPTIONS and the

Fine with me :-)

> grammars are expected to be much more complex (DAV:basicsearch, XML query,

*The currently defined* reports: yes. But why should this restrict us in
what new reports we define?

And why do we need two frameworks if the one we have can do everything we
need?

> submitted using SEARCH may not be.

Can you back that up by anything which is either in ACL, deltaV or DASL?

> body is OK for all search grammars, yet this is the current case

"If an error occurred that prevented execution of the query, the server MUST
indicate the failure with the appropriate status code and SHOULD include a
DAV:multistatus element to point out errors associated with scopes."

OK, so why is this "should" rather than "must"? Do we really non-XML based
query protocols?

> Separating the two will free DASL to develop better scoping rules.

Interesting, but this isn't really an argument in favor for SEARCH.

> to the DAV object model (it requires properties).

Where does it require properties?

I see your point that SEARCH can be something separate from WebDAV. Is this
a purely theoretical requirement, or did somebody specifically ask for it?

While I link DAV:supported-report-set, grammar discovery could also be done
through REPORT itself (it would be just another report, so it wouldn't have
to rely on PROPFIND).