[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[jamsden@us.ibm.com: DeltaV Working Group Last Call]

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-10-10 00:41:49 CEST

FYI

----- Forwarded message from Jim Amsden/Raleigh/IBM <jamsden@us.ibm.com> -----

To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org
From: "Jim Amsden/Raleigh/IBM" <jamsden@us.ibm.com>
Date: Mon, 9 Oct 2000 08:10:20 -0400
Subject: DeltaV Working Group Last Call

*** WORKING GROUP LAST CALL FOR COMMENTS ***

WebDAV Versioning and Configuration Management PROTOCOL SPECIFICATION

This is the final call for comments from the DeltaV working group on the
WebDAV Versioning and Configuration Management Specification,
draft-ietf-deltav-versioning-10. This last call for comments period begins
immediately, and ends December 1, 2000, at midnight, US Eastern time. This
allows just over seven weeks for review of the specification in time for
the December IETF '49 meeting.

At the end of the last call review period, a new draft will be issued.
Depending on the scope of changes introduced between the -10 and -11
versions, there will either be an immediate call for rough consensus (very
few changes), or a second last call review period (significant changes).
Once the document represents the rough consensus of the working group, I
will submit this document to the Internet Engineering Steering Group (IESG)
for their approval. IESG review involves a (minimum) two week public last
call for comments period. This IESG-initiated last call period is in
addition to the working group last call period.

This document is intended to be a "Proposed Standard". Quoting from RFC
2026, "The Internet Standards Process -- Revision 3":

   The entry-level maturity for the standards track is "Proposed Standard".
A specific action by the IESG is required to move a specification onto the
standards track at the "Proposed Standard" level.

   A Proposed Standard specification is generally stable, has resolved
known design choices, is believed to be well-understood, has received
significant community review, and appears to enjoy enough community
interest to be considered valuable. However, further experience might
result in a change or even retraction of the specification before it
advances.

   Usually, neither implementation nor operational experience is required
for the designation of a specification as a Proposed Standard. However,
such experience is highly desirable, and will usually represent a strong
argument in favor of a Proposed Standard designation.

Many details on the procedures used to develop an IETF standard can be
found in RFC 2026, available at: http://www.ietf.org/rfc/rfc2026.txt

If there are any procedural questions or concerns, please do not hesitate
to contact me, or raise an issue on the list.

Notes:

1) Issues raised during the last call period will be resolved individually,
rather than lumped together and dealt with as a whole. This follows the
issue-resolution convention being followed in the HTTP WG.

2) If you've been waiting for a "stable" version of the specification
before performing a review, you need wait no longer. This is it. We value
your input, but time is running out. So please review the specification now
in order to ensure your input gets included.

- Jim Amsden
Chair, IETF DeltaV Working Group

----- End forwarded message -----

-- 
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:10 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.