Rationale
Be able to access the properties of the reference
- DAV:resourcetype, DAV:reftype, etc.
- creator, create date, comment
Be able to modify properties of the reference that were set via headers at creation time
- DAV:hidetarget, DAV:refintegrity
For versioning
- Specifying different default revisions when accessed from different collections?
Notes:
If you can’t do a PROPPATCH on the properties of a direct reference, it’s not a big deal to recreate the reference -- another MKREF with the same request-URI replaces the reference, with whatever header values are desired.
Versioning example: a release configuration, a bug fix configuration that uses tip revisions of the bug fix branch of each resource, a new functionality configuration that uses tip revisions of the new functionality branch of each resource
The versioning draft had proposed a new type of reference “semi-direct” that exhibited this behavior -- by default it was a direct reference, but a header could be used on any request to make it behave like a redirect reference. Rather than have 3 types of references, it seemed preferable to modify direct references to behave as the versioning spec needed.