Text 733, 166 rader
Skriven 2007-03-21 20:43:06 av Mithgol the Webmaster (2:5063/88)
    Kommentar till text 731 av Scott Little (3:712/848)
Ärende: Fidonet URL syntax
==========================
And about 13:22 21 Mar 07 it was written from Scott Little to Mithgol the
Webmaster:

 MtW>> area://FTSC_Public/?msgid=2:5063/88+45cda489

 SL> Is the // valid URI syntax when there's no hostname (or node number)?

======= Start of the quote from FidoURL.txt =======

    5.1.2. Delimiter guidelines
    -+-------------------------

      In current Internet practice they distinguish between delimiters
      ":" and "://". The delimiter "://" is often used after scheme
      names that designate objects and resources ("http://", "ftp://",
      "gopher://", "nntp://", "ed2k://", "file://", etc.).
      The delimiter ":" is often used after scheme names that
      designate actions (e.g. "mailto:", "skype:").

      The same difference exists between Fidonet resources (objects)
      and actions. That's why, though these delimiters MUST always
      be interpreted as equivalent, it is still RECOMMENDED that ":"
      SHOULD be used after schemes that designate actions ("netmail:",
      "echomail:", "areafix:") and "://" SHOULD be used after schemes
      that designate resources ("area://", "freq://", "fecho://",
      "faqserv://", etc.).

======= End of the quote from FidoURL.txt =======

 SL> And is the final / before the ? necessary?

======= Start of the quote from FidoURL.txt =======

    7.1.1. The leading slash and the trailing slash
    -+---------------------------------------------

      The leading slash of <object-path> is a mere delimiter between
      <basic-required-part> and <object-path>. If the <object-path>
      part of a URL is empty, its leading slash MUST be ignored by the
      program interpreting the URL. If the <object-path> part of a URL
      is empty, its leading slash MAY be omitted by the author of that
      URL, thus the following URLs are equivalent:

         <scheme>://<basic-required-part>/?<optional-part>

         <scheme>://<basic-required-part>?<optional-part>

      However, the trailing slash of <object-path> has its own value,
      makes some real difference. For example, "example.zip" means
      the archive itself (a file that may be saved or sent, etc.),
      and "example.zip/" means the root directory of that archive
      (a container that may be browsed, updated, etc.)

      The trailing slash of <object-path> MUST NOT be ignored.

======= End of the quote from FidoURL.txt =======

 SL> There doesn't seem to be any logical need for an object path, it's not a
 SL> hierarchical resource below the echo level.

What makes you think that it is not a hierarchical resource below the echo
level? It is.

area://FTSC_Public/example.zip/subdir/file.ext is a file.ext in a subdir inside
the latest example.zip posted in FTSC_Public.

======= Start of the quote from FidoURL.txt =======

      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.

======= End of the quote from FidoURL.txt =======

 SL> Also, no FTN domain support?

There is FTN domain support in the relevant schemes ('netmail:', 'faqserv://',
'freq://') and optional parameters for some other schemes (parameter 'uplink='
for 'areafix:' scheme, parameter 'from=' for 'area://' scheme). Each of those
includes '@<domain>' value.

 SL> eg. area:[//node/]fidonet#ftsc_public?msgid=whatever

What would such an URL mean?


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

... 226. I will have a staff of competent detectives handy.
--- Something is rotten in the state of Denmark.  (Shakespeare, Hamlet, I, IV)
 * Origin: I have a strange feeling, as if I already had a deja vu (2:5063/88)