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 octet 20 hexadecimal MUST always be encoded.
The characters "<" and ">" are unsafe because they are used as the delimiters around tags in HTML hypertext and XML data. The octets 3C and 3E hexadecimal MUST always be encoded.
The quote mark (""") is used to delimit URLs in some systems, including valid XHTML and XML. The octet 22 hexadecimal MUST always be encoded.
The character "#" is unsafe because it is used in World Wide Web and in other systems to delimit a URL from a fragment or anchor identifier that might follow it. The octet 23 hexadecimal MUST always be encoded.
The character "%" is unsafe because it is used for encodings of other characters. The octet 25 hexadecimal MUST always be encoded.
The character sequence of triple minus ("-" repeated thrice) has a special meaning in Fidonet and can accidentally start a tearline in some cases (e.g. when a line is wrapped). At least one of the three corresponding octets (2D 2D 2D hexadecimal) MUST be encoded if they follow each other in a sequence.
The word "Origin" has a special meaning in Fidonet and can accidentally start an origin line in some cases (e.g. when preceded with an asterisk and a white space). At least one of the six corresponding octets (4F 72 69 67 69 6E hexadecimal) MUST be encoded if they follow each other in a sequence.
Other characters were declared unsafe in RFC 1738 because some gateways and other transport agents were known to sometimes modify such characters. These characters are "{", "}", "|", "\", "^", "~", "[", "]", and "`". The corresponding octets (7B 7D 7C 5C 5E 7E 5B 5D 60 hexadecimal) MUST always be encoded for the sake of Internet compatibility.
All unsafe characters MUST always be encoded within a URL. For example, the character "#" MUST be encoded within URLs even in software programs that do not normally deal with fragment or anchor identifiers, so that if the URL is copied into another program that does use them, it will not be necessary to change the URL encoding.
Many URL schemes reserve certain characters for a special meaning: appearance of that characters in the scheme-specific part of the URL (in <scheme-specific-part> after scheme name) has a designated semantics.
Usually a URL has the same interpretation when an octet is represented by a character and when it is encoded. However, this is not true for reserved characters: encoding a character that is reserved for a particular scheme may cause harm to the meaning of a URL, if the character is used according to its designated semantics.
The character "?" is used as the delimiter between required and optional parts of the URL. The delimiter itself MUST NOT be encoded. If the character "?" appear in any other part of a URL, it MUST be encoded, so it won't be confused with the delimiter.
The character "=" is used as the delimiter between parameter names and parameter values. The delimiters themselves MUST NOT be encoded. If the character "=" appear in any other part of a URL, it MUST be encoded, so it won't be confused with any of the delimiters.
The character "&" is used as the delimiter between "parameter=value" pairs. The delimiters themselves MUST NOT be encoded. If the character "&" appear in any other part of a URL, it MUST be encoded, so it won't be confused with any of the delimiters.
The character "/" is scheme-specific:
*) In some schemes ("netmail:", for example) the character "/" has its own (literal) meaning, as it is widely used in standard Fidonet addressing notation <zone>:<net>/<node>.<point> (see FSP-1004 for details).
*) In some other schemes the character "/" is reserved to be used in the file path (<directory>/<directory>/...<directory>/<filename>), and its corresponding octet (2F hexadecimal) MUST be encoded if it does not delimit parts of the path. See the scheme-specific details below (in scheme sections).
5.2.2.4. The plus ("+") and the encoding of white spaces -+------------------------------------------------------
White spaces (octets 20 hexadecimal) are the most common unsafe characters in Fidonet, and so they play a significant role in some scheme-specific parts of the URL: they appear in MSGID kludges, they are used as delimiters between words in lines of text, etc.
To enhance human readability of Fidonet URLs, and to make them shorter, a new shorter synonym for "%20" hexadecimal triplet is available. It is the plus sign ("+").
Programs interpreting scheme-specific part of Fidonet URL MUST treat the character plus ("+") there as equivalent to the white space hexadecimal triplet ("%20").
Because of that, the plus character itself is reserved, and its own corresponding octet (2B hexadecimal) MUST be encoded if it appears in scheme-specific part of Fidonet URL.
The rule of equivalence between "+" and "%20" does not apply outside of the scheme-specific part of URL; the plus sign has no special meaning in scheme name, since white spaces are not allowed in scheme names.
5.2.2.4.2. Internet practice note -+-------------------------------
However, this practice is not documented in RFC 1738.
5.3. Parsing the scheme-specific part of URL -+------------------------------------------
As it was stated above, Fidonet URLs are written as follows:
<scheme><scheme-delimiter><scheme-specific-part>
where <scheme-delimiter> is either ":" or "://".
Пока!
--- иногда пронзительно свистит на горе рак и свершается страшное (c) Marїnais * Origin: А обычно все те, кто влюблялся в Шинтаpо, кончали плохо (2:5063/88)
