Yes and this is my argument. Its only "SHOULD" and not "MUST". This means by spec:
This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course."
By the way a funny part of this spec: It does not explain how to upload or create files through PUT. It even not describes if it is allowed to use the Overwrite header. This is only described for COPY and MOVE operations. ^^
And there is even a contradiction in the spec. While creationdate should be handled as follows:
This property value SHOULD be kept during a
MOVE operation, but is normally re-initialized when a resource is
created with a COPY.
The getlastmodified is described as follows:
The last-modified date on a resource SHOULD only
reflect changes in the body (the GET responses) of the resource.
A change in a property only SHOULD NOT cause the last-modified
date to change
This means if the WebDAV servers would interpret this strict, they would not be allowed to change the getlastmodified date on COPY operations, which would cause that the last modified date is older than the creation date ^^
And as creationdate is not protected it is possible to upload a file and set the creationdate through PROPPATCH to a newer date than getlastmodified. Does not make sense either.
P.S I contacted the IETF and requested them to add an update to the spec so it becomes more clear and reflects the users needs. I mean it can't be the target of the spec that some WebDAV softwares add special (and interoperable) variables (X-OC-MTime, srt_modifiedtime, etc) to bypass a limitation that nobody wants. Let's see if we achieve something through this way 