Text 658, 159 rader
Skriven 2007-02-10 13:53:15 av Mithgol the Webmaster (2:5063/88)
Ärende: [3/11] FidoURL.txt
==========================
* written in FTSC_PUBLIC
* also sent to CU.TALK
* also sent to GANJANET.LOCAL
* also sent to RU.FIDO.WWW
* also sent to RU.FIDONET.TODAY
* also sent to RU.FTN.DEVELOP
* also sent to SU.FIDOTECH
* also sent to TITANIC.BEST

textsection 3 of 11 of file FidoURL.txt
textbegin.section

      5.2.2.2. Unsafe characters
      -+------------------------

        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 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.

        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.

      5.2.2.3. Reserved characters
      -+--------------------------

        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. And vice versa.

        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 "?" appears 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 "=" appears 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 "&" appears 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.

        5.2.2.4.1. Specificity note
        -+-------------------------

          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
        -+-------------------------------

          The same shortening already happens in Internet. Open
          http://www.google.ru/search?q=Fidonet+URL URL, and you'll
          get the Google search for "Fidonet URL" (not "Fidonet+URL");
          http://www.google.ru/search?hl=ru&q=Fidonet%2BURL is needed
          if you're looking for "Fidonet+URL".

          This practice is not documented in RFC 1738. It is, however,
          documented in RFC 1630.

textend.section


With best Fidonet 2.0 regards,
Mithgol the Webmaster.                 [Real nodelisted name: Sergey Sokoloff]

... i have no capslock and i must scream                (Bugzilla Quip System)
--- Orcs are near, All! My Golded 1.1.5-b20060515 is gleaming!..
 * Origin: Be careful, the paranoid ones are always wathing you!.. (2:5063/88)