Julian Reschke | 4 Jul 16:23 2002
Picon

Additional OPTIONS semantics for version-history feature


Hi,

I'm looking at the description for the additional OPTIONS semantics for the
version-history feature ([1]), but I don't really understand what problem
this feature is supposed to solve. Given a specific resource on a Delta-V
server, I can find one (or more) collections that may contain version
histories on this server. What is a client supposed to do with this
information?

Assuming that there is a use case for this feature -- will a future RFC
define an additional live property for this as well?

[1] <http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.5.5>

Julian Reschke | 4 Jul 17:43 2002
Picon

RE: Additional OPTIONS semantics for version-history feature


Hi,

I was just trying to implement 5.5 in our server and came across the
following issue:

- the request body is optional, so I check for the presence of a
XML-wellformed request body. If there is none - fine.

- if there is an XML request body, the protocol *requires* that it has a
certain document element.

This basically means that RFC3253 has occupied the format for *any* OPTIONS
request body -- no other HTTP-extending protocol can go out and specify
similar requirements without being in conflict with RFC3253. In particular,
RFC3253 is in conflict with a potential HTTP revision that specifies request
bodies for OPTIONS (!).

So, at a minimum, the protocol MUST allow to ignore the request body if the
document element is not DAV:options. In the long run, I'd like to see this
removed from the protocol, and possibly changed into a live property.

Julian

> -----Original Message-----
> From: ietf-dav-versioning-request <at> w3.org
> [mailto:ietf-dav-versioning-request <at> w3.org]On Behalf Of Julian Reschke
> Sent: Thursday, July 04, 2002 4:24 PM
> To: 'Deltav WG'
> Subject: Additional OPTIONS semantics for version-history feature
(Continue reading)

Clemm, Geoff | 7 Jul 01:33 2002

RE: Replacing the Label header with a DAV:labeled-version report


   From: Julian Reschke [mailto:julian.reschke <at> greenbytes.de]

   > From: Clemm, Geoff
   >
   > Julian didn't like the marshalling of this report, because it
   > makes it look like the properties are those of the VCR, when they
   > actually are properties of the version

   Yes, that's the problem, and I fear the new format doesn't address
   this.

   If the multistatus/response format is re-used for a REPORT (basically a
good
   thing), it must not break the existing semantics, in particular:

   - the properties reported must actually be the properties of the resource
   identified by the reported URI (DAV:href) and
   - the properties reported actually must be properties (!).

   If this is not the case, the response seems to indicate that there's a
   DAV:labeled-version-report property, which isn't the case.

If this is a problem, it is a problem with the 3253 definition of REPORT.
In particular, section 3.6 states:

   "If a Depth request header is included, the response MUST be a 207
   Multi-Status.  The request MUST be applied separately to the
   collection itself and to all members of the collection that satisfy
   the Depth value.  The DAV:prop element of a DAV:response for a
(Continue reading)

Clemm, Geoff | 7 Jul 14:58 2002

Marshalling DAV:xxx-collection-set as a live property, and not an OPTIONS request.


Since I was not able to convince the ACL working group to marshall
this kind of information as an OPTIONS request, we should probably
consider changing the versioning protocol to also marshall this
kind of information (i.e. DAV:workspace-collection-set,
DAV:activity-collection-set, and DAV:version-history-collection-set)
as live properties, and not as OPTIONS requests.

So I'd like to poll the mailing list (especially DeltaV client and/or
server implementors:

Do you prefer to:
(a) leave xxx-collection-set as it is (marshalled only as OPTIONS)
(b) support marshalling both as OPTIONS and as live properties
(c) marshal only as live properties and deprecate the OPTIONS marshalling

I vote for (c), as it simplifies the spec, and makes it consistent
with the ACL protocol.

Cheers,
Geoff

Clemm, Geoff | 7 Jul 14:58 2002

RE: Additional OPTIONS semantics for version-history feature


   From: Julian Reschke [mailto:julian.reschke <at> greenbytes.de]

   I'm looking at the description for the additional OPTIONS semantics
   for the version-history feature ([1]), but I don't really
   understand what problem this feature is supposed to solve. Given a
   specific resource on a Delta-V server, I can find one (or more)
   collections that may contain version histories on this server. What
   is a client supposed to do with this information?

The main use case for DAV:version-history-collection-set is when you
have deleted the last VCR for a version history, and now you want to
retrieve the content of a version from that version history.  You can
browse for that version history in the
DAV:version-history-collection-set.  If your server supports baselines
or version-controlled collections, it is likely to be much more
effective to search for that version history in the baseline histories
or collection histories, so I agree that the case for
DAV:version-history-collection-set is not all that compelling.

   Assuming that there is a use case for this feature -- will a future
   RFC define an additional live property for this as well?

We certainly could.  Would anyone object to doing so?

   From: Julian Reschke [mailto:julian.reschke <at> greenbytes.de]

   ...  if there is an XML request body for OPTIONS, the protocol
   *requires* that it has a certain document element.

(Continue reading)

Julian Reschke | 7 Jul 16:21 2002
Picon

RE: Marshalling DAV:xxx-collection-set as a live property, and not an OPTIONS request.


> From: ietf-dav-versioning-request <at> w3.org
> [mailto:ietf-dav-versioning-request <at> w3.org]On Behalf Of Clemm, Geoff
> Sent: Sunday, July 07, 2002 2:59 PM
> To: DeltaV (E-mail)
> Subject: Marshalling DAV:xxx-collection-set as a live property, and not
> an OPTIONS request.
> 
> 
> 
> Since I was not able to convince the ACL working group to marshall
> this kind of information as an OPTIONS request, we should probably
> consider changing the versioning protocol to also marshall this
> kind of information (i.e. DAV:workspace-collection-set,
> DAV:activity-collection-set, and DAV:version-history-collection-set)
> as live properties, and not as OPTIONS requests.
> 
> So I'd like to poll the mailing list (especially DeltaV client and/or
> server implementors:
> 
> Do you prefer to:
> (a) leave xxx-collection-set as it is (marshalled only as OPTIONS)
> (b) support marshalling both as OPTIONS and as live properties
> (c) marshal only as live properties and deprecate the OPTIONS marshalling
> 
> I vote for (c), as it simplifies the spec, and makes it consistent
> with the ACL protocol.

Same for me (c).

(Continue reading)

Julian Reschke | 7 Jul 20:49 2002
Picon

RE: Replacing the Label header with a DAV:labeled-version report


> From: ietf-dav-versioning-request <at> w3.org
> [mailto:ietf-dav-versioning-request <at> w3.org]On Behalf Of Clemm, Geoff
> Sent: Sunday, July 07, 2002 1:34 AM
> To: 'Deltav WG'
> Subject: RE: Replacing the Label header with a DAV:labeled-version
> report
>
>
>
>    From: Julian Reschke [mailto:julian.reschke <at> greenbytes.de]
>
>    > From: Clemm, Geoff
>    >
>    > Julian didn't like the marshalling of this report, because it
>    > makes it look like the properties are those of the VCR, when they
>    > actually are properties of the version
>
>    Yes, that's the problem, and I fear the new format doesn't address
>    this.
>
>    If the multistatus/response format is re-used for a REPORT (basically a
good
>    thing), it must not break the existing semantics, in particular:
>
>    - the properties reported must actually be the properties of  the
resource
>    identified by the reported URI (DAV:href) and
>    - the properties reported actually must be properties (!).
>
(Continue reading)

Lisa Dusseault | 8 Jul 02:36 2002

RE: Marshalling DAV:xxx-collection-set as a live property, and not an OPTIONS request.


> Since I was not able to convince the ACL working group to marshall
> this kind of information as an OPTIONS request, we should probably
> consider changing the versioning protocol to also marshall this
> kind of information (i.e. DAV:workspace-collection-set,
> DAV:activity-collection-set, and DAV:version-history-collection-set)
> as live properties, and not as OPTIONS requests.

The big picture here is that we're making OPTIONS less useful. In
particular, we're saying that OPTIONS * is too hard for servers to
implement correctly with a bunch of extra headers and body information,
because * is too ambiguous.  That's probably fair enough; it's a result
of the early decision that not all resources on a HTTP server need be
WebDAV-capable resources.  Should we go so far as to say that clients
SHOULD NOT use OPTIONS *?

My concern with going in this direction is that a client accessing a
WebDAV server may be configured initially with only the server's domain
name. How does the client start figuring out what is where on the
server?  Does "OPTIONS /" + "PROPFIND /" (or the same requests to
whatever path is given) solve this problem for the client instead?  

If the client does OPTIONS only on particular resources, how *does* the
server show capabilities? E.g. support for MKCOL can *never* show up as
an allowed method on any existing resource.  My take is that MKCOL shows
up in OPTIONS * and not in any other OPTIONS request. Thus OPTIONS *
serves an important role.

Does the client need some way to ask the server "do you support WebDAV
anywhere on the server, and if so, where?"  This would be similar to the
(Continue reading)

Sohn, Matthias | 8 Jul 07:49 2002
Picon

RE: Marshalling DAV:xxx-collection-set as a live property, and no t an OPTIONS request.


Hi,

I vote for (c)

I am not sure on which resources these live properties 
specifying server wide properties (which in general are not a property of 
a specific resource) should be exposed, I would appreciate some standardized
way to define these server wide features.

In addition I would like to see that the same mechanism can be used to
advertise 
server specific extension features preventing name clashes by the namespace 
of the respective live property

regards
Matthias

-----Original Message-----
From: Clemm, Geoff [mailto:gclemm <at> rational.com]
Sent: Sonntag, 7. Juli 2002 14:59
To: DeltaV (E-mail)
Subject: Marshalling DAV:xxx-collection-set as a live property, and not
an OPTIONS request.

Since I was not able to convince the ACL working group to marshall
this kind of information as an OPTIONS request, we should probably
consider changing the versioning protocol to also marshall this
kind of information (i.e. DAV:workspace-collection-set,
DAV:activity-collection-set, and DAV:version-history-collection-set)
(Continue reading)

Julian Reschke | 8 Jul 10:16 2002
Picon

RE: Marshalling DAV:xxx-collection-set as a live property, and not an OPTIONS request.


> From: ietf-dav-versioning-request <at> w3.org
> [mailto:ietf-dav-versioning-request <at> w3.org]On Behalf Of Lisa Dusseault
> Sent: Monday, July 08, 2002 2:36 AM
> To: Clemm, Geoff; DeltaV (E-mail)
> Subject: RE: Marshalling DAV:xxx-collection-set as a live property, and
> not an OPTIONS request.
>
>
>
> > Since I was not able to convince the ACL working group to marshall
> > this kind of information as an OPTIONS request, we should probably
> > consider changing the versioning protocol to also marshall this
> > kind of information (i.e. DAV:workspace-collection-set,
> > DAV:activity-collection-set, and DAV:version-history-collection-set)
> > as live properties, and not as OPTIONS requests.
>
> The big picture here is that we're making OPTIONS less useful. In
> particular, we're saying that OPTIONS * is too hard for servers to
> implement correctly with a bunch of extra headers and body information,
> because * is too ambiguous.  That's probably fair enough; it's a result
> of the early decision that not all resources on a HTTP server need be
> WebDAV-capable resources.  Should we go so far as to say that clients
> SHOULD NOT use OPTIONS *?

I think the main issue is that this is a usage of OPTIONS that doesn't seem
to be in line with HTTP 1.1, which says:

"If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to
apply to the server in general rather than to a specific resource. Since a
(Continue reading)


Gmane