- From: Yaron Goland <yarong@microsoft.com>
- Date: Mon, 11 Nov 1996 17:44:48 -0800
- To: "'Bernard Chester'" <BernardC@saros.com>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
>-----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