Minutes: Versioning TeleConf Agenda, 5/1/00 (Monday) 2pm-3pm EST

From: Clemm, Geoff (gclemm@Rational.Com)
Date: Mon, May 01 2000

  • Next message: Clemm, Geoff: "draft-ietf-deltav04.5 now available"

    Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D880@chef.lex.rational.com>
    From: "Clemm, Geoff" <gclemm@Rational.Com>
    To: "DeltaV (E-mail)" <ietf-dav-versioning@w3.org>
    Date: Mon, 1 May 2000 17:09:42 -0400 
    Subject: Minutes: Versioning TeleConf Agenda, 5/1/00 (Monday) 2pm-3pm EST
    
    Participants: Jim Amsden, Tim Ellison, Jim Doubek, Chris Kaler, Geoff Clemm
    
    Agenda:
    
    - Auto-versioning.  Only for downlevel clients, or also for versioning
    clients?  (Perhaps add "downlevel" as another option for DAV:auto-version?)
    
    There were no arguments raised beyond those already posted to the list,
    so in the end, we just voted, and 4 were in favor of having it only apply
    to downlevel clients (indicated by the absense of a Target-Selector or
    Workspace header), so unless more information or votes come to bear, we'll
    be going with it only applying to versioning-unaware clients.
    
    - DAV:revisions.  Is it a problem that this can be a big property?
    
    From a client perspective, this could be addressed with a "revision-count"
    property, so a client only asks for it if it really wants that much
    information.
    This still leaves the "denial of service" problem, when the server is off
    trying to create the list of 50,000 revisions at a web site.
    
    The question of why we are providing this property at all was raised,
    since you can find out what revisions of the members of a particular
    collection are
    being selected by just doing a Depth PROPFIND, asking for the DAV:revision
    property.  So unless someone comes up with a compelling reason for
    DAV:revisions,
    we'll just get rid of it.
    
    - A late addition to the agenda was DAV:linear.  In particular, is it an
    appropriate replacement for DAV:single-checkout and if so, should it be
    restricted to versioned resources that currently only have one revision
    with no descendents?
    
    Somehow, we got from DAV:linear/DAV:single-checkout to unreserved checkouts.
    Currently, an activity handles "reserved" or "exclusive" checkouts,
    but JimD and Chris both advocated the support for "unreserved" or
    "shared" checkouts.  This can be handled by adding an "unreserved"
    flag to the checkout request, so Geoff will go work up some language
    for review by the group.
    
    Note: It appears I sent the orginal agenda on Friday just to myself
    (wasn't that useful :-), so don't be surprised if the only agenda for
    today's meeting that you got was the one I posted shortly before
    the meeting itself.
    
    Cheers,
    Geoff