Subject: New draft: RFC2518bis

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 20 Feb 2002 11:01:59 -0800

I've submitted this new draft this week because there's a deadline for new
drafts this Friday.  However it appears I can submit changes sometime before
a later deadline.

This draft doesn't deal with all the open issues.  Some open issues are
listed in "RFC2518 Changes.doc", which is available temporarily at
http://www.sharemation.com/~milele/public/dav until I get these docs up on
www.webdav.org.  You can also find there "RFC2518 Revised.doc" which is a
convenient way to see the change bars done by Word.  I can provide any of
these documents in some other formats if needed.

We'll be discussing this in Minneapolis, so come one, come all!

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 21 Feb 2002 09:36:15 +0100

Lisa,

I'm not happy with:

	XML's support for multiple human languages, using the “xml:lang” attribute
(in the case of WebDAV properties, this attribute is placed on the ‘prop’
element), handles cases where the same character set is employed by multiple
human languages.

and I don't think we have reached consensus for this change.

In my opinion, this is an attempt to re-define how XML works (without sound
technical reason). In XML, attributes in the special XML namespace have
scoping. It shouldn't matter where an xml:lang is defined as long as it's in
scope of the current node.

I *do* agree, that the RFC might be more specific about this, but then it
should just quote what XML (and Canonical XML) have to say about it. Also,
this should be defined in an update of the definition of a property's value
(what's in, what's out?).

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 21 Feb 2002 09:51:41 +0100

Lisa,

I don't agree at all with the deprecation, and I don't think that there was
consensus about this.

The draft says:

Clients MUST not send allprop requests in any form (either the empty body
PROPFIND or the specific allprop element), because allprop is being removed.
WebDAV servers increasingly have expensively-calculated or lengthy
properties (see DeltaV and ACL specifications [TODO: ref RFC when
available]) and do not return all properties already.  Instead, WebDAV
clients can use propname requests to discover what properties exist, and
request named properties when retrieving values.  A WebDAV server MAY omit
certain live properties from other specifications when responding to an
allprop request from an older client, and MAY return only custom (dead)
properties and those defined in this specification.

In particular:

"WebDAV servers increasingly have expensively-calculated or lengthy
properties (see DeltaV and ACL specifications [TODO: ref RFC when
available]) and do not return all properties already."

-> This is an argument for *restricting* the set of properties returned on
allprop, not for removing the feature (and that's what deltaV does).

"Instead, WebDAV clients can use propname requests to discover what
properties exist, and request named properties when retrieving values."

-> And the benefit is? The client will issue two calls: first it will use
propname to find the list of properties. Computing whether a live property
exists maybe as expensive as computing it (for instance, to find out whether
something is checked in/out). *Then* it will submit PROPFIND / prop will all
these properties. So as compared to the current situation, the server may
have to compute things twice which wouldn't have been computed at all before
(since asking for allprop wouldn't require computing live deltaV
properties).

-> Even leaving the propname vs live properties issue out, this doesn't make
sense. You are removing a working and interoperable protocol feature without
sound reason. As a fallback you offer a workaround which requires at least
one additional trip to the server, possibly heavy computation on the client
(computing the set of all property names on the members of a collection) and
then additional marshalling (when I do a PROPFIND/prop with a long list of
(dead) property names on a collection with depth 1, the server will have to
404-status them for many collection members).

-> I agree that PROPFIND needs to be cleaned up, but this is not the way to
go. The draft continues with:

"A WebDAV server MAY omit certain live properties from other specifications
when responding to an allprop request from an older client, and MAY return
only custom (dead) properties and those defined in this specification."

-> I think this may make sense. We will however need a way to get all dead
properties and a set of named properties with a single request (see [1]). We
may also have to find a way for a client to discover that something is a
live property.

[1]
<http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-allprop-include-l
atest.html>

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 28 Feb 2002 12:21:30 +0100

Following up to my own post:

the last WG meeting minutes (at
<http://www.ietf.org/proceedings/01dec/127.htm>) say:

"What 'allprop' means....

MUST include all 2518 props and all dead props to maintain interrop. However
new live props in ACL DASL etc are being defined as NOT returned by allprop.
Property dead on one server may not be dead on another server. allprop is
historical. Promote using propname. Is it legal for Xythos to use the adobe
namespace? You could have a property that is defined dead on one server be
live on another!

allprop must return all properties required for interrop.

Eric - property should be defined dead or non-nead...you can't mix and
match.

Should we deprecate allprop?
Perhaps use allprop-include or other mechanism to save roundtrip and
deprecate allprop. Sitecopy properties would not be the same. Is deprecate
something we can do in IETF? Take it out and reference them back to the old
draft. Geoff - Short description plus reference back to old spec. We took a
vote and 3 people would like it to become a info note, nobody objected."

I'm not sure I understand what the last paragraph says. I certainly do *not*
agree to remove allprop without replacing it with something which is as
efficient. See remarks in my previous mail.

Julian

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Julian Reschke
> Sent: Thursday, February 21, 2002 9:52 AM
> To: Lisa Dusseault; Webdav WG
> Subject: RFC2518bis: allprop deprecated (4.1)
>
>
> Lisa,
>
atest.html>