Subject: I-D ACTION:draft-ietf-webdav-propfind-space-00.txt

From: [email-masked]
Date: Fri, 17 Sep 1999 08:03:14 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF.

	Title		: WebDAV PROPFIND Extension To List Specified Namespaces
	Author(s)	: J. Stracke
	Filename	: draft-ietf-webdav-propfind-space-00.txt
	Pages		: 6
	Date		: 16-Sep-99
	
This document specifies an extension to the [WEBDAV] PROPFIND method 
to permit a WebDAV client to request all properties which belong to a
specified namespace or namespaces.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-propfind-space-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-webdav-propfind-space-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-webdav-propfind-space-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Greg Stein <[email-masked]>
Date: Fri, 17 Sep 1999 16:47:45 -0700

> specified namespace or namespaces.

This is quite cool, and mod_dav could easily support something like
this.

Just a few comments:

* rather than specifying the uri as an XML attribute, shouldn't it be
part of the elem contents? [I think I saw an argument somehwere (by
Yaron?) that stated is was "best form" to avoid attributes that are
specifiers, rather than modifiers]

* do you want to explicitly state that <DAV:namespaces> can only appear
as a child of <DAV:allprop> and <DAV:propname> ?

* your sample request in 5.2 has the propname/propfind end-elements
swapped.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

---

From: John Stracke <[email-masked]>
Date: Mon, 20 Sep 1999 11:41:23 -0400

> specifiers, rather than modifiers]

Mmm...yes, OK, that makes sense.  Do you think <DAV:namespace> should contain the URI directly, or
contain <DAV:href>? The former reduces bandwidth & complexity by a tiny amount; the latter leverages the
existing definitions better.

> as a child of <DAV:allprop> and <DAV:propname> ?

Yes, that makes sense.  Here's my new text:

     Purpose: The namespaces XML element introduces a set of namespace elements (below).
     <namespaces> appears inside <allprop> or <propname>, and specifies that the PROPFIND request
     applies only to properties belonging to the namespaces listed in the enclosed namespace
     elements.

> * your sample request in 5.2 has the propname/propfind end-elements

Whoops, so it does.  Fixed.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Peace, justice, morality, culture, family,   |
[email-masked]|sport, and the extinction of all other life  |
|                |forms!                                       |
\==============================================================/

---

From: Greg Stein <[email-masked]>
Date: Mon, 20 Sep 1999 18:24:09 -0700

> existing definitions better.

The namespace is a URI. I believe an href is typically a URL (certainly
"href" connotes this meaning).

So... I would recommend that it just directly contains the URI rather
than yet-another-element.

Cheers,
-g

---

From: John Stracke <[email-masked]>
Date: Tue, 21 Sep 1999 09:35:23 -0400

> "href" connotes this meaning).

<dig, dig>...the DAV spec says "URI".

> than yet-another-element.

This was the way I was leaning, too.  The main question that made me wonder was, suppose someone wants to
define a type of namespace that's defined by something other than a URI? (In such a case, it might be best to
be able to swap out the <href> element for something else.) However, I think the answer is that they should
just define a new URI scheme.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |When rats leave a sinking ship, where exactly do|
[email-masked]|they think they're going?                       |
\=================================================================/