1738 is being updated. In the real world, people are using all kinds of
characters as "reserved", and the truth is you're really taking a risk
if you encode something on your own that wasn't encoded.
In the interest of safety, I think you're better off *not* recommending
using %xx encoding as a way of making illegal URLs safer. But this
is still just implementation advice.
> I assume this means that any other character, if occuring in the value
> submitted to a mailer for a Content-Location, must be encoded either
> using the RFC 1738 encoding method or the RFC 2047 encoding method.
It is misleading to talk about "encoding a character using the
RFC 1738 encoding method", because the RFC 1738 encoding method
is not a character-by-character encoding. That is, you have to
look at the whole URL and the scheme and the context of the
character. RFC 2047 encoding, on the other hand, can be decided
character-by-character, because it is at a different layer.