[Bug 72] Review references section from bugzilla@soe.ucsc.edu on 2006-01-29 (w3c-dist-auth@w3.org from January to March 2006)

From: <bugzilla@soe.ucsc.edu>
Date: Sun, 29 Jan 2006 01:51:53 -0800
To: w3c-dist-auth@w3.org
Message-Id: <200601290951.k0T9pr4Y015344@ietf.cse.ucsc.edu>

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

julian.reschke@greenbytes.de changed:

------- Additional Comments From julian.reschke@greenbytes.de 2006-01-29 01:51 -------
1) Made W3C refs consistent.
2) Made sure RFC2518 is indeed referenced.

Proposed changes below and in
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz072>:

Section 1., para. 11:
OLD:

WebDAV uses [XML] for property names and some values, and also uses
XML to marshal complicated request and response. This specification
contains DTD and text definitions of all all properties (Section 15)
and all other XML elements (Section 14) used in marshalling. WebDAV
includes a few special rules on extending (Section 17) WebDAV XML
marshalling in backwards-compatible ways.

NEW:

WebDAV uses XML ([REC-XML]) for property names and some values, and
also uses XML to marshal complicated request and response. This
specification contains DTD and text definitions of all all properties
(Section 15) and all other XML elements (Section 14) used in
marshalling. WebDAV includes a few special rules on extending
(Section 17) WebDAV XML marshalling in backwards-compatible ways.

Section 4.3., para. 6:
OLD:

The value of the property appears inside the property name element.
The value may be any kind of well-formed XML content, including both
text-only and mixed content. Servers MUST preserve the following XML
Information Items (using the terminology from [W3C.REC-xml-infoset-
20040204]) in storage and transmission of dead properties:

NEW:

The value of the property appears inside the property name element.
The value may be any kind of well-formed XML content, including both
text-only and mixed content. Servers MUST preserve the following XML
Information Items (using the terminology from [REC-XML-INFOSET]) in
storage and transmission of dead properties:

Section 8.1., para. 1:
OLD:

In HTTP/1.1, method parameter information was exclusively encoded in
HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter
information either in an [XML] request entity body, or in an HTTP
header. The use of XML to encode method parameters was motivated by
the ability to add extra XML elements to existing structures,
providing extensibility; and by XML's ability to encode information
in ISO 10646 character sets, providing internationalization support.

NEW:

In HTTP/1.1, method parameter information was exclusively encoded in
HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter
information either in an XML ([REC-XML]) request entity body, or in
an HTTP header. The use of XML to encode method parameters was
motivated by the ability to add extra XML elements to existing
structures, providing extensibility; and by XML's ability to encode
information in ISO 10646 character sets, providing
internationalization support.

Section 8.1., para. 3:
OLD:

All DAV compliant clients and resources MUST use XML parsers that are
compliant with [XML] and XML Namespaces [W3C.REC-xml-names-19990114].
All XML used in either requests or responses MUST be, at minimum,
well formed and use namespaces correctly. If a server receives XML
that is not well-formed then the server MUST reject the entire
request with a 400 (Bad Request). If a client receives XML that is
not well-formed in a response then the client MUST NOT assume
anything about the outcome of the executed method and SHOULD treat
the server as malfunctioning.

NEW:

All DAV compliant clients and resources MUST use XML parsers that are
compliant with [REC-XML] and [REC-XML-NAMES]. All XML used in either
requests or responses MUST be, at minimum, well formed and use
namespaces correctly. If a server receives XML that is not well-
formed then the server MUST reject the entire request with a 400 (Bad
Request). If a client receives XML that is not well-formed in a
response then the client MUST NOT assume anything about the outcome
of the executed method and SHOULD treat the server as malfunctioning.

Section 9.10.2., para. 3:
OLD:

Note that in RFC2518, clients were indicated through the example in
the text to use the If header to specify what lock to refresh (rather
than the Lock-Token header). Servers are encouraged to continue to
support this as well as the Lock-Token header.

NEW:

Note that in [RFC2518], clients were indicated through the example in
the text to use the If header to specify what lock to refresh (rather
than the Lock-Token header). Servers are encouraged to continue to
support this as well as the Lock-Token header.

Section 13.2., para. 1:
OLD:

Redirect responses (300-303, 305 and 307) defined in HTTP 1.1
normally take a Location header to indicate the new URI for the
single resource redirected from the Request-URI. Multi-Status
responses contain many resource addresses, but the original
definition in RFC2518 did not have any place for the server to
provide the new URI for redirected resources. This specification
does define a 'location' element for this information (see
Section 14.9). Servers MUST use this new element with redirect
responses in Multi-Status.

NEW:

Redirect responses (300-303, 305 and 307) defined in HTTP 1.1
normally take a Location header to indicate the new URI for the
single resource redirected from the Request-URI. Multi-Status
responses contain many resource addresses, but the original
definition in [RFC2518] did not have any place for the server to
provide the new URI for redirected resources. This specification
does define a 'location' element for this information (see
Section 14.9). Servers MUST use this new element with redirect
responses in Multi-Status.

Section 14., para. 1:
OLD:

In this section, the final line of each section gives the element
type declaration using the format defined in [XML]. The "Value"
field, where present, specifies further restrictions on the allowable
contents of the XML element using BNF (i.e., to further restrict the
values of a PCDATA element). The "Extensibility" field discusses how
the element may be extended in the future (or in existing extensions
to WebDAV.

NEW:

In this section, the final line of each section gives the element
type declaration using the format defined in [REC-XML]. The "Value"
field, where present, specifies further restrictions on the allowable
contents of the XML element using BNF (i.e., to further restrict the
values of a PCDATA element). The "Extensibility" field discusses how
the element may be extended in the future (or in existing extensions
to WebDAV.

Section 15., para. 1:
OLD:

For DAV properties, the name of the property is also the same as the
name of the XML element that contains its value. In the section
below, the final line of each section gives the element type
declaration using the format defined in [XML]. The "Value" field,
where present, specifies further restrictions on the allowable
contents of the XML element using BNF (i.e., to further restrict the
values of a PCDATA element).

NEW:

For DAV properties, the name of the property is also the same as the
name of the XML element that contains its value. In the section
below, the final line of each section gives the element type
declaration using the format defined in [REC-XML]. The "Value"
field, where present, specifies further restrictions on the allowable
contents of the XML element using BNF (i.e., to further restrict the
values of a PCDATA element).

Section 15.2., para. 4:
OLD:

Protected: SHOULD NOT be protected. Note that servers implementing
RFC2518 might have made this a protected property as this is a new
requirement.

NEW:

Protected: SHOULD NOT be protected. Note that servers implementing
[RFC2518] might have made this a protected property as this is a
new requirement.

Section 15.3., para. 4:
OLD:

Protected: SHOULD NOT be protected, so that clients can reset the
language. Note that servers implementing RFC2518 might have made
this a protected property as this is a new requirement.

NEW:

Protected: SHOULD NOT be protected, so that clients can reset the
language. Note that servers implementing [RFC2518] might have
made this a protected property as this is a new requirement.

Section 17., para. 1:
OLD:

The XML namespace extension [W3C.REC-xml-names-19990114] is used in
this specification in order to allow for new XML elements to be added
without fear of colliding with other element names. Although WebDAV
request and response bodies can be extended by arbitrary XML
elements, which can be ignored by the message recipient, an XML
element in the "DAV:" namespace SHOULD NOT be used in the request or
response body unless that XML element is explicitly defined in an
IETF RFC reviewed by a WebDAV working group.

NEW:

The XML namespace extension ([REC-XML-NAMES]) is used in this
specification in order to allow for new XML elements to be added
without fear of colliding with other element names. Although WebDAV
request and response bodies can be extended by arbitrary XML
elements, which can be ignored by the message recipient, an XML
element in the "DAV:" namespace SHOULD NOT be used in the request or
response body unless that XML element is explicitly defined in an
IETF RFC reviewed by a WebDAV working group.

Section 18.3., para. 1:
OLD:

A resource can explicitly advertise its support for the revisions to
RFC2518 made in this document. Class 1 MUST be supported as well.
Class 2 MAY be supported. Advertising class 3 support in addition to
class 1 and 2 means that the server supports all the requirements in
this specification. Advertising class 3 and class 1 support, but not
class 2, means that the server supports all the requirements in this
specification except possibly those that involve locking support.

NEW:

A resource can explicitly advertise its support for the revisions to
[RFC2518] made in this document. Class 1 MUST be supported as well.
Class 2 MAY be supported. Advertising class 3 support in addition to
class 1 and 2 means that the server supports all the requirements in
this specification. Advertising class 3 and class 1 support, but not
class 2, means that the server supports all the requirements in this
specification except possibly those that involve locking support.

Section 19., para. 2:
OLD:

XML also provides a language tagging capability for specifying the
language of the contents of a particular XML element. The "xml:lang"
attribute appears on an XML element to identify the language of its
content and attributes. See [XML] for definitions of values and
scoping.

NEW:

Section 20.6., para. 1:
OLD:

XML supports a facility known as "external entities", defined in
section 4.2.2 of [XML], which instruct an XML processor to retrieve
and include additional XML. An external XML entity can be used to
append or modify the document type declaration (DTD) associated with
an XML document. An external XML entity can also be used to include
XML within the content of an XML document. For non-validating XML,
such as the XML used in this specification, including an external XML
entity is not required by XML. However, XML does state that an XML
processor may, at its discretion, include the external XML entity.

NEW:

XML supports a facility known as "external entities", defined in
section 4.2.2 of [REC-XML], which instruct an XML processor to
retrieve and include additional XML. An external XML entity can be
used to append or modify the document type declaration (DTD)
associated with an XML document. An external XML entity can also be
used to include XML within the content of an XML document. For non-
validating XML, such as the XML used in this specification, including
an external XML entity is not required by XML. However, XML does
state that an XML processor may, at its discretion, include the
external XML entity.

Section 20.6., para. 4:
OLD:

Furthermore, there's also a risk based on the evaluation of "internal
entities" as defined in section 4.2.2 of [XML]. A small, carefully
crafted request using nested internal entities may require enormous
amounts of memory and/or processing time to process. Server
implementors should be aware of this risk and configure their XML
parsers so that requests like these can be detected and rejected as
early as possible.

NEW:

Furthermore, there's also a risk based on the evaluation of "internal
entities" as defined in section 4.2.2 of [REC-XML]. A small,
carefully crafted request using nested internal entities may require
enormous amounts of memory and/or processing time to process. Server
implementors should be aware of this risk and configure their XML
parsers so that requests like these can be detected and rejected as
early as possible.

Section 21.1., para. 3:
OLD:

2. the "DAV" URI scheme, which historically was used in RFC2518 to
disambiguate WebDAV property and XML element names and which
continues to be used for that purpose in this specification and
others extending WebDAV. Creation of identifiers in the "DAV:"
namespace is controlled by the IETF.

NEW:

2. the "DAV" URI scheme, which historically was used in [RFC2518] to
disambiguate WebDAV property and XML element names and which
continues to be used for that purpose in this specification and
others extending WebDAV. Creation of identifiers in the "DAV:"
namespace is controlled by the IETF.

Section 23.1., para. 1:
OLD:

[W3C.REC-xml-infoset-20040204]
Tobin, R. and J. Cowan, "XML Information Set (Second
Edition)", W3C REC REC-xml-infoset-20040204,
February 2004.

[W3C.REC-xml-names-19990114]
Hollander, D., Bray, T., and A. Layman, "Namespaces in
XML", W3C REC REC-xml-names-19990114, January 1999.

[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
Edition)", W3C REC-xml-20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-20040204>.
NEW:

[REC-XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
Edition)", W3C REC-xml-20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-20040204>.

[REC-XML-INFOSET]
Cowan, J. and R. Tobin, "XML Information Set (Second
Edition)", W3C REC-xml-infoset-20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-infoset-20040204/>.

[REC-XML-NAMES]
Bray, T., Hollander, D., and A. Layman, "Namespaces in
XML", W3C REC-xml-names-19990114, January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114>.

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

Received on Sunday, 29 January 2006 09:52:02 UTC