W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1998

RE: WG Last Call: Advanced Collections Requirements

From: Yaron Goland <yarong@microsoft.com>
Date: Wed, 12 Aug 1998 11:34:13 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792350@red-msg-59.dns.microsoft.com>
To: "'Slein, Judith A'" <JSlein@crt.xerox.com>, slein@wrc.xerox.com
Cc: "'WebDAV'" <w3c-dist-auth@w3.org>
I would state in the goal document the general intent of the two reference
types, indicate possible issues and then leave it to the protocol document
to resolve these issues.

		Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Wednesday, August 12, 1998 7:11 AM
> To: Yaron Goland; slein@wrc.xerox.com
> Cc: 'WebDAV'
> Subject: RE: WG Last Call: Advanced Collections Requirements
> 
> 
> Thanks for your comments.  I agree that we need to make clear that
> references are to resources, not to locations.
> 
> The problem about what we mean by direct references is a more 
> difficult
> one.  It certainly needs to be thought through more carefully than it
> has been so far.
> 
> One approach that we could take is to stay with a very strict 
> definition
> of direct reference: one for which no operations are passed through to
> the target.  Then treat direct and indirect references as marking the
> ends of a continuum, where in between are references for which some
> operations are passed through.  We could require that the protocol be
> able to represent direct references, indirect references, or 
> anything in
> between (be able to say which operations will be passed 
> through for any
> particular reference).
> 
> Or we might be able to reach consensus on one or a small set of
> reference types that are really useful and must be supported by the
> protocol (not necessarily by servers).  Indirect references are
> certainly useful.  Maybe another useful type of reference 
> passes through
> these operations:
> 
> 	PROPFIND
> 	PROPPATCH
> 	PUT
> 	GET
> 	POST
> 	HEAD
> 	DELETE
> 	MOVE
> 	COPY
> 
> But does not pass through:
> 
> 	Any operation on the parent collection
> 	MKREF
> 	DELREF
> 
> A third useful type of reference might pass through:
> 
> 	PROPFIND
> 	PROPPATCH
> 	PUT
> 	GET
> 	POST
> 	HEAD
> 
> But not pass through:
> 
> 	DELETE
> 	MOVE
> 	COPY
> 	Any operation on the parent collection
> 	MKREF
> 	DELREF
> 
> Judith A. Slein
> Xerox Corporation
> jslein@crt.xerox.com
> (716)422-5169
> 800 Phillips Road 105/50C
> Webster, NY 14580
> 
> 
> > -----Original Message-----
> > From: Yaron Goland [mailto:yarong@microsoft.com]
> > Sent: Monday, August 10, 1998 9:22 PM
> > To: slein@wrc.xerox.com
> > Subject: RE: WG Last Call: Advanced Collections Requirements
> > 
> >      3.1.5  Operations on a target resource do not affect 
> > references to it
> >             except as needed to enforce referential integrity.
> > 
> > The last sentence of the last paragraph of section 3.1.5 
> > states that "For
> > example, if the target of a strong reference is moved, the 
> > reference must
> > change to reflect the new location of the target." I realize 
> > it isn't a
> > "MUST" but a "must" however I am concerned by this statement. 
> > When I create
> > a strong reference am I referencing a particular resource or 
> > a particular
> > location? If I am referencing a resource then having the 
> > strong reference
> > change when the resource is moved makes sense. However if I 
> > am referencing a
> > location then nothing but a DELETE should cause the strong 
> > reference to
> > change. A MOVE, of course, is defined as a COPY followed by a 
> > DELETE, so it
> > would seem that moving a resource on a strong location 
> > reference should
> > result in the strong reference's deletion.
> > 
> > I think it would be acceptable to specify that references 
> > only refer to
> > resources not locations but I believe there really should be some
> > clarification on the point.
> > 
> >      3.1.15 Operations on a direct reference, except for 
> creation and
> >             deletion of the reference itself, are passed 
> > through to its
> >             target resource.
> > 
> > There are obvious problems with this rule for operations such 
> > as COPY and
> > MOVE of the parent collection. I think language is needed to 
> > call out the
> > fact that a direct reference is still a reference and thus 
> > certain methods,
> > especially COPY and MOVE, may not be passed through but 
> > rather will effect
> > the reference directly.
> > 
> > 			Yaron
> > 
> > 
> > > -----Original Message-----
> > > From: Jim Whitehead [mailto:ejw@ics.uci.edu]
> > > Sent: Thursday, August 06, 1998 4:00 PM
> > > To: WEBDAV WG
> > > Subject: WG Last Call: Advanced Collections Requirements
> > > 
> > > 
> > > *** WORKING GROUP LAST CALL FOR COMMENTS ***
> > > 
> > > ADVANCED COLLECTIONS REQUIREMENTS
> > > 
> > > Requirements for advanced collections capability within 
> > > WebDAV have been
> > > discussed at length on the mailing list, and at three 
> > > successive WebDAV
> > > face-to-face meetings.  It is my opinion as Chair that this 
> > > document is
> > > ready for final review, followed by submission to the IESG 
> > > for approval as
> > > an Informational RFC.
> > > 
> > > This is the final call for comments from the working group on 
> > > the document,
> > > "Requirements for Advanced Collection Functionality in 
> > > WebDAV", by Judith
> > > Slein and Jim Davis, <draft-ietf-webdav-collection-reqts-02>. 
> > >  This last
> > > call for comments period begins immediately, and ends Sunday, 
> > > August 30, at
> > > midnight Pacific time.  This allows over 3 weeks for 
> > > comments, including the
> > > opportunity to make comments at the Chicago IETF meeting.
> > > 
> > > At the end of the last call period, a new draft will be issued
> > > (revision -03), containing any changes based on comments 
> > > received during the
> > > working group last call period.  Unless there are significant 
> > > technical
> > > problems raised with this document during the last call 
> > > period, I intend to
> > > submit the -03 draft to the Internet Engineering Steering 
> > > Group (IESG) for
> > > approval as an Informational RFC.
> > > 
> > > Details on the procedures used to develop IETF documents can 
> > > be found in RFC
> > > 2026, which can be retrieved at:
> > > 
> > ftp://ftp.isi.edu/in-notes/rfc2026.txt
> > 
> > If there are any procedural questions or concerns, please do 
> > not hesitate to
> > contact me, or raise an issue on the list.
> > 
> > - Jim Whitehead
> > Chair, IETF WEBDAV Working Group
> > 
> 
Received on Wednesday, 12 August 1998 14:33:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:47 GMT