[Bug 73] "Changes" section missing

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=73





------- Additional Comments From julian.reschke@greenbytes.de  2006-02-11 12:26 -------
OK, here's a first version of the rewrite that *should* be complete.

While doing the changes I rearranged some more entries, and was left
with no client-only changes at all, and only few server-only. I therefore
propose dropping the distinction, and to group by topic groups instead
(as shown in the example comments).

Feedback appreciated.


Appendix D.  Summary of changes from RFC2518

   This section lists changes that are likely to result in
   implementation changes due to tightened requirements or changed
   behavior.  Servers will advertise support for the changes in this
   specification by returning the compliance class "3" in the DAV
   response header (see Sections 10.1 and 18.3).

D.1.  Changes for both Clients and Servers

   [[anchor131: Collections and Namespace Operations]]

   The definition of collection state has been fixed so it doesn't vary
   anymore depending on the Request-URI (see Section 5.2).

   The semantics of PROPFIND 'allprop' (Section 9.1) have been relaxed
   so that servers may leave out live properties defined in other
   specifications.  This reflects the actual semantics used in other
   specs, such as [RFC3253] and [RFC3744].  Related to this, 'allprop'
   requests can now be extended with the 'include' syntax to include
   specific named properties, thereby avoiding additional requests due
   to changed 'allprop' semantics.

   Servers are now allowed to reject PROPFIND requests with Depth:
   Infinity.  Generic clients will need to be able to do a series of
   Depth:1 requests instead.

   Due to interoperability problems, the requirements for the contents
   of <href> elements in multistatus responses have been strengthened
   (see Section 8.2).

   Multistatus response bodies now can transport the value of HTTP's
   Location response header in the new 'location' element.  Clients may
   use this to avoid additional roundtrips to the server when there's a
   'response' element with a 3xx status (see Section 14.24).

   Due to lack of implementation, the 'propertybehaviour' request body
   for COPY and MOVE has been removed.  Instead, requirements for
   property preservation have been clarified (see Sections 9.8 and 9.9).

   The definition of COPY has been relaxed so that it doesn't require
   servers to first delete the target resources anymore (this was a
   known incompatibility with [RFC3253] (see Section 9.8).

   [[anchor132: Properties]]

   The DAV:source property introduced in Section 4.6 of [RFC2518] was
   removed due to lack of implementation experience.

   [[anchor133: Locking]]

   RFC2518's concept of "lock-null resources" (LNRs) has been replaced
   by a simplified approach, the "locked empty resources" (see
   Section 7.3).  There are some aspects of lock-null resources clients
   can not rely on anymore, namely the ability to use them to create a
   locked collection or the fact that they disappear upon UNLOCK when no
   PUT or MKCOL request was issued.  Note that servers are still allowed
   to implement LNRs as per RFC2518.

   There is no implicit refresh of locks anymore.  Locks are only
   refreshed upon explicit request.  Furthermore, the lock token for the
   lock to be refreshed is now specified in the Lock-Token request
   header rather than the If header (see Section 9.10.2).

   Strengthened requirement to check identity of lock creator when
   accessing locked resources (see Section 6.4).  Clients should be
   aware that lock tokens returned to other principals can only be used
   to break a lock, if at all.

   Clarified that the DAV:owner value supplied in the LOCK request must
   be preserved by the server just like a dead property (Section 14.17).
   Also added the DAV:lockroot element (Section 14.12) which allows
   clients to discover the root of lock.

   [[anchor134: Headers and Marshalling]]

   Servers are now required to do authorization checks before processing
   conditional headers (see Section 8.4).

   The DAV header now allows non-IETF extensions through URIs in
   addition to compliance class tokens.  It also can now be used in
   requests, although this specification does not define any semantics
   for the compliance classes defined in here (see Section 10.1).

   The Destination and If request headers now allow absolute paths in
   addition to full URIs (see Section 8.2).  This may be useful for
   clients operating through a reverse proxy that does rewrite the Host
   request header, but not WebDAV-specific headers.

   In RFC2518, the definition of the Depth header (Section 9.2) required
   that by default request headers would be applied to each resource in
   scope.  Based on implementation experience, the default has now been
   changed not to do this (see Section 10.2).

   The TimeType format used in the Timeout request header and the
   "timeout" XML element used to be extensible.  Now, only the two
   formats defined by this specification are allowed (see Section 10.7).

   Senders and recipients are now required to support the UTF-16
   character encoding in XML message bodies (see Section 19).

   This specification adopts the error marshalling extensions and the
   "precondition/postcondition" terminology defined in [RFC3253] (see
   Section 16).  Related to that, it adds the "error" XML element inside
   multistatus response bodies (see Section 14.5, however note that it
   uses a format different from the one recommend in RFC3253).

   The definitions of HTTP status code 102 ([RFC2518], Section 10.1) and
   the Status-URI response header (Section 9.7) have been removed due to
   lack of implementation.

D.2.  Changes Notable to Server Implementors

   [[anchor136: Properties]]

   Strengthened server requirements for storage of property values, in
   particular persistence of language information (xml:lang),
   whitespace, and XML namespace information (see Section 4.3).

   Clarified requirements on which properties should be writeable by the
   client; in particular, setting "DAV:displayname" should be supported
   by servers (see Section 15).

   Only 'rfc1123-date' productions are legal as values for DAV:
   getlastmodified (see Section 15.7).

   [[anchor137: Locking]]

   Section 8.10.4 of [RFC2518] incorrectly required servers to return a
   409 status where a 207 status was really appropriate.  This has been
   corrected (Section 9.10).




------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

Received on Saturday, 11 February 2006 20:26:46 UTC