Re: WebDAV Delta-V Working Group Last Call (fwd)

Am I missing something here?  The bit which I'd have thought was 
particularly relevant to RDF is the WEBDAV work, which is already a 
proposed standard (RFC2518).  I fail to see the XP relevance of this.

The DELTAV pieces, as I understand, are those extra bits which allow 
multiple versions and incremental changes to be handled within the WEBDAV 
framework.

#g
--

At 02:07 PM 1/20/01 +0000, Dan Brickley wrote:

>RDF and XP folk,
>
>Forwarded for info; if you send in review comments please copy the RDF
>or XP lists if it seems appropriate. Bear in mind that this is a last call,
>so comments such as 'you should start again and use RDF/SOAP/XP/whatever'
>are unlikely to be helpful. If someone were to put some time into doing
>an analysis of the WebDAV/Delta-V approach in the context of things like
>RDF and XP, that'd be hugely useful, as would reports from any
>implementors working with both technology families in the same environment.
>
>noteworth excerpt...
>[[
>If you've been waiting for a "stable" version of the specification
>before performing a review, you need wait no longer.  This is it.
>]]
>
>Dan
>---------- Forwarded message ----------
>Date: Sat, 20 Jan 2001 08:43:10 -0500
>From: Jim Amsden <jamsden@us.ibm.com>
>To: ned@innosoft.com, "Patrik [iso-8859-1] Fältström" <paf@swip.net>,
>      ietf-dav-versioning@w3.org, w3c-dist-auth@w3c.org
>Subject: WebDAV Delta-V Working Group Last Call
>Resent-Date: Sat, 20 Jan 2001 08:46:17 -0500 (EST)
>Resent-From: w3c-dist-auth@w3.org
>
>*** DeltaV WORKING GROUP LAST CALL FOR COMMENTS ***
>
>Web Versioning and Configuration Management PROTOCOL SPECIFICATION
>
>We are happy to announce the second working group last call for comments
>from the DeltaV working group on the Versioning Extensions to WebDAV
>Specification, draft-ietf-deltav-versioning-12 available at
>http://www.ietf.org/ids.by.wg/deltav.html or http://www.webdav.org/deltav/.
>This last call for comments period begins immediately, and ends February 1,
>2001, at midnight, US Eastern time.  This allows sufficient time for review
>of the specification in time for the March IETF '50 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 -12 and -13
>versions, there will either be an immediate call for rough consensus (very
>few changes), or a third 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

Received on Sunday, 21 January 2001 12:57:07 UTC