"Bernd Khalil" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Garth Wallace wrote:
>
> > So, technically it should be delimiting the URL with "<URL:" and ">"
>
> As I said, there's a bug :-)
> Just not the bug I meant..
>
> Some Mailers (esp. some Webmailservices) just don't seem to know about
> this RFC and happily add the > at the end of the URL.
That note was from the appendix of the RFC, and is more of
a suggestion than a requirement. But if they're adding the
">" to the actual URL, they're violating section 2.2 of the RFC,
which states that "<" and ">" are among the "unsafe"
characters that must not appear unescaped in a URL:
> Characters can be unsafe for a number of reasons.
> The space character is unsafe because significant
> spaces may disappear and insignificant spaces may
> be introduced when URLs are transcribed or typeset
> or subjected to the treatment of word-processing
> programs. The characters "<" and ">" are unsafe
> because they are used as the delimiters around URLs
> in free text; the quote mark (""") is used to delimit
> URLs in some systems. The character "#" is unsafe
> and should always be encoded because it is used in
> World Wide Web and in other systems to delimit a
> URL from a fragment/anchor identifier that might follow
> it. The character "%" is unsafe because it is used for
> encodings of other characters. Other characters are
> unsafe because gateways and other transport agents
> are known to sometimes modify such characters. These
> characters are "{", "}", "|", "\", "^", "~", "[", "]", and "`".
>
> All unsafe characters must always be encoded within a
> URL. For example, the character "#" must be encoded
> within URLs even in systems that do not normally deal
> with fragment or anchor identifiers, so that if the URL is
> copied into another system that does use them, it will
> not be necessary to change the URL encoding.
