Appropriate XML processing in extensibility consideration (Was rfc2518bis DAV DTD)

Julian,

I am getting more clear on what the true issues are.  Thanks!

However, it seems to me that there are different options to resolve the
extensibility issue and WG seems to choose the following approach:

   1. For client implementations, ignore XML elements they do not
       understand.

       "Older clients will not break when they encounter extensions
       because they will still have the data specified in the original
       schema and will ignore elements they do not understand."

   2. For server implementations, ignore any unknown  XML
       element and all its children encountered.

       "All DAV compliant resources MUST ignore any unknown
        XML element and all its children encountered while processing
        a DAV method that uses XML as its command language."

       As told by you, this rule will be extended to include any unknown
       XML attribute.  Right?

To summarize what I understand so far:

    1. WG is seeking a formal notation to describe the XML components
        contained in any message body that need to be minimally understood
        by all DAV-compliant (including DAV's extensions) implementations.

        Any bogus (or should be called "alien") XML elements (or attributes)
        will be simply ignored without even raising a flag.  So, to avoid
        hackers using this feature to launch denial-of-access attacks is to
limit
        the size of XML data allowed in the request body.

        Additionally, there is no need for any implementation to use any
schema
        to check whether received XML data is valid or not.   What it needs
        to do is just walking through the XML elements and check if it is
what
        the implementation can understand or not.   If yes, take action;
        otherwise, ignore it.

    2. The DAV response header (and new proposed DAV request
        header is just informational and has no constraining power.

Am I right?

Thx,

-Stanley

----- Original Message -----
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Stanley Guan" <stanley.guan@oracle.com>; "Julian Reschke"
<julian.reschke@gmx.de>; <w3c-dist-auth@w3.org>
Sent: Thursday, October 16, 2003 12:28 AM
Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...)


> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stanley Guan
> > Sent: Wednesday, October 15, 2003 10:41 PM
> > To: Julian Reschke; w3c-dist-auth@w3.org
> > Subject: Re: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...)
> >
> >
> >
> > Julian,
> >
> > See my comments inline!
> >
> > Thx,
> >
> > -Stanley
> >
> > ...
> >
> > > Last time was dicussed I was told that this will not allow new
extension
> > > elements from the DAV: namespace.
> >
> > True.  But, new DAV extension elements should be explicitly listed in
> > the "choice" component.  So, any bogus element in DAV: namespace
> > can be caught.
>
> How does that help? If a recipient validates a message based on a
> RFC2518bis-based XML Schema, and draft-ietf-webdav-redirect-ref protocol
> extends a particular element, these messages will not be valid according
to
> the Schema *without* modifying the schema. The point of extensibility is
> that old components continue to work with extended messages *without*
> modification.
>
> > I thought we want to be loose on what can be allowed at element
> > level.  Within each element, don't we want all attributes to be
> > explicitly spelt out?  Why do we need arbitrary attributes to be
> > allowed on any specific DAV: element?
>
> Because that's allowed now.
>
> > ...
>
> Regards, Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>

Received on Thursday, 16 October 2003 12:48:22 UTC