URI templates: commas

Commas don't have a particularly special role in URIs. They are just 1 of 11 characters in the <reserved> set
that are not used as delimiters of the generic URI components.

URI templates (draft-gregorio-uritemplate-06), however, gives commas special meaning. They are the
only <reserved> character that can appear when expanding {var}.

I'm not aware of any reason why URI templates should single out commas for this special treatment.
It simultaneously encourages servers to use commas as separators, while also causing problems for some
servers that have (quite reasonably) chosen to use commas as separators.

Consider a bank server that accepts payment transactions such as:
  https://example.com/pay/{amount},{to},{from},{comment}

The template processor might be a trusted front-end inserting the "from" variable value based on the
authenticated user, but accepting "amount" and "to" values from the user.
This should be able to be safe. But it isn't with the current draft spec.
If the user provides a "to" value that is actually a list [ "me", "victim" ] then the expansion puts the second
"to" value where the bank was expecting the "from" account -- and a fraudulent transaction occurs.

Perhaps the bank could switch to using a different delimiter -- but that rather defeats one of the purposes
of URI templates of being able to match the server's choice of URI structure.

If the server can provide extra information *outside of the template* about which variables are
mandatory, which can or cannot be lists, and which can or cannot be composite values, then it may be able to
avoid these problems. But templates should be usable without those limitations.

Almost any URI structure using commas as delimiters can face problems with even the most basic level 1
templates since the server cannot distinguish a comma from expanding a user-provided value from a comma
that was a literal expression delimiter in the template.