W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001


From: John Hall <johnhall@xythos.com>
Date: Wed, 5 Sep 2001 14:25:56 -0700
To: "'Clemm, Geoff'" <gclemm@rational.com>, "'DeltaV'" <ietf-dav-versioning@w3.org>
Message-ID: <002601c13651$597168a0$1300a8c0@xythosjohnhall>

> -----Original Message-----
> From: John Hall [mailto:johnhall@evergo.net] 
> Sent: Wednesday, September 05, 2001 2:25 PM
> To: 'Clemm, Geoff'; 'DeltaV'
> Subject: RE: REPORTS
> Tim, I have an email folder where I keep all the message 
> traffic.  I do not have that message.  I have a message where 
> you replied on 8/14/01, but I don't have the original.  I 
> don't know what could have happened to it.
> This is NOT a simple recursion, at least not on my server.
> Version-tree is just a propfind -- for client and server.  
> Expand-property is a complete rewrite -- for client and 
> server.  I probably spent an hour or two on version-tree, and 
> a client would need less.  Expand-property is at least 2 
> orders of magnitude more difficult (at least on my server). 
> I do know you will find several refereneces to 
> expand-property by me -- all indicating that there was 
> absolutely no plans for implementation of that optional 
> report in my server.  I don't see how moving this can be 
> considered 'by consensus'.
> It was considered OPTIONAL before, it still should be.  At a 
> minimum, change the SHOULD to a MAY.
> ===============
> I do not agree that the VCR is not properly associated with 
> the list of previous versions.  They are intimately related 
> both on my server and, to the best of my ability to predict, 
> the minds of my users.  I have no PROBLEM crippling the 
> report (version-tree) to comply with the spec.  So I guess 
> I'll let that one rest.
> > 
> > This was discussed in the ondon IETF meeting and reported in
> > the minutes 
> > 
> http://lists.w3.org/Archives/Public/ietf-dav-versioning/2001Ju
> As I recall, there was little objection in the room to this
> report as it was considered a relatively simple recursion for 
> the client and/or server to implement.
Received on Wednesday, 5 September 2001 17:26:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC