XML in LOCK <owner> tag should be self-contained

Ladies and Gentleman,
 
At the WebDAV interop fest, we saw that some servers weren't doing the
right thing when clients send them <owner> tags on a LOCK request.  When
doing a LOCK a client can put in XML in the owner tag, and this XML
often times has namespaces prefixes in it.  So we have something like...

 
LOCK
 
<xml>
 <lockinfo xmlns:MyNS="MyNameSpace">
  [...]
   <owner>
      <MyNS:MyTag>...</MyNS:MyTag>
   </owner>
  [...]
 
When the server returns this owner tag on a lockdiscovery, it has to
also return the definition of the MyNS namespace in the <owner> tags or
clients will choke on not recognizing MyNS prefix.  Having to keep track
of prefix mappings when parsing the LOCK body is an added piece of
complexity that servers don't really need.  It would be better if we
could require (or more likely strongly encourage) clients to make any
XML inside the <owner> tag work standalone, i.e. forcing them to define
any namespaces they use there.  They would send something like this on a
LOCK.
 
 <owner>
   <MyNS:MyTag xmlns:MyNS="MyNameSpace">...</MyNS:MyTag>
 </owner>
 
This way the server could just keep a copy of the data between the
<owner> tags without any extra processing.
 
Steps to increase interop:
1. Server implementers should be aware of this and code accordingly.  A
number of servers at the WebDAV interop fest only copied the data
between <owner> tags, not doing the extra name space processing.
 
2. We should say something to the effect that clients SHOULD send
self-contained XML data with all the namespaces prefixes they used
defined between the <owner> tags to workaround servers that don't handle
this correctly.
 
3. We should practice what we preach in the spec.  For instance in RFC
2518 example 8.10.8, we have <D:href> inside an <owner> tag that could
cause certain servers to have the problem described here.
 
4. We should keep general scenario in mind when writing specs in the
future that involve one party saving XML with namespace tags in it from
another party, possibly saying that the client MUST send self-contained
XML.
 
Alas, since RFC 2518 is a done-deal there's not much we can do on #3.
Issues #1 and #2 are mostly education issues for WebDAV client and
server implementers.  The main reason I'm writing this is for #4, so
that we can be aware of this scenario in the future.
 
Thank you,
John Spaith
Software Design Engineer
Windows CE
Microsoft