Subject: Access Control Protocol -07 submitted

From: "Jim Whitehead" <[email-masked]>
Date: Fri, 9 Nov 2001 16:57:04 -0800

I have submitted draft-ietf-webdav-acl-07, the WebDAV Access Control
Protocol, to the IETF for inclusion in the Internet Drafts directory. It
should appear there in a few days.

Big thanks are due to Julian Reschke, Stefan Eissing, Keith Wannamaker,
Dylan Barrell, Tim Ellison, Lisa Dusseault, Greg Stein, and Geoff Clemm for
their review of the -06 specification, and/or comments and suggestions on
working drafts between -06 and -07.

This specification can be found at:

http://www.webdav.org/acl/

Specifically:

Text:
http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.txt
PDF:
http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.pdf
Word (change tracking active):
http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07-tracked.doc
HTML:
http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.htm

- Jim

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 13 Nov 2001 19:16:46 +0100

Hi,

I'd suggest to extend section 10 to make a few statements about content type
and encoding of request/responses.

In particular,

- MUST support text/xml,

(because it's what all examples have been using since RFC2518)

- SHOULD accept application/xml,

(because it makes more sense than text/xml)

- when text/xml is used and the encoding is not US-ASCII, the charset MUST
be declared in the content type

(as per XML media types RFC2376),

- the bodies MUST be encoded in UTF-8 or UTF-16.

(because XML processors are not required to support anything else).

(of course this is not really an ACL issue, but ACL would be the first
WebDAV spec to clarify this).

Julian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Jim
> Whitehead
> Sent: Saturday, November 10, 2001 1:57 AM
> To: [email-masked]; WebDAV
> Subject: [ACL] Access Control Protocol -07 submitted
>
>
> _______________________________________________
> acl mailing list
> [email-masked]
> http://mailman.webdav.org/mailman/listinfo/acl
>

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 13 Nov 2001 19:43:14 +0100

OK, here's my attempt to clarify it:

10	XML PROCESSING

10.1	Request / response marshalling

The XML media type rules as defined in [RFC2376] apply:
Servers and clients MUST support the content type "text/xml". When this
content type is used, the character set MUST be specified in the "charset"
parameter unless the character set is "US-ASCII".
Servers and clients also SHOULD accept the content type "application/xml".
For this content type, the "charset" parameter is not required, but it is
STRONGLY RECOMMENDED to specify it anyway.
Request and response bodies MUST be encoded in one of the standard XML
encodings ("UTF-8" or "UTF-16") .

10.2	Request / response parsing
Implementations of this specification MUST support the XML element ignore
rule, as specified in Section 23.3.2 of [RFC2518], and the WebDAV XML
Namespace  interpretation convention, described in Section 23.4 of
[RFC2518]recommendation [REC-XML-NAMES].
Note that use of the DAV namespace is reserved for XML elements and property
names defined in a standards-track or Experimental IETF RFC.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Julian Reschke
> Sent: Tuesday, November 13, 2001 7:17 PM
> Subject: content type for WebDAV request/response bodies, was: [ACL]
> Access Control Protocol -07 submitted
>
>
> Hi,
>

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 16 Nov 2001 21:41:43 +0100

Below is an attempt to clarify the role of the DTD fragments:

19	APPENDICIES
19.1	WebDAV XML Document Type Definition Addendum
All XML elements defined in this Document Type Definition (DTD) belong to
the XML namespace "DAV:"DAV namespace. This DTD should be viewed as an
addendum to the DTD provided in [RFC2518], section 23.1.
Note that WebDAV messages must not be validated using the DTD, as WebDAV is
based on XML namespaces, and the special WebDAV "element ignore" rule
([RFC2518], section 23.3.2) applies.
The following transformations need to be applied to a WebDAV message before
it can be validated using the DTD:
-	removal of all elements and attributes not defined in RFC2518 or this
specification,
-	transformation of all remaining elements into elements in no namespace.

> Sent: Tuesday, November 13, 2001 7:43 PM
> To: Julian Reschke; [email-masked]; WebDAV
> Subject: RE: content type for WebDAV request/response bodies, was: [ACL]

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 18 Nov 2001 16:59:15 +0100

OK,

to verify my wording, I've done the following:

1) write an XSLT that extracts all XML examples from rfc2518.xml (needs an
XSLT engine with the XSLT 1.1 xsl:document function),

2) write an XSLT that implements the transformation in my proposal (XSLT
1.0).

Results (attached):

1) The RFC2518 DTD has an error in the keepalive element (at least according
to MSXML).

2) Example 8.1.1 in RFC2518 (response) isn't wellformed.

3) Several DTD validation errors were found:

3a) in ordering of lockdiscovery child elements,
3b) in the examples in appendix C (which were supposed to fail).

Question: so *do* we assume that child element ordering is relevant? In
which case, the examples in RFC2518 should be fixed.

Julian

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Julian Reschke
> Sent: Friday, November 16, 2001 9:42 PM

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 19 Nov 2001 17:10:27 -0800

> 1) The RFC2518 DTD has an error in the keepalive element (at
> least according to MSXML).

OK -- how *should* this element be represented in DTD language?

> 2) Example 8.1.1 in RFC2518 (response) isn't wellformed.

Which is the offending element. This looks OK to me.

> which case, the examples in RFC2518 should be fixed.

It was certainly my and Yaron's position that the ordering rules of XML
didn't apply when sending XML across the wire. That is, the ordering rules
make sense when you're doing markup of documents, but do not when you're
sending a set of protocol elements where semantically the order of arrival
is not meaningful. However, reading through RFC 2518, it appears we never
explicitly stated this. It is certainly implied in the fact that we do not
require validity, but only well formedness.  Well-formed XML does not
necessarily adhere to the ordering given in a specific DTD.

- Jim

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 19 Nov 2001 17:10:27 -0800

It seems reasonable to me to add this text. I'd also go further, and
explicitly note that validating requests and responses is generally a bad
idea. IETF protocols should be strict in what they send, liberal in what
they accept. Strict checking of a DAV message for validity is more stringent
than is necessary to interpret the meaning of the message. It has been my
experience that implementations that do require strict validity tend to be
much less interoperable, since they tend to reject XML that most other
implementations accept without any problem. This is why the DAV spec. has
never required anything more than well formedness.

- Jim

> Note that WebDAV messages must not be validated using the DTD, as
> WebDAV is based on XML namespaces, and the special WebDAV "element
> ignore" rule ([RFC2518], section 23.3.2) applies.
> The following transformations need to be applied to a WebDAV
> message before it can be validated using the DTD:
> -	removal of all elements and attributes not defined in
> RFC2518 or this specification,

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 20 Nov 2001 09:11:02 +0100

> Sent: Tuesday, November 20, 2001 2:10 AM

Well, it's not possible anyway, unless we have a proper definition of what
this means for WebDAV. The DTD as it stands won't do it.

> never required anything more than well formedness.

Well, XML does "draconian" error checking on accept, and this is one of the
reasons *why* XML interoperability  is quite good. The main point is to
state the requirements clearly and early.

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 20 Nov 2001 09:18:07 +0100

> OK -- how *should* this element be represented in DTD language?

I'm not DTD expert, but in the worst case it would have to be "ANY".

> Which is the offending element. This looks OK to me.

~/dav-validation> saxon exmpl-8.1.1.f.2.xml ../identity.xslt
Error on line 17 column 26 of
file:/c:/reschke/dav-validation/exmpl-8.1.1.f.2.xml:
  Error reported by XML parser: undeclared name prefix in: R:DingALing
Error on line 17 column 26 of
file:/c:/reschke/dav-validation/exmpl-8.1.1.f.2.xml:
  Error reported by XML parser: undeclared name prefix in: R:DingALing
Error on line 17 column 32 of
file:/c:/reschke/dav-validation/exmpl-8.1.1.f.2.xml:
  Error reported by XML parser: undeclared name prefix in: R:Random
Error on line 17 column 32 of
file:/c:/reschke/dav-validation/exmpl-8.1.1.f.2.xml:
  Error reported by XML parser: undeclared name prefix in: R:Random
Error
  XML Parsing failed
Transformation failed: run-time errors were reported

> necessarily adhere to the ordering given in a specific DTD.

You can't loosen the rules for XML validity (without stating them precisely
and possibly giving them a different term).

WebDAV messages can't be validated programatically, so well-formedness is
all we have.

We are having this discussion as I was trying to come up with a way how to
turn the (by definition) non-normative DTD fragments into something that is
actually usable (even if just for debugging).

I agree that in WebDAV, element ordering *shouln't* matter. If this is the
consensus, I'd try to rephrase my proposal so this is covered. In
particular, the transformation algorithm would have to re-order elements
(which requires some typing, but shouldn't be a problem).

Yes, this is getting messy. Other approaches would be:

- make sure that the specs work without the DTD fragments (I think deltav
does), or

- use a schema language that does what we need (I think XML Schema won't
work either because of the ordering aspect, but RELAX NG might do it).

Julian

---

From: "Matt Timmermans" <[email-masked]>
Date: Tue, 20 Nov 2001 11:15:48 -0500

> -----Original Message-----
From: Jim Whitehead
> From: Julian Reschke

The closest you can get is (#PCDATA|href)*

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 20 Nov 2001 18:05:25 +0100

BTW:

<href> doesn't make sense here anyway, right? (property names aren't HREFs).

> [mailto:[email-masked]]On Behalf Of Matt Timmermans
> Sent: Tuesday, November 20, 2001 5:16 PM
> To: 'WebDAV'

---

From: "Jim Whitehead" <[email-masked]>
Date: Tue, 20 Nov 2001 09:39:07 -0800

Wow, even knowing where to look, I still had to look twice.  Yes, this is
definitely an error -- we need to either move the xmlns declaration up into
the response element, or add a second declaration of it.

- Jim

---

From: "Matt Timmermans" <[email-masked]>
Date: Tue, 20 Nov 2001 16:49:16 -0500

Appendix 23.4 provides an unambiguous interpretation of property names as
HREFs.  This will no longer apply when appendix 23.4 goes away.

I've seen Microsoft use a convention for coding property names as HREFs that
would work well for 2518:

If the property's namespace ends in "/" or ":", then the property HREF is
namespace+local_name, just like Today.

Otherwise, the property HREF is namespace+"#"+local_name.

WebDAV would have to codify this in the description of DAV:keepalive.  This
would at least be compatible with most current environments.

Ideally, keepalive should be (allprop|prop), but that would break everybody.

> Sent: Tuesday, November 20, 2001 12:05 PM
> To: 'WebDAV'

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 21 Nov 2001 01:07:45 +0100

Matt,

> Sent: Tuesday, November 20, 2001 10:49 PM
> To: 'Julian Reschke'; 'WebDAV'

The definition is broken. It doesn't work. See [1].

> would work well for 2518:

No, it doesn't.

> Otherwise, the property HREF is namespace+"#"+local_name.

How do you encode the local name? Given an arbitrary URI, how do you select
base URI and element name? ...and so on. It doesn't work.

> would at least be compatible with most current environments.

I would care more if there is a single server implementation that actually
implements keepalive. Is there?

> Ideally, keepalive should be (allprop|prop), but that would break

Ideally, the whole behaviour of copying live/dead properties needs to be
redefined, I think.

Regards, Julian

[1] <http://mailman.webdav.org/pipermail/acl/2001-November/000929.html>

---

From: "Matt Timmermans" <[email-masked]>
Date: Wed, 21 Nov 2001 12:44:35 -0500

From: Julian Reschke
> From: Matt Timmermans

To encode a general local name, you use UTF8 encoding and %xx escapes, as
recommended in section B.2.1 of the HTML spec.

http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.1

To get the namespace URI and local name from a property URI, just scan
backwards for the last '#', '/', or ':', and split the URI.  If the left
part ends in #, then remove it.

> implements keepalive. Is there?

Sort of.  Depending on the context, our server can either satisfy any
keepalive request, or it cant satisfy any keepalive request.  In the latter
situation, we fail the copy if keepalive is specified.

But a server doesn't have to implement keepalive to be broken by changing
the content model -- it only has to validate requests.

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 21 Nov 2001 18:51:24 +0100

> From: Matt Timmermans [mailto:[email-masked]]
> Sent: Wednesday, November 21, 2001 6:45 PM

That doesn't give you a one-to-one mapping.

For instance:

<foo xmlns="http://a.b.c/d#"/> and <foo xmlns="http://a.b.c/d"/>

would map to the same URI.

How would you map

<foo xmlns="http://a.b.c/d#e"/>

???

---

From: "Matt Timmermans" <[email-masked]>
Date: Wed, 21 Nov 2001 13:14:41 -0500

> From: Julian Reschke [mailto:[email-masked]]

Sure it does.
 
> would map to the same URI.

You get

http://a.b.c/d#%23foo and http://a.b.c/d#foo

> <foo xmlns="http://a.b.c/d#e"/>

http://a.b.c/d#e%23foo

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 21 Nov 2001 19:21:54 +0100

OK,

so how do you map

<oo xmlns="http://a.b.c/d#f"/>

?

> Sent: Wednesday, November 21, 2001 7:15 PM

---

From: "Matt Timmermans" <[email-masked]>
Date: Wed, 21 Nov 2001 13:26:33 -0500

> <oo xmlns="http://a.b.c/d#f"/>
http://a.b.c/d#f%23oo

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 20 Nov 2001 22:35:18 -0800

> <foo xmlns="http://a.b.c/d#e"/>

I've seen this done before.  MTimmerman's rules for undoing the
concatenation were correct as I recall, but he didn't put the rules for
concatenation in, which would have cleared things up.
 - If the namespace ends in '/' or ':', concatenate.
 - If the namespace ends in anything else, add a '#' and concatenate.

Thus, you'd transform <foo xmlns="http://a.b.c/d#"/> to
"http://a.b.c/d##foo".  Clearly different than "http://a.b.c/d#foo" since
you only remove the last '#' when un-concatenating.

You ask how to map <foo xmlns="http://a.b.c/d#e"/>: since it ends in 'e',
add a '#', and it becomes "http://a.b.c/d#e#foo".  When going back to real
XML form, scan backward from the end for the last '#', remove it.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 21 Nov 2001 19:40:31 +0100

> From: Lisa Dusseault [mailto:[email-masked]]
> Sent: Wednesday, November 21, 2001 7:35 AM
> To: Julian Reschke; [email-masked]; 'WebDAV'
> ..

But "http://a.b.c/d#e#foo" isn't a valid URI (reference), right?

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 20 Nov 2001 22:54:53 -0800

Where I saw this used, it wasn't supposed to be a valid URI.  It was just
supposed to be a way of representing DAV property names to systems that only
supported name/value pairs, rather than namespace/name/value tuples.

lisa

> Sent: Wednesday, November 21, 2001 10:41 AM
> To: Lisa Dusseault; Julian Reschke; [email-masked]; 'WebDAV'

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 21 Nov 2001 20:24:06 +0100

OK,

then it's much easier to use Jim Clark's:

{namespaceUri}name

Julian

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Wednesday, November 21, 2001 7:55 AM

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 21 Nov 2001 20:49:54 +0100

> Sent: Wednesday, November 21, 2001 8:08 PM
> To: 'Julian Reschke'; 'Lisa Dusseault'; 'WebDAV'
> ...
> If we must have an encoding scheme for property URIs, and I think we must,
> then it would help interoperability to conform to Microsoft's wherever
> possible.

Why do you think that we need an encoding scheme?

And does the encoding scheme need to produce URIs, or will any Unicode
string do?

I think that identifying properties using the pair (namespace name, local
name) is just fine, and how a server treats this internally shouldn't be of
any concern to the spec.

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 21 Nov 2001 19:36:53 +0100

Well,

that's not what your algorithm said, right?

> Sent: Wednesday, November 21, 2001 7:27 PM

---

From: "Matt Timmermans" <[email-masked]>
Date: Wed, 21 Nov 2001 14:08:18 -0500

> But "http://a.b.c/d#e#foo" isn't a valid URI (reference), right?

It is if you uri-escape the added '#' to get http:/a.b.c/d#e%23foo

I wasn't as detailed as I could have been about the algorithm, because these
particular details aren't important.  There are any number of injective
encodings you might devise.

The important part is the decision about whether to add '#' or to just
concatenate.  Most people have started making sure that their namespaces end
in ':' or '/', depending on whether they use URNs or URLs.  This is
especially true for WebDAV developers who might think about a property's
URI, and don't want the local name to merge with a final path segment.

This URI encoding scheme preserves element identity in accordance with
XMLNS, while maintaining backward compatability for these existing systems.
Microsoft is the only implementor I know of that makes extensive use of
property URIs (I think they use them a lot in their DASL implementation).
It's just one implementor, but it's an important one, and they already have
an encoding scheme for property URIs that makes some sense.

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 22 Nov 2001 09:57:39 +0100

> Sent: Wednesday, November 21, 2001 8:50 PM
> To: [email-masked]; 'Julian Reschke'; 'Lisa Dusseault'; 'WebDAV'

Another one:

what's the point of having a URI for a WebDAV property?

Is the underlying assumption that if the URIs of two properties are
equivalent, the properties are identical? In which case: this won't work:
the scheme name is case insensitive, the definition of equivalence for the
scheme-specific-part is up to the URI scheme, so how could a program know
them all?

Consider:

a) <foo xmlns="http://www.webdav.org/xmlns/2001" />

b) <foo xmlns="HTTP://www.webdav.org/xmlns/2001" />

c) <foo xmlns="HTTP://www.webdav.org/xmlns/2001/." />

According to XML NS and RFC2518, all these properties are different (because
namespace matching is done character by character).

However, the namespace URIs in a) and b) are equivalent as per RFC2396,
section 6.

c's namespace name would be equivalent, depending on whether the program
knows the equivalence rules for this particular URI scheme.

---

From: "Stefan Eissing" <[email-masked]>
Date: Thu, 22 Nov 2001 09:56:57 +0100

> [...]

Sorry, I must have missed that. Why do we need property URIs as compared
to identifiers like {namespaceuri}localname? In which specification are
they used?

//Stefan