RE: Comments: DAV Specification 0.2
>From: Bernard Chester [SMTP:BernardC@saros.com]
>Sent: Monday, November 11, 1996 4:43 PM
>Subject: Comments: DAV Specification 0.2
>Well, I thought that I would have my comments to 0.1 out a week ago, but
>my responsibilities elsewhere (like to getting DMA 1.0 out) took
>precedence. I've read the new draft and consolidated my comments below.
> Please note that my expertise is with information management systems
>and DMA, not HTTP and HTML. I promise to complete my review HTTP 1.1
>and HTML 3.2 before Thursday if I attend. You do appear to be asking
>the same questions that I've heard in Shamrock and DMA meetings for
>years; maybe Dennis and some of the other DMA folks attending can help
>you avoid re-inventing the wheel.
> Checkout and Checkin
>(see below) How does this differ from Lock and Unlock? I get the
>impression (am almost certain) that you are using these verbs in a
>manner different from the document management industry.
>[Yaron Goland] I believe the document is very clear on how these are
>different. If our use of language differs from Industries then please provide
>us with new definitions which are consistent with the semantics of the
>2.1 Attr. Hdr URIs
> Your attribute naming scheme would seem to have the following problems:
>1- They seem to be language/locale dependent strings. This can be seen
>to be "English-arrogant". In DMA we eliminated those problems by using
>DCE GUIDs, and let the associated display string be able to
>language/locale related.Yes, I know that GUIDs are ugly and long. But
>you avoid the need for a central name clearinghouse.
>[Yaron Goland] I actually suggested using GUIDs in the original spec but got
>screamed down. We are English arrogant and we need to accept this. However
>nothing in the current spec prevents you from using GUID attribute names.
>2- If you like, pick a shorter scheme for "Well-knowns". For
>interoperability, you are well advised to publish a list of well-knowns,
>beyond section 2.3. I don't want to discover that my tool doesn't
>understand the standard attribs of a page because it was created with a
>[Yaron Goland] We will be publishing a list of well-knowns but it will be
>very very small. Instead we are depending upon the attribute sets to be used
>as a mechanism to publish groups of related attributes.
>3- Same issues occur with your prefixes. No need with GUID-type scheme.
>[Yaron Goland] The problem is that attributes need to appear in HTML
>documents and users hate typing in GUIDs.
>4- Do you have any thoughts about who would be the clearinghouse in your
>[Yaron Goland] IANA. Why? Why not. (Lama? Stam.)
>Sounds like I have to independently GET every attribute value, as an
>operation separate from getting the content. Low performance approach;
>why can't I ask for multiple items in one request?
>I'd like to see a way to get the complete package in one request (or at
>least, one response).
>[Yaron Goland] This is the MGET problem and applies just as much to
>attributes as it does to anything else under HTTP. With pipelining and
>compressed headers, however, I don't believe this is an issue.
>Why not extend HEAD to allow retrieval of the entire Attribute Set?
>[Yaron Goland] Careful with your terminology. Attribute Set has a very
>specific definition in this draft. If you mean why not just use HEAD to
>retrieve all the attributes the reason is simple: We expect to have many of
>them and we expect many of them to have octet stream values. Thus we would
>have a huge header and we would have to printable-quotable the contents. That
>is too much overhead.
>?Why not extend HTTP with new verbs?
>[Yaron Goland] That is, in essence, what we have done. POST with MIME types
>or new Methods are functionally equivalent.
>2.3 Std Attributes
>Are these required to be supported?
>[Yaron Goland] No. We expect most of the ones listed to be dropped. They are
>presented for argument. Of the ones that are accepted there is no requirement
>that they be supported. The only requirement is that if an attribute with a
>name equal to any of the one's listed is available it must use the defined
>syntax and semantics. In other words, you don't have to play but if you do
>you have to follow the rules.
>SiteMaps are not yet an accepted mechanism of HTML; this specification
>is dependent on them. What are other alternatives?
>[Yaron Goland] WebMaps (new name for SiteMaps) have gained a lot of
>acceptance in the W3C and they meet our needs very nicely. However they are
>just another content type and their use is optional. However if we don't like
>WebMaps then we need to define some default to act as the common denominator.
>Feel free to submit a proposal.
>I'd like to be able to operate on std containment approaches, such as
>directorys and links/shortcuts, as containers. I need to take some time
>to explain the various approaches that I've seen.
>[Yaron Goland] I hope you will provide a presentation on Thursday or Friday.
>Search: A 'page' will need to know and return the URL of a page that
>permits searching? Searching for what and over what domain /
>collection? How would I use this?
>[Yaron Goland] Its a horrible hack. Don't try to understand it, there is no
>point. It is our way of saying "we have failed." That is why I am starting to
>think that we may need to provide LDAP semantics in HTTP for attribute
>setting, retrieval, and search.
>In the DMA view, you've combined access control with versioning
>behavior. Personally, I think you'd better look at a richer scheme.
>There is an important reason for the difference: Access Control
>dictates who has permission to perform an operation; Authoring &
>Versioning is an activity specifically related to the modification of
>content and attributes, and the introduction of new versions. By
>separating the two, I avoid confusion between the information management
>and the information maintenance activities. [IMHO, I believe it makes
>it easier to implement also]
>[Yaron Goland] Locking is not an access control scheme in the security
>sense. Access control is totally orthogonal to locking. Locking is a
>mechanism to allow principals who have legitimate access to the same document
>to serialize that access.
>Many current products only support a single Editor, but a larger set of
>possible Editors. I am unclear how I can tell the difference between
>making a new person capable of editting versus his actually being in the
>process of editting and needing control over the document state.
>[Yaron Goland] I do not understand this paragraph.
>Do I have the ability to have multiple independent write locks active at
>the same time? Current implementations permit multiple branched
>versions. What do you think should be the behavior on the end
>[Yaron Goland] Due to a screw up on my part the current spec does not
>include a paragraph from a previous version that defines the behavior for
>"end of documents". I will be including that paragraph. As for multiple
>locks, not only is it legal but the text defines a whole token syntax to
>allow for atomization of multiple locks.
>Lock Ownership and Contact information cannot be required. This
>information is often privileged. The privilege may not be tied to who
>has access to the document.
>[Yaron Goland] They can be required, they can also be empty. Please note
>that the spec allows this. Specs are like the American Constitution, they say
>what you can't do, only rarely what you can do.
>4. Name Space Manipulation
>4.2 I am uncomfortable with your redefinition of delete. How is this
>different from an unlock? Is this equivalent to a rollback of changes?
>[Yaron Goland] Redefinition? It is absolutely identical to the definition of
>delete in HTTP. I have simply pointed out an implication of the definition I
>have not extended or changed it. Currently DAV does not provide for a
>rollback facility. This will have to be fixed.
>?You've specified a standard way to request notifications, but no
>standard way under HTTP to (a) receive them, (b) their format?
>Wouldn't they be the response to the next HTTP request? (You haven't
>provided for contact information here, so I guess SMTP is out of the
>question as a notification approach?!)
>[Yaron Goland] There are two different types of notifications. The first one
>would leverage return type 1xx. Please refer to the definition in the HTTP
>1.1 spec. We can send multiple 1xx responses thus giving updates. The reason
>there is no more detailed information is that, as the header indicates, this
>is a request for comment. I didn't want to fully flesh it out until I had buy
>off. For the second type of notification any URI can be referenced for
>notification purposes. mailto is a legal URI thus smtp can be used.
>I don't understand your versioning model. Please answer the following
>as a start:
>(1) can I see multiple versions of a document? if true, How do I address
>them? if false, I strongly disagree.
>[Yaron Goland] The word "see" is too loaded. Every version of a resource is
>uniquely addressable so you can retrieve any of them at any time.
>(2) When a document is being revised, as a reader, can I see the
>[Yaron Goland] That is up to the server. You can always perform a get, it is
>the server's job to decide if it will respond.
>(3) Checkout and locks seem used in reverse. Why is it that I don't
>checkout a document, and then lock/unlock all or part of the document as
>I work. Then complete with a checkin. This would allow multiple
>simultaneous editors of a version (collaboration). In this view, a
>checkout is still a declaration of intent to edit.
>[Yaron Goland] The following is cut and pasted from the version of the spec
A Check In is a declaration that the principal no longer intends to edit
A Check Out is a declaration by a principal that they intend to edit a
>(4) Is Checkout a Lock+Get combination? Checkin a PUT+Unlock? If they
>aren't compound operations, what are they?
>[Yaron Goland] Please refer to the spec. Have you read the terminology
>section? Your comments on the definition of "read/write/no-modify lock" and
>check in/out are inconsistent with what is defined there.
>Saros / FileNet
>[Yaron Goland] Yaron