Draft: draft-reschke-webdav-property-datatypes-09.txt Reviewer: Spencer Dawkins [spencer@mcsr-labs.org] Date: Sunday 6/5/2005 11:10 PM CST Summary: Ready as experimental; some comments for consideration Review Comments: Review Criteria for "Individual submission via RFC Editor": Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Summary: Since the ID Tracker comments already say "not an end run", I focused more on the second question. In Section 7, "Compatibility Considerations", the following two considerations appear: Clients not aware of datatype handling should not supply the "xsi: type" attribute on property elements (after all, this attribute belongs to the XML Schema-Instance namespace which has been defined for exactly this purpose). Old clients should also ignore additional attributes on property elements returned by PROPFIND (and similar methods), although the WebDAV specification only defines this behaviour for unknown elements (and is silent about unknown attributes). 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. I would feel quite a bit better if the "should" and "will never" actually referenced normative text in some specification somewhere - the document feels like it's relying on common implementation behaviors without these references, and that would be quite a bit more likely to trip over compatibility issues. I also wondered about "should" vs. "SHOULD", but decided that "requirements" for clients and servers that aren't aware of this capability are probably problematic anyway :-) Other than this - no objection for Experimental.