Hi,
I agree with Jim that deltav needs some time to see what issues people
find during implementation and to iron out some of the issues we already
know about.
In my opinion the group needs to spend some time looking at existing issues,
working on scenarios, FAQs, clarifications to the specification, sorting out
packaging issues, etc. Many members of deltav are also in the webdav group,
that specification needs to be revised (to move along the standards track),
ACL, DASL and advanced collections need to be completed. This sounds like
plenty of work to keep the group busy :-)
Over time APIs like the proposed JSR-147 will help get implementations up
and
running and we can see what issues we find during interop testing.
I would be interested in proposals to extend deltav for:
Change/Issue Management (and simple Workflow),
Event Notification (servers letting clients know when resources/properties
change),
Multi-part mime requests (setting properties and doing an operation in one
request),
Strong typed properties (eg this property only contains dates/numbers/list
of valid values etc).
The larger specs like Change Management could run in a separate working
group.
As WebDAV becomes more widely adopted and the web is used as a writeable
medium I
expect many users will require some kind of change/task/issue management and
workflow
to help them control and manage the changes.
MERANT has been doing some work on Change Management extensions to WebDAV
internally,
I would be interested to see how our thoughts on this subject match up (or
not) with
those of other members of the WebDAV community.
Regards,
--
Peter Raymond - MERANT
Principal Architect (PVCS)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
mailto:Peter.Raymond@merant.com
WWW: http://www.merant.com
-----Original Message-----
From: Jim Amsden [mailto:jamsden@us.ibm.com]
Sent: 23 October 2001 01:41
To: ietf-dav-versioning@w3.org
Subject: Re: Submission: deltav subset
Roy,
We're not talking about shutting down DeltaV just yet. As I pointed out
below, the spec isn't an Internet Standard yet, we still have quite a ways
to go. However, the current working group has fulfilled its charter and
its time to update it or create a new one. The work that remains is to see
how well the spec is adopted, both by clients and servers, and how well we
met our goals, including interoperability objectives. To do this I think
we need some "quiet time" where we aren't making substantive changes to
the spec so developers have something stable to build from. Once we have
more experience, we should see what work is left to do and establish a new
charter to address it. This doesn't need to be a continuation of DeltaV,
but it could be. We have an established community and infrastructure
(webdav.org and the DeltaV mailing list). Depending on what surfaces, we
may want to leverage the existing working group for continuity.
In an case, if DeltaV did shutdown, the process would be to hold a BOF at
an IETF meeting to introduce ideas and gather interest, develop a new
charter spelling out the activities of a new working group, getting AD
approval, and doing the work by submitting Internet drafts. This is
certainly the right way to go for significant new features like change
management for example. But for expedience, fixing details and
interoperability problems in the current spec should probably be done in
the context of the current working group.
Roy Seto <Roy.Seto@oracle.com>
Sent by: ietf-dav-versioning-request@w3.org
10/22/2001 04:55 PM
To: ietf-dav-versioning@w3.org
cc:
Subject: Re: Submission: deltav subset
If the WG shuts down, what is the accepted mechanism for hashing out
protocol usage issues that surface during implementation?
Roy
Jim Amsden wrote:
I'm inclined to declare victory on our DeltaV charter and let some servers
get built on what we have before we start making a lot of immediate
changes. Of course I would welcome any BOF to determine level of interest
in extensions, new packages, etc. DeltaV is now firmly on the standards
track. The next step is to get some implementation and determine
interoperability issues. If the community fragments immediately on
different packages that aren't interoperable in meaningful ways, then
certainly that's good information for the standards process that would
need to be addressed. But I think the community would benefit from
attempting to implement the spec as written so we encourage
interoperability.
As for shutting down DeltaV, we're only at proposed standard. We could
consider updating the charter to move to the next stage in the lifecycle.
I would be happy to entertain suggestions as to the content of such a
charter, and if there's sufficient interest, we can propose the next set
of work items to the AD's as either continuation of DeltaV (with a new
charter), or other working groups focused on more specific tasks.
"Jim Whitehead" <ejw@cse.ucsc.edu>
10/18/2001 06:36 PM
To: "Clemm, Geoff" <gclemm@rational.com>, "'Lisa
Dusseault'" <lisa@xythos.com>, "Jim Amsden" <jamsden@us.ibm.com>
cc:
Subject: RE: Submission: deltav subset
Geoff Clemm writes:
> I think it is more appropriate to keep it as an
> individual submission until the working group has had
> a chance to review/iterate on it.
This may be true, but IETF policy does say that it is the Chair's
discretion
on whether a document is a WG draft or an individual submission.
I was just pointing out that Jim may cause friction with the ADs if, by
making a new WG draft, he extends the life of DeltaV when they think it's
close to being shut down. I imagine they are keen to avoid another WebDAV
:-)
But, even if Jim does decide that it should not be a new draft, it would
be
well within Lisa's rights to hold a BOF at the next IETF with an eye
towards
creating a new WG, "SDV" (simple Delta V), say.
- Jim