除了标准的 HTTPPUT方法（用于创建或覆盖 Web 资源）之外，WebDAV 还定义了新的COPY和MOVE方法，用于复制或重新排列资源。

这只是 WebDAV 中资源（URI）分组的术语。在大多数情况下，它类似于“目录”。如果某项以尾随的“/”结尾，则可以判断它是一个集合。而文件资源可以使用PUT方法进行写入或创建，集合资源则可以使用新的MKCOL方法进行创建。

这与 Subversion 中的理念相同——附加到文件和集合的元数据。客户端可以使用新的PROPFIND方法列出或检索附加到资源的属性，并可以使用PROPPATCH方法更改属性。某些属性完全由用户创建和控制（例如，名为“color”的属性），而另一些属性完全由 WebDAV 服务器创建和控制（例如，包含文件上次修改时间的属性）。前者称为“死”属性，后者称为“活”属性。

WebDAV 服务器可能决定为客户端提供锁定功能——规范的这部分是可选的，尽管大多数 WebDAV 服务器都提供此功能。如果存在，则客户端可以使用新的LOCK和UNLOCK方法来调节对资源的访问。在大多数情况下，这些方法用于创建独占写锁定（如名为“锁定-修改-解锁解决方案”的部分中所述），但也可以使用共享写锁定。

与 CVS 和其他版本控制系统一样，DeltaV 假设每个资源都有无限个状态。客户端首先使用新的VERSION-CONTROL方法将资源置于版本控制之下。这将创建一个新的版本控制资源 (VCR)。每次您更改 VCR（通过PUT, PROPPATCH等）时，都会创建一个新的资源状态，称为版本资源 (VR)。VCR 和 VR 仍然是普通 Web 资源，由 URL 定义。特定的 VR 也可以有易于理解的名称。

某些 DeltaV 服务器支持在服务器上创建虚拟“工作区”，您可以在其中执行所有工作。客户端使用MKWORKSPACE方法创建私有区域，然后指示他们想要更改特定 VCR，方法是将其“检出”到工作区，对其进行编辑，然后再次“检入”。从 HTTP 的角度来看，方法的顺序为CHECKOUT, PUT, CHECKIN。每次进行CHECKIN时，都会创建一个新的 VR，并且编辑的 VCR 的内容现在“指向”最新的 VR。每个 VCR 还具有一个“历史”资源，用于跟踪和排序其各种 VR 状态。

某些 DeltaV 服务器还支持客户端可能拥有一个包含特定 VR 的私有工作副本的理念。（这就是 CVS 和 Subversion 的工作方式。）当客户端想要将更改提交到服务器时，它首先使用MKACTIVITY方法创建临时服务器事务（称为活动）。然后，客户端对要更改的每个 VR 执行CHECKOUT，这会在活动中创建许多临时“工作资源”，可以使用PUT和PROPPATCH方法对其进行修改。最后，客户端对每个工作资源执行CHECKIN，这会在每个 VCR 中创建一个新的 VR，并且整个活动将被删除。

DeltaV 允许您定义称为“配置”的 VCR 的灵活集合，这些集合不一定对应于特定的目录。每个 VCR 的内容可以使用UPDATE方法使其指向特定的 VR。一旦配置完美，客户端就可以创建整个配置的“快照”，称为“基线”。客户端使用CHECKOUT和CHECKIN方法来捕获配置的特定状态，就像它们使用这些方法来创建 VCR 的特定 VR 状态一样。

DeltaV 定义了一种新方法，即REPORT，它允许客户端和服务器执行自定义数据交换。客户端发送一个REPORT请求，请求体中包含一个带有适当标签的 XML，其中包含自定义数据；假设服务器理解特定报告类型，则它将使用同样自定义的 XML 体进行响应。此技术非常类似于 XML-RPC。

对许多人来说，这是 DeltaV 的“杀手”功能。如果 DeltaV 服务器支持此功能，则基本的 WebDAV 客户端（即不知道版本控制的客户端）仍然可以写入服务器，并且服务器会自动执行版本控制。在最简单的示例中，来自基本 WebDAV 客户端的无知的PUT可能会被服务器翻译为CHECKOUT, PUT, CHECKIN.