From w3c-dist-auth-request@www10.w3.org  Fri Jan  1 10:58:10 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA24873
	for <w3c-dist-auth@www19.w3.org>; Fri, 1 Jan 1999 10:58:10 -0500 (EST)
Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id KAA13612
	for <w3c-dist-auth@w3.org>; Fri, 1 Jan 1999 10:58:10 -0500 (EST)
Received: from severy (1Cust149.tnt1.damascus.md.da.uu.net [153.35.150.149])
	by swan.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id HAA00284;
	Fri, 1 Jan 1999 07:58:07 -0800 (PST)
Message-Id: <199901011558.HAA00284@swan.prod.itd.earthlink.net>
X-Sender: severy@mail3.pair.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Fri, 01 Jan 1999 10:57:04 -0500
To: Yaron Goland <yarong@microsoft.com>
>From: Randall Severy <severy@cyberteams.com>
Cc: w3c-dist-auth@w3.org, webdav-list@cyberteams.com
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792C2B@RED-MSG-59>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: New CyberTeams WebDAV Mailing List

At 01:45 PM 12/31/98 -0800, you wrote:
>... the general consensus was that the WG would very
>much like to encourage implementers to not set up separate mailing lists to
>discuss the specifics of their interoperability tests.
>...
>As such I would like to ask CyberTeams to please consider directing people
>to the main WebDAV mailing list for the purpose of discussing
>interoperability and other protocol specific issues associated with
>CyberTeams WebDAV implementation.
>
Yaron,

      My apologies.  I was not aware of that consensus when I set up the
CyberTeams WebDAV list.  We will keep our new mailing list around for
discussing issues with our WSDLite software that are not related to the
WebDAV interoperability testing.  We will direct people to the main WebDAV
mailing list for any discussions related to interoperability testing or the
WebDAV protocol itself.  If a message is posted to our webdav-list that
pertains to interoperability testing or the WebDAV protocol, we'll repost
it to the main WebDAV mailing list.  I have modified the "welcome" message
for our mailing list as follows:

---------------------------------------------------------------------------
          Welcome to the CyberTeams WebDAV Server Mailing List!

This list is used for discussions about the CyberTeams WebDAV Test Site
and problem reports, suggestions, feedback, or ideas about WebSite Director
Lite and any other products in the CyberTeams product line.  This list
should NOT be used for discussions about interoperability testing between
WebDAV clients and the CyberTeams WebDAV server.  For those discussions
and other issues specific to the WebDAV protocol, please use the IETF
WebDAV Working Group mailing list at:

                           w3c-dist-auth@w3.org

If you are not subscribed to the w3c-dist-auth mailing list, you can
subscribe by sending a message with "Subject: subscribe" to:

                       w3c-dist-auth-request@w3.org

Your subscription address for the CyberTeams WebDAV Server Mailing List
will be kept completely confidential and will not be disclosed to anyone
outside of CyberTeams.  For more information about the CyberTeams WebDAV
Test Site, go to the following web page:

                      http://www.cyberteams.com/webdav

To send a message to this mailing list, send it to the following address:

                         webdav-list@cyberteams.com

If you have any problems with this list or wish to unsubscribe from the
list, send a message to "listmaster@cyberteams.com".
---------------------------------------------------------------------------

     Does that cover what you had in mind?

Cheers......     Randall


Randall Severy    severy@cyberteams.com    http://www.cyberteams.com/severy
CyberTeams, Inc.    info@cyberteams.com    http://www.cyberteams.com
Mt. Airy, MD
(301) 829-6144          "Building effective teams in cyberspace"
1-888-832-5575


From w3c-dist-auth-request@www10.w3.org  Fri Jan  1 17:37:32 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA27289
	for <w3c-dist-auth@www19.w3.org>; Fri, 1 Jan 1999 17:37:32 -0500 (EST)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id RAA14534
	for <w3c-dist-auth@w3.org>; Fri, 1 Jan 1999 17:37:31 -0500 (EST)
Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <Z7CCXG22>; Fri, 1 Jan 1999 14:37:30 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792C3B@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Randall Severy'" <severy@cyberteams.com>
Cc: w3c-dist-auth@w3.org, webdav-list@cyberteams.com
Date: Fri, 1 Jan 1999 14:37:30 -0800 
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: New CyberTeams WebDAV Mailing List

No apologies necessary. You did everything right. No one expects you to hang
out in a room in Florida listening to arguments about the latest extensions
to WebDAV. The meeting notes only came out this week and if memory serves
they didn't include a note about the discussion on the topic of mailing
lists. So there was absolutely no way for you to know.

By setting up your mailing list and by making your server available for
public testing you have nothing but the thanks of the entire WebDAV
community. It is acts like yours that make open standards work.

			Thank You,
					Yaron

> -----Original Message-----
> From: Randall Severy [mailto:severy@cyberteams.com]
> Sent: Friday, January 01, 1999 7:57 AM
> To: Yaron Goland
> Cc: w3c-dist-auth@w3.org; webdav-list@cyberteams.com
> Subject: RE: New CyberTeams WebDAV Mailing List
> 
> 
> At 01:45 PM 12/31/98 -0800, you wrote:
> >... the general consensus was that the WG would very
> >much like to encourage implementers to not set up separate 
> mailing lists to
> >discuss the specifics of their interoperability tests.
> >...
> >As such I would like to ask CyberTeams to please consider 
> directing people
> >to the main WebDAV mailing list for the purpose of discussing
> >interoperability and other protocol specific issues associated with
> >CyberTeams WebDAV implementation.
> >
> Yaron,
> 
>       My apologies.  I was not aware of that consensus when I 
> set up the
> CyberTeams WebDAV list.  We will keep our new mailing list around for
> discussing issues with our WSDLite software that are not 
> related to the
> WebDAV interoperability testing.  We will direct people to 
> the main WebDAV
> mailing list for any discussions related to interoperability 
> testing or the
> WebDAV protocol itself.  If a message is posted to our 
> webdav-list that
> pertains to interoperability testing or the WebDAV protocol, 
> we'll repost
> it to the main WebDAV mailing list.  I have modified the 
> "welcome" message
> for our mailing list as follows:
> 
> --------------------------------------------------------------
> -------------
>           Welcome to the CyberTeams WebDAV Server Mailing List!
> 
> This list is used for discussions about the CyberTeams WebDAV 
> Test Site
> and problem reports, suggestions, feedback, or ideas about 
> WebSite Director
> Lite and any other products in the CyberTeams product line.  This list
> should NOT be used for discussions about interoperability 
> testing between
> WebDAV clients and the CyberTeams WebDAV server.  For those 
> discussions
> and other issues specific to the WebDAV protocol, please use the IETF
> WebDAV Working Group mailing list at:
> 
>                            w3c-dist-auth@w3.org
> 
> If you are not subscribed to the w3c-dist-auth mailing list, you can
> subscribe by sending a message with "Subject: subscribe" to:
> 
>                        w3c-dist-auth-request@w3.org
> 
> Your subscription address for the CyberTeams WebDAV Server 
> Mailing List
> will be kept completely confidential and will not be 
> disclosed to anyone
> outside of CyberTeams.  For more information about the 
> CyberTeams WebDAV
> Test Site, go to the following web page:
> 
>                       http://www.cyberteams.com/webdav
> 
> To send a message to this mailing list, send it to the 
> following address:
> 
>                          webdav-list@cyberteams.com
> 
> If you have any problems with this list or wish to 
> unsubscribe from the
> list, send a message to "listmaster@cyberteams.com".
> --------------------------------------------------------------
> -------------
> 
>      Does that cover what you had in mind?
> 
> Cheers......     Randall
> 
> 
> Randall Severy    severy@cyberteams.com    
> http://www.cyberteams.com/severy
> CyberTeams, Inc.    info@cyberteams.com    http://www.cyberteams.com
> Mt. Airy, MD
> (301) 829-6144          "Building effective teams in cyberspace"
> 1-888-832-5575
> 


From w3c-dist-auth-request@www10.w3.org  Fri Jan  1 17:54:03 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA27449
	for <w3c-dist-auth@www19.w3.org>; Fri, 1 Jan 1999 17:54:03 -0500 (EST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id RAA14583
	for <w3c-dist-auth@w3.org>; Fri, 1 Jan 1999 17:54:02 -0500 (EST)
Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <Z7CB8ZXA>; Fri, 1 Jan 1999 14:54:01 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792C3C@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Larry Masinter'" <masinter@parc.xerox.com>,
        "'Jim Davis'"
	 <jdavis@parc.xerox.com>, w3c-dist-auth@w3.org
Date: Fri, 1 Jan 1999 14:54:01 -0800 
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Don't copy live properties

This one isn't easy. 

As I discussed previously
(http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html), it
is my personal opinion that the reasons for live properties have to do with
performance issues with HTTP. 

It made us do something that I now believe has very serious ramifications on
the ability of people to innovate using HTTP and upon the future
extensibility of the protocol.

So how does one make the trade off? Until we fix HTTP I guess the answer is
fairly obvious. Who cares if you have a perfect protocol if no one can
efficiently implement it?

Maybe we will fix this next time. In the meantime, if I was designing a
WebDAV extension I would do my best to stay away from using properties. 

	If you can't, you can't. 

		But I bet in most cases, you can.

				Yaron

> -----Original Message-----
> From: Larry Masinter [mailto:masinter@parc.xerox.com]
> Sent: Thursday, December 31, 1998 6:31 PM
> To: Yaron Goland; 'Jim Davis'; w3c-dist-auth@w3.org
> Subject: RE: Don't copy live properties
> 
> 
> I think the way out of the live property quandary is not to try to
> overspecify server behavior, but rather, to reduce client dependence
> on server behavior.
> 
> Despite the useful goal of wanting server predictability, you
> might not always accomplish it, and it's not a goal that
> requires you to be uncompromising about it.
> 
> I don't think it is possible to specify server behavior on COPY
> when applied to live properties. So I think the standard should
> say that it is unspecified. It's not required, it's not outlawed,
> it's just unspecified. Clients shouldn't depend on it.
> 
> Similarly, for all of the reasons given for inventing live
> properties in the first place, don't think it is a good idea
> to "outlaw" live properties. However, interoperable
> clients shouldn't depend on them.
> 
> Larry
> -- 
> http://www.parc.xerox.com/masinter
> 


From w3c-dist-auth-request@www10.w3.org  Sun Jan  3 16:53:00 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA01735
	for <w3c-dist-auth@www19.w3.org>; Sun, 3 Jan 1999 16:53:00 -0500 (EST)
Received: from pm02sm.pmm.cw.net (pm02sm.pmm.cw.net [208.159.126.151])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id QAA22238
	for <w3c-dist-auth@w3.org>; Sun, 3 Jan 1999 16:52:58 -0500 (EST)
Received: from galileo (usr31-dialup23.mix2.Boston.cw.net [166.55.74.151])
 by PM02SM.PMM.CW.NET (PMDF V5.2-29 #33506)
 with SMTP id <0F5000GNI7EUDX@PM02SM.PMM.CW.NET> for w3c-dist-auth@w3.org; Sun,
  3 Jan 1999 21:52:57 +0000 (GMT)
Date: Sun, 03 Jan 1999 16:52:22 -0500
>From: Jim Whitehead <ejw@ics.uci.edu>
In-reply-to: <000701be352e$c5d6a9a0$aa66010d@copper.parc.xerox.com>
To: w3c-dist-auth@w3.org
Reply-to: ejw@ics.uci.edu
Message-id: <000801be3763$57d947a0$a42039cc@galileo>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Subject: RE: Don't copy live properties


Larry Masinter writes:
> I don't think it is possible to specify server behavior on COPY
> when applied to live properties. So I think the standard should
> say that it is unspecified. It's not required, it's not outlawed,
> it's just unspecified. Clients shouldn't depend on it.

This suggests to me that the behavior of a live property on COPY is a
quality of the property, rather than a quality of the server.  Hence, the
COPY behavior of a live property should be specified on a per-property
basis.  The discussion so far has effectively shown the COPY behavior for
all live properties is not a quality of the server.

Larry Masinter writes:
> Similarly, for all of the reasons given for inventing live
> properties in the first place, don't think it is a good idea
> to "outlaw" live properties. However, interoperable
> clients shouldn't depend on them.

The discussion has assumed there are two kinds of live properties,
"standard" and "non-standard".  There is a third class: those which are
registered (via an, as-yet unspecified, registration process) with a
concrete description of their syntax and semantics.  Lisa Lippert's
presentation in Orlando on a class of new live properties suggests to me
that such a registration process is necessary.

Registered properties will allow for interoperation, since client/server
pairs can implement the property according to the same semantics, yet not
require the effort required to create community consensus around a set of
properties.

> However, interoperable clients shouldn't depend on them.

Agreed.

Jim Davis writes:
> Finally, I doubt the distinction between descriptive and operational can
be
> formallized well enough that we could standardize it.

I agree.  Is the "DAV:getetag" property descriptive or operational?
Furthermore, many of the properties that Lisa Lippert described are
qualities of the collection's contents (the list of its children) such as
hassubs and childcount.

Larry Masinter writes:
> I'm suggesting that we declare client dependence on non-standard
operational
> live properties as "bad design" and declare such dependence as
> non-conformant.

This seems too restrictive to me.  HTTP had a similar danger -- you could be
100% compliant, yet dependent on non-standard HTTP methods.  This was not a
major operational problem in practice.

- Jim





From w3c-dist-auth-request@www10.w3.org  Sun Jan  3 22:22:44 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA04106
	for <w3c-dist-auth@www19.w3.org>; Sun, 3 Jan 1999 22:22:43 -0500 (EST)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id WAA23383
	for <w3c-dist-auth@w3.org>; Sun, 3 Jan 1999 22:22:42 -0500 (EST)
Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <52392(1)>; Sun, 3 Jan 1999 19:22:34 PST
Received: from copper.parc.xerox.com ([13.0.208.21]) by thelma.parc.xerox.com with SMTP id <98221>; Sun, 3 Jan 1999 19:22:28 PST
>From: "Larry Masinter" <masinter@parc.xerox.com>
To: <ejw@ics.uci.edu>, <w3c-dist-auth@w3.org>
Date: Sun, 3 Jan 1999 19:22:27 PST
Message-ID: <000101be3791$74357a80$15d0000d@copper.parc.xerox.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <000801be3763$57d947a0$a42039cc@galileo>
Subject: RE: Don't copy live properties

> This seems too restrictive to me.  HTTP had a similar danger -- 
> you could be 100% compliant, yet dependent on non-standard
> HTTP methods.  This was not a major operational problem in
> practice.

Uhhhhh....

If this wasn't a major operational problem, why didn't we just
close the working group and use FrontPage extensions?


From w3c-dist-auth-request@www10.w3.org  Tue Jan  5 17:40:07 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA16937
	for <w3c-dist-auth@www19.w3.org>; Tue, 5 Jan 1999 17:40:07 -0500 (EST)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id RAA12254
	for <w3c-dist-auth@w3.org>; Tue, 5 Jan 1999 17:40:06 -0500 (EST)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42])
	by netscape.com (8.8.5/8.8.5) with ESMTP id OAA08151
	for <w3c-dist-auth@w3.org>; Tue, 5 Jan 1999 14:40:04 -0800 (PST)
Received: from netscape.com ([208.12.58.40]) by tintin.mcom.com
          (Netscape Messaging Server 4.0) with ESMTP id F53YYS00.RRM; Tue,
          5 Jan 1999 14:40:04 -0800 
Sender: francis@netscape.com (John Stracke)
Message-ID: <369294C3.82C2C91F@netscape.com>
Date: Tue, 05 Jan 1999 14:40:04 -0800
>From: John Stracke <francis@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 4.5 [en] (X11; U; IRIX 6.2 IP22)
X-Accept-Language: en
MIME-Version: 1.0
To: WebDAV WG <w3c-dist-auth@w3.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by www19.w3.org id RAA16937
Subject: Leaving Netscape, sticking with DAV

FYI, I'm leaving Netscape; as of the 18th (or earlier), my
email address will be francis@appoint.net.  My new employers
have agreed to let me remain active in the DAV WG, but I
will not have time for the versioning design team.

I do not think Netscape will be sending anybody to replace
me in the working group--at least, I haven't heard anything
so far.

--
/======================================================================\
|John (Francis) Stracke    |My opinions are my own.| S/MIME supported  |
|Software Retrophrenologist|===========================================|
|Netscape Comm. Corp.      |Id est fabula nostra, et non mutabimus eam!|
|francis@netscape.com      | --House Falconguard and Affiliated Scum   |
\======================================================================/



From w3c-dist-auth-request@www10.w3.org  Tue Jan  5 18:07:27 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA17385
	for <w3c-dist-auth@www19.w3.org>; Tue, 5 Jan 1999 18:07:27 -0500 (EST)
Received: from NIH2WAAE (smtp5.site1.csi.com [149.174.183.74])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id SAA12580
	for <w3c-dist-auth@w3.org>; Tue, 5 Jan 1999 18:07:26 -0500 (EST)
Received: from mail pickup service by csi.com with Microsoft SMTPSVC;
	 Tue, 5 Jan 1999 18:07:14 -0500
Sender: nicholas@synarchy.net
Received: from synarchy.net ([195.232.124.15] (may be forged))
	by hil-img-ims-2.compuserve.com (8.8.6/8.8.6/IMS-1.6) with ESMTP id SAA05363;
	Tue, 5 Jan 1999 18:06:10 -0500 (EST)
Message-ID: <369299E1.9C4571D4@synarchy.net>
Date: Tue, 05 Jan 1999 23:01:53 +0000
>From: Nicholas Roberts <nicholas@synarchy.net>
Organization: Synarchy Networks
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: John Stracke <francis@netscape.com>
CC: WebDAV WG <w3c-dist-auth@w3.org>
References: <369294C3.82C2C91F@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Leaving Netscape, sticking with DAV

does this signal a trend from Netscape: it will be not so active in the
exploration/development of the W3C projects?

John Stracke wrote:
> 
> FYI, I'm leaving Netscape; as of the 18th (or earlier), my
> email address will be francis@appoint.net.  My new employers
> have agreed to let me remain active in the DAV WG, but I
> will not have time for the versioning design team.
> 
> I do not think Netscape will be sending anybody to replace
> me in the working group--at least, I haven't heard anything
> so far.
> 
> --
> /======================================================================\
> |John (Francis) Stracke    |My opinions are my own.| S/MIME supported  |
> |Software Retrophrenologist|===========================================|
> |Netscape Comm. Corp.      |Id est fabula nostra, et non mutabimus eam!|
> |francis@netscape.com      | --House Falconguard and Affiliated Scum   |
> \======================================================================/

-- 
Nicholas Roberts
mailto:nicholas@synarchy.net
+44(0)181 960 8931
Synarchy Universalis Ltd
http://synarchy.net/
London UK

--
'In the lightless abyss, many creatures carry 
constellations of luminous organs.' 
				
A. C. Clarke



From w3c-dist-auth-request@www10.w3.org  Tue Jan  5 18:21:36 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA17889
	for <w3c-dist-auth@www19.w3.org>; Tue, 5 Jan 1999 18:21:36 -0500 (EST)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id SAA12750
	for <w3c-dist-auth@w3.org>; Tue, 5 Jan 1999 18:21:35 -0500 (EST)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42])
	by netscape.com (8.8.5/8.8.5) with ESMTP id PAA11471
	for <w3c-dist-auth@w3.org>; Tue, 5 Jan 1999 15:21:34 -0800 (PST)
Received: from netscape.com ([208.12.58.40]) by tintin.mcom.com
          (Netscape Messaging Server 4.0) with ESMTP id F540VY00.TRL for
          <w3c-dist-auth@w3.org>; Tue, 5 Jan 1999 15:21:34 -0800 
Sender: francis@netscape.com (John Stracke)
Message-ID: <36929E7E.6A5B533D@netscape.com>
Date: Tue, 05 Jan 1999 15:21:34 -0800
>From: John Stracke <francis@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 4.5 [en] (X11; U; IRIX 6.2 IP22)
X-Accept-Language: en
MIME-Version: 1.0
To: WebDAV WG <w3c-dist-auth@w3.org>
References: <369294C3.82C2C91F@netscape.com> <369299E1.9C4571D4@synarchy.net>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by www19.w3.org id SAA17889
Subject: Re: Leaving Netscape, sticking with DAV

Nicholas Roberts wrote:

> does this signal a trend from Netscape: it will be not so active in the

I have no idea.  Anyway, I do not speak for Netscape.

> exploration/development of the W3C projects?

(Note that DAV is not a W3C effort.)

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      | Veni, Vidi, Ridi:                       |
|francis@netscape.com      |  I came, I saw, I mocked.               |
\====================================================================/



From w3c-dist-auth-request@www10.w3.org  Wed Jan  6 10:52:41 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA26782
	for <w3c-dist-auth@www19.w3.org>; Wed, 6 Jan 1999 10:52:41 -0500 (EST)
Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id KAA19170
	for <w3c-dist-auth@w3.org>; Wed, 6 Jan 1999 10:52:40 -0500 (EST)
Received: from crthub.crt.xerox.com (crthub.crt.xerox.com [13.138.80.3])
	by pasiphae.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id KAA01375
	for <w3c-dist-auth@w3.org>; Wed, 6 Jan 1999 10:52:39 -0500 (EST)
Received: by crthub.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <CJNRVKS1>; Wed, 6 Jan 1999 10:52:38 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76D54@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
Date: Wed, 6 Jan 1999 10:52:36 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Notes from WebDAV Collections Breakout Session

Here are my notes from the Collections Breakout Session at the Orlando IETF:

The breakout session on advanced collections discussed several issues
related to referencing: (1) whether we need to provide backpointers from
target resources to the references that point to them, (2) whether we should
reconsider our earlier decision to exclude referential integrity from our
scope, (3) how to allow clients to operate on references as well as on their
targets, (4) whether we really need both direct and redirect references, (5)
whether to drop a requirement to be able to hide the location of a target
resource, and (6) the relationship between the versioning spec and
referencing.

Attending:
 
Jim Whitehead (University of California / Irvine)
Judy Slein (Xerox)
Ken Coar (IBM, Apache)
Manoj Kasichainula (IBM, Apache)
Geoff Clemm (Rational - ClearCase)
Yuri Demchenko (TERENA)

BACKPOINTERS

There has been a lot of controversy about whether to expose in the protocol
a property (DAV:references) that lists the references to a given resource.
An alternative is to perform a DASL search for resources that have
DAV:reftarget equal to the URI of the resource in question.  (Since
DAV:reftarget is a structured property, this strategy is only possible if
DASL includes search on structured properties.)

Performance considerations are not decisive between the two strategies.
Search could be efficient.  This particular query could be optimized to
examine a property (not exposed through the protocol).  A DAV:references
property might be implemented as a list, or might be computed on the fly by
scanning the file system.

Clients need to know whether the search will be optimized before they
request the search.  There is no way to find out.  DASL does include a
mechanism for clients to limit the resources a server spends on a given
query.

Clients need to know whether the property is computed on the fly before
requesting it.  There is no way to find out.  The impact of computing on the
fly is especially significant when a client requests allprop.  There may be
other properties that are computed on the fly as well.  DAV:getetag is
computed, and some versioning history properties may also be computed.

We could include an implementation note for clients, warning them not to
assume that examining DAV:references will be more efficient that searching
on DAV:reftarget.
 
We could include an implementation note for servers, warning them to use
computed properties with care, because of their potential impact on allprop.
Servers that are built on file systems may be unable to provide
backpointers.  In a Unix environment, if references are aliases it is easy
to discover the references to a given resource; but if references are
symbolic links it is difficult or impossible.  Servers that are based on
file systems are unlikely to implement backpointers.

>From a client's point of view, since many servers will not provide
backpointers, only advanced clients will take advantage of them. Clients
that are tailored for use with document management systems are the most
likely to make use of backpointers.
  
DAV:references includes both direct and redirect references to the target
resource.
 
Systems that provide strong references (e.g., systems that provide versioned
collections) use backpointers internally to keep DAV:reftargets up to date.
Users do want to be able to find out which versions and collections ever
contained this resource.
  
Versioned collections need backpointers.  If backpointers are not provided
in the collections protocol spec, the versioning spec will extend the
semantics of some sort of reference to get this functionality.
 
Conclusion: The attendees favor a DAV:references property, optional at the
resource level.  There should be an implementation note addressed to
servers: Be cautious about implementing DAV:references as a computed
property, because of the possible impact of computation on allprop.  Be
clear about the semantics of DAV:references: when it gets created, deleted,
and updated.  If servers do implement backpointers, we want them to use the
same name for the property, and the same semantics.

STRONG REFERENCES
 
Geoff Clemm is interested in reopening the issue of strong references.  He
believes that support for strong references may not require much more than
backpointers. He believes that strong references will be important for
versioning / configuration management systems.  If the collections spec does
not provide strong references, the versioning spec may have to.

Geoff will send a mailnote on this subject at least to the attendees of this
meeting.
  
We need to try to recreate and capture for the record the considerations
that led to ruling strong references out of scope in the first place.

RE-DIRECT VS. NO-PASSTHROUGH HEADER

The new Re-Direct header applies only to direct references, and makes them
behave like redirect references just for the request that includes the
Redirect header.  It asks the server to apply the request to the reference
itself, rather than to its target.

Jim Whitehead suggests that we really need a header like this for both
redirect and direct references.

At the moment the collections spec requires servers to respond to HTTP
requests on redirect references with a 302.  This makes it possible for
plain HTTP clients to take advantage of redirect references.  In fact, we
should require servers to respond with a 302 to WebDAV requests as well as
to HTTP requests, so that non-referencing WebDAV clients can take advantage
of redirect references.   Once we have made this change, there is no way to
operate on the redirect reference itself.
  
So we need a header that can be applied to both redirect and direct
references, asking the server to apply the request to the reference itself,
not to its target.  Let's call it No-Passthrough.  The more common case is
for the client to want the request to be applied to the target.  So the
header will just be used for the less common case.

REDIRECT + DIRECT

Judy Slein asked whether we really need both redirect and direct references.
They started out being very different from each other.  In the first draft,
redirect references were just resources with no content and a DAV:reftarget
property that a client could retrieve to locate the target resource, and
then perform operations on that resource.   But over time redirect and
direct references have become more similar.  First the semantics of redirect
references changed to accommodate plain HTTP clients: responses to HTTP
requests got a 302 response accompanied by the DAV:reftarget property in the
Location header.  Now if we take Jim Whitehead's advice, all requests on
redirect references will use this semantics, so that non-referencing WebDAV
clients can be accommodated.  For both direct and redirect references, if
the client wants to operate on the reference itself, it must use the
No-Passthrough header.  At this point, is the distinction between redirect
and direct references significant?

There is still an important difference in the difficulty of the server
implementation.  We need redirect references for cases where the target is
on a different server from the reference.  Direct references could not work
across servers unless the server had proxy capabilities or used some
server-to-server protocol.
 
We might want to let direct references respond with 302 if the target is on
a different server.

The direct / redirect distinction mirrors Apache's internal / external
redirects.  Both are useful.
 
We may want redirect references to allow clients to update their tables. 
Conclusion: We need both redirect and direct references.
  
DELETE, MOVE, AND COPY

Delete and move are special cases.  They always get applied to the
reference, not to its target.  Why?
 
They amount to editing the collection containing the reference, not the
object being referenced.   In some systems performing a delete or a move
only requires a permission on the directory, not on the object.  This is a
common semantics.  It is Unix semantics.

MOVE: We need to define the semantics for what happens to the backpointers
when a reference gets moved.
 
What about MOVE requests from non-referencing clients?  Should these
requests ever result in the target being moved?  Would you ever want to do
move with pass-through?  In many systems it would be literally wrong to do a
move with pass-through semantics.  We don't want other references to the
target to get broken.  We should not allow a pass-through move.
 
Conclusion: Stay with the status quo - DELETE, MOVE, and COPY are always
applied to the reference, never to its target.
 
HIDING THE TARGET
 
The requirement to be able to hide the location of a target resource was
motivated by a scenario.  Sue has a collection full of highly confidential
information.  She doesn't want anyone to know about it.  But she needs to
give Tom access to one resource in the collection to get his comments on it.
So she would like to create a reference to it for him, but prevent him from
knowing the location where it and all the other confidential resources
reside.
  
Another motivation: Tilde-name directories provide point of attack by
revealing a user name.

This is "security through obscurity."  Security through obscurity is rarely
the right answer.
  
Don't keep things in directory structures that reveal information you want
to hide.

If we have access control, we don't need this.  We would need access control
on properties, so that we could prevent clients from seeing DAV:reftarget.  
In any case, this is not very important.  The security exposure is limited. 
We can add this capability later if it really looks as if people want it.
Wait and see whether people implement it with properties.

Add a discussion of the risk to security considerations rather than add a
header.
  
Conclusion: Drop the requirement that it be possible to hide the location of
a target resource.

VERSIONING AND REFERENCES

Versioning of collections is being implemented on top of referencing.

Judy Slein requests that before extensions to referencing capabilities are
put into the versioning spec, the team consider whether they would be more
generally useful.  If so, they should be added to the collections
(referencing) spec instead.

Do we need to extend the syntax of DAV:reftarget, to allow it to contain
more than just a URL?  Versioning may need it to include the URL of a
version graph, together with information about which member of the graph to
select.
 
We may want to make the syntax of DAV:reftarget extensible by using
attribute-value pairs. The Ref-Target header would also have to become more
flexible, and might need to be incorporated in an xml body.

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580


From w3c-dist-auth-request@www10.w3.org  Wed Jan  6 15:52:15 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA02922
	for <w3c-dist-auth@www19.w3.org>; Wed, 6 Jan 1999 15:52:14 -0500 (EST)
Received: from snipe.prod.itd.earthlink.net (snipe.prod.itd.earthlink.net [207.217.120.62])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id PAA22875
	for <w3c-dist-auth@w3.org>; Wed, 6 Jan 1999 15:52:13 -0500 (EST)
Received: from severy (1Cust214.tnt1.damascus.md.da.uu.net [153.35.150.214])
	by snipe.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id MAA24492
	for <w3c-dist-auth@w3.org>; Wed, 6 Jan 1999 12:52:06 -0800 (PST)
Message-Id: <199901062052.MAA24492@snipe.prod.itd.earthlink.net>
X-Sender: severy@mail3.pair.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 06 Jan 1999 15:50:37 -0500
To: w3c-dist-auth@w3.org
>From: "Robert Barham" <RBarham@GW.Novell.com> (by way of Randall Severy <severy@cyberteams.com>)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Using Office 2000

Date: Wed, 06 Jan 1999 13:27:17 -0700
>From: "Robert Barham" <RBarham@GW.Novell.com>
To: <webdav-list@cyberteams.com>
Subject: Using Office 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Resent-Message-ID: <"Bor8p.A.ueC.uc8k2"@epsilon.pair.com>

I am trying to attach to your WebDAV test server using Office 2000 beta
2 and I keep getting an error saying the site is not available or busy. 
I have tried to attach using other WebDAV servers and got in okay.  So
my question is this:  Did MS just mess up in their beta 2 implementation
of WebDAV?  I don't seem to be able to connect to any server using
it....not even their NT 5 Beta 2 server.  Or, is there some setup or
syntax that perhaps I am missing when trying to make my connection?  Any
ideas?

Thanks,
Robert Barham
rbarham@novell.com


From w3c-dist-auth-request@www10.w3.org  Wed Jan  6 16:03:21 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA03216
	for <w3c-dist-auth@www19.w3.org>; Wed, 6 Jan 1999 16:03:21 -0500 (EST)
Received: from snipe.prod.itd.earthlink.net (snipe.prod.itd.earthlink.net [207.217.120.62])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id QAA22958
	for <w3c-dist-auth@w3.org>; Wed, 6 Jan 1999 16:03:20 -0500 (EST)
Received: from severy (1Cust214.tnt1.damascus.md.da.uu.net [153.35.150.214])
	by snipe.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id NAA08619;
	Wed, 6 Jan 1999 13:03:13 -0800 (PST)
Message-Id: <199901062103.NAA08619@snipe.prod.itd.earthlink.net>
X-Sender: severy@mail3.pair.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 06 Jan 1999 16:01:16 -0500
To: w3c-dist-auth@w3.org, webdav-list@cyberteams.com
>From: Randall Severy <severy@cyberteams.com>
In-Reply-To: <s6936351.075@GW.NOVELL.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Re: Using Office 2000

At 01:27 PM 1/6/99 -0700, Robert Barham wrote:
>I am trying to attach to your WebDAV test server using Office 2000 beta
>2 and I keep getting an error saying the site is not available or busy. 
>I have tried to attach using other WebDAV servers and got in okay.  So
>my question is this:  Did MS just mess up in their beta 2 implementation
>of WebDAV?  I don't seem to be able to connect to any server using
>it....not even their NT 5 Beta 2 server.  Or, is there some setup or
>syntax that perhaps I am missing when trying to make my connection?  Any
>ideas?
>
Robert,

     We haven't had any better luck with Office 2000 than you have.  We saw
the same symptoms with our WebDAV server as were reported in testing Office
2000 with the PyDAV and mod_dav servers, so I assume something is not
working right in Office 2000.

     Can someone from Microsoft shed some light on the current status of
interoperability testing between MSIE5/Office 2000 and any of the available
WebDAV servers?

Cheers......    Randall


Randall Severy    severy@cyberteams.com    http://www.cyberteams.com/severy
CyberTeams, Inc.    info@cyberteams.com    http://www.cyberteams.com
Mt. Airy, MD
(301) 829-6144          "Building effective teams in cyberspace"
1-888-832-5575


From w3c-dist-auth-request@www10.w3.org  Thu Jan  7 14:08:39 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA16626
	for <w3c-dist-auth@www19.w3.org>; Thu, 7 Jan 1999 14:08:39 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id OAA03606
	for <w3c-dist-auth@w3.org>; Thu, 7 Jan 1999 14:08:37 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa04026;
          7 Jan 99 10:51 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>, Lisa Lippert <lisal@microsoft.com>
Date: Wed, 6 Jan 1999 10:50:52 -0800
Message-ID: <001d01be39a5$7c4a8c40$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: Comments on Access Control Goals

In preparation for the access control breakout at the Orlando IETF, I read
through the Access Control Goals document, and, while we never ended up
discussing the goals document during the breakout, I did want to pass along
my comments on the document.

In general, I thought it was a good document, which goes a long way towards
capturing group consensus on access control goals for WebDAV.  But, I also
suspect it can be improved with some diligent review.  I'd appreciate it if
members of the list would read through this draft
<draft-ietf-webdav-acl-reqts-00> and send out detailed comments.

Detailed comments below:

Section 5, definitions
  - The concept of a "right" needs to be defined.
  - It would be helpful to separate out the definitions of ACL, and ACE, and
also to have an example, in English, of an ACL and an ACE.
  - The concept of "ownership" needs to be defined.

Section 5.2, definition of Principal -- A principal is also intended to
model a computational process, like a Web crawler, whose access needs to be
controlled, but which doesn't map neatly onto the concept of "user", which
typically impies a human. Also, it might be useful to have a brief
discussion of the interaction between authentication mechanisms and the
notion of a principal.

Section 5.3. Scenarios -- this should be a separate, top-level section (it
doesn't really fit under "definitions", the heading for section 5.

Section 5.4, "Interoperability" -- This should also be its own, top-level
section.  It should also include the discussion from the breakout session on
the issue of mapping access control protocol semantics into the access
control semantics of the underlying repository, and the possible pitfalls.

Section 6, "Goals"
 - A general comment on the entire section is that each goal needs to have
at least a paragraph of rationale associated with it.  This rationale serves
many functions: 1) it provides a new reader the information they need to
assess whether the goal makes sense, 2) it provides a check to the author on
whether the goal is correct -- if the rationale is difficult to provide, it
may indicate a problem, 3) it provides a starting point for discussion on
the goal.

Section 6.2, "Specifying Principals":

          It must also be possible to specify special types of principals,
          in particular all authorized principals, all anonymous
          principals, and all principals.

I'm not sure what is meant by "special types of principals" here.  I'd like
to see some rationale.

Section 6.3, "Rights":

 - to alter the properties of a resource  -- "alter all the properties"
might be slightly better wording here

 - None of the rights discussed in this section map to the HTTP methods
"HEAD" or "OPTIONS".  Does it make sense to have an access right for these
too?
 - None of the access rights map onto HTTP POST either (an "execute" right?)
 - The following rights need to be added:
   - Read the body of a resource
   - Read the properties of a resource

Section 6.7, "Security":

  "It should be acceptable to deny unprotected transactions."

  I don't understand what is meant by an "unprotected transaction" in this
context.

Section 7.1:

          It is recommended that users be able to add access control
          information to an object without having to reset all access
          control settings.

I agree with this.

          This is recommended because certain systems or
          implementations may allow a user to add certain kinds of access
          rights but not others (i.e. grant "read" but not grant "delete").
          Similarly, it should be possible for users to be able to remove,
          delete or clear access rights without having to reset all rights.

However, this rationale seems to be too implementation-oriented.  Why did
the original stores implement the feature this way?

7.2.2.    Inheritance

          If the underlying system uses inheritance, then users of the DAV
          access control mechanism should still be able to predict its
          behavior.  This could be achieved if the type of inheritance is
          discoverable, or if the type(s) of inheritance is/are specified
          by the DAV access control protocol draft.

Even if the goals don't take a stand on the inheritance issue, I think they
should still lay out the decision space for which kinds of inheritance are
possible.  It seems like more work needs to be done to factor out the
underlying goals for inheritance.  For example, the goals might be something
like, "a new resource should receive a default ACL, and this default ACL may
depend on its URL."

       7.2.3.    Ownership

          Systems in which resources have owners also must be treated with
          care.  Predictability can be achieved on systems with owners by
          including owner functionality in DAV access control.  Systems
          which do not support owner functionality could refuse requests to
          change or set ownership.

          There may be other ways to preserve predictability with
          inheritance and ownership.

Similarly, the goals are sidestepping the issue of ownership.  For document
authoring, I think having a special principal for each resource, known as
the owner, can be justified.  The protocol can make ownership actions a
SHOULD if the repository mapping issues are too hard, but having ownership
seems like a reasonable goal.

Section 8.2, "Roles"

          Those with experience building complex document management or
          workflow systems on top of stores with simple ACLs know how hard
          it is to define roles for individuals. For example, the document
          management system can map the role "author" to grant the rights
          read/write/delete, but it is more difficult to go the other way.
          Is an individual with read/write/delete permissions an author, an
          editor, or somebody with no role and just a list of rights?  Many
          systems employ the concept of assigning roles, more temporary
          than identities, to more flexibly define access.

          Roles are important. However, roles would appear to be difficult
          and not necessarily related to ACLs.  The protocol draft MAY
          define how roles may be assigned.


I'm pretty convinced we do not want roles in the protocol.  However, the
above paragraph doesn't do roles justice.  Roles can be very helpful in
helping to administer access control across a repository.  Plus, roles can
be orthogonal to an ACL/ACE mechanism, and hence a role based system could
be built to use what we're proposing.

      8.3. Certificate-based security

          Certificates are out of scope for the DAV ACL protocol.

Why?  Some rationale is needed here.

       8.4. Time-based access control

          Time-based access control is out of scope for the DAV ACL
          protocol.

I agree, although I feel that a brief description of time-based access
control, as well as some rationale for not supporting it, is needed here.

Also, what is our stance on IP-based access control?

      9.   SECURITY CONSIDERATIONS

This section should reference the new, soon to be Draft Standard
authentication document (descendant of RFC 2069).


Nits:

Section 4.1:

          These
          controls define what actions a particular principals is allowed
          to exercise on a particular resource.

"principals" -> "principal"

Section 6.2:

It MUST be possible to use a the octet strings --> delete "a" after "use"

References:

[1] Y. Goland, J. Whitehead, A. Faizi, S. Carter, D. Jensen,
          "Extensions for Distributed Authoring on the World Wide Web",
          <draft-ietf-webdav-protocol-08>, April 1998.

This should be updated.

         H. Palmer, "Requirements for Access Control within Distributed
          Authoring and Versioning Environments on the World Wide Web",
          <draft-ietf-webdav-acreq-01.txt>, November 1997

This can be deleted.

          P. J. Leach, Y. Y. Goland, "WebDAV ACL Protocol", <draft-ietf-
          webdav-acl-00.txt> November 1997

          M. Satyanarayanan, "Integrating Security in a Large Distributed
          System", ACM transactions on computer systems 7(3), August 1989.

These should actually be referenced someplace.  Or, perhaps the last one
could be put in a "recommended reading" section.

- Jim


From w3c-dist-auth-request@www10.w3.org  Thu Jan  7 14:42:10 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA22591
	for <w3c-dist-auth@www19.w3.org>; Thu, 7 Jan 1999 14:42:10 -0500 (EST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id OAA03981
	for <w3c-dist-auth@w3.org>; Thu, 7 Jan 1999 14:42:07 -0500 (EST)
Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9)
	id <Z5H7D47X>; Thu, 7 Jan 1999 11:38:31 -0800
Message-ID: <BFF90FB6CF66D111BF4F0000F840DB8506062425@LASSIE>
>From: "Lisa Lippert (Dusseault) (Exchange)" <lisal@exchange.microsoft.com>
To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
Date: Thu, 7 Jan 1999 11:38:18 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01BE3A75.4CB8F670"
Subject: FW: I-D ACTION:draft-hopmann-collection-props-00.txt

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BE3A75.4CB8F670
Content-Type: text/plain;
	charset="windows-1252"

Finally this is available for you to peruse.  Note that this is a proposal
for a set of OPTIONAL properties that make it easier to do client-side GUIs
for DAV.

Lisa

-----Original Message-----
>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Thursday, January 07, 1999 7:17 AM
Subject: I-D ACTION:draft-hopmann-collection-props-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Additional WebDAV Collection Properties
	Author(s)	: A. Hopmann, L. Lippert
	Filename	: draft-hopmann-collection-props-00.txt
	Pages		: 5
	Date		: 06-Jan-99
	
   The WebDAV protocol defines a basic set of properties that should be
   understood by all DAV servers. This document defines a small set of
   additional properties that are very useful for displaying navigation
   interfaces for WebDAV enabled web sites.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hopmann-collection-props-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-hopmann-collection-props-00.txt".

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

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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-hopmann-collection-props-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.



------_=_NextPart_000_01BE3A75.4CB8F670
Content-Type: message/rfc822
Content-Location: ATT-0-3436954056A6D2119BEF00805F50C597

To: 
Subject: 
Date: Thu, 7 Jan 1999 11:38:31 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01BE3A75.4CB8F670"


------_=_NextPart_002_01BE3A75.4CB8F670
Content-Type: text/plain



------_=_NextPart_002_01BE3A75.4CB8F670
Content-Type: application/octet-stream;
	name="ATT43988"
Content-Disposition: attachment;
	filename="ATT43988"
Content-Location: ATT-0-4730EE943CA6D211BE6800805F4C88C4-A
	TT43988.txt

Content-type: message/external-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-type: message/external-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990106130905.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-hopmann-collection-props-00.txt

------_=_NextPart_002_01BE3A75.4CB8F670
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-hopmann-collection-props-00.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"
Content-Location: ATT-1-4830EE943CA6D211BE6800805F4C88C4-d
	raft-ho.url


------_=_NextPart_002_01BE3A75.4CB8F670--

------_=_NextPart_000_01BE3A75.4CB8F670--


From w3c-dist-auth-request@www10.w3.org  Thu Jan  7 14:58:56 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA27458
	for <w3c-dist-auth@www19.w3.org>; Thu, 7 Jan 1999 14:58:56 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id OAA04375
	for <w3c-dist-auth@w3.org>; Thu, 7 Jan 1999 14:58:55 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa10796;
          7 Jan 99 11:49 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Wed, 6 Jan 1999 11:48:25 -0800
Message-ID: <003601be39ad$85f36980$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: FW: RDF Model and Syntax moves to W3C Proposed Recomendation

Caught by the spam filter.

- Jim

-----Original Message-----
>From: www-webdav-dasl-request@w3.org
[mailto:www-webdav-dasl-request@w3.org] On Behalf Of Eric Miller
Sent: Thursday, January 07, 1999 11:42 AM
To: chairs@w3.org; rdf-dev@mailbase.ac.uk; w3c-rdf-schema@w3.org;
w3c-rdf-syntax@w3.org; w3c-xml-schema-wg@w3.org;
www-rdf-comments@w3.org; rdf-dev@mailbase.ac.uk; xml-dev@ic.ac.uk;
dc-datamodel@mailbase.ac.uk; www-webdav-dasl@w3.org;
w3c-dist-auth@w3.org; mozilla-rdf@mozilla.org; dc-general@mailbase.ac.uk
Subject: RDF Model and Syntax moves to W3C Proposed Recomendation


We are pleased to announce that the W3C has granted Proposed
Recommendation Status to the RDF Model and Syntax specification [1].
RDF is the result of several metadata communities bringing together
their needs to provide a robust and flexible architecture for supporting
metadata on the web.  Additional information on RDF including software,
projects, and presentations can be found on the RDF home page [2].
Public comments and discussion on this work are welcomed [3].

[1] http://www.w3.org/TR/PR-rdf-syntax/
[2] http://www.w3.org/RDF/
[3] http://www.w3.org/Archives/Public/www-rdf-comments/

--
Eric Miller, OCLC, W3C RDF Model and Syntax Chair
Robert Schloss, IBM, W3C RDF Model and Syntax Chair
Ralph Swick, W3C, W3C Metadata Activity Leader



From w3c-dist-auth-request@www10.w3.org  Thu Jan  7 19:16:45 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA03392
	for <w3c-dist-auth@www19.w3.org>; Thu, 7 Jan 1999 19:16:44 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id TAA07165
	for <w3c-dist-auth@w3.org>; Thu, 7 Jan 1999 19:16:43 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa13697;
          7 Jan 99 16:14 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Cc: Yaron Goland <yarong@microsoft.com>, Paul Leach <paulle@microsoft.com>
Date: Thu, 7 Jan 1999 16:13:34 -0800
Message-ID: <004101be3a9b$bb5c8fe0$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: Comments on ACL Protocol

Here are my comments on the WebDAV ACL Protocol,
draft-ietf-webdav-acl-00.txt.

Like the access control goals document, I found this document to be a good
starting point for discussions on creating an access control protocol for
WebDAV.  It too could benefit from review by the mailing list, but it is in
very good shape for an initial draft.

Comments:

Contents:
 - There are several "standard" sections which are missing from this draft,
such as:
   * Notational conventions
   * Terminology (the definitions should be the same as in the goals
document)
   * Security considerations
   * Internationalization considerations

General:

- Somewhere, this document needs to have a section describing the problem of
mapping the rights in the access control protocol into rights supported by
the underlying repository.

Title:
 - Since this document is really a Web access control protocol, the title
should reflect this.  I prefer the title, "Web Access Control Protocol"

Introduction:

 - The introduction should, before leaping into a discussion of mechanism,
give a brief overview of the problem, and the need for a protocol.

 - The introduction states that "individual properties can be given their
own ACL", yet this is different from my reading of the goals document.

Principal Identifiers:

 - The goals document states that groups are out of scope, yet a compound
principal sounds very much like a group.  Furthermore, compound principals
are underspecified -- this document has a brief definition, and no associate
protocol elements.

 - Human readability of principal identifiers is going to be a problem,
since presumably they will be exposed in the user interface at some point in
time.

Granting and Denying Rights:

- The first paragraph needs some work.  First, my understanding is that it
is an ACE, not an ACL which does the actual granting and denying of rights.
An ACL is just a collection of ACEs.  Second, the need for having both grant
and deny capability comes from many sources, not just from compound
principals.  In particular, I had thought that groups could be modeled by
sets of ACEs, and hence the compound principal notion isn't strictly needed.
Plus, if the protocol is going to have compound principals, then the goals
need to allow them, rather than disallowing them.

- In the third paragraph it states, "Rights MAY only be granted to a
principal by an explicit listing of that principal in a 'grant' section of
an ACL."  First, I think the "ACL" should be an "ACE".  Second, the MAY
isn't really right -- this is really a MUST requirement phrased in a odd
way.

- The rules for resolution of access control conflicts have a few
definitional problems:
  * The conflict resolution rules use the term "parent" and "child", which
need to be defined.
  * This definition could be difficult, since a resource may be accessible
via multiple collections.  I'm assuming that ACLs are associated with a
resource, rather than associated with a URL, in which case "parent" and
"child" relationships aren't 1:1.  It also raises tough questions like, how
should inheritance occur when a resource is accessible via multiple URIs
which exist in mutiple collections. Having ACLs associated with URLs might
not be a bad approach here.

Section 3.1, "Examples"

 - The examples need to carefully use the defined terms in the protocol.
So, for example, Section 3.1.1 should read:

"An ACE in the ACL defined on a resource specifies that the principal whose
opaque identifier as provided by the authentication service is 'A'..."

Section 4, "ACL Inheritance"

 - The inheritance model needs to consider non 1:1 containment relationships

 - There is some discussion here about the "owner value" being set upon
resource creation.  Ownership is important enough that it deserves its own
section, which discusses how the owner is set, read, etc.

 - "Inheritance can either be static or dynamic." -- The specification needs
to be a little more detailed here.  If inheritance can go either way, can a
client specify this when they MKCOL?  Or is this an inherent characteristic
of the repository?  Is it discoverable?  Personally, I think mandating
static inheritance, and having no dynamic inheritance is the best choice
here.

Section 5, Properties and ACLs

 - Do we want properties to have per-property access rights?

Section 6, Rights definitions

 - All the namespaces need to be "DAV:"

Section 6.5, createchild

 - The "ADDREF" reference should be changed to "MKREF"
 - MKCOL needs to be added

Section 6.6

 - The reference to "DELREF" goes away.

Section 6.9

 - The definition should be restated in terms of the ACL method, not
modifying the ACL property

There also nede to be some new rights:

 - read body
 - read properties
 - a right that controls POST (?)
 - a right that controls LOCK/UNLOCK (?)
 - a right that controls HEAD, OPTIONS (?)

Section 7.2 - "allauthprincipals XML element"

 - what is the scope of "all authenticated principals"?  Per connection? Per
server?

Section 8.2

 - I think it would be appropriate to start specifying the error reporting.

End of section 8:

 - There needs to be a DTD section which captures all of the properties and
elements into one DTD.

Nits:

In the "Status of this Memo" section, ds.internic.net is no longer active.
This section should also add the standard WebDAV draft boilerplate on the
DAV mailing list, and DAV archives location.

In the header for all pages except the first, WebDAV is miscapitalized as
"WEBDav" rather than "WebDAV".  Although, this should really just be the
"Web Access Control Protocol".

The section "Principals Identifiers" should either be "Principal's
Identifiers" or better yet, "Principal Identifiers"

6.2, "read Right"

- There is a reference to the INDEX method in here.

Section 9:

- need to use new XML namespaces syntax


- Jim


From w3c-dist-auth-request@www10.w3.org  Fri Jan  8 17:45:30 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA29438
	for <w3c-dist-auth@www19.w3.org>; Fri, 8 Jan 1999 17:45:30 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id RAA20856
	for <w3c-dist-auth@w3.org>; Fri, 8 Jan 1999 17:45:29 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa24284;
          8 Jan 99 14:39 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 8 Jan 1999 14:38:05 -0800
Message-ID: <000001be3b57$8f171240$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: Issues List

I have prepared a list of issues in the Distributed Authoring Protocol
specification, and have placed it online at:

http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html

If you have any additional issues, please submit them to me for inclusion in
the list.

- Jim


From w3c-dist-auth-request@www10.w3.org  Mon Jan 11 14:25:01 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA27646
	for <w3c-dist-auth@www19.w3.org>; Mon, 11 Jan 1999 14:25:01 -0500 (EST)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id OAA21765
	for <w3c-dist-auth@w3.org>; Mon, 11 Jan 1999 14:25:00 -0500 (EST)
Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <53977(2)>; Mon, 11 Jan 1999 11:24:51 PST
Received: from copper.parc.xerox.com ([13.1.102.170]) by thelma.parc.xerox.com with SMTP id <101050>; Mon, 11 Jan 1999 11:24:42 PST
>From: "Larry Masinter" <masinter@parc.xerox.com>
To: "Lisa Lippert (Dusseault) (Exchange)" <lisal@exchange.microsoft.com>,
        <w3c-dist-auth@w3.org>
Date: Mon, 11 Jan 1999 11:24:34 PST
Message-ID: <000c01be3d98$052840c0$aa66010d@copper.parc.xerox.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-to: <BFF90FB6CF66D111BF4F0000F840DB8506062425@LASSIE>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Subject: RE: I-D ACTION:draft-hopmann-collection-props-00.txt

> Finally this is available for you to peruse.  Note that this is a proposal
> for a set of OPTIONAL properties that make it easier to do 
> client-side GUIs
> for DAV.
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hopmann-collection-props-00.txt

In what way are these properties optional? If a server didn't support
them, would the client work equally as well? If so, why have them
at all? If not, why are they optional?

Larry
-- 
http://www.parc.xerox.com/masinter



From w3c-dist-auth-request@www10.w3.org  Mon Jan 11 15:16:29 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA29411
	for <w3c-dist-auth@www19.w3.org>; Mon, 11 Jan 1999 15:16:29 -0500 (EST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id PAA22424
	for <w3c-dist-auth@w3.org>; Mon, 11 Jan 1999 15:16:28 -0500 (EST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9)
	id <CQX3X8DK>; Mon, 11 Jan 1999 12:12:10 -0800
Message-ID: <BFF90FB6CF66D111BF4F0000F840DB8506062456@LASSIE>
>From: "Lisa Lippert (Dusseault) (Exchange)" <lisal@exchange.microsoft.com>
To: "'Larry Masinter'" <masinter@parc.xerox.com>, w3c-dist-auth@w3.org
Date: Mon, 11 Jan 1999 12:12:01 -0800
X-Mailer: Internet Mail Service (5.5.2232.9)
Subject: RE: I-D ACTION:draft-hopmann-collection-props-00.txt



Why are these properties optional?  
First, these properties are optional in that any standards draft is more or
less optional:  server implementors can be DAV-compliant by supporting the
original DAV draft and not this one.  The whole draft is optional.  At the
DAV WG, somebody responded to my presentation by saying "We don't want to
support this.  Don't make us support this".  I'm reacting to that by stating
up front that this draft is optional.

Second, the collection properties draft states that these properties are not
essential to running a DAV server.  Clients can work by using PROPFIND ALL
to find out how many items are in a collection, and how many of these are
hidden, and how many are folders, how many are structured documents.   Or
the client may not care about hidden documents and structured documents, and
may treat these as ordinary documents and collections.  So to answer your
second question, clients work but not as well (assuming that "working well"
includes "user-friendly").

Third, many of these properties need not exist on all items.  If an item is
"hidden", then "ishidden" should be TRUE.  But if it is not hidden, then it
doesn't matter if the property doesn't exists because that works the same
way as FALSE.  Same thing with "isstructureddocument".  In that sense,
certain properties are entirely optional even if they are supported by the
server.

It might be a good idea to make these properties a "bundle" -- if one is
supported, all should be supported.  That would make it easier for the
client to figure out what to expect.

Why have them at all?   

One: The client can provide a more friendly UI when browsing, if these
properties are available.  The client can show with each collection how many
sub-collections it has, how many resources, etc.  When the user clicks on a
new folder, the display can immediately show how many items there are before
retrieving the names of each of them.  

Two: The feature of being able to hide a document is new to this draft.
It's a very easy feature to implement on the server, it's
backwards-compatible with clients that don't support it, but clients that do
support the feature get a cleaner presentation of a collection.  

Three: Two new features in this draft that work together are the
"defaultdocument" property and the "isstructureddocument" property.  Many
collections have a web-page or two and a bunch of images, but unless the
user is in editing mode (e.g. adding and removing images) it makes more
sense for the user to see the collection as if it was a document.  What is
displayed if the user decides to view the structured document as such?  The
client sends a GET request to the structured document, and the
"defaultdocument" is returned.  The resource referred to by the
"defaultdocument" property is the one intended to be viewed, and it may have
links to the other resources or contain them inline.  The "defaultdocument"
property also works with ordinary collections.  If I'm browsing somebody
else's collections with DAV, I can tell what their main document is for each
collection.  This also allows for standard administration:  many servers
already have the concept of a default document, and this can be the standard
way for authors/administrators to set that.

Four: The server can provide greater browsing performance. Rather than
browse all collections by doing PROPFIND ALL, the client can know up front
if there are any objects or collections within the collection.  This may
avoid a number of PROPFIND ALL queries.  

I received comments from several people just after the WG ended that they
thought these properties would be useful and were interested in working with
us to standardize them.   DAV is great, but in order for it be widely
deployed and used, user-friendly features would be helpful.
Lisa

-----Original Message-----
>From: Larry Masinter [mailto:masinter@parc.xerox.com]
Sent: Monday, January 11, 1999 11:25 AM
To: Lisa Lippert (Dusseault) (Exchange); w3c-dist-auth@w3.org
Subject: RE: I-D ACTION:draft-hopmann-collection-props-00.txt


> Finally this is available for you to peruse.  Note that this is a proposal
> for a set of OPTIONAL properties that make it easier to do 
> client-side GUIs
> for DAV.
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hopmann-collection-props-00.txt

In what way are these properties optional? If a server didn't support
them, would the client work equally as well? If so, why have them
at all? If not, why are they optional?

Larry
-- 
http://www.parc.xerox.com/masinter


From w3c-dist-auth-request@www10.w3.org  Mon Jan 11 15:39:27 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA29944
	for <w3c-dist-auth@www19.w3.org>; Mon, 11 Jan 1999 15:39:27 -0500 (EST)
Received: from atrium.helios.co.nz (atrium.helios.co.nz [203.97.152.10])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id PAA22662
	for <w3c-dist-auth@w3.org>; Mon, 11 Jan 1999 15:39:25 -0500 (EST)
Received: from workstation2 (workstation2.helios.co.nz [203.97.152.28])
	by atrium.helios.co.nz (8.8.8/8.8.8/Debian/GNU) with SMTP id JAA14451
	for <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 09:39:21 +1300
Message-Id: <3.0.5.32.19990112093617.009943f0@atrium.helios.co.nz>
X-Sender: miles@atrium.helios.co.nz
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Tue, 12 Jan 1999 09:36:17 +1300
To: w3c-dist-auth@w3.org
>From: Miles Thompson <miles@mail.com>
In-Reply-To: <BFF90FB6CF66D111BF4F0000F840DB8506062456@LASSIE>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-hopmann-collection-props-00.txt

Lisa,


>It might be a good idea to make these properties a "bundle" -- if one is
>supported, all should be supported.  That would make it easier for the
>client to figure out what to expect.

If I were writing a client would it be reasonable for me to expect that
such properties as for example a collections 'childcount' are available
in any "WebDav compliant" server ? If not then the stating of their
'optional' existance only causes confusion for me as a developer.

Surely the whole purpose of a standard is that the whole thing,
*all* the properties and methods, API etc can be treated as a 'bundle'
that I can assume to exist. If I cannot assume some properties exist
then I would have to, as you say, fall back on more primitive methods,
in which case why even put them in the spec?




               _
           o  | |
    _  _      | |  _   ,
 /|/ |/ |  |  |/  |/  / \_
  |  |  |_/|_/|__/|__/ \/

  miles@mail.com 
  miles@helios.co.nz
	


From w3c-dist-auth-request@www10.w3.org  Mon Jan 11 16:04:00 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA00825
	for <w3c-dist-auth@www19.w3.org>; Mon, 11 Jan 1999 16:03:59 -0500 (EST)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id QAA23032
	for <w3c-dist-auth@w3.org>; Mon, 11 Jan 1999 16:03:59 -0500 (EST)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42])
	by netscape.com (8.8.5/8.8.5) with ESMTP id NAA29737
	for <w3c-dist-auth@w3.org>; Mon, 11 Jan 1999 13:03:54 -0800 (PST)
Received: from netscape.com ([208.12.58.40]) by tintin.mcom.com
          (Netscape Messaging Server 4.01) with ESMTP id F5EYII00.ABN for
          <w3c-dist-auth@w3.org>; Mon, 11 Jan 1999 13:03:54 -0800 
Sender: francis@netscape.com (John Stracke)
Message-ID: <369A6739.E03C87CC@netscape.com>
Date: Mon, 11 Jan 1999 13:03:53 -0800
>From: John Stracke <francis@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 4.5 [en] (X11; U; IRIX 6.2 IP22)
X-Accept-Language: en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <3.0.5.32.19990112093617.009943f0@atrium.helios.co.nz>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by www19.w3.org id QAA00825
Subject: Re: I-D ACTION:draft-hopmann-collection-props-00.txt

Miles Thompson wrote:

> Surely the whole purpose of a standard is that the whole thing,
> *all* the properties and methods, API etc can be treated as a 'bundle'
> that I can assume to exist.

This is not the case; standards are not monolithic.  WebDAV is built over
HTTP, but that doesn't mean that every HTTP server should support WebDAV.
Similarly, the collection properties proposal is built over WebDAV, but not
every WebDAV server would have to support the collection properties.

More generally, even within a single spec, there are often parts that not
everybody will support.  Most HTTP servers don't support PUT; many (most?)
routers ignore the TOS field; many SMTP servers laugh in your face if you
try to use EXPN or VRFY.  You just have to deal with it.

> If I cannot assume some properties exist
> then I would have to, as you say, fall back on more primitive methods,
> in which case why even put them in the spec?

They are not in the spec; they are in a separate spec of their own.

I believe the point of specifying them is that, for certain classes of
client, they will provide certain efficiency benefits; since some vendors
are going to want those benefits, we should standardize how you get them,
rather than keeping quiet and watching everybody define their own
mechanisms.  It does introduce an extra axis of variation, but at least it
standardizes that axis.

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      | You buttered your bread, now lie in it. |
|francis@netscape.com      |                                         |
\====================================================================/



From w3c-dist-auth-request@www10.w3.org  Mon Jan 11 16:12:36 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA01246
	for <w3c-dist-auth@www19.w3.org>; Mon, 11 Jan 1999 16:12:35 -0500 (EST)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id QAA23138
	for <w3c-dist-auth@w3.org>; Mon, 11 Jan 1999 16:12:35 -0500 (EST)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42])
	by netscape.com (8.8.5/8.8.5) with ESMTP id NAA10114
	for <w3c-dist-auth@w3.org>; Mon, 11 Jan 1999 13:12:32 -0800 (PST)
Received: from netscape.com ([208.12.58.40]) by tintin.mcom.com
          (Netscape Messaging Server 4.01) with ESMTP id F5EYWW00.RBY for
          <w3c-dist-auth@w3.org>; Mon, 11 Jan 1999 13:12:32 -0800 
Sender: francis@netscape.com (John Stracke)
Message-ID: <369A6940.5F8F169F@netscape.com>
Date: Mon, 11 Jan 1999 13:12:32 -0800
>From: John Stracke <francis@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 4.5 [en] (X11; U; IRIX 6.2 IP22)
X-Accept-Language: en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <BFF90FB6CF66D111BF4F0000F840DB8506062456@LASSIE>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by www19.w3.org id QAA01246
Subject: Re: I-D ACTION:draft-hopmann-collection-props-00.txt

"Lisa Lippert (Dusseault) (Exchange)" wrote:

> Three: Two new features in this draft that work together are the
> "defaultdocument" property

I kind of like defaultdocument, but I think it might need to be a list.  Most
existing servers have a rule for picking out the default document (e.g.,
"index.html, then index.cgi, then index.txt"); it would be a Good Thing if, on
directories with no default set, they could expose the rule rather than just
the document that they would currently serve up.

(I'm not sure whether there's a need to be able to *set* an individual
collection's defaultdocument to a list, but it could be useful, e.g., if a
server decides that defaultdocument should be inherited by subcollections.)

Also, one oversight (probably): the current Draft does not require that
defaultdocument point to a member of the collection; as it stands now, it would
be possible for it to point to a completely separate server.  This might be a
cute trick occasionally, but I think it'd be cleaner to create a referential
member and make that the default.

Oh, and the Draft does not specify what "the default document for a collection"
means.  We all know that it's the resource that gets referenced by a GET or
HEAD on the collection URI; but that should be specified.

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      |Q: What goes "Pieces of 7! Pieces of 7!"?|
|francis@netscape.com      |A: A parroty error!!                     |
\====================================================================/



From w3c-dist-auth-request@www10.w3.org  Mon Jan 11 16:27:40 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA01966
	for <w3c-dist-auth@www19.w3.org>; Mon, 11 Jan 1999 16:27:39 -0500 (EST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id QAA23345
	for <w3c-dist-auth@w3.org>; Mon, 11 Jan 1999 16:27:38 -0500 (EST)
Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9)
	id <CQY3CSV8>; Mon, 11 Jan 1999 13:23:21 -0800
Message-ID: <BFF90FB6CF66D111BF4F0000F840DB8506062460@LASSIE>
>From: "Lisa Lippert (Dusseault) (Exchange)" <lisal@exchange.microsoft.com>
To: "'John Stracke'" <francis@netscape.com>
Cc: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
Date: Mon, 11 Jan 1999 13:23:16 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: I-D ACTION:draft-hopmann-collection-props-00.txt

I just noticed the possibility for infinite loops today.  That would be
fixed by requiring the "defaultdocument" property to point to a member of
the collection.  Perhaps we should also say that "defaultdocument" cannot
point to a collection, which could in turn point somewhere else...

Lisa

-----Original Message-----
>From: John Stracke [mailto:francis@netscape.com]
Sent: Monday, January 11, 1999 1:13 PM
To: w3c-dist-auth@w3.org
Subject: Re: I-D ACTION:draft-hopmann-collection-props-00.txt


"Lisa Lippert (Dusseault) (Exchange)" wrote:

> Three: Two new features in this draft that work together are the
> "defaultdocument" property

I kind of like defaultdocument, but I think it might need to be a list.
Most
existing servers have a rule for picking out the default document (e.g.,
"index.html, then index.cgi, then index.txt"); it would be a Good Thing if,
on
directories with no default set, they could expose the rule rather than just
the document that they would currently serve up.

(I'm not sure whether there's a need to be able to *set* an individual
collection's defaultdocument to a list, but it could be useful, e.g., if a
server decides that defaultdocument should be inherited by subcollections.)

Also, one oversight (probably): the current Draft does not require that
defaultdocument point to a member of the collection; as it stands now, it
would
be possible for it to point to a completely separate server.  This might be
a
cute trick occasionally, but I think it'd be cleaner to create a referential
member and make that the default.

Oh, and the Draft does not specify what "the default document for a
collection"
means.  We all know that it's the resource that gets referenced by a GET or
HEAD on the collection URI; but that should be specified.

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      |Q: What goes "Pieces of 7! Pieces of 7!"?|
|francis@netscape.com      |A: A parroty error!!                     |
\====================================================================/


From w3c-dist-auth-request@www10.w3.org  Mon Jan 11 17:30:47 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA04276
	for <w3c-dist-auth@www19.w3.org>; Mon, 11 Jan 1999 17:30:46 -0500 (EST)
Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id RAA24371
	for <w3c-dist-auth@w3.org>; Mon, 11 Jan 1999 17:30:45 -0500 (EST)
Received: from inner-relay-1.Adobe.COM ([153.32.1.51] (may be forged))
	by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id OAA28554
	for <w3c-dist-auth@w3.org>; Mon, 11 Jan 1999 14:25:16 -0800 (PST)
Received: from mail-321.corp.Adobe.COM  by inner-relay-1.Adobe.COM (8.8.5) with ESMTP id OAA05882; Mon, 11 Jan 1999 14:30:41 -0800 (PST)
Received: from dsds3  by mail-321.corp.Adobe.COM (8.7.5) with SMTP id OAA26469; Mon, 11 Jan 1999 14:30:40 -0800 (PST)
>From: "Satwinder Mangat" <smangat@Adobe.COM>
To: <w3c-dist-auth@w3.org>
Date: Mon, 11 Jan 1999 14:25:44 -0800
Message-ID: <000001be3db1$547545b0$f69e2099@dsds3.corp.adobe.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <BFF90FB6CF66D111BF4F0000F840DB8506062460@LASSIE>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Subject: WebDAV client implementation

Hi,

>From where I can get WebDAV client implementation, either for a small fee or
as a public downloadable?
Please specify the language in which the client is implemented.

Thanks
Satwinder Mangat
Adobe Systems
smangat@adobe.com


From w3c-dist-auth-request@www10.w3.org  Mon Jan 11 18:08:48 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA06281
	for <w3c-dist-auth@www19.w3.org>; Mon, 11 Jan 1999 18:08:48 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id SAA25119
	for <w3c-dist-auth@w3.org>; Mon, 11 Jan 1999 18:08:47 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa14840;
          11 Jan 99 15:05 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: Satwinder Mangat <smangat@adobe.com>, w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
Date: Mon, 11 Jan 1999 15:04:12 -0800
Message-ID: <003101be3db6$b3b9e800$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-reply-to: <000001be3db1$547545b0$f69e2099@dsds3.corp.adobe.com>
Importance: Normal
Subject: RE: WebDAV client implementation

Hi Satwinder,

There is a list of WebDAV clients on the WebDAV Home Page:

http://www.ics.uci.edu/pub/ietf/webdav/

The one that is publically available, and most up-to-date w.r.t. the WebDAV
specification right now is Joe Orton's sitecopy.

- Jim

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Satwinder Mangat
> Sent: Monday, January 11, 1999 2:26 PM
> To: w3c-dist-auth@w3.org
> Subject: WebDAV client implementation
>
>
> Hi,
>
> >From where I can get WebDAV client implementation, either for a
> small fee or
> as a public downloadable?
> Please specify the language in which the client is implemented.
>
> Thanks
> Satwinder Mangat
> Adobe Systems
> smangat@adobe.com
>


From w3c-dist-auth-request@www10.w3.org  Tue Jan 12 05:45:59 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA14125
	for <w3c-dist-auth@www19.w3.org>; Tue, 12 Jan 1999 05:45:59 -0500 (EST)
Received: from m7300a.mecom.mecomnet.de (mail.mecomnet.de [194.152.58.195])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id FAA01195
	for <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 05:45:58 -0500 (EST)
Received: from mecomnet.de by m7300a.mecom.mecomnet.de (AppleShare IP Mail Server 6.1b3) id 1021 via TCP with SMTP; Thu, 12 Nov 1998 11:49:28 +0100
Message-ID: <369B28CE.488B629A@mecomnet.de>
Date: Tue, 12 Jan 1999 11:49:53 +0100
>From: james anderson <James.Anderson@mecomnet.de>
Reply-To: James.Anderson@mecomnet.de
Organization: mecom gmbh
X-Mailer: Mozilla 4.04 (Macintosh; I; PPC)
MIME-Version: 1.0
To: "Lisa Lippert (Dusseault) (Exchange)" <lisal@exchange.microsoft.com>
CC: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
References: <BFF90FB6CF66D111BF4F0000F840DB8506062425@LASSIE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: structured documents [draft-hopmann-collection-props-00.txt]

greetings;

Is the nature and behaviour of structured documents specified at any other
place in webdav specs? I note the term for the first time in "1.7 The
isstructureddocument Property". Just to check, I went back through
"draft-ietf-webdav-protocol-10" and find that the word "structured" appears in
generic or colloquial senses only and that there is neither a description of
the content nor one of the behaviour of such a resource.

If this document (draft-hopmann-collection-props-00.txt) is the only place
where the term appears, then a more extensive definition and a distinction
between structured documents and generic collections are necessary. for
instance, is the intended hierarchy
 collection
   structured-document
     directory
or is it
 collection
   structured-document
   directory
?

Note that I very much welcome the introduction of s-d's as specialized
collections, as webdav, in its present form, is a bit fixated on "directories
/ folders" as the only collection forms. Where, for example, I would like to
consider a patient record to be a special form of collection, I'd be
stretching the present spec. on the other hand I can't express enough if I try
to model them as generic resources.

bye,


From w3c-dist-auth-request@www10.w3.org  Tue Jan 12 10:18:35 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA18558
	for <w3c-dist-auth@www19.w3.org>; Tue, 12 Jan 1999 10:18:35 -0500 (EST)
Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id KAA03688
	for <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 10:18:34 -0500 (EST)
Received: from crthub2.crt.xerox.com (crthub2.crt.xerox.com [13.138.80.5])
	by pasiphae.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id KAA17555
	for <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 10:18:33 -0500 (EST)
Received: by crthub2.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <CX004YFY>; Tue, 12 Jan 1999 10:17:45 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76D5C@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
Date: Tue, 12 Jan 1999 10:19:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: WebDAV Issues List

Related to COPY_LIVE_PROPS, I think there is a more general question about
whether any sweeping statements like those in 8.8.2 (COPY for Properties)
and 8.9.1 (MOVE for Properties) can really be made about how servers should
treat live properties on COPY or MOVE.  For DAV:lockdiscovery it's not just
that it should never be copied dead, but it should never be copied (or
moved) at all.  Other live DAV properties (supportedlock, getetag) should be
copied / moved live if possible, but should not be copied / moved dead.
Sometimes the rules for copy will be different from the rules for move.  

Does the spec anywhere state which of the DAV: properties are live and which
are dead?  It probably should.  I'm assuming that all except displayname are
live, but I could be wrong.

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580


From w3c-dist-auth-request@www10.w3.org  Tue Jan 12 13:07:43 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA22096
	for <w3c-dist-auth@www19.w3.org>; Tue, 12 Jan 1999 13:07:43 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id NAA05646
	for <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 13:07:42 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa00781;
          12 Jan 99 10:05 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 12 Jan 1999 10:04:24 -0800
Message-ID: <000101be3e55$fcc0f940$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <369B28CE.488B629A@mecomnet.de>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: RE: structured documents [draft-hopmann-collection-props-00.txt]


> Is the nature and behaviour of structured documents specified at any other
> place in webdav specs? I note the term for the first time in "1.7 The
> isstructureddocument Property". Just to check, I went back through
> "draft-ietf-webdav-protocol-10" and find that the word
> "structured" appears in generic or colloquial senses only and that
> there is neither a description of the content nor one of the behaviour
> of such a resource.

You are correct -- structured (or compound) documents are not well defined
in any existing WebDAV specifications.

> If this document (draft-hopmann-collection-props-00.txt) is the only place
> where the term appears, then a more extensive definition and a distinction
> between structured documents and generic collections are necessary.

This seems quite reasonable -- otherwise, how would you know how to set the
property value?

> for
> instance, is the intended hierarchy
>  collection
>    structured-document
>      directory
> or is it
>  collection
>    structured-document
>    directory
> ?

I don't follow this, since my understanding of what is meant by structured
document in the WebDAV sense isn't covered by these two cases.  Could you
give some examples of what you mean here?

I'll let Lisa speak to her intent is when she says "structured document".

- Jim


From w3c-dist-auth-request@www10.w3.org  Tue Jan 12 13:54:23 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA23083
	for <w3c-dist-auth@www19.w3.org>; Tue, 12 Jan 1999 13:54:23 -0500 (EST)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id NAA06223
	for <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 13:54:22 -0500 (EST)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42])
	by netscape.com (8.8.5/8.8.5) with ESMTP id KAA00591
	for <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 10:54:20 -0800 (PST)
Received: from netscape.com ([208.12.58.40]) by tintin.mcom.com
          (Netscape Messaging Server 4.01) with ESMTP id F5GN6K00.EJ5 for
          <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 10:54:20 -0800 
Sender: francis@netscape.com (John Stracke)
Message-ID: <369B9A5C.C1F1F906@netscape.com>
Date: Tue, 12 Jan 1999 10:54:20 -0800
>From: John Stracke <francis@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 4.5 [en] (X11; U; IRIX 6.2 IP22)
X-Accept-Language: en
MIME-Version: 1.0
To: WEBDAV WG <w3c-dist-auth@w3.org>
References: <000101be3e55$fcc0f940$d115c380@galileo.ics.uci.edu>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by www19.w3.org id NAA23083
Subject: Re: structured documents [draft-hopmann-collection-props-00.txt]

Jim Whitehead wrote:

> > for
> > instance, is the intended hierarchy
> >  collection
> >    structured-document
> >      directory
> > or is it
> >  collection
> >    structured-document
> >    directory
> > ?
>
> I don't follow this, since my understanding of what is meant by structured
> document in the WebDAV sense isn't covered by these two cases.

I think he means class heirarchy, not namespace heirarchy.  My sense is that
the latter form is the correct class heirarchy.

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      | It's not an optical illusion, it just   |
|francis@netscape.com      |  looks like one.                        |
\====================================================================/



From w3c-dist-auth-request@www10.w3.org  Tue Jan 12 13:55:56 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA23155
	for <w3c-dist-auth@www19.w3.org>; Tue, 12 Jan 1999 13:55:55 -0500 (EST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id NAA06253
	for <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 13:55:55 -0500 (EST)
Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9)
	id <CQY3CWLC>; Tue, 12 Jan 1999 10:51:47 -0800
Message-ID: <BFF90FB6CF66D111BF4F0000F840DB850606247A@LASSIE>
>From: "Lisa Lippert (Dusseault) (Exchange)" <lisal@exchange.microsoft.com>
To: "'ejw@ics.uci.edu'" <ejw@ics.uci.edu>, WEBDAV WG
	 <w3c-dist-auth@w3.org>
Date: Tue, 12 Jan 1999 10:51:33 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: structured documents [draft-hopmann-collection-props-00.txt]

Our intent was that a structured document is treated by the server just like
any other collection (it is a collection).  However, the client can (if in
"read" or "browse" mode) display a structured document as a document and
allow the user to read the document without being aware of all the pieces of
the structured document.  

The pieces of the structured document are actually resources within the
collection, which means that old clients can  do authoring normally.
Clients that support structured documents also have the option to display as
a collection (i.e. so that one of the resources/pieces can be deleted).

Our spec does not define what the structure of a structured document is --
that should be handled by the default document, which could be an HTML page,
XML file or some other thing which defines how the pieces fit together.

Are there other required characteristics of a structured document?

Lisa

-----Original Message-----
>From: Jim Whitehead [mailto:ejw@ics.uci.edu]
Sent: Tuesday, January 12, 1999 10:04 AM
To: WEBDAV WG
Subject: RE: structured documents
[draft-hopmann-collection-props-00.txt]



> Is the nature and behaviour of structured documents specified at any other
> place in webdav specs? I note the term for the first time in "1.7 The
> isstructureddocument Property". Just to check, I went back through
> "draft-ietf-webdav-protocol-10" and find that the word
> "structured" appears in generic or colloquial senses only and that
> there is neither a description of the content nor one of the behaviour
> of such a resource.

You are correct -- structured (or compound) documents are not well defined
in any existing WebDAV specifications.

> If this document (draft-hopmann-collection-props-00.txt) is the only place
> where the term appears, then a more extensive definition and a distinction
> between structured documents and generic collections are necessary.

This seems quite reasonable -- otherwise, how would you know how to set the
property value?

> for
> instance, is the intended hierarchy
>  collection
>    structured-document
>      directory
> or is it
>  collection
>    structured-document
>    directory
> ?

I don't follow this, since my understanding of what is meant by structured
document in the WebDAV sense isn't covered by these two cases.  Could you
give some examples of what you mean here?

I'll let Lisa speak to her intent is when she says "structured document".

- Jim


From w3c-dist-auth-request@www10.w3.org  Tue Jan 12 14:34:15 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA24034
	for <w3c-dist-auth@www19.w3.org>; Tue, 12 Jan 1999 14:34:14 -0500 (EST)
Received: from m7300a.mecom.mecomnet.de (mail.mecomnet.de [194.152.58.195])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id OAA06814
	for <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 14:34:13 -0500 (EST)
Received: from mecomnet.de by m7300a.mecom.mecomnet.de (AppleShare IP Mail Server 6.1b3) id 1534 via TCP with SMTP; Thu, 12 Nov 1998 20:37:51 +0100
Message-ID: <369BA4A9.876FB63D@mecomnet.de>
Date: Tue, 12 Jan 1999 20:38:22 +0100
>From: james anderson <James.Anderson@mecomnet.de>
Reply-To: James.Anderson@mecomnet.de
Organization: mecom gmbh
X-Mailer: Mozilla 4.04 (Macintosh; I; PPC)
MIME-Version: 1.0
To: WEBDAVWG <w3c-dist-auth@w3.org>
References: <000101be3e55$fcc0f940$d115c380@galileo.ics.uci.edu> <369B9A5C.C1F1F906@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: structured documents [draft-hopmann-collection-props-00.txt]

yes, i meant a "class hierarchy".

John Stracke wrote:
> 
> Jim Whitehead wrote:
> 
> > > for
> > > instance, is the intended hierarchy
> > >  collection
> > >    structured-document
> > >      directory
> > > or is it
> > >  collection
> > >    structured-document
> > >    directory
> > > ?
> >
> > I don't follow this, since my understanding of what is meant by structured
> > document in the WebDAV sense isn't covered by these two cases.
> 
> I think he means class heirarchy, not namespace heirarchy.  My sense is that
> the latter form is the correct class heirarchy.


From w3c-dist-auth-request@www10.w3.org  Tue Jan 12 14:56:45 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA24707
	for <w3c-dist-auth@www19.w3.org>; Tue, 12 Jan 1999 14:56:45 -0500 (EST)
Received: from m7300a.mecom.mecomnet.de (mail.mecomnet.de [194.152.58.195])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id OAA07063
	for <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 14:56:44 -0500 (EST)
Received: from mecomnet.de by m7300a.mecom.mecomnet.de (AppleShare IP Mail Server 6.1b3) id 1548 via TCP with SMTP; Thu, 12 Nov 1998 21:00:23 +0100
Message-ID: <369BA9F0.F6B29B24@mecomnet.de>
Date: Tue, 12 Jan 1999 21:00:55 +0100
>From: james anderson <James.Anderson@mecomnet.de>
Reply-To: James.Anderson@mecomnet.de
Organization: mecom gmbh
X-Mailer: Mozilla 4.04 (Macintosh; I; PPC)
MIME-Version: 1.0
To: WEBDAV WG <w3c-dist-auth@w3.org>
References: <BFF90FB6CF66D111BF4F0000F840DB850606247A@LASSIE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: structured documents [draft-hopmann-collection-props-00.txt]

I will try to summarize my present uncertainty about the webdav model.

A simplistic view of entities in a net is that each "thing" can be "named" and
"described" as well as it can "name" and "describe" other things. Restated,
for each node, there are links in and out and the there are attributes about
and attributes of. Nothing new here.

As far as I've been able to understand webdav, it recognizes "links in",
"links out", and "attributes about". These things are sufficient to describe
files and directories. They are sufficient for structured documents only if
"attributes of" are solely the responsibility of the application.

In other words, my sense is that the properties supported for collections are
strictly "attributes about" and that, in order to provide a standardized
interface for structured documents, one would need, in addition, a standard
interface to the means to identify and manipulate "attributes <em>of</em>" the document.

Lisa Lippert (Dusseault) (Exchange) wrote:
> 
> Our intent was that a structured document is treated by the server just like
> any other collection (it is a collection).  However, the client can (if in
> "read" or "browse" mode) display a structured document as a document and
> allow the user to read the document without being aware of all the pieces of
> the structured document.
> 

I'm not sure I believe this. It presumes that the only structure involves
relations to other resources and that any other information about the resource
is "unstructured".

?


From w3c-dist-auth-request@www10.w3.org  Tue Jan 12 17:30:09 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA29990
	for <w3c-dist-auth@www19.w3.org>; Tue, 12 Jan 1999 17:30:08 -0500 (EST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id RAA09053
	for <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 17:30:07 -0500 (EST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9)
	id <CQX3YQ7F>; Tue, 12 Jan 1999 14:30:08 -0800
Message-ID: <BFF90FB6CF66D111BF4F0000F840DB8506062483@LASSIE>
>From: "Lisa Lippert (Dusseault) (Exchange)" <lisal@exchange.microsoft.com>
To: "'James.Anderson@mecomnet.de'" <James.Anderson@mecomnet.de>,
        WEBDAVWG <w3c-dist-auth@w3.org>
Date: Tue, 12 Jan 1999 14:30:07 -0800
X-Mailer: Internet Mail Service (5.5.2232.9)
Subject: RE: structured documents [draft-hopmann-collection-props-00.txt]

In the collection properties draft, both "folders" and "structured
documents" are types of collection.  They differ in how they are intended to
be displayed.

Lisa

-----Original Message-----
>From: james anderson [mailto:James.Anderson@mecomnet.de]
Sent: Tuesday, January 12, 1999 11:38 AM
To: WEBDAVWG
Subject: Re: structured documents
[draft-hopmann-collection-props-00.txt]


yes, i meant a "class hierarchy".

John Stracke wrote:
> 
> Jim Whitehead wrote:
> 
> > > for
> > > instance, is the intended hierarchy
> > >  collection
> > >    structured-document
> > >      directory
> > > or is it
> > >  collection
> > >    structured-document
> > >    directory
> > > ?
> >
> > I don't follow this, since my understanding of what is meant by
structured
> > document in the WebDAV sense isn't covered by these two cases.
> 
> I think he means class heirarchy, not namespace heirarchy.  My sense is
that
> the latter form is the correct class heirarchy.


From w3c-dist-auth-request@www10.w3.org  Tue Jan 12 18:44:15 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA01607
	for <w3c-dist-auth@www19.w3.org>; Tue, 12 Jan 1999 18:44:15 -0500 (EST)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id SAA09899
	for <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 18:44:14 -0500 (EST)
Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <61410(3)>; Tue, 12 Jan 1999 15:43:59 PST
Received: from copper.parc.xerox.com ([13.1.102.170]) by thelma.parc.xerox.com with SMTP id <101845>; Tue, 12 Jan 1999 15:43:43 PST
>From: "Larry Masinter" <masinter@parc.xerox.com>
To: <James.Anderson@mecomnet.de>,
        "Lisa Lippert (Dusseault) (Exchange)" <lisal@exchange.microsoft.com>
Cc: <w3c-dist-auth@w3.org>
Date: Tue, 12 Jan 1999 15:43:34 PST
Message-ID: <000001be3e85$5e806d80$aa66010d@copper.parc.xerox.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <369B28CE.488B629A@mecomnet.de>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Subject: RE: structured documents [draft-hopmann-collection-props-00.txt]

I think if we want interoperable standards here, that it would
be useful to take on the job of designing a set of attributes
that could successfully carry a useful document model.

If support for structured documents is needed for interoperable
clients, then it should only be "optional" in the sense of another
set of collective features which form yet another standard for
which 'conformance implies interoperability'.

I don't know if this requires a charter addition, or the formation
of a separate working group.

Larry
-- 
http://www.parc.xerox.com/masinter


From w3c-dist-auth-request@www10.w3.org  Tue Jan 12 18:56:15 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA01837
	for <w3c-dist-auth@www19.w3.org>; Tue, 12 Jan 1999 18:56:15 -0500 (EST)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id SAA10069
	for <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 18:56:14 -0500 (EST)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42])
	by netscape.com (8.8.5/8.8.5) with ESMTP id PAA23485
	for <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 15:56:13 -0800 (PST)
Received: from netscape.com ([208.12.58.40]) by tintin.mcom.com
          (Netscape Messaging Server 4.01) with ESMTP id F5H15P00.QLE for
          <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 15:56:13 -0800 
Sender: francis@netscape.com (John Stracke)
Message-ID: <369BE11C.9DC47B4D@netscape.com>
Date: Tue, 12 Jan 1999 15:56:13 -0800
>From: John Stracke <francis@netscape.com>
Reply-To: francis@appoint.net
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 4.5 [en] (X11; U; IRIX 6.2 IP22)
X-Accept-Language: en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <000001be3e85$5e806d80$aa66010d@copper.parc.xerox.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by www19.w3.org id SAA01837
Subject: Re: structured documents [draft-hopmann-collection-props-00.txt]

Larry Masinter wrote:

> If support for structured documents is needed for interoperable
> clients, then it should only be "optional" in the sense of another
> set of collective features which form yet another standard for
> which 'conformance implies interoperability'.

Do we really want to invent our own structured documents model?
Rhetorical question: what's wrong with multipart/related?

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      | You! Out of the gene pool!              |
|francis@netscape.com      |                                         |
\====================================================================/



From w3c-dist-auth-request@www10.w3.org  Tue Jan 12 19:00:01 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA01949
	for <w3c-dist-auth@www19.w3.org>; Tue, 12 Jan 1999 19:00:00 -0500 (EST)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id SAA10111
	for <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 19:00:00 -0500 (EST)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42])
	by netscape.com (8.8.5/8.8.5) with ESMTP id PAA28158
	for <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 15:59:58 -0800 (PST)
Received: from netscape.com ([208.12.58.40]) by tintin.mcom.com
          (Netscape Messaging Server 4.01) with ESMTP id F5H1BY00.ELY for
          <w3c-dist-auth@w3.org>; Tue, 12 Jan 1999 15:59:58 -0800 
Sender: francis@netscape.com (John Stracke)
Message-ID: <369BE1FE.D938FF89@netscape.com>
Date: Tue, 12 Jan 1999 15:59:58 -0800
>From: John Stracke <francis@netscape.com>
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 4.5 [en] (X11; U; IRIX 6.2 IP22)
X-Accept-Language: en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <000001be3e85$5e806d80$aa66010d@copper.parc.xerox.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by www19.w3.org id TAA01949
Subject: Re: structured documents [draft-hopmann-collection-props-00.txt]

(Whoops--I set the Reply-To: on my last post so that I would
get replies after I left Netscape; but I just realized it'll
make it hard for some people to reply to the list.  So I'm
resending.)

Larry Masinter wrote:

> If support for structured documents is needed for
> interoperable
> clients, then it should only be "optional" in the sense of
> another
> set of collective features which form yet another standard
> for
> which 'conformance implies interoperability'.
>
I'm wondering whether we actually want a new
structured-document model.  Rhetorical question: What's
wrong with multipart/related?

--
/=====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported  |
|Software Retrophrenologist|==========================================|
|Netscape Comm. Corp.      |In the long run, there is no middle ground|
|francis@netscape.com      | between justice and genocide.            |
\=====================================================================/



From w3c-dist-auth-request@www10.w3.org  Wed Jan 13 10:49:28 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA15138
	for <w3c-dist-auth@www19.w3.org>; Wed, 13 Jan 1999 10:49:28 -0500 (EST)
Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id KAA17822
	for <w3c-dist-auth@w3.org>; Wed, 13 Jan 1999 10:49:27 -0500 (EST)
Received: from crthub2.crt.xerox.com (crthub2.crt.xerox.com [13.138.80.5])
	by pasiphae.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id KAA25501;
	Wed, 13 Jan 1999 10:47:15 -0500 (EST)
Received: by crthub2.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <CX0049VV>; Wed, 13 Jan 1999 10:46:26 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76D5E@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "Masinter, Larry <masinter@parc.xerox.com>" <masinter@parc.xerox.com>,
        James.Anderson@mecomnet.de,
        "Lisa Lippert (Dusseault) (Exchange)"
	 <lisal@exchange.microsoft.com>
Cc: w3c-dist-auth@w3.org
Date: Wed, 13 Jan 1999 10:47:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: structured documents [draft-hopmann-collection-props-00.txt]

I agree that taking on compound documents would be a significant amount of
work that probably requires either an addition to our charter or the
formation of a new working group.

Just agreeing on what a compound document is could be challenging.  I was
recently involved in discussions where the following were just some of the
characteristics proposed:

Composed of multiple files
Composed of elements that might not be files (might be database objects,
cells in a relational database, etc.)
Composed of other documents
Component parts can be independently manipulated
Contains multiple renditions
Contains content elements in a variety of formats
Is a configuration of specific versions of component documents
Component parts can be shared by multiple compound documents

Lots of models exist that could be the basis for work in this area.  DMA
provides a fairly simple model where documents are composed of renditions,
which in turn are composed of content elements.  They are struggling with
trying to extend this model to allow documents to contain other documents.
Documentum has a model where documents can contain other documents.  Etc.

--Judy 

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580


> -----Original Message-----
> From: Larry Masinter [mailto:masinter@parc.xerox.com]
> Sent: Tuesday, January 12, 1999 6:44 PM
> To: James.Anderson@mecomnet.de; Lisa Lippert (Dusseault) (Exchange)
> Cc: w3c-dist-auth@w3.org
> Subject: RE: structured documents
> [draft-hopmann-collection-props-00.txt]
> 
> 
> I think if we want interoperable standards here, that it would
> be useful to take on the job of designing a set of attributes
> that could successfully carry a useful document model.
> 
> If support for structured documents is needed for interoperable
> clients, then it should only be "optional" in the sense of another
> set of collective features which form yet another standard for
> which 'conformance implies interoperability'.
> 
> I don't know if this requires a charter addition, or the formation
> of a separate working group.
> 
> Larry
> -- 
> http://www.parc.xerox.com/masinter
> 


From w3c-dist-auth-request@www10.w3.org  Wed Jan 13 10:53:28 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA15447
	for <w3c-dist-auth@www19.w3.org>; Wed, 13 Jan 1999 10:53:28 -0500 (EST)
Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id KAA17874
	for <w3c-dist-auth@w3.org>; Wed, 13 Jan 1999 10:53:27 -0500 (EST)
Received: from crthub2.crt.xerox.com (crthub2.crt.xerox.com [13.138.80.5])
	by pasiphae.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id KAA28248;
	Wed, 13 Jan 1999 10:53:23 -0500 (EST)
Received: by crthub2.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <CX0049WV>; Wed, 13 Jan 1999 10:52:34 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76D5F@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'francis@appoint.net'" <francis@appoint.net>, w3c-dist-auth@w3.org
Date: Wed, 13 Jan 1999 10:54:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: structured documents [draft-hopmann-collection-props-00.txt]

multipart/related might be part of an implementation of compound documents
-- the way to represent its content when you want to transport the whole
compound document together -- but I doubt that it provides everything people
will want.  For example, normally you expect to be able to operate both on
the compound document as a whole and on each of its components individually.
So there would have to be some instructions to the server to give each
component a URL as well as the parent document.  There probably need to be
some standard poroperties on the compound document as a whole as well as
some on its components. etc.

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580


> -----Original Message-----
> From: John Stracke [mailto:francis@netscape.com]
> Sent: Tuesday, January 12, 1999 6:56 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: structured documents
> [draft-hopmann-collection-props-00.txt]
> 
> 
> Larry Masinter wrote:
> 
> > If support for structured documents is needed for interoperable
> > clients, then it should only be "optional" in the sense of another
> > set of collective features which form yet another standard for
> > which 'conformance implies interoperability'.
> 
> Do we really want to invent our own structured documents model?
> Rhetorical question: what's wrong with multipart/related?
> 
> --
> /====================================================================\
> |John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
> |Software Retrophrenologist|=========================================|
> |Netscape Comm. Corp.      | You! Out of the gene pool!              |
> |francis@netscape.com      |                                         |
> \====================================================================/
> 
> 


From w3c-dist-auth-request@www10.w3.org  Wed Jan 13 11:33:16 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA18188
	for <w3c-dist-auth@www19.w3.org>; Wed, 13 Jan 1999 11:33:15 -0500 (EST)
Received: from phaisos.cube.com (phaisos.cube.com [207.242.168.31])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id LAA18592
	for <w3c-dist-auth@w3.org>; Wed, 13 Jan 1999 11:33:15 -0500 (EST)
Received: from appoint.net (mail1.cubelink.net [207.242.168.65])
	by phaisos.cube.com (8.8.5/8.8.5) with SMTP id MAA15304
	for <w3c-dist-auth@w3.org>; Wed, 13 Jan 1999 12:36:21 -0500
Received: from appoint.net [204.179.134.121] by appoint.net with ESMTP
  (SMTPD32-4.06) id AB411112012A; Wed, 13 Jan 1999 11:35:13 EST
Sender: francis@phaisos.cube.com
Message-ID: <369CA0D3.B9916D65@appoint.net>
Date: Wed, 13 Jan 1999 13:34:11 +0000
>From: John Stracke <francis@appoint.net>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <201BB34B3A73D1118C1F00805F1582E8B76D5F@x-wb-0128-nt8.wrc.xerox.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IMSTrailer: __IMail_4__
Subject: Re: structured documents [draft-hopmann-collection-props-00.txt]

"Slein, Judith A" wrote:

> multipart/related might be part of an implementation of compound documents
> -- the way to represent its content when you want to transport the whole
> compound document together -- but I doubt that it provides everything people
> will want.  For example, normally you expect to be able to operate both on

> the compound document as a whole and on each of its components individually.

But, for that, you can create a multipart/related whose body parts are stored
externally, using a message/external-body (or perhaps just a Content-Location:,
though that's apparently not part of MIME proper).

Advantages of doing structured documents as multipart/related instead of
collections:

   * There are obviously going to be types of structured documents;
     multipart/related already has a mechanism and namespace for specifying
     these types.
   * Given a multipart/related document with externall parts, there's an
     obvious way to serialize the document for transport.
   * Structural sharing: if two structured documents use the same image (for
     example), and the DAV server doesn't support references, then a
     collections-based approach requires that that image be copied, since
     there's no way for a client to tell the server to have it show up in both
     collections.  With a multipart/related approach, you just have both
     documents reference the same image.
   * Cross-server documents: with multipart/related, the external body parts
     can live anywhere on the Net (well, anywhere accessible to the client,
     anyway ;-).  With collections, this works only if the DAV server supports
     references.

(Mind you, I hope references will be pretty common; but, if we don't have to
depend on them, we shouldn't.)

--
/===============================================================\
|John Francis Stracke| http://www.thibault.org |S/MIME & HTML OK|
|francis@thibault.org|==========================================|
|Xton, Mists, West   |NT's lack of reliability is only surpassed|
|My LAN, my opinions.| by its lack of scalability. -- John Kirch|
\===============================================================/




--
[This message was sent using an evaluation copy of
IMail Server for Windows NT, a product of Ipswitch, Inc.]


From w3c-dist-auth-request@www10.w3.org  Wed Jan 13 11:41:15 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA18519
	for <w3c-dist-auth@www19.w3.org>; Wed, 13 Jan 1999 11:41:14 -0500 (EST)
Received: from phaisos.cube.com (phaisos.cube.com [207.242.168.31])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id LAA18693
	for <w3c-dist-auth@w3.org>; Wed, 13 Jan 1999 11:41:13 -0500 (EST)
Received: from appoint.net (mail1.cubelink.net [207.242.168.65])
	by phaisos.cube.com (8.8.5/8.8.5) with SMTP id MAA15566
	for <w3c-dist-auth@w3.org>; Wed, 13 Jan 1999 12:44:20 -0500
Received: from appoint.net [204.179.134.121] by appoint.net with ESMTP
  (SMTPD32-4.06) id AD201B22012A; Wed, 13 Jan 1999 11:43:12 EST
Sender: francis@phaisos.cube.com
Message-ID: <369CA2B1.A2F91914@appoint.net>
Date: Wed, 13 Jan 1999 13:42:09 +0000
>From: John Stracke <francis@appoint.net>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <201BB34B3A73D1118C1F00805F1582E8B76D5E@x-wb-0128-nt8.wrc.xerox.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IMSTrailer: __IMail_4__
Subject: Re: structured documents [draft-hopmann-collection-props-00.txt]

"Slein, Judith A" wrote:

> Just agreeing on what a compound document is could be challenging.  I was
> recently involved in discussions where the following were just some of the
> characteristics proposed:

I believe that these can all be handled by MIME.

> Composed of multiple files

multipart/related, multipart/mixed

> Composed of elements that might not be files (might be database objects,
> cells in a relational database, etc.)

Give 'em a MIME type, maybe define a URL scheme to access them, and you're
done.

> Composed of other documents

Multiparts can contain multiparts.

> Component parts can be independently manipulated

Split them out with message/external-body or Content-Location:.

> Contains multiple renditions

multipart/alternative

> Contains content elements in a variety of formats

Content-Type:

> Is a configuration of specific versions of component documents

This should be addressed by the versioning protocol, since each version will
be a resource.

> Component parts can be shared by multiple compound documents

Split them out (as above).

Now, it may be a good idea for someone to form a WG on how to use MIME and
DAV for compound documents.  But they shouldn't need to create any new
mechanisms; they're all there.  I think.  :-)

--
/===============================================================\
|John Francis Stracke| http://www.thibault.org |S/MIME & HTML OK|
|francis@thibault.org|==========================================|
|Xton, Mists, West   |NT's lack of reliability is only surpassed|
|My LAN, my opinions.| by its lack of scalability. -- John Kirch|
\===============================================================/




--
[This message was sent using an evaluation copy of
IMail Server for Windows NT, a product of Ipswitch, Inc.]


From w3c-dist-auth-request@www10.w3.org  Wed Jan 13 12:08:34 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA20118
	for <w3c-dist-auth@www19.w3.org>; Wed, 13 Jan 1999 12:08:33 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id MAA19210
	for <w3c-dist-auth@w3.org>; Wed, 13 Jan 1999 12:08:27 -0500 (EST)
Received: from tantalum by gw.atria.com id <MAA25799@gw.atria.com> Wed, 13 Jan 1999 12:07:30 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA10925; Wed, 13 Jan 1999 12:07:29 -0500
Date: Wed, 13 Jan 1999 12:07:29 -0500
Message-Id: <9901131707.AA10925@tantalum>
>From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: francis@appoint.net
Cc: w3c-dist-auth@w3.org
In-Reply-To: <369CA2B1.A2F91914@appoint.net> (message from John Stracke on
	Wed, 13 Jan 1999 13:42:09 +0000)
Subject: Re: structured documents [draft-hopmann-collection-props-00.txt]


Given that WebDAV already makes significant use of XML, I would propose
that using XML as the compound document format should be the default choice
unless proven deficient for that purpose.

I realize that everyone has their favorite alternative to XML (and MIME
certainly has its advantages), but it's rather late in the game to switch
from XML to MIME, and depending on both XML *and* some other structured
document format (such as MIME) is a complexity I'd prefer to avoid if at
all possible.

John did have one smiley at the end of his second message, so if the
proposal to consider MIME was just a joke, as they say on SNL,
"nevermind" (:-).

Cheers,
Geoff

   From: John Stracke <francis@appoint.net>

   "Slein, Judith A" wrote:

   > Just agreeing on what a compound document is could be challenging.  I was
   > recently involved in discussions where the following were just some of the
   > characteristics proposed:

   I believe that these can all be handled by MIME.
   ...
   Now, it may be a good idea for someone to form a WG on how to use MIME and
   DAV for compound documents.  But they shouldn't need to create any new
   mechanisms; they're all there.  I think.  :-)

-- 
Geoffrey M. Clemm
Chief Engineer, Configuration Management Business Unit
Rational Software Corporation
(781) 676-2684   geoffrey.clemm@rational.com   http://www.rational.com


From w3c-dist-auth-request@www10.w3.org  Wed Jan 13 12:17:56 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA20599
	for <w3c-dist-auth@www19.w3.org>; Wed, 13 Jan 1999 12:17:56 -0500 (EST)
Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id MAA19421
	for <w3c-dist-auth@w3.org>; Wed, 13 Jan 1999 12:17:55 -0500 (EST)
Received: from crthub2.crt.xerox.com (crthub2.crt.xerox.com [13.138.80.5])
	by pasiphae.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id MAA00395;
	Wed, 13 Jan 1999 12:17:54 -0500 (EST)
Received: by crthub2.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <CX00401D>; Wed, 13 Jan 1999 12:17:05 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76D61@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'John Stracke'" <francis@appoint.net>, w3c-dist-auth@w3.org
Date: Wed, 13 Jan 1999 12:18:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: structured documents [draft-hopmann-collection-props-00.txt]

I agree that if we tackle this problem, we should use existing tools for
implementation if possible.  MIME is certainly a candidate to be taken
seriously.  I see compound documents as a conceptual layer on top of WebDAV
collections or MIME multipart or ... 

--Judy 

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580


From w3c-dist-auth-request@www10.w3.org  Wed Jan 13 12:39:12 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA21397
	for <w3c-dist-auth@www19.w3.org>; Wed, 13 Jan 1999 12:39:11 -0500 (EST)
Received: from phaisos.cube.com (phaisos.cube.com [207.242.168.31])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id MAA19686
	for <w3c-dist-auth@w3.org>; Wed, 13 Jan 1999 12:39:11 -0500 (EST)
Received: from appoint.net (mail1.cubelink.net [207.242.168.65])
	by phaisos.cube.com (8.8.5/8.8.5) with SMTP id NAA17195
	for <w3c-dist-auth@w3.org>; Wed, 13 Jan 1999 13:42:17 -0500
Received: from appoint.net [204.179.134.121] by appoint.net with ESMTP
  (SMTPD32-4.06) id AAAF30A20070; Wed, 13 Jan 1999 12:41:03 EST
Sender: francis@phaisos.cube.com
Message-ID: <369CB040.78D5FC54@appoint.net>
Date: Wed, 13 Jan 1999 14:40:01 +0000
>From: John Stracke <francis@appoint.net>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <9901131707.AA10925@tantalum>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IMSTrailer: __IMail_4__
Subject: Re: structured documents [draft-hopmann-collection-props-00.txt]

"Geoffrey M. Clemm" wrote:

> Given that WebDAV already makes significant use of XML, I would propose
> that using XML as the compound document format should be the default choice
> unless proven deficient for that purpose.

Hmm.  Does there already exist an XML DTD for compound documents?

> I realize that everyone has their favorite alternative to XML (and MIME
> certainly has its advantages), but it's rather late in the game to switch
> from XML to MIME, and depending on both XML *and* some other structured
> document format (such as MIME) is a complexity I'd prefer to avoid if at
> all possible.

We already depend on MIME at least a little bit, because we're based on HTTP.

My feeling is that, while XML is a good format for single documents, there is no
good reason to use it to duplicate the MIME mechanisms.  MIME is more widely
deployed, understood, and supported; and it already does what we want.  Plus, as a
(blech) political point, any working group that attempts to reimplement MIME is
going to face objections from the IETF community, asking why they didn't stick
with the protocol that was already there.  (And God help any working group that
reimplements MIME and omits an obscure feature in a subclause in RFC 31415926536.
:-)

> John did have one smiley at the end of his second message, so if the
> proposal to consider MIME was just a joke,

No, it just applied to the "I think"--an acknowledgment that I don't have as much
experience as the people I'm disputing.  :-)

--
/===============================================================\
|John Francis Stracke| http://www.thibault.org |S/MIME & HTML OK|
|francis@thibault.org|==========================================|
|Xton, Mists, West   |NT's lack of reliability is only surpassed|
|My LAN, my opinions.| by its lack of scalability. -- John Kirch|
\===============================================================/




--
[This message was sent using an evaluation copy of
IMail Server for Windows NT, a product of Ipswitch, Inc.]


From w3c-dist-auth-request@www10.w3.org  Wed Jan 13 13:16:53 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA23363
	for <w3c-dist-auth@www19.w3.org>; Wed, 13 Jan 1999 13:16:52 -0500 (EST)
Received: from phaisos.cube.com (phaisos.cube.com [207.242.168.31])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id NAA20333
	for <w3c-dist-auth@w3.org>; Wed, 13 Jan 1999 13:16:52 -0500 (EST)
Received: from appoint.net (mail1.cubelink.net [207.242.168.65])
	by phaisos.cube.com (8.8.5/8.8.5) with SMTP id OAA18375
	for <w3c-dist-auth@w3.org>; Wed, 13 Jan 1999 14:19:58 -0500
Received: from appoint.net [204.179.134.121] by appoint.net with ESMTP
  (SMTPD32-4.06) id A38A4B7A0070; Wed, 13 Jan 1999 13:18:50 EST
Sender: francis@phaisos.cube.com
Message-ID: <369CB91B.BD89E6ED@appoint.net>
Date: Wed, 13 Jan 1999 15:17:47 +0000
>From: John Stracke <francis@appoint.net>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <201BB34B3A73D1118C1F00805F1582E8B76D61@x-wb-0128-nt8.wrc.xerox.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IMSTrailer: __IMail_4__
Subject: Re: structured documents [draft-hopmann-collection-props-00.txt]

"Slein, Judith A" wrote:

> I agree that if we tackle this problem, we should use existing tools for
> implementation if possible.  MIME is certainly a candidate to be taken
> seriously.  I see compound documents as a conceptual layer on top of WebDAV
> collections or MIME multipart or ...

The practical problem with layering like this is that you can't actually vary
the lower layers and still keep interoperability.  How many implementations of
HTTP, or SMTP, have you seen that were not running over TCP? It could be done,
but the resulting software would be limited to a small island of
connectivity.  Similarly, if a compound document spec just specifies the
concepts, and leaves the representation up to implementers, then we don't have
interop.  Whatever working group addresses this problem may want to layer the
spec conceptually, but they should make sure they specify a recommended
representation, too.  Otherwise we'll all be stuck using different
representations, and we'll have chaos until everybody migrates to whatever
representation Microsoft decides to build into Office.  (No offense meant.
Microsoft *might* spontaneously come up with the best of all possible
protocols; but the point of standards bodies is to make sure we don't have to
rely on them to do so.)

--
/==============================================================\
|John Stracke       | My opinions are my own |S/MIME & HTML OK |
|francis@appoint.net|==========================================|
|Chief Scientist    |NT's lack of reliability is only surpassed|
|Appoint.Net, Inc.  | by its lack of scalability. -- John Kirch|
\==============================================================/




--
[This message was sent using an evaluation copy of
IMail Server for Windows NT, a product of Ipswitch, Inc.]


From w3c-dist-auth-request@www10.w3.org  Wed Jan 13 13:43:38 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA25033
	for <w3c-dist-auth@www19.w3.org>; Wed, 13 Jan 1999 13:43:38 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id NAA20737
	for <w3c-dist-auth@w3.org>; Wed, 13 Jan 1999 13:43:36 -0500 (EST)
Received: from tantalum by gw.atria.com id <NAA08415@gw.atria.com> Wed, 13 Jan 1999 13:42:40 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA11062; Wed, 13 Jan 1999 13:42:39 -0500
Date: Wed, 13 Jan 1999 13:42:39 -0500
Message-Id: <9901131842.AA11062@tantalum>
>From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: francis@appoint.net
Cc: w3c-dist-auth@w3.org
In-Reply-To: <369CB040.78D5FC54@appoint.net> (message from John Stracke on
	Wed, 13 Jan 1999 14:40:01 +0000)
Subject: Re: structured documents [draft-hopmann-collection-props-00.txt]

   From: John Stracke <francis@appoint.net>

   "Geoffrey M. Clemm" wrote:

   > Given that WebDAV already makes significant use of XML, I would propose
   > that using XML as the compound document format should be the default choice
   > unless proven deficient for that purpose.

   Hmm.  Does there already exist an XML DTD for compound documents?

XML provides the mechanisms for specifying "immediate" data and references
to other resources.  A DTD just specifies a particular type of
compound document (or at least, specifies its syntax).  Providing
a MIME namespace and DTD's to support interoperability between MIME and
XML would be fine, but that's very different from using MIME as the
structured document format for WebDAV.

   > I realize that emveryone has their favorite alternative to XML (and MIME
   > certainly has its advantages), but it's rather late in the game to switch
   > from XML to MIME, and depending on both XML *and* some other structured
   > document format (such as MIME) is a complexity I'd prefer to avoid if at
   > all possible.

   We already depend on MIME at least a little bit, because we're based on HTTP.

Can you be more specific?  I don't remember ever feeling the need to read
any MIME spec to understand some part of WebDAV (and I read a *large*
number of specs during my recusive descent into WebDAV-world :-).

   My feeling is that, while XML is a good format for single documents, there is no
   good reason to use it to duplicate the MIME mechanisms.

A good reason would be if XML already provides the required MIME
functionality, and is already an explicit and widely used component of
WebDAV, then the spec is needlessly complicated by introducing MIME.

    MIME is more widely
    deployed, understood, and supported; and it already does what we want.

There are many things that are widely deployed, understood, and supported
than XML (and certainly than WebDAV), but selecting an additional redundant
format just because it is widely deployed is a major step against
interoperability.

  Plus, as a
   (blech) political point, any working group that attempts to reimplement MIME is
   going to face objections from the IETF community, asking why they didn't stick
   with the protocol that was already there.

We are sticking with a protocol that was already there ... it's just that
it is XML, and not MIME.  So I need to see a convincing argument
that MIME provides essential functionality not already provided by XML.

To emphasize, I'm not saying there is no such argument that could be
made -- it's just that I haven't seen it, and I subscribe strongly to the
"keep it out of the spec until proven necessary" philosophy.

   (And God help any working group that
   reimplements MIME and omits an obscure feature in a subclause in RFC 31415926536.
   :-)

Which illustrates why I would resist seeing MIME as a required part of the
WebDAV spec (:-).

Cheers,
Geoff


From w3c-dist-auth-request@www10.w3.org  Thu Jan 14 15:48:13 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA26928
	for <w3c-dist-auth@www19.w3.org>; Thu, 14 Jan 1999 15:48:13 -0500 (EST)
Received: from m7300a.mecom.mecomnet.de (mail.mecomnet.de [194.152.58.195])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id PAA06326
	for <w3c-dist-auth@w3.org>; Thu, 14 Jan 1999 15:48:10 -0500 (EST)
Received: from mecomnet.de by m7300a.mecom.mecomnet.de (AppleShare IP Mail Server 6.1b3) id 2912 via TCP with SMTP; Sat, 14 Nov 1998 21:51:48 +0100
Message-ID: <369E5901.86B78F5F@mecomnet.de>
Date: Thu, 14 Jan 1999 21:52:46 +0100
>From: james anderson <James.Anderson@mecomnet.de>
Reply-To: James.Anderson@mecomnet.de
Organization: mecom gmbh
X-Mailer: Mozilla 4.04 (Macintosh; I; PPC)
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <201BB34B3A73D1118C1F00805F1582E8B76D5F@x-wb-0128-nt8.wrc.xerox.com> <369CA0D3.B9916D65@appoint.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: structured documents [draft-hopmann-collection-props-00.txt]

[please note - beyond what one can set in a browser, my experience with mime
types ends with 'text/xml'.]

while  i won't assert, given a cursory reading of rfc 1521, that multipart is
obsolete, i wouldn't deny it either.


John Stracke wrote:
> 
> 
> Advantages of doing structured documents as multipart/related instead of
> collections:
> 
>    * There are obviously going to be types of structured documents;
>      multipart/related already has a mechanism and namespace for specifying
>      these types.

as does xml - dtd's - or whatever schema form follows on. xml has the
disadvantage that it does not permit inline encoding variations, but it does
permit references to arbitrary external encodings (including those covered by
mime types) and it does offer better means to discover document structure.

>    * Given a multipart/related document with external parts, there's an
>      obvious way to serialize the document for transport.

xml is incomplete in this regard, but only in the sense the the possible
semantics of links is not yet "ratified". 

>    * Structural sharing: if two structured documents use the same image (for
>      example), and the DAV server doesn't support references, then a
>      collections-based approach requires that that image be copied, since
>      there's no way for a client to tell the server to have it show up in both
>      collections.  With a multipart/related approach, you just have both
>      documents reference the same image.

wouldn't href="..." or imgsrc="..." accomplish the same thing.

>    * Cross-server documents: with multipart/related, the external body parts
>      can live anywhere on the Net (well, anywhere accessible to the client,
>      anyway ;-).  With collections, this works only if the DAV server supports
>      references.

i have to look back at the webdav spec for this....
i'm not sure what the issue is in this paragraph. "reference" does not appear
to be a special term w.r.t dav collections. which i would take to mean that
uri's suffice - which i would expect any http-capable server to support... ?


From w3c-dist-auth-request@www10.w3.org  Thu Jan 14 16:41:56 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA28488
	for <w3c-dist-auth@www19.w3.org>; Thu, 14 Jan 1999 16:41:52 -0500 (EST)
Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id QAA07039
	for <w3c-dist-auth@w3.org>; Thu, 14 Jan 1999 16:41:52 -0500 (EST)
Received: from crthub.crt.xerox.com (crthub.crt.xerox.com [13.138.80.3])
	by pasiphae.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id QAA26533;
	Thu, 14 Jan 1999 16:40:35 -0500 (EST)
Received: by crthub.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <CP6GSZM6>; Thu, 14 Jan 1999 16:41:25 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76D66@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'James.Anderson@mecomnet.de'" <James.Anderson@mecomnet.de>,
        w3c-dist-auth@w3.org
Date: Thu, 14 Jan 1999 16:41:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: structured documents [draft-hopmann-collection-props-00.txt]

> -----Original Message-----
> From: james anderson [mailto:James.Anderson@mecomnet.de]
> Sent: Thursday, January 14, 1999 3:53 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: structured documents
> [draft-hopmann-collection-props-00.txt]
> 
> 
> >    * Cross-server documents: with multipart/related, the 
> external body parts
> >      can live anywhere on the Net (well, anywhere 
> accessible to the client,
> >      anyway ;-).  With collections, this works only if the 
> DAV server supports
> >      references.
> 
> i have to look back at the webdav spec for this....
> i'm not sure what the issue is in this paragraph. "reference" 
> does not appear
> to be a special term w.r.t dav collections. which i would 
> take to mean that
> uri's suffice - which i would expect any http-capable server 
> to support... ?
> 

There are several specifications being worked on in addition to the core
WebDAV specification.  One of them is on advanced collections and includes
referencing and ordered collections:

http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-collecti
on-protocol-02.txt


From w3c-dist-auth-request@www10.w3.org  Sat Jan 16 21:39:25 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA00876
	for <w3c-dist-auth@www19.w3.org>; Sat, 16 Jan 1999 21:39:24 -0500 (EST)
Received: from gw.atria.com (gw.atria.com [192.88.237.2])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id LAA28329
	for <w3c-dist-auth@w3.org>; Sat, 16 Jan 1999 11:56:18 -0500 (EST)
Received: from tantalum by gw.atria.com id <LAA23083@gw.atria.com> Sat, 16 Jan 1999 11:56:17 -0500 (EST)
Received: by tantalum (5.x/920526.BPD)
	id AA12304; Sat, 16 Jan 1999 11:56:16 -0500
Date: Sat, 16 Jan 1999 11:56:16 -0500
>From: gclemm@atria.com (Geoffrey M. Clemm)
Message-Id: <9901161656.AA12304@tantalum>
To: w3c-dist-auth@w3.org
Subject: Protocol Design: new XML elements in the body or new headers?

Many of the new methods being defined for WebDAV versioning have
an XML document as the value of their request and/or response body.
While designing the protocol, I am continually faced with the question:

Should an input parameter to the method be represented as a new XML
element in the request body or as a new request header?  Similarly,
should an output parameter to the method be represented as a new XML
element in the response body or as a new respose header?

In each case, there is backward compatibility, since downlevel clients
would just not generate the header/element, and downlevel servers
would just ignore the unknown header/element.

An argument for the XML element is that the contents of the XML element
can hold a much wider range of data, and can have its structure defined,
at least in a coarse syntactic fashion, with a DTD.

Another argument for the XML element is that you don't have to worry
about proxies stripping off headers they don't recognize.

The only argument I can think of for using a header is that it is
the only technique applicable when the body is being used for some
other purpose (such as GET/PUT).

One possible rule of thumb:

If the request/response body is an XML document, then the request/response
parameters should be specified as XML elements.  Only if the body is not an
XML document should parameters be specified as headers.

Comments?

Cheers,
Geoff

---
Geoffrey M. Clemm
Chief Engineer, Configuration Management Business Unit
Rational Software Corporation
(781) 676-2684   geoffrey.clemm@rational.com   http://www.rational.com


From w3c-dist-auth-request@www10.w3.org  Sun Jan 17 01:44:06 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA03732
	for <w3c-dist-auth@www19.w3.org>; Sun, 17 Jan 1999 01:44:06 -0500 (EST)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id BAA02134
	for <w3c-dist-auth@w3.org>; Sun, 17 Jan 1999 01:44:05 -0500 (EST)
Received: by mail4.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <CZ8X0MGD>; Sat, 16 Jan 1999 22:44:04 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792D2A@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'gclemm@atria.com'" <gclemm@atria.com>, w3c-dist-auth@w3.org
Date: Sat, 16 Jan 1999 22:44:02 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Protocol Design: new XML elements in the body or new headers?

http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0113.html

> -----Original Message-----
> From: gclemm@atria.com [mailto:gclemm@atria.com]
> Sent: Saturday, January 16, 1999 8:56 AM
> To: w3c-dist-auth@w3.org
> Subject: Protocol Design: new XML elements in the body or new headers?
> 
> 
> Many of the new methods being defined for WebDAV versioning have
> an XML document as the value of their request and/or response body.
> While designing the protocol, I am continually faced with the 
> question:
> 
> Should an input parameter to the method be represented as a new XML
> element in the request body or as a new request header?  Similarly,
> should an output parameter to the method be represented as a new XML
> element in the response body or as a new respose header?
> 
> In each case, there is backward compatibility, since downlevel clients
> would just not generate the header/element, and downlevel servers
> would just ignore the unknown header/element.
> 
> An argument for the XML element is that the contents of the 
> XML element
> can hold a much wider range of data, and can have its 
> structure defined,
> at least in a coarse syntactic fashion, with a DTD.
> 
> Another argument for the XML element is that you don't have to worry
> about proxies stripping off headers they don't recognize.
> 
> The only argument I can think of for using a header is that it is
> the only technique applicable when the body is being used for some
> other purpose (such as GET/PUT).
> 
> One possible rule of thumb:
> 
> If the request/response body is an XML document, then the 
> request/response
> parameters should be specified as XML elements.  Only if the 
> body is not an
> XML document should parameters be specified as headers.
> 
> Comments?
> 
> Cheers,
> Geoff
> 
> ---
> Geoffrey M. Clemm
> Chief Engineer, Configuration Management Business Unit
> Rational Software Corporation
> (781) 676-2684   geoffrey.clemm@rational.com   http://www.rational.com
> 


From w3c-dist-auth-request@www10.w3.org  Mon Jan 18 09:06:38 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA11317
	for <w3c-dist-auth@www19.w3.org>; Mon, 18 Jan 1999 09:06:38 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id JAA13337
	for <w3c-dist-auth@w3.org>; Mon, 18 Jan 1999 09:06:36 -0500 (EST)
Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa14287;
          18 Jan 99 6:04 PST
To: "Geoffrey M. Clemm" <gclemm@atria.com>
cc: w3c-dist-auth@w3.org
In-reply-to: Your message of "Sat, 16 Jan 1999 11:56:16 EST."
             <9901161656.AA12304@tantalum> 
Date: Mon, 18 Jan 1999 06:04:20 -0800
>From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-ID:  <9901180604.aa14287@paris.ics.uci.edu>
Subject: Re: Protocol Design: new XML elements in the body or new headers? 

>Many of the new methods being defined for WebDAV versioning have
>an XML document as the value of their request and/or response body.
>While designing the protocol, I am continually faced with the question:
>
>Should an input parameter to the method be represented as a new XML
>element in the request body or as a new request header?  Similarly,
>should an output parameter to the method be represented as a new XML
>element in the response body or as a new respose header?

The body of an HTTP request/response is payload.  If it contains anything
significant to the semantics of the operation or result, aside from a
representation of data as defined by those semantics, then it isn't HTTP.
It is something else tunneling inside HTTP, which is a waste of bytes.

In general, if you find yourself with many new methods and request
header fields, then it means there is something fundamentally wrong
with the protocol design.  Usually the fix is to do the same thing
with far fewer extensions simply by using a redirect to a different
resource rather than using new methods/fields to act indirectly.

This is from experience -- I haven't looked at the WebDAV versioning
stuff at all.

....Roy


From w3c-dist-auth-request@www10.w3.org  Mon Jan 18 20:22:28 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA20108
	for <w3c-dist-auth@www19.w3.org>; Mon, 18 Jan 1999 20:22:27 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id UAA19764
	for <w3c-dist-auth@w3.org>; Mon, 18 Jan 1999 20:22:25 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa29120;
          18 Jan 99 17:14 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Mon, 18 Jan 1999 17:12:49 -0800
Message-ID: <000001be4348$d4ea8c40$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: Advanced Collections conference call minutes

The minutes from the January 14, 1998 conference call on Advanced
Collections have been placed on the WebDAV web site, at:

http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes990114.txt

An intermediate draft of the Advanced Collections protocol specification,
produced for discussion during the conference call, is available at:

http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/CollSpec021.txt

These are both also available via the WebDAV WG home page:

http://www.ics.uci.edu/pub/ietf/webdav/

Thanks are due to Judy Slein for her work in organizing the conference call,
producing the intermediate draft, and generating minutes so quickly
afterwards.

- Jim


From w3c-dist-auth-request@www10.w3.org  Mon Jan 18 20:30:13 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA20203
	for <w3c-dist-auth@www19.w3.org>; Mon, 18 Jan 1999 20:30:13 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id UAA19803
	for <w3c-dist-auth@w3.org>; Mon, 18 Jan 1999 20:30:12 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa29705;
          18 Jan 99 17:24 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: "Geoffrey M. Clemm" <gclemm@atria.com>, WEBDAV WG <w3c-dist-auth@w3.org>
Date: Mon, 18 Jan 1999 17:23:18 -0800
Message-ID: <000101be434a$4ba1fa20$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <9901161656.AA12304@tantalum>
Subject: RE: Protocol Design: new XML elements in the body or new headers?

> Many of the new methods being defined for WebDAV versioning have
> an XML document as the value of their request and/or response body.
> While designing the protocol, I am continually faced with the question:
>
> Should an input parameter to the method be represented as a new XML
> element in the request body or as a new request header?  Similarly,
> should an output parameter to the method be represented as a new XML
> element in the response body or as a new respose header?

I discussed some of these marshalling issues in a workshop paper I wrote for
the HTTP Future workshop held at WWW7 last year -- it complements Yaron's
header/body rationale post. The paper is titled, "Lessons from WebDAV for
the Next Generation Web Infrastructure", and covers the topics of parameter
marshalling, multi-resource operations, operations on resource hierarchies,
status reporting, and built-in lock support.  The paper was written to try
and separate out the "take-home" lessons from WebDAV which would be of
interest to future protocol authors, specifically for HTTP-NG.

The position paper is available at:

http://www.ics.uci.edu/~ejw/http-future/whitehead/http_pos_paper.html

- Jim


From w3c-dist-auth-request@www10.w3.org  Mon Jan 18 23:30:56 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA21401
	for <w3c-dist-auth@www19.w3.org>; Mon, 18 Jan 1999 23:30:56 -0500 (EST)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id XAA20983
	for <w3c-dist-auth@w3.org>; Mon, 18 Jan 1999 23:30:55 -0500 (EST)
Received: by mail4.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <CZ8YDZCC>; Mon, 18 Jan 1999 20:30:54 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792D42@RED-MSG-59>
>From: Yaron Goland <yarong@microsoft.com>
To: "'ejw@ics.uci.edu'" <ejw@ics.uci.edu>, WEBDAV WG
	 <w3c-dist-auth@w3.org>
Date: Mon, 18 Jan 1999 20:30:52 -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Subject: RE: Advanced Collections conference call minutes

I would appreciate it if the collection meeting minutes were edited to say
something along the lines of: "Yaron, at the December 1998 IETF, stated that
he believed that no-passthrough was the equivalent of URL munging."

People generally do URL munging to save themselves a round trip. Instead of
trying to search for the resource you want to execute a method against, just
tack the search request to the end of the URL and let the server handle
everything for you. In the case of no-passthrough instead of discovering the
address of a resource which you can use to manage the reference you just use
the no-passthrough header. No-passthrough = true and you are editing the
reference resource. No-passthrough = false and you are editing the resource
being referenced. The whole thing smells too much like the derefencing
mistake WebDAV tried early on (see:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html).

On the other hand, one could look at no-passthrough as an argument to the
method which specifies if the method should be reflected or not.

It would be an interesting exercise to design a mechanism which allows you
to create new names for existing resources and then see what kind of errors
you have to handle because you went off-line. I bet the design issues would
be similar to weak references. I also bet the design would be a lot simpler
than the current referential resource design. So many interesting
problems... so little time.

						Yaron


> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@ics.uci.edu]
> Sent: Monday, January 18, 1999 5:13 PM
> To: WEBDAV WG
> Subject: Advanced Collections conference call minutes
> 
> 
> The minutes from the January 14, 1998 conference call on Advanced
> Collections have been placed on the WebDAV web site, at:
> 
> http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes990114.txt
> 
> An intermediate draft of the Advanced Collections protocol 
> specification,
> produced for discussion during the conference call, is available at:
> 
> http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/CollSpec021.txt
> 
> These are both also available via the WebDAV WG home page:
> 
> http://www.ics.uci.edu/pub/ietf/webdav/
> 
> Thanks are due to Judy Slein for her work in organizing the 
> conference call,
> producing the intermediate draft, and generating minutes so quickly
> afterwards.
> 
> - Jim
> 


From w3c-dist-auth-request@www10.w3.org  Tue Jan 19 15:24:17 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA02870
	for <w3c-dist-auth@www19.w3.org>; Tue, 19 Jan 1999 15:24:17 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id PAA29723
	for <w3c-dist-auth@w3.org>; Tue, 19 Jan 1999 15:24:16 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa16439;
          19 Jan 99 12:13 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: Yaron Goland <yarong@microsoft.com>, WEBDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 19 Jan 1999 12:12:16 -0800
Message-ID: <002601be43e8$02b45940$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792D42@RED-MSG-59>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: RE: Advanced Collections conference call minutes


> I would appreciate it if the collection meeting minutes were edited to say
> something along the lines of: "Yaron, at the December 1998 IETF,
> stated that he believed that no-passthrough was the equivalent of URL
munging."

Amended.

- Jim


From w3c-dist-auth-request@www10.w3.org  Tue Jan 19 15:37:17 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA03182
	for <w3c-dist-auth@www19.w3.org>; Tue, 19 Jan 1999 15:37:16 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id PAA29869
	for <w3c-dist-auth@w3.org>; Tue, 19 Jan 1999 15:37:15 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa18077;
          19 Jan 99 12:30 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 19 Jan 1999 12:28:22 -0800
Message-ID: <002901be43ea$43071b20$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: FW: I-D ACTION:draft-bradner-handshake-03.txt

FYI.

- Jim

-----Original Message-----
>From: cclark@ns.cnri.reston.va.us [mailto:cclark@ns.cnri.reston.va.us]
On Behalf Of Internet-Drafts@ietf.org
Sent: Tuesday, January 19, 1999 8:04 AM
To: IETF-Announce: ;
Subject: I-D ACTION:draft-bradner-handshake-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Secret Handshakes: How to get RFCs published in the IETF
	Author(s)	: S. Bradner
	Filename	: draft-bradner-handshake-03.txt
	Pages		: 6
	Date		: 18-Jan-99

   There is confusion over how to get an RFC published in the IETF.
   Recently a long time IETF participant asked me what 'secret
   handshake' was need to get documents published as RFCs since he had
   been trying unsuccessfully to get that done.  This memo is the result
   of that query and describes the procedures required, gives the proper
   references and the required email addresses.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bradner-handshake-03.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-bradner-handshake-03.txt".

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

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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-bradner-handshake-03.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.


From w3c-dist-auth-request@www10.w3.org  Tue Jan 19 17:05:02 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA06016
	for <w3c-dist-auth@www19.w3.org>; Tue, 19 Jan 1999 17:05:01 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id RAA01297
	for <w3c-dist-auth@w3.org>; Tue, 19 Jan 1999 17:05:00 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa26088;
          19 Jan 99 13:50 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 19 Jan 1999 13:49:08 -0800
Message-ID: <003401be43f5$8afdf420$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: Next meeting: Minneapolis IETF

The next full meeting of the WebDAV WG will be held during IETF-44, in
Minneapolis, MN (USA), March 15-19, 1999.  At present, I have submitted a
request for a meeting slot, but I do not yet know when the WebDAV WG meeting
will be held during the week.  Like the Orlando IETF, I expect there will
also be some WebDAV-related breakout sessions, in addition to the main
meeting.

For information on the Minneapolis IETF meeting, including hotel and
registration information, consult the Minneapolis IETF Web page:

http://www.ietf.org/meetings/IETF-44.html

Experienced IETF attendees know that spaces in the main hotel tend to fill
quickly, so plan accordingly.

- Jim


From w3c-dist-auth-request@www10.w3.org  Tue Jan 19 18:22:15 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA07648
	for <w3c-dist-auth@www19.w3.org>; Tue, 19 Jan 1999 18:22:14 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id SAA02369
	for <w3c-dist-auth@w3.org>; Tue, 19 Jan 1999 18:22:13 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa05726;
          19 Jan 99 15:17 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 19 Jan 1999 15:15:49 -0800
Message-ID: <004101be4401$a6f6c9c0$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: FYI: Next Versioning & Variant Design Team

As a matter of public record, the next Versioning and Variant Authoring
Design Team meeting will be held February 10-11, 1999, in Orem, Utah, hosted
by Novell.

- Jim


From w3c-dist-auth-request@www10.w3.org  Tue Jan 19 18:42:28 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA08566
	for <w3c-dist-auth@www19.w3.org>; Tue, 19 Jan 1999 18:42:28 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id SAA02587
	for <w3c-dist-auth@w3.org>; Tue, 19 Jan 1999 18:42:26 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa07436;
          19 Jan 99 15:34 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 19 Jan 1999 15:32:55 -0800
Message-ID: <004201be4404$0ae832a0$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: WebDAV Tutorials

I'd like to let you know about two upcoming tutorials on WebDAV.

* The Web as a Collaborative, Writeable Medium: An Introduction
  to the IETF WebDAV Standard
  - Taught by Jim Whitehead
  - Hypertext'99 Conference, Darmstadt, Germany
  - February 22, 1999
    http://www.kom.e-technik.tu-darmstadt.de/~ht99/html/courses.html
    http://www.kom.e-technik.tu-darmstadt.de/~ht99/


* HTTP extensions for Web Collaboration (WebDAV)
  - Taught by Jim Davis
  - WWW8 Conference, Toronto, Canada
  - May 11, 1999
    http://www8.org/tutorials.html#HTTP%20extensions
    http://www8.org/


Either tutorial would be an excellent, and comparatively inexpensive way to
get up-to-speed on the WebDAV protocol.

- Jim


From w3c-dist-auth-request@www10.w3.org  Wed Jan 20 16:36:24 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA11454
	for <w3c-dist-auth@www19.w3.org>; Wed, 20 Jan 1999 16:36:24 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id QAA17552
	for <w3c-dist-auth@w3.org>; Wed, 20 Jan 1999 16:36:23 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa20768;
          20 Jan 99 13:19 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Wed, 20 Jan 1999 13:17:50 -0800
Message-ID: <000601be44ba$5616e760$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: Minutes from Jan. 19, 1999 Adv. Coll. Call

The minutes from the Jan. 19, 1999 Advanced Collections conference call are
now available online at:

http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes990119.txt

An interim version of the Advanced Collections protocol spec. created for
this meeting is also available, at:

http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/CollSpec022.txt

The Advanced Collections issues list was also updated, and is available at:

http:/www.ics.uci.edu/pub/ietf/webdav/collection/issues.html

- Jim


From w3c-dist-auth-request@www10.w3.org  Thu Jan 21 21:23:01 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA10839
	for <w3c-dist-auth@www19.w3.org>; Thu, 21 Jan 1999 21:23:01 -0500 (EST)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id VAA05900
	for <w3c-dist-auth@w3.org>; Thu, 21 Jan 1999 21:22:59 -0500 (EST)
Received: from mailback.parc.xerox.com ([13.1.101.39]) by alpha.xerox.com with SMTP id <55325(5)>; Thu, 21 Jan 1999 18:22:51 PST
Received: from schuur ([13.0.209.76]) by mailback.parc.xerox.com with SMTP id <147478>; Thu, 21 Jan 1999 18:22:46 PST
Message-Id: <3.0.3.32.19990121182238.00957ba0@mailback.parc.xerox.com>
X-Sender: jdavis@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 21 Jan 1999 18:22:38 PST
To: "Alex Hopmann" <alexhop@microsoft.com>
>From: Jim Davis <jdavis@parc.xerox.com>
Cc: w3c-dist-auth@w3.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: comments on draft-hopmann-collection-props-00.txt

Alex, some comments on your internet draft, organized by the section
number.  Some of these are clarifying questions, some are just
glitches, and are substantive.

section 2, paragraph three, says
   This document follows the same collections as the WebDAV protocol 
   specification [1] for defining these properties. 

The word 'collections' should be 'conventions'

The subsections within this section are numbered from 1.2 but should
be from 2.1

1.2  childcount

Does this include hidden?  The definition should explicitly say it does. 

I am puzzled by the three 'count' properties.
you have 
 childcount == count all children
 objectcount == count all children that are not folders
 visiblecount == count all children that are not folders or hidden

The count of folders is childcount - objectcount, right?


right?

One criticism I have of all these countings is that it seems hard to
generalize.  Likewise, there are some things one can't count, such as 
the number of non-hidden objects of any type. 

Would it perhaps be better to define a generalized "partition" of the
collection members, so you could slice it up in multiple, nested ways?

Here's a sketch of how to do that

<!ELEMENT division count name? partition*) >
<!ELEMENT partition division+?>
<!ELEMENT count PCDATA>
<!ELEMENT name PCDATA>

A division has a count, an optional name, and an optional set of
partitions.  Here, a name is just a string.  (You might prefer it to
be a propertyname or even a (boolean valued) expression.  I don't
care.)

The name is intended to serve the same purpose as the
isstructuredocument property, it's a hint to the UI about how to
display the thing.

Simple example.  A collection with 17 members, of which 12 are
folders, and the rest are something else

<division>
 <count>17</count>
 <partition>
   <division>
     <count>12</count>
     <name>folder</name>
   </division>
   <division>
     <count>5</count>
   </division>
 <partition>
</division>

Since the sum of counts of the divisions of a partition must sum to
the count of the containing division, the final (none of the above)
division may be omitted, so we can write the above as

<division>
 <count>17</count>
 <partition>
   <division>
     <count>12</count>
     <name>folder</name>
   </division>
 <partition>
</division>

Same collection, with 17 members.  The 12 folders are further
partitioned into 5 'special' folders, 2 'reserved' folders, and the
remaining five are just 'generic' folders.

<division>
 <count>17</count>
 <partition>
   <division>
     <count>12</count>
     <name>folder</name>
     <partition>
       <division>
         <count>5</count>
         <name>special</name>
       </division>       
       <division>
         <count>2</count>
         <name>reserved</name>
       </division>       
     </partition>
   </division>
 <partition>
</division>


Same as above, with two alternate partitions of the seventeen
members.  The first one is based on the folder/non-folder distinction,
the second on the hidden/non-hidden distinction.
<division>
 <count>17</count>
 <partition>
   <division>
     <count>12</count>
     <name>folder</name>
     <partition>
       <division>
         <count>5</count>
         <name>special</name>
       </division>       
       <division>
         <count>2</count>
         <name>reserved</name>
       </division>       
     </partition>
   </division>
 <partition>
 <partition>
   <division>
     <count>2</count>
     <name>hidden</name>
   </division>
 <partition>
</division>

 You could also express this with only one top level partition
(folder/non folder) where each of its two divisions was then divided
by hidden/non-hidden.
   

1.3 defaultdocument 

Is this supposed to define what GET on a collection returns?  If so it
should say so.

Must the resource identified by defaultdocument be an (immediate)
member of the collection?

1.4 id 

Would a weak etag suffice for this purpose?

If a resource is copied (not moved) must the copy have a different id?
If so, then how do you MOVE, sinnce MOVE is COPY plus DELETE.  And
likewise, how could I use the id for replication?  On the other hand,
if a copy kept the id, then if you edited one copy and not the other,
you'd have two different resources, with the same ID but  different
contents.  On the other hand, since you don't change the ID when you
edit the resource, this could happen anyway (given a caching proxy)

1.5 isfolder

The DTD for this item defines ishidden not isfolder

Why can't you make this a "subtype" of the DAV:resourcetype property?

<collection></folder></collection>

1.6 ishidden

The text Description says "If this property is absent, the collection
is not hidden." the word "collection" should be "resource"


1.7 isstructureddocument

Why not use dav:resourcetype for this?

<collection><structured/></collection?

The Purpose referers to the "iscollection" property, which is
undefined.

(typo) missing a newline before the Definition

1.8 hassubs

would be better named "hassubfolders"

1.9 nosubs

Perhaps a better name is "contraception" or "sterile" since the
meaning is that one can't create any more children.  Hmm, that's a bad
plan, it would make the republicans not want to fund WebDAV.  Okay,
how about instead "nocreatechildren"? or even "dontmkcol".

Otherwise it's too easy for people to confuse this with meaning "this
collection has no subfolders"

1.10 objectcount

does this count hidden items?

1.11 reserved

Could a plain (non collection) resource also be reserved?

Can one do a PROPPATCH on a reserved collection?  Can one do an
ORDERPATCH (from the Advanced Collection Resources draft)

Would a printer queue be a good example of reserved?

1.12 visiblecount

The definition DTD is for 'reserved' not 'visiblecount'

I'd like to suggest an additional property, "ispaged".  If this
property is true of a collection it means there is a one to one
correspondance between the children of the collection and the 'pages'
of a document.  So for instance, if you scanned a document into a
collection of TIFF files, that collection would have the ispaged set.
Or if you saved a powerpoint file into HTML, creating one HTML
resource for each slide, that would also be paged.

If the collection is ordered, as in ACR, then the collection ordering
corresponds to the page ordering.

best regards

Jim Davis



From w3c-dist-auth-request@www10.w3.org  Thu Jan 21 21:33:40 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA11040
	for <w3c-dist-auth@www19.w3.org>; Thu, 21 Jan 1999 21:33:40 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id VAA05987
	for <w3c-dist-auth@w3.org>; Thu, 21 Jan 1999 21:33:38 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa08226;
          21 Jan 99 18:29 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Thu, 21 Jan 1999 18:27:41 -0800
Message-ID: <000201be45ae$c9940660$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: New interim advanced collections protocol spec.

A new, interim version of the advanced collections protocol specification
has been updated, and placed on the WebDAV Web site at:

http://www.ics.uci.edu/pub/ietf/webdav/collections/dt/CollSpec023.txt

A change report listing changes between this, and previous revisions, is
available at:

http://www.ics.uci.edu/pub/ietf/webdav/collections/dt/ssreport.txt

The purpose of this interim revision is to provide the basis for discussions
during the Advanced Collections conference calls, and to also keep the
working group informed of the current state of the document.  Comments on
this, or any WebDAV draft are welcomed.

- Jim


From w3c-dist-auth-request@www10.w3.org  Fri Jan 22 12:06:13 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA23951
	for <w3c-dist-auth@www19.w3.org>; Fri, 22 Jan 1999 12:06:13 -0500 (EST)
Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id MAA14175
	for <w3c-dist-auth@w3.org>; Fri, 22 Jan 1999 12:06:12 -0500 (EST)
Received: from crthub2.crt.xerox.com (crthub2.crt.xerox.com [13.138.80.5])
	by pasiphae.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id MAA19097
	for <w3c-dist-auth@w3.org>; Fri, 22 Jan 1999 12:06:10 -0500 (EST)
Received: by crthub2.crt.xerox.com with Internet Mail Service (5.5.2232.9)
	id <DHBPW1XK>; Fri, 22 Jan 1999 12:05:12 -0500
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76D80@x-wb-0128-nt8.wrc.xerox.com>
>From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
Date: Fri, 22 Jan 1999 12:07:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Issue: MOVE Semantics

In the current version of the WebDAV specification, MOVE is defined as COPY
followed by DELETE.

I believe that this definition causes enough problems that we should
consider changing it.

As Jim Davis recently pointed out (in his comments on
draft-hopmann-collection-props-00.txt), it causes problems for IDs.  We
expect that when an object is moved, it will have the same ID.  But we
expect that when an object is copied, the new copy will have a distinct ID.
We can't have both these semantics if MOVE is defined as COPY followed by
DELETE.

Other properties will have similar problems, like creation date.

An attempt to MOVE a resource to its same location will result in the
resource being deleted.  (This forced the advanced collections protocol to
invent a new method for changing the position of a resource in a
collection's ordering, when we might otherwise have been able to use MOVE.)

It is probably this definition that forced the spec to say that locks are
lost after a MOVE, a counterintuitive result.  I would expect an object that
was locked before a MOVE still to be locked after the MOVE.

Could we just say that after a MOVE, the resource is accessible through the
URI in the Destination header, and is no longer accessible through the
request-URI of the MOVE request, and get rid of the definition in terms of
COPY and DELETE?

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580


From w3c-dist-auth-request@www10.w3.org  Fri Jan 22 13:30:15 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA25473
	for <w3c-dist-auth@www19.w3.org>; Fri, 22 Jan 1999 13:30:15 -0500 (EST)
Received: from pump2.york.ac.uk ([144.32.128.12])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id NAA15266
	for <w3c-dist-auth@w3.org>; Fri, 22 Jan 1999 13:30:13 -0500 (EST)
Received: from tower.york.ac.uk (tower.york.ac.uk [144.32.128.102])
	by pump2.york.ac.uk (8.8.7/8.8.7) with SMTP id SAA21546
	for <w3c-dist-auth@w3.org>; Fri, 22 Jan 1999 18:30:06 GMT
Date: Fri, 22 Jan 1999 18:30:05 +0000 (GMT)
>From: Joe Orton <jeo101@york.ac.uk>
To: w3c-dist-auth@w3.org
Message-ID: <Pine.SOL.3.95L.990122175412.25308B-100000@tower.york.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Multistatus responses


Just wondering why it's necessary to use the specific 207 response code
for *all* multi-status responses - why can't a more meaningful code be
used as appropriate? For instance, when a multi-status response is needed
if MOVE or DELETE fails, use a 4xx class response. It still bugs me that a
2xx class code is used for methods which fail. 

Regards,

joe

-- 
Joe Orton
jeo101@york.ac.uk ... joe@orton.demon.co.uk
http://www.orton.demon.co.uk/


From w3c-dist-auth-request@www10.w3.org  Fri Jan 22 13:49:07 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA25693
	for <w3c-dist-auth@www19.w3.org>; Fri, 22 Jan 1999 13:49:07 -0500 (EST)
Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id NAA15456
	for <w3c-dist-auth@w3.org>; Fri, 22 Jan 1999 13:49:06 -0500 (EST)
>From: jamsden@us.ibm.com
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id NAA59190;
	Fri, 22 Jan 1999 13:26:09 -0500
Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35])
	by southrelay02.raleigh.ibm.com (8.8.7/NCO v1.8) with SMTP id NAA30364;
	Fri, 22 Jan 1999 13:49:01 -0500
Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 85256701.00675959 ; Fri, 22 Jan 1999 13:48:50 -0500
X-Lotus-FromDomain: IBMUS
To: Joe Orton <jeo101@york.ac.uk>
cc: w3c-dist-auth@w3.org
Message-ID: <85256701.00675663.00@d54mta03.raleigh.ibm.com>
Date: Fri, 22 Jan 1999 13:41:45 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: Multistatus responses



Joe,

It is my understanding that methods only return a multistatus when they
effect multiple resources. So for example, you could DELETE a collection
and get a multistatus if it failed indicating which resource in the
collection couldn't be deleted. If the DELETE failed because the collection
itself was locked, then you could also return a single status as the
members were unaffected. Similarly, if the method succeeded, you would just
get a 200 status code for the whole operation.





Joe Orton <jeo101@york.ac.uk> on 01/22/99 01:30:05 PM

To:   w3c-dist-auth@w3.org
cc:    (bcc: Jim Amsden/Raleigh/IBM)
Subject:  Multistatus responses





Just wondering why it's necessary to use the specific 207 response code
for *all* multi-status responses - why can't a more meaningful code be
used as appropriate? For instance, when a multi-status response is needed
if MOVE or DELETE fails, use a 4xx class response. It still bugs me that a
2xx class code is used for methods which fail.

Regards,

joe

--
Joe Orton
jeo101@york.ac.uk ... joe@orton.demon.co.uk
http://www.orton.demon.co.uk/






From w3c-dist-auth-request@www10.w3.org  Fri Jan 22 14:03:51 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA25831
	for <w3c-dist-auth@www19.w3.org>; Fri, 22 Jan 1999 14:03:51 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id OAA15602
	for <w3c-dist-auth@w3.org>; Fri, 22 Jan 1999 14:03:49 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa13920;
          22 Jan 99 11:00 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 22 Jan 1999 10:59:03 -0800
Message-ID: <001301be4639$4762f3a0$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: FW: new webdav up

Accidentally caught by the spam filter.

- Jim

-----Original Message-----
>From: Dana Carson [mailto:dcarson@cyberteams.com] 
Sent: Friday, January 22, 1999 2:07 AM
To: Joe Orton; Jim Davis; w3c-dist-auth@w3.org
Cc: webdav@cyberteams.com
Subject: [Moderator Action] new webdav up


A new version of the Cyberteams webdav server is up. I think this fixes all
the open problems reported. Please check and see if anything else turns up.

--
Dana Carson
dcarson@cyberteams.com           http://www.access.digex.net/~dcarson
Artemis Society International    http://www.asi.org/



From w3c-dist-auth-request@www10.w3.org  Fri Jan 22 14:12:30 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA26090
	for <w3c-dist-auth@www19.w3.org>; Fri, 22 Jan 1999 14:12:30 -0500 (EST)
Received: from pump2.york.ac.uk (pump2.york.ac.uk [144.32.128.12])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id OAA15788
	for <w3c-dist-auth@w3.org>; Fri, 22 Jan 1999 14:12:29 -0500 (EST)
Received: from tower.york.ac.uk (tower.york.ac.uk [144.32.128.102])
	by pump2.york.ac.uk (8.8.7/8.8.7) with SMTP id TAA25723;
	Fri, 22 Jan 1999 19:12:25 GMT
Date: Fri, 22 Jan 1999 19:12:25 +0000 (GMT)
>From: Joe Orton <jeo101@york.ac.uk>
Reply-To: Joe Orton <jeo101@york.ac.uk>
To: jamsden@us.ibm.com
cc: w3c-dist-auth@w3.org
In-Reply-To: <85256701.00675663.00@d54mta03.raleigh.ibm.com>
Message-ID: <Pine.SOL.3.95L.990122185441.300B-100000@tower.york.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: Multistatus responses


> It is my understanding that methods only return a multistatus when they
> effect multiple resources.

PROPPATCH uses 207 responses for methods on single resources, I think?

> So for example, you could DELETE a collection and get a multistatus if
> it failed indicating which resource in the collection couldn't be
> deleted. If the DELETE failed because the collection itself was locked,
> then you could also return a single status as the members were
> unaffected.

Yes, so if it failed, why not return a 4xx class response which is what
4xx class responses are for? The 'degree' to which it failed (i.e., which
resources couldn't be deleted) is indicated only by the response body, but
the bottom line is that the request did NOT succeed, which is what 2xx
responses are for.

I'm not trying to suggest that multistatus responses should be scrapped,
only that they should not have a fixed status code.

Regads,

joe

-- 
Joe Orton
jeo101@york.ac.uk ... joe@orton.demon.co.uk
http://www.orton.demon.co.uk/




From w3c-dist-auth-request@www10.w3.org  Fri Jan 22 14:15:17 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA26141
	for <w3c-dist-auth@www19.w3.org>; Fri, 22 Jan 1999 14:15:17 -0500 (EST)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id OAA15822
	for <w3c-dist-auth@w3.org>; Fri, 22 Jan 1999 14:15:16 -0500 (EST)
Received: from mailback.parc.xerox.com ([13.1.101.39]) by alpha.xerox.com with SMTP id <55516(3)>; Fri, 22 Jan 1999 11:15:08 PST
Received: from schuur ([13.0.209.76]) by mailback.parc.xerox.com with SMTP id <147483>; Fri, 22 Jan 1999 11:15:02 PST
Message-Id: <3.0.3.32.19990122111018.009932d0@mailback.parc.xerox.com>
X-Sender: jdavis@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 22 Jan 1999 11:10:18 PST
To: w3c-dist-auth@w3.org
>From: Jim Davis <jdavis@parc.xerox.com>
Cc: webdav-list@cyberteams.com
In-Reply-To: <199901221456.GAA23908@hawk.prod.itd.earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Cyberteams webdav server still broken

At 06:54 AM 1/22/99 PST, Dana Carson wrote:
>A new version of the Cyberteams webdav server is up. 

It seems to me it is still broken.  Consider the following

PROPFIND / HTTP/1.1
Authorization: Basic anJkOmZvbw==
Host: www.fwi.com
Connection: close
Content-Type: text/xml
Content-Length: 115
 
<?xml version="1.0"?>
<A:propfind xmlns:A="DAV:">
  <A:prop>
    <A:resourcetype/>
  </A:prop>
</A:propfind>

HTTP/1.1 200 OK
Date: Fri, 22 Jan 1999 19:02:16 GMT
Server: Apache/1.3.3 (Unix) WSD/DAV 0.5.14
Connection: close
Transfer-Encoding: chunked
Content-Type: httpd/unix-directory
 
0
 

Three problems here:
 1) the Content-Type should be text/xml or application/xml
 2) There's not PROPFIND reply.  Note that PROPFIND seems to work if there
is no request body at all, it only fails when a non-null body is provided.
 3) httpd/unix-directory is not a standard MIME type
 
My test scripts require PROPFIND to work, so I have not tested anything
further.



From w3c-dist-auth-request@www10.w3.org  Fri Jan 22 14:52:17 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA27484
	for <w3c-dist-auth@www19.w3.org>; Fri, 22 Jan 1999 14:52:17 -0500 (EST)
Received: from proxy3.ba.best.com (proxy3.ba.best.com [206.184.139.14])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id OAA16265
	for <w3c-dist-auth@w3.org>; Fri, 22 Jan 1999 14:52:16 -0500 (EST)
Received: from diogenes ([209.31.231.69])
	by proxy3.ba.best.com (8.9.2/8.9.2/best.out) with SMTP id LAA08215;
	Fri, 22 Jan 1999 11:46:39 -0800 (PST)
Message-Id: <4.1.19990122112806.00a39b00@shell7.ba.best.com>
X-Sender: glyph-max@pplus.shell14.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 22 Jan 1999 11:46:07 -0800
To: w3c-dist-auth@w3.org
>From: Max Rible <max@glyphica.com>
Cc: webdav-list@cyberteams.com
In-Reply-To: <3.0.3.32.19990122111018.009932d0@mailback.parc.xerox.com>
References: <199901221456.GAA23908@hawk.prod.itd.earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Re: Cyberteams webdav server still broken

At 11:10 1/22/99 -0800, Jim Davis wrote:
>At 06:54 AM 1/22/99 PST, Dana Carson wrote:
>>A new version of the Cyberteams webdav server is up. 

>It seems to me it is still broken.  Consider the following
>
>PROPFIND / HTTP/1.1
>Authorization: Basic anJkOmZvbw==
>Host: www.fwi.com
>Connection: close
>Content-Type: text/xml
>Content-Length: 115
> 
><?xml version="1.0"?>
><A:propfind xmlns:A="DAV:">
>  <A:prop>
>    <A:resourcetype/>
>  </A:prop>
></A:propfind>
>
>HTTP/1.1 200 OK

My own test client complaints about the 200 reply as well; I can't
get it to respond to XML PROPFIND requests.  One case does seem to work:

% telnet www.fwi.com 8080
Trying 209.84.160.61...
Connected to serv1-r.fwi.com.
Escape character is '^]'.
PROPFIND / HTTP/1.0
Authorization: Basic ------------

HTTP/1.1 207 Multi-Status
Date: Fri, 22 Jan 1999 19:11:35 GMT
Server: Apache/1.3.3 (Unix) WSD/DAV 0.5.14
Content-Length: 27041
Connection: close
Content-Type: text/xml

<?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:" xmlns:W="http://www.cyberteams.com/">
<D:response>
<D:href>http://serv1-r.fwi.com/</href>
<D:propstat>
<D:prop>
<D:creationdate>Fri Jan 22 14:11:42 1999</D:creationdate>
<D:displayname>/</D:displayname>
<D:resourcetype><D:collection/>
</D:resourcetype>
</D:prop>
 <D:status>HTTP/1.1 200 OK</D:status></D:propstat>
</D:response>

...

Two things I notice about the returned XML:

1.  The href refers to a different machine than the host returning
the multistatus response.

2.  The creation date is not in ISO8601 format, as specified in 
Appendix 2 of the WebDAV document.

-- 
%% Max Rible %%% max@glyphica.com %%% http://www.amurgsval.org/~slothman/ %%
%% "Ham is good...  Glowing *tattooed* ham is *bad*!"         - the Tick  %%


From w3c-dist-auth-request@www10.w3.org  Sat Jan 23 12:30:55 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA08167
	for <w3c-dist-auth@www19.w3.org>; Sat, 23 Jan 1999 12:30:55 -0500 (EST)
Received: from pump2.york.ac.uk (pump2.york.ac.uk [144.32.128.12])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id MAA26166
	for <w3c-dist-auth@w3.org>; Sat, 23 Jan 1999 12:30:53 -0500 (EST)
Received: from tower.york.ac.uk (tower.york.ac.uk [144.32.128.102])
	by pump2.york.ac.uk (8.8.7/8.8.7) with SMTP id RAA04819;
	Sat, 23 Jan 1999 17:30:25 GMT
Date: Sat, 23 Jan 1999 17:30:24 +0000 (GMT)
>From: Joe Orton <jeo101@york.ac.uk>
Reply-To: Joe Orton <jeo101@york.ac.uk>
To: Dana Carson <dcarson@cyberteams.com>
cc: webdav@cyberteams.com, w3c-dist-auth@w3.org
In-Reply-To: <v03130303b2cdfdb708f5@[209.49.30.7]>
Message-ID: <Pine.SOL.3.95L.990122205326.2376A-100000@tower.york.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: new webdav up


> A new version of the Cyberteams webdav server is up. I think this fixes all
> the open problems reported. Please check and see if anything else turns up.

I'm occasionally getting '422 Unprocessable Entity' responses, usually
soon followed by a closed socket. Haven't been able to reproduce this
predictably.

I thought this might be sitecopy but I can't find any problems when
testing against IIS or mod_dav.

Try something like this to see it happen with sitecopy (latest code from
http://www.lyra.org/sitecopy/develop.html). 

mkdir `seq 1 100`
sitecopy -d9 -u sitename

Regards,

joe

-- 
Joe Orton
jeo101@york.ac.uk ... joe@orton.demon.co.uk
http://www.orton.demon.co.uk/


From w3c-dist-auth-request@www10.w3.org  Mon Jan 25 10:18:53 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA28382
	for <w3c-dist-auth@www19.w3.org>; Mon, 25 Jan 1999 10:18:52 -0500 (EST)
Received: from mail.rdc1.ct.home.com (ha1.rdc1.ct.home.com [24.2.0.66])
	by www10.w3.org (8.9.1/8.9.1) with ESMTP id KAA14397
	for <w3c-dist-auth@w3.org>; Mon, 25 Jan 1999 10:18:51 -0500 (EST)
Received: from [24.0.249.126] by mail.rdc1.ct.home.com
          (InterMail v4.00.03 201-229-104) with ESMTP
          id <19990125151850.PJHL19602.mail.rdc1.ct.home.com@[24.0.249.126]>
          for <w3c-dist-auth@w3.org>; Mon, 25 Jan 1999 07:18:50 -0800
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04011704b2d23885cb46@[24.0.249.126]>
In-Reply-To: <9901161656.AA12304@tantalum>
Date: Mon, 25 Jan 1999 10:20:15 -0500
To: w3c-dist-auth@w3.org
>From: "David G. Durand" <dgd@cs.bu.edu>
Subject: Re: Protocol Design: new XML elements in the body or new headers?

At 11:56 AM -0500 1/16/99, Geoffrey M. Clemm wrote:

Roy already responded to this from an HTTP protocol point of view, based on
hs rules of thumb for extension design. I'd like to make a few points based
on XML document and DTD design. Roy and I both think that Geoff's proposed
bundling is a bad idea, but we have different reasons for thinking it.

I haven't had a chance to read Jim's paper, so apologies if I'm duplicating
any of his points.

>Many of the new methods being defined for WebDAV versioning have
>an XML document as the value of their request and/or response body.
>While designing the protocol, I am continually faced with the question:
>
>Should an input parameter to the method be represented as a new XML
>element in the request body or as a new request header?  Similarly,
>should an output parameter to the method be represented as a new XML
>element in the response body or as a new respose header?

> snip... Snop...

>The only argument I can think of for using a header is that it is
>the only technique applicable when the body is being used for some
>other purpose (such as GET/PUT).

AS Roy says, the body is "payload". For some of our operations we treat
some parameters as "payload". He might not like that part of the protocol
design but it's at least logical I think. However, there are some other
reasons to use headers (that I'll get to).

>One possible rule of thumb:
>
>If the request/response body is an XML document, then the request/response
>parameters should be specified as XML elements.  Only if the body is not an
>XML document should parameters be specified as headers.

This rule of thumb might bo OK, but should _never apply_ to methods like
GET/PUT, since the document being modified should not have parameters added
into it, even if it were an XML document.

For other messages that _already_ need to take XML encoded request bodies,
your hand is also not as free as it might be. You must use a header for any
information that could make sense for a GET/PUT (now, and probably also if
it could ever make sense in any future extension of these methods). In
general since Headers are part HTTP (the base protocol) protocol
information should use headers unless it's very obviously _method
specific_. If it might not always be method specific, putting it in an XML
request body is dangerous, as some future method might need it in a header
because the method's body is pure "payload" in an arbitrary media-type.

Of course a new header (potentially) interacts with _all_ other methods,
and that increases spec complexity, and (even if the effects are very local
and simple) increases the time for an implementor to comprehend the spec.
and implement it.

So Roy is also right that minimizing the use of headers is a good idea.

Of course,the versioning spec. must inherently deal with a lot of complex
data objects like revision histories, and configuration specifications, and
so forth. These need to be expressed in XML, but where they must be
referred to in methods they should probably have URIs or some other names
that can fit sensibly in headers.

The Property mechanism is one way to deal with some of these, but as Yaron
has pointed out, properties should not be abused as a way to create new
HTTP methods...

Still, I think there actually needs to be a presumptive preference for
headers, unless data format, character-encoding, or protocol complexity
prevent it. As Roy says, a profusion of new headers (and thus header/method
interactions) is probably telling you something important that should not
be ignored.

   -- David
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________


From w3c-dist-auth-request@www10.w3.org  Mon Jan 25 23:57:50 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA02142
	for <w3c-dist-auth@www19.w3.org>; Mon, 25 Jan 1999 23:57:50 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id XAA26645
	for <w3c-dist-auth@w3.org>; Mon, 25 Jan 1999 23:57:48 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa20446;
          25 Jan 99 20:52 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Mon, 25 Jan 1999 20:50:50 -0800
Message-ID: <000d01be48e7$72219000$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: Volunteer: write DAV article for IEEE Multimedia

Unfortunately, the person who initially volunteered to write an introductory
article on WebDAV for IEEE Multimedia is now unable to write the article.
So, I'm making a second call for volunteers.

I'm looking for someone to write an article for IEEE Multimedia, first draft
due the first of March, which gives an introduction to WebDAV for the IEEE
Multimedia audience, over 10,000 strong.

I see there being a lot of opportunities out there for people who like to
write, and who like WebDAV.  Articles need to be written on many topics,
like:

* Programming with WebDAV
* Getting up and running with your WebDAV server
* Introductions to WebDAV, at varying levels of detail, for varying
audiences

There are still many people who would be interested in WebDAV, but who just
haven't heard about it yet.  I need your help to spread the word.

- Jim


From w3c-dist-auth-request@www10.w3.org  Tue Jan 26 13:24:30 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA22001
	for <w3c-dist-auth@www19.w3.org>; Tue, 26 Jan 1999 13:24:30 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id NAA06878
	for <w3c-dist-auth@w3.org>; Tue, 26 Jan 1999 13:24:28 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa19704;
          26 Jan 99 10:08 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 26 Jan 1999 10:06:42 -0800
Message-ID: <000101be4956$a18f70e0$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <000201be45ae$c9940660$d115c380@galileo.ics.uci.edu>
Importance: Normal
Subject: RE: New interim advanced collections protocol spec.

My apologies -- the URLs below were off by one character:

> A new, interim version of the advanced collections protocol specification
> has been updated, and placed on the WebDAV Web site at:
>
> http://www.ics.uci.edu/pub/ietf/webdav/collections/dt/CollSpec023.txt

Should be:

http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/CollSpec023.txt

> A change report listing changes between this, and previous revisions, is
> available at:
>
> http://www.ics.uci.edu/pub/ietf/webdav/collections/dt/ssreport.txt

Should be:

http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/ssreport.txt

>
> The purpose of this interim revision is to provide the basis for
discussions
> during the Advanced Collections conference calls, and to also keep the
> working group informed of the current state of the document.  Comments on
> this, or any WebDAV draft are welcomed.

- Jim


From w3c-dist-auth-request@www10.w3.org  Fri Jan 29 18:01:53 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA07680
	for <w3c-dist-auth@www19.w3.org>; Fri, 29 Jan 1999 18:01:53 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id SAA24201
	for <w3c-dist-auth@w3.org>; Fri, 29 Jan 1999 18:01:49 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa17965;
          29 Jan 99 14:52 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 29 Jan 1999 14:50:31 -0800
Message-ID: <000201be4bd9$c6c5f0c0$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: Collections: 1/26 minutes, new spec.

The minutes from the January 26, 1999 conference call on Advanced
Collections are available on the WebDAV Web site at:

http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes990126.txt

A revision of the Advanced Collections specification has been made based on
discussion during the conference call, as preparation for the next
conference call.  It is available at:

http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/CollSpec024.txt

Your comments on this specification are welcome.

Big thanks to Judy Slein for her perserverance in working through the open
issues on the Advanced Collection draft.

- Jim



From w3c-dist-auth-request@www10.w3.org  Fri Jan 29 18:14:51 1999
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA08095
	for <w3c-dist-auth@www19.w3.org>; Fri, 29 Jan 1999 18:14:51 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
	by www10.w3.org (8.9.1/8.9.1) with SMTP id SAA24350
	for <w3c-dist-auth@w3.org>; Fri, 29 Jan 1999 18:14:49 -0500 (EST)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa19911;
          29 Jan 99 15:07 PST
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 29 Jan 1999 15:05:00 -0800
Message-ID: <000601be4bdb$cbe731c0$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: FW: Revised Internet-Draft boilerplate

FYI.

- Jim

-----Original Message-----
>From: scoya@ns.cnri.reston.va.us [mailto:scoya@ns.cnri.reston.va.us] On
Behalf Of The IESG
Sent: Friday, January 29, 1999 8:24 AM
To: IETF-Announce: ;
Subject: Revised Internet-Draft boilerplate



Following up on the discussion in the plenary session at the IETF meeting in
Orlando and the discussion on the poised mailing list, the IESG on Thursday,
January 28th approved the new boilerplate text that must be included with
all Internet-Draft submissions.

Beginning Monday, February 1, all Internet-Draft submissions must include
the new boilerplate.  Any submissions that do not use the new text will
be returned to the author/submitter.

The new template can be accessed with this URL:

	http://www.ietf.org/ietf/1id-guidelines.txt


