Text 664, 145 rader
Skriven 2007-02-10 13:53:47 av Mithgol the Webmaster (2:5063/88)
Ärende: [9/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 9 of 11 of file FidoURL.txt
textbegin.section

      7.2.1.5. Future message-identifying optional parameters
      -+-----------------------------------------------------

        Future versions of this document MAY introduce additional
        message-identifying optional parameters. For example,
        hypertext messages could be identified by meta information
        in their HTML headers. Messages could also be searched for,
        using different methods than the regular expressions.

        However, it is safe to discard unknown optional parameters of
        area URLs, though programs interpreting Fidonet URLs SHOULD
        probably warn their users if an unknown parameter is discarded
        and when such a warning is appropriate.

    7.2.2. Encoded objects within echomail messages
    -+---------------------------------------------

      It is possible for a Fidonet echomail message to contain one
      or more binary objects, encoded to appear in text-alike lines
      of characters. Possible methods of encoding include UUE, MIME
      (RFC 2045-2049), "data:" (RFC 2397), etc.

      An echomail message MAY contain several objects, which MAY be
      encoded in different manner. On the other hand, an encoded
      object MAY span several Fidonet messages: for example, each
      of those Fidonet messages MAY bear a section or two of UUE,
      and the whole bunch of sections is needed to decode a file.

      7.2.2.1. Names of encoded objects
      -+-------------------------------

        This subsection is informative.

        Most of encoded objects within echomail messages are named.

        The name of a UUE-encoded object usually appears within
        "begin" and/or "section" line of UUE codes.

        The name of a MIME-encoded object usually appears within
        either the "Content-type" header (in its "name" section) or in
        the "Content-disposition" header (in its "filename" section).

        RFC 2397 "data:" does not specify an object name; however, the
        hypertext object populated by that data MAY be named itself,
        via "id" or "name" attribute of its tag.

      7.2.2.2. How the designated object is determined
      -+----------------------------------------------

        If the <object-path> of an area URL is not empty, then the URL
        designates either an encoded object as a whole or some inner
        part of such an object. Abstracting from this inner details,
        the whole object is called "the designated object" in this
        subsection.

        If the <object-path> of an area URL is not empty, then its
        <object-name> MUST also be non-empty by definition, and it
        specifies the name of the designated object.

        However, the echomail message base (of the area given in
        <areatag> section of the URL) MAY contain more than one object
        of the same name. It is therefore important to define what
        object is considered "the latest".

        Among those messages that contain objects of the same name
        (or just parts of those objects, e.g. UUE sections), there is
        the latest message. If that latest message contains only one
        of those objects (partly or as a whole), then that object is
        the latest one. If that latest message contains parts and/or
        whole encoded images of more than one object of the same name,
        then the object whose complete encoding or just the last
        section of encoding (last among its sections contained in this
        latest message) appears nearest to the bottom of that message
        (farthest from top) is the latest object.

        How "the latest message" itself is defined is beyond the scope
        of this document. It MAY be the latest received, it MAY be
        the one with the most up-to-date creation date, etc.

        The designated object is always determined as the latest one
        among those of the name given in <object-name>.

        Fidonet browser software MUST ignore objects which have such
        encodings that browser can not decode; the designated object
        MUST always be the latest of only those ones of the given name
        that are able to be decoded from the echomail message base.

        If one or several message-identifying optional parameters are
        present in the optional part of the URL, then the designated
        object is the latest one among only those decodable objects
        of the same name whose complete encoding (or just a section
        of encoding) appears in one of the messages identified by the
        optional parameter(s).

        7.2.2.2.1. Possible applications
        -+------------------------------

          This subsection is informative.

          As the <object-name> always designates the latest object of
          the same name, it is possible for "area://" URL to designate
          an object that is updated by means of Fidonet echomail area
          transport. Such objects MAY update daily (as in a weather
          forecast), weekly (as in a nodelist statistical report),
          etc. That's how Fidonet may easily serve dynamic up-to-date
          content. And if some URL is intended to point to an older
          static version instead of the up-to-date dynamic one, then
          an optional message-identifying parameter (if matches just
          a single message) is always able to ensure that.

          If several nodes have write access to the same echo area,
          and it is not possible to rely just on the latest object of
          the same name, then "from" parameter can be used to ensure
          that the trusted origin is chosen.

          As any Fidonet browser software MUST ignore objects which
          have such encodings that browser can not decode, it is made
          possible to include several alternative versions of the same
          object (encoded differently), even in the same one echomail
          letter, provided that the names of published object versions
          are all the same. The browser will happily pick the encoding
          it understands. For example, someone may post both UUE (for
          GoldEd+) and RFC 2397 (for Gecko) versions of the same icon.

textend.section


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

... 105. I will design all doomsday machines myself.
--- Orcs are near, All! My Golded 1.1.5-b20060515 is gleaming!..
 * Origin: And the Soviets ÄÄ waist-deep in the snow ÄÄ marched in (2:5063/88)