geos_one/archie
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Intial commit

Browse Source
This commit is contained in:
Mario Fetka
2024-05-27 16:13:40 +02:00
parent f8dc12b10a
commit d71d446104
2495 changed files with 539746 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
prospero/doc/working-notes/FILES Normal file
View File

@@ -0,0 +1,9 @@
FILES
README
collation-order.txt
gopher-hsonames.txt
new-acl-rights
object-interpretation.txt
pdap.txt
pfs-udp-ports.txt
wais-link-format.txt

4
prospero/doc/working-notes/README Normal file
View File

@@ -0,0 +1,4 @@
This directory is for Prospero documentation that is not yet formally
written up in the manuals but which should be distributed anyway rather
than held back for the great day when we have all the manuals in final
shape :)

141
prospero/doc/working-notes/collation-order.txt Normal file
View File

@@ -0,0 +1,141 @@
Revised again: 6/18/93, 11:20 am
COLLATION-ORDER is a new LINK attribute of type SEQUENCE in the
ATTRIBUTE namespace.
In this document, where I specify sequences, spaces separate tokens
within a sequence, just as they do in the Prospero protocol.
. NUMERIC
For the GOPHER implementation, the value will always be either
NUMERIC ...
or
LAST NUMERIC ...
.. NUMERIC <1st-number> <2nd-number> <3rd-number> ... <nth-number>
Multiple instances of these are ordered with lower numbers coming
before higher ones. One sorts on the <1st-number> field. If the
<1st-number> fields of two vlinks are equal, then the <2nd-number>
field is exampined, and so on. All items with a COLLATION-ORDER
attribute with NUMERIC as the 1st field will come before other menu
items. The <number> fields are arbitrary integers; clients are not
required to properly handle integers that cannot be represented in the
customary 32 bit 2s-complement representation.
If a number not present in a field, this is considered to come before
all other numbers. Therefore,
NUMERIC 1
comes before
NUMERIC 1 3
Another way of saying this is that if one value of the COLLATION-ORDER
is a proper prefix of another, the shorter item comes first.
If inappropriate values are present in a numeric
field (for example, the ASCII string 'foo'), then the ordering is
undefined. Thus,
NUMERIC 1
NUMERIC foo
is just as valid an ordering as
NUMERIC foo
NUMERIC 1
.. LAST NUMERIC <1st-number> <2nd-number> <3rd-number> ... <nth-number>
All items with a COLLATION-ORDER attribute of this form come after all
other items in the menu/directory. These are ordered just as with the
NUMERIC collation-order attribute; just as with the NUMERIC
collation-order attribute, smaller numbers go closer toward the front
of the menu and larger towards the end.
. ASCII
ASCII <major-key-string> <minor-key-string>
<even-more-minor-key-string> ...
LAST ASCII <major-key-string> <minor-key-string>
<even-more-minor-key-string> ...
This works like NUMERIC, but 'preceeding in ASCII collating sequence
comes earlier' replaces 'lower numbers coming before higher ones' in
the above discussion.
. Conflicting Values for COLLATION-ORDER ATTRIBUTE:
If two items have the same value for the COLLATION-ORDER attribute,
then they will be sorted normally, in accordance with the usual
directory sorting procedure. For now, this means sorting them in
increasing order by the ASCII values of their NAME-COMPONENT fields.
Eventually, when the DIRECTORY-ORDERING attribute is implemented, this will
change. (The DIRECTORY-ORDERING attribute and its interactions with
COLLATION-ORDER are documented separately, and we do not need to
concern ourselves with it for now.) If two items have equal sort
keys, order should be preserved.
. ASCII/NUMERIC precedence
If a directory contains some links with NUMERIC COLLATION-ORDER and
others with ASCII collation-order defined, then the NUMERIC comes
before the ASCII. This is an arbitrary choice. If a directory
contains some links with LAST NUMERIC and others with LAST ASCII, then
LAST NUMERIC precedes LAST ASCII.
<A nice move being made in gopherspace is to support -ve numbers, ordered
last, after elements with no ordering specified - Mitra>
. Marginal cases
A COLLATION-ORDER attribute with a zero-length sequence as its value
is treated as if the COLLATION-ORDER were not defined at all and is
sorted appropriately. It follows from this that simply "LAST" is an
acceptable order as well. Any items with 'LAST' defined as the
collation order go after items with LAST NUMERIC or LAST ASCII.
Note that simply "LAST" fits the model since it goes at the end, but
is then sorted compared to others as if no collation-order was
specified.
LAST without arguments comes after all other LAST's. If there are
multiple LAST's without arguments, they are considered unordered, and
order between them is based on other criteria (eventually directorey
ordering if available, and if not, the order should be preserved (i.e.
the order they were in before sorting.
. Implementation notes for Kwynn
The COLLATION-ORDER attribute will be examined within the m_get_menu()
function. m_get_menu will call get_vdir() with the GVD_NOSORT flag.
It will then call a special function (which Kwynn will write) to sort
the VLINKs returned by get_vdir(). Kwynn should look at the source to
the vl_insert(), and probably wants to insert links by calling
vl_insert() with the VLI_NOSORT option.
Don't bother implementing ASCII collation order for now. Don't bother
implementing LAST by itself.
Kwynn should write this sorting function with an eye to it possibly
becoming a part of the PFS library. When Kwynn he has time, he should
run the interface to his function by me and then write some library
documentation for it to go into the PFS library manual. Depending on
when this happens and on future discussions, we may also make this
function the default sorting routine used by vl_insert(); this must be
discussed.
Kwynn should also look at the sorting function in aq_query.c, with an
eye to his sorting function being something that we could drop into
aq_query.c as an alternative function.
The sort function Kwynn implements should be order preserving. This
will lets us run multiple sort functions on the data; first for the
minor key and then for the major key. How about taking an argument to
the sort function that is the directory ordering field for the
directory. Ignore the field for now. -bcn.
Yout sort ordering function should be in two parts, the sort code, and
a comparison function. The comparison function should be the only
place all these rules are encoded, and should be fairly
straightforward. Doing comparisons one token at a time, maintaining
perhaps one bit of state indicating whether the previous token seen
was "LAST".

192
prospero/doc/working-notes/gopher-hsonames.txt Normal file
View File

@@ -0,0 +1,192 @@
There are three separate servers involved in the following document:
1) GOPHER-GW Servers: servers responding to Prospero protocol queries
and making Gopher protocol queries. This server feature is
implemented and is available in Prospero release Alpha.5.2.
2) Prospero Servers that support the GOPHER database (that can read
native gopher directory format) and reply to Prospero queries. They
do not make any queries themselves. These servers have not been implemented
yet. They are not our top priority, since the GOPHER-GW server appears
to fill much of the niche that this was intended to fill. We call
them 'local Gopher database' servers.
3) Gopher servers that make Prospero protocol queries.
----
The GOPHER-GW Prospero servers (the ones that can make Gopher protocol
queries and export the results as Prospero directories (the server
that supports the GOPHER-GW Prospero database) and the Prospero
servers that can export the local Gopher hierarchy (the servers that
support the GOPHER Prospero database) will return links to Gopher
objects using the following format:
The Prospero servers export links to Gopher objects on the local
host (known to run both Gopher and Prospero) as normal Prospero links
which have normal Prospero access methods, INCLUDING the GOPHER access
method. They export links to all objects on other hosts (except for
directories/menus and searches) as Prospero EXTERNAL links with the
GOPHER access method, TELNET access method, TN3270 access method, or
AFTP access method.
They export links to Gopher menus and searches on other hosts (Recall
that all Gopher links have the form <gopher-host> <gopher-port>
<gopher-selector-string>) as links with a HOST-NAME field of some
known GOPHER-GW host and an HSONAME of the form:
GOPHER-GW/<gopher-host>(<gopher-port>)/<gopher-type-char>/<gopher-selector-string>
This canonical form means that a Gopher server which is capable of
making Prospero queries can always convert links of that form back to
normal gopher links, and return the reconstructed normal Gopher link
rather than leading the user through a series of gateways. The
gopher-type-character will always be 1 (menu) or 7 (search) when a
GOPHER-GW link is exported by a Prospero server supporting the GOPHER
database. The GOPHER-GW server will export all links to Gopher
non-menu objects as Prospero EXTERNAL links with the GOPHER access
method.
. How gopher searches are exported.
They are exported as Prospero directories with an
OBJECT-INTERPRETATION of SEARCH.
In addition, a QUERY-METHOD attribute is exported for them. This is
an instance of the more general QUERY-METHOD format (documentation not
in final form yet). The first token of the query method looks like a
procedure call. The GOPHER-GW server uses the format
gopher-query(search-words); since there is only one search string in a
gopher search, there is only one argument to the procedure call.
For the gopher query method, the 2nd token is always going to be
${search-words}.
The third and last component will always be '' for gopher searches;
this indicates that the contents of a directory are being asked for
and will be returned, not a link to a directory. So:
{ I presume this is syntactically equivalent to '*' ? - Mitra }
gopher-query(search-words) ${search-words} ''
There will also be an instance of the QUERY-ARGUMENT field. Note that 'char*' is a single word with no spaces.
search-words 'Index word(s) to search for:' 'mandatory char*' '%s' ''
And two instances of the QUERY-DOCUMENT attribute, one for
gopher-query() and one for search-words. But you don't even have to
pay attention to them for now.
To execute the search, the next request to the server will be:
DIRECTORY <search-directory-hsoname>
LIST '' COMPONENTS <search-string>
This can be implemented by a simple call to
p_get_dir(<vlink-to-directory>, <search-string>, usual dir,
usual flags, leave ACOMP set to null)
. Special cases
Gopher links to files with selector strings that start with ftp: and
contain an @ are exported with two access methods: the regular GOPHER
access methods and the AFTP access method directly to the host. The
AFTP access method is given preference. The client will then attempt
to make a direct anonymous FTP connection, if it supports the Prospero
AFTP access method. (all current Prospero clients do.) This is
considerably more efficient and more robust than putting lots of
additional load on the Gopher/AFTP gateways.
Gopher links to directories with selector strings that start with ftp:
and contain an @ are instead exported as native Prospero links to the
Prospero server running on an archie host (the default is
ARCHIE.SURA.NET, but this can be changed easily by editing the
definition in the file lib/psrv/gopher_gw/goph_gw_dsdb.c).
This bypasses the Gopher server, which would just be gatewaying
Prospero queries to that archie server.
<This is wrong, many ftp hosts arent indexed by archie, but may still
be pointed at by gopher, in the long term it should go directly to ftp
in the short term it should go through the gopher->ftp gateway. - Mitra>
. Gopher CSO type
We currently do not have a gateway that speaks CSO phonebook protocol.
(Gopher type 2). We will have to write a CSO gateway in order to
handle these. (Send email to info-prospero@isi.edu if the lack of
this gateway strongly affects you, and we'll probably move it up on
our priority list.)
< Cant this go through the gopher->cso gateway, or is this something
gopher clients handle - Mitra >
. Form for links on the local GOPHER database
HSONAMEs for Gopher menu objects on the local host (and on remote
hosts known to be running both Prospero and Gopher), when the menu is
being exported as part of the local GOPHER database, are always of
the form:
GOPHER/<gopher-port>/<gopher-type-character>/<gopher-selector-string>
. GOPHER-MENU-ITEM attribute and how to implement a Gopher server that
makes Prospero queries (this is being worked on right now):
The GOPHER-GW server will provide a GOPHER-MENU-ITEM attribute
associated with some links or directories. This is an attribute of
type SEQUENCE in the APPLICATION namespace. It is an OBJECT attribute
(which means it might be CACHED, ADDITIONAL, or REPLACEMENT -- you
know the story :)). It contains a single element -- the raw Gopher
(or Gopher+) protocol line that led to this link being generated. The
trailing CR and LF are stripped from the protocol line. You
should explicitly request this attribute, as part of the ATTRIBUTES
argument to the Prospero protocol LIST command. (In your
implementation, make sure to specify the GVD_ATTRIB flag to
p_get_dir()).
This means that a gatewaying service which translates Gopher queries
into prospero queries and exports the results as Gopher menus and objects
will never be caught in the incestuous situation of telling a gopher client
to make a gopher query to a gateway server that will be translated
into a prospero query and then translated back into a gopher query by
the responding Prospero server.
. Sidebar: How to check if a Prospero link can be exported as a raw
Gopher link (i.e, a link that doesn't involve going through your gateway).
1) Check for the presence of the GOPHER-MENU-ITEM attribute. If it's
there, you're all set.
2) Look at the ACCESS-METHOD attribute. If an object supports the
GOPHER access method, you're set.
3) Otherwise, you'll have to gateway the link yourself.
. End of sidebar
When you export a generic Prospero link as a Gopher menu entry, for
now the Gopher type character will be 0 (file) or 1 (directory).
Other types are also possible, as outlined in the
OBJECT-INTERPRETATION document (currently in doc/working-notes).
(Specifically, enough informatin is available to let you support the
Gopher SEARCH type, the TELNET, TN3270, and various image and sound
types.) The Gopher host and port for the link will be the same host
and port your Gopher server is running on. The gopher selector string
for the link will be:
ProsperoPoC/<prospero-host-name>/<prospero-hsoname>
(ProsperoPoC means 'Prospero Point of Contact'.) My gateway (the
Prospero server that exports Gopher directories) will detect such an
HSONAME and take that as a hint to test whether there is really a
Prospero hostname and hsoname that matches that. My gateway will
eventually cache the results of such tests. Your following this
convention means that my server will never return a Prospero link that
requires the client to go through my server and your server in order
to make a Prospero query that it could have made directly.
Implementation tip: Your server should fork when servicing requests
(the existing Gopher servers do this).
I have a more elaborate later implementation in mind for the Gopher
server exporting Prospero searches as if they were Gopher searches,
but this is not important right now.

41
prospero/doc/working-notes/new-acl-rights Normal file
View File

@@ -0,0 +1,41 @@
The more common entry appears first if multiple rights allow an
operation. The operation identifier appears second.
Object File Directory* Link* Meaning
A A A Aa Administer ACL
VYA VYA VYA VvAa View ACL
L Ll List link
Rg RG RQ RrQ Read link, get attribute or file
Wu Ww WM WmM Modify attribute, data, links
DzWu DKWM DdKWMm Delete link or attribute
EiWu EeWw EIWM Insert attributes or links, append (extend)
>) >) >) >] Add rights (that follow the symbol)
<( <( <( <[ Remove rights (that follow the symbol)
Note that there used to be a B right, which you should consider as
equivalent to A, but you should avoid using it.
The following only appear on the server maintenance ACL
S Restart server
T Terminate server
U Update system information
P Administer passwords
p P Add new password entry
A "-" sign in an ACL entry means that the specified rights are
explicitly denied.
* A small letter on a directory ACL means that this right applies by
default for links in the directory that do not specify their own
ACL or that include the directory ACL. A capital letter on a link
ACL is ignored.
** When restrictions are supported, they can be used to restrict the
specific attributes to which a right applies, or to restrict the
interpretation of an ACL entry to only the Object, File, or Directory,
or link.
Note that OBJECT, FILE, and DIRECTORY ACLs are stored in the same
place, and share the same access control list (well, directory is
different for now, but will eventually be merged).

256
prospero/doc/working-notes/object-interpretation.txt Normal file
View File

@@ -0,0 +1,256 @@
This document describes the OBJECT-INTERPRETATION attribute.
This attribute resides in the APPLICATION namespace. It is of type
SEQUENCE. It normally has OBJECT precedence.
There may be multiple instances of the OBJECT-INTERPRETATION attribute.
The first token specifies the class of the object. The class tells
the user of a simple-minded browser what you can DO with the object.
It tells the browser what icon to put up.
In general, the second token is interpreted on a per-class basis as
the particular format in use. The third and subsequent tokens depend
upon the file format in use.
(For the Prospero menu browsers, the icons we put up currently are :
for searches, . for files, ] for portals, and > for directories).
The classes are:
.. UNKNOWN This will never be sent over the network. It is used
internally by clients.
.. VOID
This class is used when the TARGET of a link is NULL. The only cases
in which this arises are (A) when a link is listable but not readable
(then the server's LIST command returns this link) and (b) when a
gopher type of 'i' is sent. (This is a little-used type supported by
Panda, the University of Iowa Gopher variant.)
A menu browser should just display this with no type character -- it's
a pure text string. All attempts to retrieve it will fail. Just look
at the MENU-ITEM-DESCRIPTION and NAME.
A server should never return such a link with any attributes except
(possibly) an OBJECT-INTERPRETATION of VOID.
.. PORTAL -- Portals are always attached to raw OBJECTs (not yet
implemented) or to EXTERNAL links. They will NEVER be attached to
FILEs or DIRECTORYs, although the implementor should not bother
checking this fact. One looks at the ACCESS-METHOD to determine how
to use it.
An OBJECT-INTERPRETATION of portal means that the process of accessing
the object leaves the user in some sort of interactive session.
. Details
PORTALS: For now, the only implementation of the PORTAL class is to
have the TELNET access method on an object. This instance of the
ACCESS METHOD token has type TELNET, and that is the 1st token. Of
the conventional next 4 arguments, only HOST is relevant. The hsoname
is ignored. The fifth argument is a set of instructions to display to
the user before opening the connection. If the fifth argument is not
present, that is the same as if it is explicitly specified as the null
string. We will later extend that to a full template, so anything
that parses this access method should ignore any additional arguments
beyond the fifth for now; they may be used later.
The conventional 4 arguments to an ACCESS METHOD are that the 2nd
token is the host type (always INTERNET-D for now), the 3rd is a
hostname, optionally followed by a port # in parentheses (in the case
of the TELNET access method, the port # is mandatory), the 4th is the
HSONAME type (always ASCII) and the fifth is the HSONAME (ignored in
this case)
If the port # is not specified in the HOST name, then the default port
for the TELNET service is used.
.. Gopher mapping
This can be served up by a Gopher server as a gopher menu/directory
containing two entries: (a) the directions, as a Gopher file. (b) the
TELNET link.
A Prospero server that makes Gopher protocol queries should serve up
the Gopher type '8' (Telnet session) as an objet with PORTAL class and
TELNET access method. If a GOPHER selector string (username) is
present, the instructions should be the literal string:
'Use the account name "<selector-string>" to log in'
This convention will guarantee that information transformed from
Gopher Protocol to Prospero format will be able to automatically be
transformed back into Gopher protocol.
The TN3270 access method is identical to the TELNET access method,
except that the word TELNET is replaced by TN3270 in the above
description. Gopher type 'T' should be served up as the TN3270 access
method. If the HOST does not specify a port, then the default port
should be used.
.. EXECUTABLE -- At the moment, the only format (2nd token) firmly
defined is PRM. The third token is always PRM_V1. We propose
EXECUTABLE SUN4 and EXECUTABLE SUN3, but this is subject to change
depending on implementation experience. The third and subsequent
tokens are not clear (SUNOS4, perhaps?).
Treat it as DATA if you don't recognize the format.
.. DOCUMENT
At this moment, the only format is TEXT. The third token is ASCII;
other character sets will be defined later.
DOCUMENT MIME is defined but won't be implemented immediately. The
GOPHER 'M' type will be exported under Prospero as DOCUMENT MIME.
If you don't have a MIME reader, treat it as DOCUMENT TEXT ASCII.
.. SEARCH --
Only form for this: SEARCH QUERY-METHOD V1.
A long form of the query-method attribute is currently defined in
/pfs/notes/query-method. This will be SEARCH QUERY-METHOD V2, and
will be a superset of V1. For V1, we are just implementing the simple
Gopher search type. Look at how to do this in the file
'/pfs/notes/gopher-searches', under the section 'How to handle this
under Prospero'.
If no QUERY-METHOD attribute is found, this can be handled at your
discretion. One reasonable way to handle it would be to quietly (not
obnoxiously) warn the user that the link has an erroneous format.
Don't go to the expense of more protocol requests to retrieve the
QUERY-METHOD until the link is actually selected.
This corresponds to gopher type '7' and will correspond to type '2'
when I implement the CSO gateway.
.. VIRTUAL-SYSTEM
The only format for this CLASS is VS-DESCRIPTION. The VIRTUAL-SYSTEM
VS-DESCRIPTION format is only associated with directories.
Menu browser should treat it as a DIRECTORY for now.
.. SOUND
No format defined at the moment.
Corresponds to gopher type 'S' and Gopher+ type '<'.
Treat it as DATA if you don't have a sound player or don't recognize
the format.
.. IMAGE
Only format currently in use: IMAGE GIF. IMAGE POSTSCRIPT is defined;
an object may be DOCUMENT POSTSCRIPT or IMAGE POSTSCRIPT, depending on
whether it is primarily considered an image or a document.
MPEG, JPEG, X bitmaps, and other image encodings will be added later
as needed.
IMAGE GIF corresponds to the gopher 'g' type.
Treat it as DATA if you don't have an image viewer.
.. VIDEO
The VIDEO class may contain prerecorded (perhaps live too? We'll have
to see as a result of use) sound and image data. Treat it as DATA for now.
.. SOURCE-CODE
The MENU API may treat this as identical to DOCUMENT TEXT ASCII. The
file-format (2nd field) is the computer language it's source code for.
The current defined computer language is 'C'.
.. DATA
This is for raw files that just contain raw binary data. No
file-format is defined for them. They cannot be displayed or printed.
Just offer to save them.
.. PROGRAM
Interpreted code will be of class "PROGRAM", which means you can
execute it using the interpreter named in the format field, and you
can display it as an ASCII document. No official interpreter names
are currently defined for PROGRAM, although we will come up with some
on an as-needed basis. I suggest the first interpreter names be 'PERL',
'SED', 'SH', and 'CSH'. This class is for things which are really
both SOURCE-CODE and EXECUTABLE.
.. EMBEDDED
This class is used for objects that have to be uncompressed, unzipped,
untarred, or have some other transformation applied to them to be
useful.
The 2nd token (format) should identify the transformation. Currently
defined ones: GZIP, COMPRESS, TAR, BINHEX (macintosh BinHex format),
UUENCODE.
The third field for any transformation of class EMBEDDED may be a
number. If it is, it indicates the number of additional arguments to
be specified for the transformation. If a number is specified, that
many arguments follow. Any tokens after the arguments are parsed as
if they were a new freestanding OBJECT-INTERPRETATION attribute. If
this third field is not a number, then it is assumed to be zero, and
the third and subsequent tokens should be parsed as if they were a
freestanding OBJECT-INTERPRETATION attribute.
GZIP, COMPRESS, TAR, BINHEX, and UUENCODE are not currently defined to
take additional arguments. If a specific file is to be extracted from
the tar file, see the SEGMENT field (as defined in
/pfs/notes/aggregate).
Default for saving should be to save it in the raw (unextracted) form.
A more sophisticated client can offer to unembed it before saving it.
If you don't recognize a particular EMBEDDED type, just treat it as
DATA. You can still offer to save it in a file.
.. AGGREGATE
This type is documented in another file but does not need to be
discused here (yet).
.. DIRECTORY
This is a raw DIRECTORY with no special OBJECT-INTERPRETATION.
. Kwynn:
For now, just implement the following types:
PORTAL (with the ACCESS-METHOD TELNET)
DOCUMENT TEXT ASCII
SEARCH
DIRECTORY
DATA
Your next pass will be to implement:
VOID
IMAGE GIF
EMBEDDED GZIP
EMBEDDED COMPRESS
Until you implement all of the OBJECT-INTERPRETATIONs, please do this hack:
EXECUTABLE, AGGREGATE, IMAGE, SOUND, EMBEDDED, and DATA should all be
treated as raw DATA.
Treat DOCUMENT MIME, SOURCE-CODE, and PROGRAM as if they were DOCUMENT
TEXT ASCII.
Treat VIRTUAL-SYSTEM as if it were just DIRECTORY.
. If No OBJECT-INTERPRETATION present
If no OBJECT-INTERPRETATION is present, treat random FILEs as if
they were either DOCUMENT TEXT ASCII or DATA. Just display them as
TEXT, but when you're asked to retrieve them, sample the first 1k or
so and make sure it's printable. If it isn't, say that the file isn't
really text, and offer to save it.
Treat unadorned directories as if they were DIRECTORY.

89
prospero/doc/working-notes/pdap.txt Normal file
View File

@@ -0,0 +1,89 @@
Prospero Data Access Protocol (doc/working-notes/pdap.txt in the
Prospero Release)
Note that this document is not necessarily going to be fully in sync
with the PDAP draft paper (Augart, Neuman, Rao, unpublished). Until
that paper is published, the protocol is subject to change.
Goal: To provide a single file system protocol supporting several
modes of file access (whole file caching, remote read/write, etc),
that supports gateway functionality to other file services,
as well as support for a range of authentication and authorization
mechanisms.
Note: authentication and encryption/integrity eventually
provided by ARDP library. For now, authentication
and authorization provided directly by this protocol.
Message format - this is layered on ARDP protocol.
sequence { 1 octet version
sequence of sequence { 1 octet operation
asn1length data-length
data-length octets operation-data}
}
Operations =
1 open
2 open response
3 close
4 close response
5 stat
6 stat response
7 read
8 read response
9 write
10 write response
11 lease request
12 lease response
13 authenticate/authorization/accounting (for methods not provided in ARDP)
14 authentication/authorization/accounting response (if not done in ARDP)
Commands:
1 open 1 octet flags: read, write, append, create, cache, oob-xfer
1 octet name-type
name-type APPLICATION, FILESYSTEM, DEVICE, URL, PROSPERO-AM
application takes application name and application specific name
filesystem takes local system pathname
device takes device identifier and an integer for i-node
URL takes a URL for string (for gatewaying)
PROSPERO-AM takes an access method sequence (for gatewaying)
if oob-xfer flags set, path or identifier where to store
2 open response 1 octet (success/failure/warning)
1 octet handle type (capability,crypto_cap,asn1int,none)
asn1length length
length octets file handle
optional file name if left out in request, gensymed
if oob-xfer, name of file to open
error/warning code and text
3 close file handle type and handle. If none, then file opened in
same request.
4 close response
success/failure/warning
error/warning code and text
7 read file handle type and handle (if none, as opened in same message)
offset
asn1length length
8 read response
success/failure/warning
asnlength length
length octets data to be returned
error/warning code and text
9 write file handle type and handle (if none, as opened in same message)
offset
asn1length lenght
length octets data to be written
10 write response
success/failure/warning
error/warning code and text

35
prospero/doc/working-notes/pfs-udp-ports.txt Normal file
View File

@@ -0,0 +1,35 @@
From bcn Tue Jun 1 07:51:35 1993
Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.61+local-12)
id <AA09948>; Tue, 1 Jun 1993 14:51:40 -0700
Date: Tue, 1 Jun 93 14:51:35 PDT
Posted-Date: Tue, 1 Jun 93 14:51:35 PDT
Message-Id: <9306012151.AA00562@tgo.isi.edu>
Received: by tgo.isi.edu (4.1/4.0.3-4)
id <AA00562>; Tue, 1 Jun 93 14:51:35 PDT
From: Clifford Neuman <bcn>
To: PETER@psychnet.psychol.utas.edu.au
Cc: C.Warren@deakin.edu.au, bajan@bunyip.com, info-prospero
In-Reply-To: Alan Emtage's message of Tue, 1 Jun 1993 17:19:13 -0400 <9306012119.AA17783@mocha.bunyip.com>
Subject: About UDP ports that archie uses
Status: R
There are two ports officially assigned to Prospero (and hence archie
as well). The official port is 191, and the official non-privileged
port is 1525. If a Prospero or archie server is able to bind the
privileged port, the server will listen on both ports. If not, it
will only listen on the non-privileged port.
If the server can bind the privileged port, the response will be sent
on the privileged port. The default port used to contact a server is
presently 1525, which is the most general port since all servers
listen on it. It is not uncommon to have a message sent on 1525, but
to receive the response from 191. If you are writing your own client,
it should not reject a response simply because the server port
changed. You may use the connection id in the response to pair the
response with the request.
~ Cliff

71
prospero/doc/working-notes/wais-link-format.txt Normal file
View File

@@ -0,0 +1,71 @@
gWAIS LINK FORMAT
This document describes Prospero links to files accessible through
WAIS; we have not yet determined a format for WAIS directory & index
lookups. This format works for both external WAIS links and native
WAIS links (that is, links to WAIS files stored on a server running
Prospero).
The WAIS record locator string has a port # and hostname encoded into
it. We treat the record locator as an impenetrable object that we
just give to the WAIS server at a particular wais server (WAIS servers
are uniquely identified by a hostname port # pair); Prospero itself
doesn't worry about extracting this information from the WAIS record
locator string. The person or computer program creating a link to a
WAIS object is responsible for obtaining the WAIS port # and hostname.
The HOSTNAME on the VLINK is the hostname of the prospero server which
stores information about that file. If the server is running on a
non-standard port, this hostname will be followed by a port number in
parentheses.
The HSONAME on the VLINK for a file which is usually accessed through
WAIS begins with the sequence WAIS/OBJECT/ and then finishes with the
WAIS record locator string.
Not all files which can be retrieved via the WAIS access method will
have an HSONAME on the VLINK in this format. This is because the
server may send a WAIS access method even for a file that is primarily
accessed through NFS, Anonymous FTP, or some other access method. In
this case, the ACCESS-METHOD attribute for the file will usually have
the six-token format (described below).
The ACCESS-METHOD attribute for WAIS files consists of 5 [sometimes 6] tokens:
WAIS INTERNET-D <hostname> ASCII <hsoname>
[optional record locator string]
WAIS, INTERNET-D, and ASCII are literals.
The <hostname> token in the ACCESS-METHOD attribute is the name of the
host whose WAIS server must be contacted to retrieve the object (same
as the hostname encoded into the record locator). If the WAIS server
is running on the default WAIS port (210), this <hostname> token may be the
normal Internet hostname or it may be followed by the port # in
parentheses. The <hostname> token must always include the port # in
parentheses if the WAIS server is running on a non-default port.
If a sixth token is present in the WAIS access-method attribute, then
this is the WAIS record locator string which will be sent to the WAIS
server to retrieve the object. If the sixth token is not present,
then the <hsoname> token of the ACCESS-METHOD attribute must begin with
the sequence WAIS/OBJECT/ and then finish off with the WAIS record
locator string. The WAIS/OBJECT/ prefix will be stripped off and the
resulting string will be sent to the WAIS server.
The most common case for the WAIS access method is on a link whose
target is FILE (not EXTERNAL) to an object which can be retrieved from
a wais server running on the default WAIS port on the same host as the
PROSPERO server which indexes it, and with the PROSPERO server running
on the default PROSPERO port. In this case, the HOST and HOSNAME
tokens in the ACCESS-METHOD attribute are the same and those for the
link. Therefore, using the defaults that apply to all access methods,
the ACCESS-METHOD attribute can be sent across the network as:
WAIS '' '' '' ''
In the case of an EXTERNAL link to a WAIS object, the HOST and HSONAME
tokens in the vlink are customarially (although this is not strictly
enforced) the same as those for the access method, and the access
method is sent across the network using the defaulting mechanism.