🚀 go-pugleaf

In article <1992Apr13.130106.8102@informatik.uni-erlangen.de> mskuhn@immd4.informatik.uni-erlangen.de (Markus Kuhn) writes:

>Both FTP and FTAM have far less capabilities and are not the optimal
>choice for a public file archive system.
>
>Can anyone tell me whether the ISO DFR (document filing and retrieval)
>protocol and service (ISO 10166) describes a better alternative?

Yes, DFR is EXACTLY what you are looking for and includes all the features
you describe in your later message. I will take the hint to provide a
summary shortly. To understand it properly, you also need to look at
ISO/IEC 10031, "Distributed-office-applications model" - both "Part 1:
General model" and "Part 2: Distinguished-object-reference and associated
procedures." Make sure you have ordered those as well.

Markus also writes (earlier):

>It would be fine to have a protocol which provides things like
>
>   - free names for files/documents (e.g. with spaces, ISO 10646 characters).

Of course. DfrTitle is defined as CharacterData which means choice of
GraphicString, T61String, PrintableString, GeneralString...

>   - for comfortable browsing attributes like a one-line-description of
>     the file contents

The "basic attributes" available on any DFR implementation include the
following sub-string searchable attributes as well as title and pathname:

Version-Name, External-Location, User-Reference, 
User-Reference-To-Other-Objects.

The "extension attributes" based on those for ODA documents include
many more. In addition, attributes can be added in exactly the same
way as for X.500 Directory.

>   - an attribute that contains a longer description like the README file
>     in many of today's *.tar.Z files. I want to be able to read this
>     attribute before I load the whole package.

Unless you want to make the README searchable on substrings, it might
be better to handle this by forming a "group" that contains both
the full item and the README file separately, with attributes for the
group. Incidentally, "references" like symbolic links can point 
to documents and groups (and search-result-lists) and have their own
attributes for searching so you can have as many "views" as you like. 

>   - attributes like author, version number, keywords, ... in order
>     to make browsing through the archive more comfortable.

All there. As well as arbitrary version titles there is also a DFR
maintained system of next and previous versions which could be used
like RCS and SCCS for version control (and could be implemented using
RCS or shapetool etc - the latter provides a complete "attributed file
system" which I think is rather similar to the DFR concept).

There is also a system for reserving documents to change them (comprehensive
read and write locks).

>   - search operations for keywords, author, names ... (a de luxe archie).

Of course, same arbitrary filter expressions as used in Directory Service
and Message Store. (In fact I would be inclined to use DFR as front end
for, and implementation of, both of those).

>   - distributed search operations

This is where you need to read ISO 10031. ISO 10166-1 just describes DFR as
though it was a single server, rather than a distributed system. Perhaps
that is why there is so little interest - people assume it is just a
fancy filing system. But this is the same as the description of the
X.400 Message Transfer System as a single "object", which only on 
"closer inspection" can be "decomposed" into a system of MTAs relaying
messages to each other. ALL the hooks needed for distributed operations
are there, but they are not explained. Instead there is a footnote (page v):

"...This International Standard governs the interactions of a Document Filing
and Retrieval client and a single Document Filing Retrieval server. Future
standardization will consider the facilities of a Distributed Filing and
Retrieval server system and the need for inter-server protocols and a DFR
administration protocol..."

With the aid of ISO 10031 one can read between the lines to understand
how this will work and the role that strange features like "Distinguished
Object References" and search lists will play in a distributed system.

Result should be more like "Prospero" than archie - i.e. you browse
within your own "home" DFR store organized how you want it, and it
transparently goes and gets information from other DFR stores when
you actually need it - either for an actual content, or to be able
to browse the attributes of a collection of documents.

>   - a well defined unique identifier for each document

They have a very interesting approach. Each document in a DFR store has
a Unique Permanent Identifier (UPI) which is PERMANENTLY unique (like
a Message Store message number, not re-allocated when a document is
deleted). These are not universally unique among other DFR stores and cannot 
be, since two separate copies can be made of the same document, with
different UPIs, even within one DFR store.

BUT, each document also has a path-name, similar to an ftp file pathname,
which can be unique if the DFR is setup that way. Access can be via
either UPI, path-name or "relative-path-name". The latter is just a
working domain for accessing via pathnames that are relative to a
sort of "current directory". This "base" is specified as a UPI.

So, if you have a system of mirror or cache sites, it is only necessary
to coordinate the "base" used by each site for a given sub-tree, and the
same "relative-path-name" accesses would apply. There are cumulative
"search-result-lists" that could easily be used for automatic updating between
archives (including user creation of such mirroring on the fly).

Now a "Distinguished-Object-Reference" (DOR) can be used to quickly
access a document on any DFR (or any other Distributed Office Application
- there will be protocols for Message Stores etc). This includes a
"local reference", (which could be a UPI or a "base" and "relative-path" as 
above), together with details of where to go to use that "local reference".

Now here comes the interesting trick. "Where to go" can of course be
the presentation address of a DFR store (or for that matter a gateway to
any ftp store, with simple pathnames used as "local reference"). It can
also be the Directory NAME of a DFR store or whatever, for independence
of changes in physical location and network address. Finally it can
also be a Directory POINTER to the name. The latter could easily be used
to implement a system that leads you to your local mirror/cache site
that updates the same "base" directory!

Sorry if that's too confusing, but read this again when you have
access to the standards - this is NOT spelt out clearly there either.

>   - all attribute contents should be as much machine readable
>     as possible in order to allow developping comfortable
>     browsing tools.

Same approach as MS and DS.

There has been a lot of discussion in the iafa mailing list and elsewhere
on issues that relate DIRECTLY to DFR, but only passing mention of it as
though a DOR was just another form of document ID to be incorporated. In
fact DFR is a framework within which archie, prospero, WAIS, WWW, ftp
areas etc etc can best be designed to function.

I believe it is also the key to designing adequate X.400 based news
software - (note Markus reference to use of DFR in "group communications").

The Distributed Office Applications architecture is also highly relevant
to OSI access for dialup users, PCs etc. It implies that simple Remote
Operations protocols can be used to gain indirect access to virtually
any "office application" - which basically covers the vast majority
of the sort of requirements people have for internet use. This reduces
the importance of both network and transport layer multiplexing and 
NSAP addresssing and relaying for dialup applications. A local DOA applications
gateway can do far more than a "transport bridge" - and do it transparently.

DOA also answers some of the concerns that have led to proposals for
a simplified OSI stack - but without violating the OSI Reference Model.