Subject: Re: Request for feedback: WebDAV property datatype draft

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Sep 2004 09:15:29 +0200

Hi,

I just submitted draft 07 of draft-reschke-webdav-property-datatypes:

<http://www.ietf.org/internet-drafts/draft-reschke-webdav-property-datatypes-07.txt>

As previously announced, this draft removes the definition of various 
property flags and DASL extensions, concentrating on the core property 
datatyping as implemented / being implemented in SAP's Enterprise Portal 
and SAP Netweaver, and Xythos WebFile Server.

This part of the spec has been stable for several years now, and as far 
as I can tell, the WebDAV working group currently lacks the time to 
transform this into a Working Group activity. On the other hand, this 
work not only is implemented in shipping products, it should also be 
valuable for anybody looking at adding typing to WebDAV properties. 
Thus, it probably makes sense for it being published by the IETF, either 
as experimental or proposed protocol.

I hereby invite all readers to review the spec (both for content and 
editorial aspects). Unless no new issues are raised, I plan to last-call 
it and then submit it to the IESG as a private submission. I'd also 
appreciate feedback on which publication status (experimental/proposed) 
I should target.

Note that those sections that were removed (see change information in 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-07.html>) 
will later appear in a separate draft built on top of the core property 
types spec.

Best regards, Julian

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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 12 Sep 2004 14:19:14 +0200

Hi,

so far I haven't received any feedback on the content of the latest 
property datatypes draft (announcement in [1], TXT and HTML versions at 
[2] and [3]).

I'm therefore last-calling this draft, with the goal of submitting a 
minimally revised version (see below) for publication as "Experimental 
RFC" in two weeks from now.

Quoting from "The Internet Standards Process -- Revision 3" 
(<http://www.ietf.org/rfc/rfc2026.txt>), section 4.2.1:

    4.2.1  Experimental

    The "Experimental" designation typically denotes a specification that
    is part of some research or development effort.  Such a specification
    is published for the general information of the Internet technical
    community and as an archival record of the work, subject only to
    editorial considerations and to verification that there has been
    adequate coordination with the standards process (see below).  An
    Experimental specification may be the output of an organized Internet
    research effort (e.g., a Research Group of the IRTF), an IETF Working
    Group, or it may be an individual contribution.

I think that this protocol extension falls under this definition; the 
WebDAV working group currently doesn't seem to plan working on it 
itself, but the protocol is already implemented by different vendors, 
and thus it's a good thing to have it documented and published. 
Furthermore, it hasn't changed significantly since it was proposed first 
in August 2001. Also, the IETF is the right place to do this as it 
extends another IETF protocol (RFC2518).

If the working group at a later point decides to work on property 
datatypes itself, it can use the document as a basis (with real world 
deployment), or it can still decide to define something completely 
different.

Edits continue on the "latest" version ([4]). Right now I'm only 
planning to simplify the subsection nesting (which really is only an 
artefact from the time when the draft also spoke about two other 
features, property flags and displayname information).

Best regards, Julian

[1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/0108.html>
[2] 
<http://www.ietf.org/internet-drafts/draft-reschke-webdav-property-datatypes-07.txt>
[3]
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-07.html>
[4]
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-latest.html>

---

From: Brian Korver <[email-masked]>
Date: Mon, 13 Sep 2004 11:14:28 -0700

Julian,

I think that the MUST and MUST NOT in the following should really
be must and must not, in other words:

  5.1  Marshalling of datatype information

    PROPFIND is extended to return the data type information for
    properties unless one of the following conditions is met:

    o  The data type must be different from "xs:string" (because this can
       be considered the default data type).

    o  The property's data type must not be defined in [RFC2518] (because
       these types are already well-defined).

-brian
[email-masked]

On Sep 1, 2004, at 12:15 AM, Julian Reschke wrote:
> datatyping as implemented / being implemented in SAP's Enterprise  
> Portal and SAP Netweaver, and Xythos WebFile Server.
>
> This part of the spec has been stable for several years now, and as  
> far as I can tell, the WebDAV working group currently lacks the time  
> to transform this into a Working Group activity. On the other hand,  
> this work not only is implemented in shipping products, it should also  
> be valuable for anybody looking at adding typing to WebDAV properties.  
> Thus, it probably makes sense for it being published by the IETF,  
> either as experimental or proposed protocol.
>
> editorial aspects). Unless no new issues are raised, I plan to  
> last-call it and then submit it to the IESG as a private submission.  
> I'd also appreciate feedback on which publication status  
> (experimental/proposed) I should target.
>
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-property- 
> datatypes-07.html>) will later appear in a separate draft built on top  
> of the core property types spec.
>
> Best regards, Julian
>
> --

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Sep 2004 00:01:49 +0200

>       these types are already well-defined).

Brian,

good catch; I'll make that change and will also check for more places 
where we aren't specific enough.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Sep 2004 00:06:22 +0200

>       these types are already well-defined).

OK, I got that backwards.

Why do you think they should be lowercase? Are you anticipating servers 
that either do not want or can't implement it exactly that way? If so, why?

Best regards, Julian

---

From: Brian Korver <[email-masked]>
Date: Mon, 13 Sep 2004 16:56:12 -0700

Because these are conditions describing the state
of the world, not (in this context) mandates on
server behavior.

-brian
[email-masked]

On Sep 13, 2004, at 3:06 PM, Julian Reschke wrote:
> Why do you think they should be lowercase? Are you anticipating 
> servers that either do not want or can't implement it exactly that 
> way? If so, why?
>
> Best regards, Julian
>
> --

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Sep 2004 02:16:19 +0200

> of the world, not (in this context) mandates on

Yes, they are.

It says exactly when the server behaviour gets extended (when the type 
isn't "simple string" *and* if the property isn't defined in RFC2518).

Can you suggest alternative wording that keeps the  RFC2119 terminology?

Best regards, Julian

---

From: Brian Korver <[email-masked]>
Date: Tue, 14 Sep 2004 10:52:11 -0700

Julian,

I'm officially confused.  Your text states that they
are conditions ("the following conditions"), but you
claim here that they're not.  Anyhow, not worth arguing
about....

-brian
[email-masked]

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 14 Sep 2004 11:05:38 -0700

I have a nit on the draft: the example shows a boolean value of '1' in  
section 5.1, but the text below says this is a value of 'true'.

More globally, some issues:
  - I had some understanding from previous discussions that this was  
supposed to allow multi-valued properties.  However, it appears that  
the entire property value must be provided in each PROPPATCH request.   
It would be helpful if the specification communicated this.

  - I'm a little concerned that the multi-valued stuff is in an  
appendix.  If this functionality MUST be supported (by servers that  
support the draft) then the examples should be in the main text, so  
that server implementors aren't tempted not to support it.

  - The draft should make more explicit requirements on server  
implementors, to help ensure more interoperable and consistent  
implementations.  For example, the draft should say something along the  
lines of "Servers supporting this feature MUST support the following  
list of data types and the array data type... [etc] "

  - Should there be a way for clients to detect whether the server  
supports this feature?  I would think that would be better.  However,  
if there's no way, then there should be some guidance for clients along  
the lines of "If the client supports this draft, the client SHOULD send  
data typing information for all non-string data types, without even  
knowing whether the server supports the feature."

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Sep 2004 22:56:16 +0200

> claim here that they're not.  Anyhow, not worth arguing

Brian, I still don't get your point. The text clearly defines under 
which conditions the server should return datatype information. Do you 
have any proposal how to rephrase that?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Sep 2004 23:05:24 +0200

> section 5.1, but the text below says this is a value of 'true'.

The *typed* value is the same. Both "1" and "true" are legal 
serializations of the XML Schema datatype "boolean".

> It would be helpful if the specification communicated this.

Well, the spec doesn't change basic PROPPATCH semantics (and it never 
was claimed it does). Does it really need to state that it doesn't? Why?

> that server implementors aren't tempted not to support it.

No, it's an appendix because it's entirely optional. All that the spec 
defines is how you can use the xsi:type attribute from XML Schema to 
forward type information. It doesn't mandate support for any specific types.

> list of data types and the array data type... [etc] "

See above, they don't have to. Is there any hope that we can get a 
consensus of a minimum set?  I guess it wouldn't contain more than 
strings, dates and integers (I wouldn't even expect boolean support from 
everybody).

> supports this feature?  I would think that would be better.  However,  

The client can detect that by looking at PROPFIND and PROPPATCH responses.

> knowing whether the server supports the feature."

Section 6 
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-latest.html#rfc.section.6>) 
states that it's harmless to provide data type information upon 
PROPPATCH. Is there any need to expand this?

Julian

---

From: Brian Korver <[email-masked]>
Date: Tue, 14 Sep 2004 14:22:32 -0700

Julian,

It doesn't need rephrasing.  I think the capitalization needs
to be changed (from upper to lower), but the text is clear
(if a little jarring) without that change so it really doesn't
matter.

-brian
[email-masked]

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 14 Sep 2004 15:35:22 -0700

Responses inline...

On Sep 14, 2004, at 2:05 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> I have a nit on the draft: the example shows a boolean value of '1'  
>> in  section 5.1, but the text below says this is a value of 'true'.
>

It seemed like a bug to me, so maybe the example needs more explanation.

> was claimed it does). Does it really need to state that it doesn't?  

Only a matter of setting expectations -- what this spec does provide,  
what it doesn't provide.  Human-readable overview text to provide  
context for how to consider this work.

> forward type information. It doesn't mandate support for any specific  

If it were going to the regular standards track I'd strongly push for a  
list of mandated types to support.  Since you're proposing this for the  
experimental track, I suppose it can be conceptualized as a description  
of the way an implementor might do things with very little (nothing?)  
in the draft being required.

One consequence of having weak or no requirements, and no advertisement  
of the feature, you might find that it's difficult to get critical mass  
of support for this stuff, beyond the implementations that already  
support this or something of the kind.

>> implementations.  For example, the draft should say something along  
>> the  lines of "Servers supporting this feature MUST support the  
>> following  list of data types and the array data type... [etc] "
>
> strings, dates and integers (I wouldn't even expect boolean support  
> from everybody).

Depending on the concept for the document, I would go so far as to  
propose that all the built-in primitive types would be required,  
possibly also integer and a few of the integer-derived types.  Also the  
server would be required to support lists of any of the supported  
types.

>
>> if there's no way, then there should be some guidance for clients  
>> along  the lines of "If the client supports this draft, the client  
>> SHOULD send  data typing information for all non-string data types,  
>> without even  knowing whether the server supports the feature."
>
> Section 6  
> (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property- 
> datatypes-latest.html#rfc.section.6>) states that it's harmless to  
> provide data type information upon PROPPATCH. Is there any need to  
> expand this?

Depends on how readable you want the spec to be.  I would consider that  
information very helpful and clarifying.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Sep 2004 12:00:50 +0200

> It seemed like a bug to me, so maybe the example needs more explanation.

It currently says:

"This example shows that the property value "true" is returned with the 
correct data type information, and that the server chose one of the two 
possible representations defined in XML Schema."

Can you suggest a change? I think it's already clear enough...

> ...

> propose that all the built-in primitive types would be required,  

All of 
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#built-in-datatypes>??? 
Including things like all these specific date/duration formats?

> possibly also integer and a few of the integer-derived types.  Also the  

Integers *are* builtin types.

> server would be required to support lists of any of the supported  types.

1) I can easily imagine servers that do not support array-typed 
properties, and

2) even if they do, that would require the spec to make a normative 
statement about the format; the current format implented by us and 
described in the appendis is based on SOAP 1.1; and I'm sure many would 
prefer to avoid any SOAP dependencies.

> ...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Sep 2004 16:38:37 +0200

OK,

here's an issue I'd like to fix in the draft ([1]):

the current text speaks about PROPFIND, but what it *really* should be 
saying that this change applies to all methods that return RFC2518-style 
multistatus response bodies (such as REPORT/DAV:expand-property, defined 
in RFC3253, or SEARCH).

Proposal: add a new section (6) "Changes for other methods", specifying 
this (this will also add an informative reference to RFC3253 if we 
mention REPORT).

Feedback appreciated, Julian

[1] 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-latest.html#rfc.issue.other-method-semantics>

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 15 Sep 2004 13:16:59 -0400

That's fine with me.

Cheers,
Geoff

> datatypes-latest.html#rfc.issue.other-method-semantics>
> 
> --

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 15 Sep 2004 11:33:57 -0700

I also think it's a good idea.  Again, the draft could specify what the 
server MUST support, depending on what standards it has implemented.  
E.g. if the server has implemented both DeltaV and property data types, 
MUST it return whatever data typing information it has in REPORT 
responses?

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Sep 2004 00:24:20 +0200

Lisa Dusseault wrote:
> MUST it return whatever data typing information it has in REPORT responses?

That's the plan (ie., multistatus response bodies should be handled the 
same way no matter whether result of PROPFIND, REPORT or SEARCH).

Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Sep 2004 18:58:43 +0200

> MUST it return whatever data typing information it has in REPORT responses?

OK.

Issue and resolution: 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-latest.html#rfc.issue.other-method-semantics>:

"6.  Changes for other methods

    Servers that support other methods using the DAV:multistatus response
    format (such as the REPORT method defined in [RFC3253], section 3.6)
    SHOULD apply the same extensions as defined in Section 5."

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 22 Sep 2004 15:52:45 +0200

> context for how to consider this work.

OK, see 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-latest.html#rfc.issue.1_clarify_scope>:

    The following potential datatyping related features were deliberately
    considered out of scope:

    o  getting "schema" information for classes of resources (set of
       "required" properties, their types, display information),

    o  definition of a set of mandatory property types,

    o  discovery of supported property types,

    o  extensions to PROPPATCH that would allow updates to parts of a
       (structured) property.

> information very helpful and clarifying.

<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-latest.html#rfc.issue.7_discovery>:

    Servers not aware of datatype handling either drop the "xsi:type"
    attribute, or persist it along with the property value.  However,
    they will never indicate successful parsing of the data type by
    returning back the type in the response to PROPPATCH.  Thus, clients
    can supply type information without having to poll for server support
    in advance.

Feedback appreciated,

Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 23 Sep 2004 05:55:31 -0700

Bernard & I came up with more questions yesterday:

Can there be untyped arrays?  How would I show an array of XML elements?

E.g.  would this be valid?
   <supportedliveproperties xsi:type="soap-enc:Array">
     <supportedliveproperty><getetag/></supportedliveproperty>
     <supportedliveproperty><resourcetype/></supportedliveproperty>
     ...
   </supportedliveproperties>

Are arrays assumed to be ordered or unordered?  Would it be legal for a  
server to reorder array values when returning them?

Lisa

On Sep 22, 2004, at 6:52 AM, Julian Reschke wrote:

> datatypes-latest.html#rfc.issue.1_clarify_scope>:
>
>> Depends on how readable you want the spec to be.  I would consider  
>> that  information very helpful and clarifying.
>
> datatypes-latest.html#rfc.issue.7_discovery>:
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 23 Sep 2004 15:49:53 +0200

> Can there be untyped arrays?  How would I show an array of XML elements?

1) Yes. You can have whatever datatypes you want.

2) It's up to you to define a type for that (so far, we haven't needed 
that).

>   </supportedliveproperties>

As far as I can tell, it would be legal according to 
<http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383522>.

> server to reorder array values when returning them?

"The representation of the value of an array is an ordered sequence of 
elements constituting the items of the array."

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 23 Sep 2004 06:58:18 -0700

Can we include an example of an array of XML elements in the draft, so 
that implementors are likely to do it the same way?

I would also like to request some words on ordering in the draft, 
although I agree that the W3C Note says that ordering is significant 
that doesn't say everything.
  - Say that "servers MUST preserve ordering if the server is storing a 
dead property in array format" or something equivalent
  - What clients should do is a little less clear but let's take a stab 
at it:  clients that are adding a new value, removing a value, or 
changing a value in an array SHOULD maintain the rest of the array 
ordering, unless the user actually intends to resort the array to a 
different order.

thanks,

Lisa

On Sep 23, 2004, at 6:49 AM, Julian Reschke wrote:

>> Are arrays assumed to be ordered or unordered?  Would it be legal for 
>> a  server to reorder array values when returning them?
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 23 Sep 2004 16:06:59 +0200

> that implementors are likely to do it the same way?

I'd prefer not to. Adding examples for more then the absolute trivial 
things (like booleans or dates) is likely to open the proverbial can of 
worms, because people have different tastes about types and optimal 
serializations. So in doubt I'd even prefer to *remove* the current 
appendix (as I'm not convinced that this is a good serialization format 
given it's based on an outdated SOAP spec; it just happens to be what we 
*do* implement right now).

> dead property in array format" or something equivalent

Again, I'd prefer not to. An array is an array; not a set.

> ordering, unless the user actually intends to resort the array to a 

Well, that's the whole point of having an array.

I understand that you are particulary interested in this data type 
because you'll need it. It seems to me that the best strategy for you is 
to define that type in a separate document (possibly standalone or 
caldav), and let the property types spec stay out of this business.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 23 Sep 2004 07:21:02 -0700

Having the data-types spec stay out of arrays would certainly simplify 
it, so I can't object to that approach.  Certainly I would think that 
if somebody does an array/list/set property draft later the property 
data-type stuff can be re-used then.

What about clarifying that XML-valued properties don't need a data type?

I do disagree with the approach of minimizing examples for the reasons 
you cited.  Isn't it a *bad* thing if people have different tastes 
about types and optimal serializations, and doesn't that lead to lower 
interoperability?  Within an experimental protocol, that approach may 
be acceptable, but still undesirable.

Lisa

On Sep 23, 2004, at 7:06 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> Can we include an example of an array of XML elements in the draft, 
>> so that implementors are likely to do it the same way?
>
> things (like booleans or dates) is likely to open the proverbial can 
> of worms, because people have different tastes about types and optimal 
> appendix (as I'm not convinced that this is a good serialization 
> format given it's based on an outdated SOAP spec; it just happens to 
> be what we *do* implement right now).
>
>>  - Say that "servers MUST preserve ordering if the server is storing 
>> a dead property in array format" or something equivalent
>
>>  - What clients should do is a little less clear but let's take a 
>> stab at it:  clients that are adding a new value, removing a value, 
>> or changing a value in an array SHOULD maintain the rest of the array 
> because you'll need it. It seems to me that the best strategy for you 
> is to define that type in a separate document (possibly standalone or

---

From: Yves Lafon <[email-masked]>
Date: Thu, 23 Sep 2004 16:41:15 +0200 (MEST)

> elements constituting the items of the array."

Btw, you should see what has been done in SOAP Version 1.2
(see http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapenc ), which 
is a REC and not a Note.
Thanks,

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

---

From: Julian Reschke <[email-masked]>
Date: Thu, 23 Sep 2004 16:46:21 +0200

Lisa Dusseault wrote:

> it, so I can't object to that approach.  Certainly I would think that if 
> somebody does an array/list/set property draft later the property 

Yep. So is this a vote in favor of dropping Appendix A? (I would put it 
into a separate document, then).

> What about clarifying that XML-valued properties don't need a data type?

I do not agree they don't need one. As far as I concerned, the question 
of whether the property has just simple text content has nothing to do 
with whether it should have a type.

For instance, it would make sense to have a common type identifier for 
WebDAV properties that use the popular "href*" content format.

> you cited.  Isn't it a *bad* thing if people have different tastes about 
> types and optimal serializations, and doesn't that lead to lower 
> interoperability?  Within an experimental protocol, that approach may be 

Yes.

> acceptable, but still undesirable.

It's simply an area I don't want to cover here. IMHO, it makes perfect 
sense to state "if you have type information, this is how you can send 
it" without actually defining particular types (and instead, relying on 
existing type libraries).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 23 Sep 2004 16:51:56 +0200

Yves Lafon wrote:
> (see http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapenc ), 
> which is a REC and not a Note.
> Thanks,

I did a long time ago and couldn't find any description of array types 
anymore. Did I miss something?

Best regards, Julian

---

From: Yves Lafon <[email-masked]>
Date: Thu, 23 Sep 2004 17:26:09 +0200 (MEST)

> anymore. Did I miss something?

Yes, there are at
http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#complexenc
point 4 is about arrays, then you have
http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#itemtypeattr
and
http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#arraySizeattr
(along with a clarification in the errata
http://www.w3.org/2003/06/REC-soap12-20030624-errata.html#E29 )

---

From: Julian Reschke <[email-masked]>
Date: Thu, 23 Sep 2004 18:20:02 +0200

> http://www.w3.org/2003/06/REC-soap12-20030624-errata.html#E29 )

Oh, interesting.

IMHO we should thus eliminate the SOAP11-based example from the spec 
(see 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-latest.html#rfc.issue.a_remove_array_example>). 
I'm not so convinced that we should add a SOAP12 based example instead 
(for the simple reason that this wouldn't represent running code at 
Xythos and SAP anymore).

Best regards, Julian

---

From: Yves Lafon <[email-masked]>
Date: Thu, 23 Sep 2004 21:48:30 +0200 (MEST)

On Thu, 23 Sep 2004, Julian Reschke wrote:

> IMHO we should thus eliminate the SOAP11-based example from the spec (see 
> I'm not so convinced that we should add a SOAP12 based example instead (for 
> the simple reason that this wouldn't represent running code at Xythos and SAP 
> anymore).

Agreed. Having only one example would lead to the assumption that it is 
the only way to go, having all examples is close to impossible.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 25 Sep 2004 11:48:26 +0200

OK,

thanks for the feedback that was sent within the last two weeks. I think 
I have captured all major issues and resolved them, either by removing 
questionable stuff (such as the array example using SOAP 1.1 
marshalling) or adding clarifications.

The current edits are published at 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-latest.html>. 
  I plan to submit this as a new Internet Draft early next week and then 
ask the RFC Editor for publication as "Experimental" RFC. Note that if 
it gets accepted, there will be another last-call period during which 
issues can be raised.

Best regards, Julian