Subject: [Bug 72] Review references section

From: [email-masked]
Date: Sun, 29 Jan 2006 01:51:53 -0800

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

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         [email-masked]    [email-masked]
             Status|REOPENED                    |NEW
            Version|-08                         |-11

------- Additional Comments From [email-masked]  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:

    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 [REC-XML] for definitions of values and
    scoping.

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.