|
|
|
|
Found 6 records.
Errata ID: 1068
Status: Verified
Type: Technical
Reported By: Julian Reschke
Date Reported: 2007-11-13
Verifier Name: Lisa Dusseault
Date Verified: 2007-11-13
Section 10.4.7 says:
If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
<urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)
It should say:
If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
<urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)
Notes:
Indentation is relevant here. In the published form, the second line would be a separate (invalid) HTTP header, not a continuation line.
Errata ID: 1430
Status: Verified
Type: Editorial
Reported By: Werner Baumann
Date Reported: 2008-05-26
Verifier Name: Lisa Dusseault
Date Verified: 2008-05-30
Section 9.3 says:
9.3 MKCOL Method MKCOL creates a new collection resource at the location specified by the Request-URI. [...]
It should say:
9.3 MKCOL Method The MKCOL method is used to create a new collection. All DAV compliant resources MUST support the MKCOL method. MKCOL creates a new collection resource at the location specified by the Request-URI. [...]
Notes:
The statement, that support for MKCOL is a MUST-requirement has unintentionally been dropped.
Errata ID: 1207
Status: Reported
Type: Technical
Reported By: Julian Reschke
Date Reported: 2008-01-03
Section 9.10.1 says:
A LOCK request to an existing resource will create a lock on the resource identified by the Request-URI, provided the resource is not already locked with a conflicting lock. The resource identified in the Request-URI becomes the root of the lock. LOCK method requests to create a new lock MUST have an XML request body. The server MUST preserve the information provided by the client in the 'owner' element in the LOCK request. The LOCK request MAY have a Timeout header.
It should say:
A LOCK request to an existing resource will create a lock on the resource identified by the Request-URI, provided the resource is not already locked with a conflicting lock. The Request-URI becomes the root of the lock. LOCK method requests to create a new lock MUST have an XML request body. The server MUST preserve the information provided by the client in the 'owner' element in the LOCK request. The LOCK request MAY have a Timeout header.
Notes:
This is incorrect in that it implies that the "lock root" is a resource, not a URL (<http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=251>). However, should a directly locked resource have multiple bindings, only the one used in the Request-URI of the LOCK request will be the protected from changes of clients not supplying the lock token.
Note that this change makes the description consistent with the definition of the DAV:lockroot XML element in Section 14.12 of [RFC4918].
Errata ID: 1519
Status: Reported
Type: Technical
Reported By: Manfred Baedke
Date Reported: 2008-09-19
Section 8.3 says:
Within Simple-ref productions, senders MUST NOT:
o use dot-segments ("." or ".."), or
o have prefixes that do not match the Request-URI (using the
comparison rules defined in Section 3.2.3 of [RFC2616]).
It should say:
Within Simple-ref productions, senders MUST NOT use dot-segments ("." or "..").
Simple-ref productions used in Multi-Status responses MUST NOT have prefixes that
do not match the Request-URI (using the comparison rules defined in Section 3.2.3
of [RFC2616]).
Notes:
The original text explicitly applies not only to Simple-ref productions used in Multi-Status responses, but also to those used in Destination Headers. Since URIs used in Destination headers may have other prefixes (for example in a cross-server COPY request), this is wrong.
Errata ID: 1371
Status: Reported
Type: Editorial
Reported By: Julian Reschke
Date Reported: 2008-03-14
Edited by: Alexey Melnikov
Date Edited: 2010-07-07
Section 9.2 says:
Servers MUST process PROPPATCH instructions in document order (an
exception to the normal rule that ordering is irrelevant).
It should say:
Servers MUST process the child elements of the propertyupdate XML
element in the order they appear in the request body (an exception to
the normal rule that ordering is irrelevant).
Notes:
There are no "PROPPATCH" instructions in the request document (PROPPATCH is a method name, not an XML element name used in WebDAV).
Note this issue was raised during Gen-art review, but not fixed before publication (http://www.ietf.org/mail-archive/web/gen-art/current/msg01823.html)
Errata ID: 1635
Status: Held for Document Update
Type: Editorial
Reported By: Zdenek Kouba
Date Reported: 2008-12-13
Held for Document Update by: Alexey Melnikov
Date Held: 2010-07-11
Section 7.4 says:
MOVE an internal member into the collection,
It should say:
MOVE inserting a new internal member into the collection,
Notes:
Edited the corrected text as per discussion between Lisa and Julian.