Text 739, 132 rader
Skriven 2007-03-23 00:10:24 av Mithgol the Webmaster (2:5063/88)
    Kommentar till text 735 av Scott Little (3:712/848)
Ärende: Fidonet URL syntax
==========================
And about 22:12 22 Mar 07 it was written from Scott Little to Mithgol the
Webmaster:

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

 SL> It's still not a hierarchical resource, nor does that form make any
 SL> logical sense.  It's also a security risk that would make Microsoft proud
 SL> ;)

 SL> At least, for an echomail area.  It's fine for a file echo.

Define 'hierarchical resource' then. Because I just can't get it. Why on Earth
area://FTSC_Public/example.zip/subdir/file.ext is not hierarchical resource and
fecho://Some_File_Echo/example.zip/subdir/file.ext is hierarchical?

The security risk is addressed, so I still may hope it's safer than Microsoft:

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

      7.2.1.3. Optional parameter "from"
      -+--------------------------------

        The "from" optional parameter is used to define the Fidonet
        netmail address of an individual or service that designated
        message(s) originate from.

        The value of the "from" parameter uses standard Fidonet
        addressing notation, <zone>:<net>/<node>.<point>@<domain>
        (see FSP-1004 for details).

        If "from" is present in the <optional-part> of an area URL,
        then

           area://<areatag>?<optional-part>

        no longer designates the whole message base of the given area,
        but only the message(s) posted to that area by the specified
        node or point. The field of that messages can be narrowed even
        further if some other message-identifying parameters are used
        in the same URL.


[ /_*... skipped ...*_/ ]

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

[ /_*... skipped ...*_/ ]

          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.

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

 SL> The node part would likely be rare or normally ignored.  Possibly only
 SL> added dynamically by the local reader to to disambiguate between
 SL> multiple feeds; maybe applied at the origin and used in conjunction with
 SL> an automatic subscription mechanism (areafix, FSP-1016, etc) or some
 SL> other foreign-access protocol to handles cases when the area isn't
 SL> available.

It makes sense only when the echomail area is areafixed, and specially for this
I've created 'areafix:' URL scheme and the 'uplink=...' optional parameter:

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

    6.2.1. Optional parameter "uplink"
    -+--------------------------------

      Fidonet software usually has its own means to determine which
      uplink has the requested echomail area and would receive the
      areafixing netmail letter. However, if the system has several
      uplink nodes able to distribute the given echo, the "uplink"
      optional parameter MAY be used to recommend the preferred uplink
      node (provided that the author of the hyperlink has some reasons
      to recommend one uplink above all others).

      The "uplink" parameter takes a value that uses standard Fidonet
      addressing notation, <zone>:<net>/<node>.<point>@<domain>

      However, some parts of address ("<zone>:", "@<domain>"
      and/or ".<point>") MAY be omitted (see FSP-1004 for details).
      The point number is often omitted in the "uplink" parameter
      values, because Fidonet points almost never become uplinks.

      Examples:

         ...get the echo about embedded systems directly from its
         moderator, use areafix:Ru.Embedded?uplink=2:5029/32

         ...those Titanic echoes never were on the backbone, use
         areafix:Titanic.PVT?uplink=2:5020/830 and subscribe to one
         from the primary hub...

      The "uplink" parameter has no default value; the default
      behaviour of the subscription management software has to be
      determined by the network topology of uplink-downlink relations.

      Generally the software has nothing to do if an areafix URL
      designates an already subscribed echomail area. However, if
      the "uplink" optional parameter is present, the software MAY
      choose to cancel echomail subscription order formerly sent to
      the current uplink for the given echomail area, and then arrange
      for supply of the same echomail area from the preferred uplink
      provided by the value of the "uplink" parameter. (The user
      SHOULD be asked first whether such an action is appropriate.)

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

 SL> fidonet#ftsc_public is the network and area (I hate the @domain syntax,
 SL> but that's just me).

I've never seen echomail area names prefixed and/or suffixed by domain names,
even if they are gated between different FTN domains. Hence the question below.

 SL> There is no point implementing domains anywhere at all if you don't
 SL> apply them everywhere.

Do you mean that different echomail/fileechomail areas in different FTN domains
may have same names, so it should be possible to append domain names to area
names to prevent ambiguity?


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

... 4. Shooting is *not* too good for my enemies.
--- Come with me in the twilight of a summer night for a while...  .hack//SIGN
 * Origin: I have a strange feeling, as if I already had a deja vu (2:5063/88)