Re: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...)

Hi,

I'm new on this mailing list.  So, forgive me if my questions were
brought up before.

For security consideration, external XML entities are considered
vulnerable to denial of service attack. So, I agree that WebDAV
messages MUST not be validated using DTDs.  Or it can be
optional, if an implementation opt to do that.

Anyone else have ever thought of using XML Schema, instead of
DTD, to validate WebDAV messages?  Any security concerns?

Will appreciate your inputs!


-Stanley



----- Original Message -----
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: "Julian Reschke" <julian.reschke@gmx.de>; <w3c-dist-auth@w3.org>
Sent: Tuesday, October 14, 2003 12:31 PM
Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...)



Hi Julian,

I'm surprised once again.  OK, there are several topics here:

1. Having a generic DTD for WebDAV, or at least one that is generic as
possible considering that actual documents can introduce ad hoc elements and
attributes in various places.

There was a question about how to do it and sources on the technique.  I
have addressed that question.  I have only addressed the question in the
context of section 24.2 of bis-04, because I saw immediate application
there.  It is also an useful cross-check on the specification and it
provides an operable DTD that people can use in working with the
specification, creating DAV protocol elements manually, etc., under the
understanding that it is non-normative.

2. Having a way that someone could develop a quasi-generic DTD for a family
of WebDAV XML documents of interest.

I think that comes out of (1).  Since this is a restricted-use situation, a
precise DTD might actually be possible for many situations in practice, and
I demonstrated a way to have that.  It is also possible in many places where
ad hoc properties and attributes are either not provided for or don't happen
to be used.

3. Using XML DTD Fragments (markup declarations) to illustrate/explicate
(not specify) the structures that apply for specific elements of WebDAV.

Since that can't be "normative" as a DTD anywhere that allows ad hoc
elements in the content model, or ad hoc attributes of an element, I would
think  it is a nit whether you use a convention of supposing a
representative (explicit) namespace prefix for QNames in the specification,
as many XML-family specifications do, or you show the use of parameters in
the specimen markup declarations.  It's the difference between

<!ELEMENT dav:error ...>
<!ATTLIST dav:error
                xmlns:dav (DAV:) #REQUIRED
          ... >
and <!ELEMENT %dp;error ...>
<!ATTLIST %dp;error
                xmlns%ds; (DAV:) #REQUIRED
          ... >

where the second parameterizes the use of namespace prefix, but which might
not be so appealing in the flow of the exposition.  Either way, I would not
show the <!ATTLIST ...> everywhere.  The assumption of such an <!ATTLIST
...> would be explained in the documentation of fragment usage in the
specification.

I am not addressing the question of DTD fragments with my proposal for
section 24.2.  One can do 24.2 independent of whether markup declarations
are used elsewhere in the specification, and whether they are of the same
literal form.

4. Concerning the question of whether or not Document Type Declarations
(<!DOCTYPE ...>) should be allowed in the XML document prolog of DAV request
and response bodies, I see my recommendation for 24.2 as orthogonal to that.

Also, I don't believe there is agreement to disallow Document Type
Declarations at this time.  (I will keep repeating that presence of a
Document Type Declaration and using a non-validating processor are separate
but interacting matters.)

It is valuable to have a DTD that is crafted in such a way that it can be
used to establish validity of a document in proper form (e.g., no defaulted
attribute values for required attributes) for use with or without
validation, with or without a Document Type Declaration.  I think one can
come close to that as a practical matter.  I find it valuable.

I find interactions with the requirement for use of a non-validating XML
processor to be problematic.  A way to assure a predictable, interoperable
non-validating process case is to omit Document Type Declarations in
requests (as a practice, even if not a requirement of 2518).  There is
absolutely no doubt about validation in that case. So omission of a Document
Type Declaration is a good practice for obtaining clearly-predictable
behavior in DAV requests (and appropriate safety, regarding any concern for
reference to external parameters and external XML entities as identified in
section 18.6 of bis-04).

Dealing with a server that provides Document Type Declarations in responses
is something I don't want to think about.  In practice, that borders on a
hostile act, since it imposes processing on the client and has the
interpretation of the response be unpredictable in some cases.  It raises
the bar for universal client processors.

5. Why do I consider (4) and some of the other items when we are "only"
talking about HTTP extensions and what happens in that narrow band of what
the DAV functioning is all about -- the exchange of protocol elements?

I answer with a question: Why is it important to use XML in that narrow
setting? I am considering the setting and the desire people have to be able
to understand the rules, apply tools that are available and supported in the
industry, and also be able to check their work (or the work of their
software) as well as trouble-shoot.  That strikes me as valuable.

6. Is it worth it?  I don't know.  I demonstrated the degree to which it
could be done.  Developers of other XML-family specifications have found it
worthwhile.  Does it hurt?  How can it?
Would I do it?  Yes.

This can clearly be done.  Whether it is included in the specification or
not seems to be the question.  We need some other countries to be heard
from.

-- Dennis


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Tuesday, October 14, 2003 07:43
To: dennis.hamilton@acm.org; w3c-dist-auth@w3.org
Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...)


Dennis,

I'm not sure what you're trying to achieve.

On the one hand, we're trying to clarify that WebDAV messages MUST not be
validated using DTDs. On the other hand, you're trying to come up with a
clever way to enable DTD validation. As far as I understand, it will never
work for arbitrary now legal WebDAV messages, so why bother?

After all, the initial question was about whether we want to continue using
DTD fragments to specify some constraints on WebDAV messages -- after all,
this is what all published and soon-to-be published WebDAV-related specs do.
So if there's an issue with that notation, we should fix just that, nothing
more... In particular, if "fixing" the DTD notation essentially means to
make it extremely complicated to read, this will be in fact
contra-productive.

[ ... ]

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Tuesday, 14 October 2003 16:24:48 UTC