I don't think standards should say (normatively) how senders should
figure out what to send; standards should say what the message _means_.

If you want to give implementation advice for how a sender might
create a valid message, it should be clearly labelled as just
information and not part of the normative spec.

    Handling of URLs containing inappropriate characters

     Some URLs may contain characters that are inappropriate
     for an RFC 822 header, either because the URL itself
     has an incorrect syntax or the URL syntax has changed to
     allow characters not allowed in mail headers. To include
     such a URL in a mail header, an implementation might:

     (a) Transform the URL, e.g., using the encoding method of
     [RFC URL SYNTAX], in both the HTML text and the mail header.
     This transformation must be done carefully, since
     the %xx hex encoding cannot be applied directly to the
     URL but rather must be applied to its component parts.

     Note that transforming HTML text has several difficulties,
     including the fact that message integrity checks are
     no longer valid.

     (b) Use the encoding method for message headers described
     in RFC 2047, using either a charset value of "US-ASCII",
     or, if the URL contains octets outside of the 7-bit range,
     "UNKNOWN-8BIT" [RFC 1428], or "UTF8", as appropriate.
     Note that for MHTML processing (URL matching), the charset
     value is irrelevant, but it may be relevant for other operations
     on the URL.

     Note that recipients of messages must reverse the encoding
     used in method (b) before matching URLs.

Larry
--
http://www.parc.xerox.com/masinter