[Bug 73] "Changes" section missing

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

julian.reschke@greenbytes.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu
             Status|ASSIGNED                    |NEW



------- Additional Comments From julian.reschke@greenbytes.de  2006-02-12 08:29 -------
OK, see text below. I'd also suggest to remove the client/server/client+server
separation and to use instead the suggested structure based on functional areas.
XML source for the new section was attached in
<http://ietf.cse.ucsc.edu:8080/bugzilla/attachment.cgi?id=11&action=view>.
Reassigning to Elias.


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).

   [[changes.organization: Looking at the current contents of the
   changes section, it seems to be more useful to organize by group
   instead by client/server.  Adding some more comments to highlight
   potential grouping...]]

D.1.  Changes for both Clients and Servers

   [[D.1.1: 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, 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 is a
   'response' element with a 3xx status (see Section 14.24).

   Due to lack of implementation, support for 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.

   [[D.1.2: Properties]]

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

   [[D.1.3: 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.

   [[D.1.4: 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 associated
   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
   reversed (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).

   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.

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

D.2.  Changes Notable to Server Implementors

   [[D.2.1: 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).

   [[D.2.2: 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 Sunday, 12 February 2006 16:29:38 UTC