RE: Comments: DAV Specification 0.2

>-----Original Message-----
>From:	Bernard Chester [SMTP:BernardC@saros.com]
>Sent:	Monday, November 11, 1996 4:43 PM
>To:	'w3c-dist-auth@w3.org'
>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. 
>
>Comments:
>
>1.2 Terminology
>	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
>current ones.
>
>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
>different product.
>
>[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
>approach?
>
>[Yaron Goland]  IANA. Why? Why not. (Lama? Stam.)
>
>2.2.1 GET
>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.
>
>2.2.2 HEAD
>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.
>
>3. Lock/Unlock
>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
>document(s)?
>
>[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.
>
>6. Notifications
>?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.
>
>8&9. Versioning
>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
>in-transition document?
>
>[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
>I posted:
"check in 
A Check In is a declaration that the principal no longer intends to edit
a resource(s). 
check out 
A Check Out is a declaration by a principal that they intend to edit a
resource(s). "
>
>(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.
>
>Bernard Chester
>Saros / FileNet
>bernardc@saros.com
>
>[Yaron Goland]  				Yaron

Received on Monday, 11 November 1996 20:44:46 UTC