RE: Comments

> - Thanks for catching the 7.5 typo ... will fix.

Thanks.

> - Concerning the statement about working-resource and
> workspace options, I'm happy to delete this sentence,
> since I don't see that it improves interoperability,
> and could incorrectly lead a reader to believe that
> the options are inconsistent.  So I'll delete this sentence
> unless anyone objects.

Thanks.

> - As for the complexity of the protocol, if there is
> something that you would like to see addressed before
> we send the protocol to the IESG for "proposed standard"
> status, please identify the specific issue during the
> working group last call period (i.e. before 2/1/01).
> It is my belief that the complexity issues have been
> adequately addressed by clearly identifying the part
> of the document that should be read by those only
> interested in "core" versioning functionality.  Each of
> the options consist of functionality that is currently
> supported by multiple versioning repositories, and
> therefore it significantly contributes to interoperability
> to provide an option that standardizes access
> to that functionality.

I agree with what you've stated here in the segregation of the functionality
to aid in understanding and implementation of the current specification.

My thoughts about complexity are in two areas.

1)  HTTP

The marshalling in DeltaV is designed around WebDAV's premise as an HTTP
extension.  This was a design decision for WebDAV and I am not going to
argue on way or the other on this issue.  My only comment is that there may
be people that want to implement the WebDAV+DeltaV specification that
participate in other transport agnostic standards.  In that case, DeltaV is
a very specific implementation and may appear complex relative to the other
agnostic activities.

2)   Marshalling

IMHO, the marshalling in the current version of the specification is very
fine grained.  The number of properties is large and the number of
client-server transactions to accomplish a specific activity can be
potentially as large.

My experiences have shown that fine grained specifications can also result
in less interoperability.  In this case, I speculate that disparate client
and server vendors will need to work closely to insure that the
implementations are consistent and function as expected on either end.
This may result in one-off client-server implementations.  Again, this is
speculative and does not specifically address items in the proposal.

A number of others have also commented on complexity.  I am interested in
seeing how they describe their thoughts.


Overall, the team had worked hard to develop a specification on a very
difficult subject  and I for one appreciate the efforts that have gone into
this.

	Thank you and have a good day,

	Mark

Received on Tuesday, 30 January 2001 15:16:39 UTC