The Problem:
============

Subversion is supposed to fully support colons in property names (I
mean besides our own "svn:" properties).  Such properties are
desirable, because they are the most intuitive subspacing mechanism
within the Subversion property namespace.  For example, "svk:" and
"cvs2svn:" are already in use.

Subversion's support for such properties is not stable, however.  As
described in issue #1971, a strict XML parser would not permit them to
be transmitted as we currently transmit them.  We're getting along
right now because Subversion tends to be compiled with a loose XML
parser.  But we're not compatible with generic DAV clients that use a
stricter parser.  If someone sets properties with colons in their
names, a DAV client could error out on receiving them.

There was a related fix in r10190 (issue #1807), but as noted in that
issue, it doesn't really solve this problem.  It was just a workaround
to make our revprops work with svn clients the same way regular props
currently do.

Secondarily, there is a problem that other characters cannot be
transported over ra_dav, because they are not valid in XML element
names.  For example, "/" is unusable right now, with both Subversion
over DAV and with generic DAV clients.

Some General Points:
====================

In theory, Subversion's property namespace should not be restricted by
XML rules.  XML is merely an artifact of one of our transport layers,
and it is up to Subversion to get its data across using that protocol
by whatever means necessary.  However, we have a slightly conflicting
goal: we'd also like generic DAV clients to get reasonable responses
from our servers.

In the solution below, I reconcile these two goals as best I can, but
the reconciliation is not perfect.

Proposed Solution:
==================

This is the simple overview of the solution -- compatibility stages
will be discussed afterwards.

Anything in the "svn:" namespace is safe for us to use, since we have
already implemented that namespace -- all Subversion clients and
servers know about it, and Subversion owns it.  Therefore, we create a
new property prefix:

   "svn:quoted-"

When a client or server receives a property like this:

   "svn:quoted-XXXXXXXXXX"

it interprets the property name as being just the "XXXXXXXXXX"
portion,  but decoded according to these rules: 

   1. Letters, numbers, periods, and hyphens represent themselves.

   2. All other characters are decoded using underscore as a
      delimiter, like this: "_NNN_", where NNN is the decimal
      representation of the character's Unicode value.

      (Note that the decoder could easily be extended to decode
      hexadecimal numbers, or even words, e.g., "_colon_".  Since it
      starts out allowing only numbers, we can use letters as a wedge
      to expand the representation space.  This may have UI
      implications for people using generic DAV clients, more on that
      later.)

   3. For now, *only* colon ("_58_") is decoded this way.  Any other
      special character causes an error in decoding.  But, we also
      error when any other character attempts to enter the property
      namespace, i.e., at propset time or as early as we can detect
      it.  Which brings us to Point 4:

   4. We publish the characters allowed in property names as of this
      fix.  The set is letters, numbers, period, hyphen, underscore,
      and colon.  That's it.

Remember, all decoding happens in the "svn:" namespace, so we're not
affecting any existing properties, unless someone was setting a
property in "svn:" when they shouldn't have been :-).

[1] From http://www.developer.com/tech/article.php/797861 :

    "Every element has a name made up of one or more characters. This
     is the name included in the element's start and end tags. Element
     names begin with a letter such as y or A or an underscore _.
     Subsequent characters in the name may include letters, digits,
     underscores, hyphens, and periods. They cannot include other
     punctuation marks such as %, ^, or &. They cannot include white
     space. (The underscore often substitutes for white space.) Both
     lower- and uppercase letters may be used in XML names. In this
     book, I mostly follow the convention of making my names
     uppercase, mainly because this makes them stand out better in the
     text. However, when I'm using a tag set that was developed by
     other people it is necessary to adopt their case convention. For
     example, the following are legal XML start tags with legal XML
     names:

       <HELP>
       <Book>
       <volume>
       <heading1>
       <section.paragraph>
       <Mary_Smith>
       <_8ball>

     Note: Colons are also technically legal in tag names. However,
     these are reserved for use with namespaces. Namespaces allow you
     to mix and match XML applications that may use the same tag
     names. Chapter 13 introduces namespaces. Until then, you should
     not use colons in your tag names.

     The following are not legal start tags because they don't contain
     legal XML names:

       <Book%7>
       <volume control>
       <3heading>
       <Mary Smith>
       <.employee.salary>

     Note: The rules for element names actually apply to names of many
     other things as well. The same rules are used for attribute
     names, ID attribute values, entity names, and a number of other
     constructs you'll encounter over the next several chapters."