Re: New IAFA Draft
Markus Stumpf <stumpf@informatik.tu-muenchen.de> Mon, 18 April 1994 23:06 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10158;
18 Apr 94 19:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10154;
18 Apr 94 19:06 EDT
Received: from mocha.bunyip.com by CNRI.Reston.VA.US id aa28165;
18 Apr 94 19:06 EDT
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA10421 on Mon, 18 Apr 94 18:32:42 -0400
Received: from tuminfo2.informatik.tu-muenchen.de by mocha.bunyip.com with
SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA10411 (mail destined for /usr/lib/sendmail -odq -oi -fiafa-request
iafa-out) on Mon, 18 Apr 94 18:32:21 -0400
Received: from hphalle0.informatik.tu-muenchen.de ([131.159.4.1])
by tuminfo2.informatik.tu-muenchen.de
with SMTP id <326456>; Tue, 19 Apr 1994 00:32:13 +0200
Received: by hphalle0.informatik.tu-muenchen.de id <209155>;
Tue, 19 Apr 1994 00:31:56 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Markus Stumpf <stumpf@informatik.tu-muenchen.de>
To: iafa@bunyip.com
Cc: bajan@bunyip.com
Subject: Re: New IAFA Draft
X-Newsreader: NN version 6.5.0 #5 (NOV)
Message-Id: <94Apr19.003156mesz.209155@hphalle0.informatik.tu-muenchen.de>
Date: Tue, 19 Apr 1994 01:31:47 +0200
I finally found some time to write down my comments, here we go ...
1) on "handles":
How are these handles intended to be used? In 3.6.1 there is only
"Unique identifier for this record". But unique in which context?
Archive wide? This could cause problems with automatic updates (e.g.
mirrors), NFS linked archives where some larchives are maintained
e.g. across various departments.
IMHO a more precise specification would be good and solve some
problems. Would it be valid to have e.g. a URI or URL?
The fragment information could be used as an index to a "subhandle"
in case naming scheme 1 (multirecord file) is used.
e.g. url:ftp//some.host/pub/handles/AFA-USER#USER1 could refer
to the record containing
Handle: USER1
in the multirecord AFA-USER file.
2) on the "Title" fields:
It would be nice to have ONE field across all template files that
has a unique name and giving kind of a short description that could
be used for descriptive indexes like e.g. in the 00-index.txt files
in some msdos archives.
However this short description is
Name: USER, SERVICES
Organization-Name: ORGANIZATION
Host-(?)Name: SITEINFO (description says with Host-,
template says without)
<missing> LARCHIVE
Title: MIRROR, DOCUMENT, IMAGE, SOFTWARE,
MAILARCHIVE, USENET, SOUND, VIDEO, FAQ
I'd prefer to have "Name:" in all templates and "Title:" to be obsolete.
3) 3.6.3 MISCELLANEOUS:
There is a Title:, Short-Title: and Description:. What exactly is the
difference (and later on in some templates there is also a Abstract:.
4) All template types are singular, only SERVICES is plural.
Can we change this to SERVICE?
Problem: how to specify e.g. a WAIS database?
Template-Type: SERVICE
Name: A WAIS database containing mic information
Host-Name: some.server
Host-Port: 1234
Protocol: wais
How do I specify the name of the database? Can't find an appropriate
field.
5) on "3.8.4 DOCUMENTS, ..."
Could we add a field called "Posting-Id:" or something like that,
that would contain the Newsgroup(s) the object was posted to,
the volume/issue information, the Archive-Name: information of the
posting and the date. Thus, it could look like:
Posting-Id: comp.sources.x: v004i123 - xprog/part01, 27 Feb 1993
comp.sources.x: v004i124 - xprog/part02, 27 Feb 1993
comp.sources.misc: v010i001 - xprog/part01, 27 Feb 1993
comp.sources.misc: v010i002 - xprog/part02, 27 Feb 1993
This would allow to find objects even if only the Newsgroup and/or
volume/issue information is given.
However I am not sure about whether there records should be deleted
if a newer version was posted or if the object is of a newer version
than the one posted. I would tend to keeping this information, as
it may help the user in locating the object at all and then pointing
to an uptodate object.
Could we allow for a URI-v* to collapse Access-Protcol-v*,
Access-Hostname-v*, Access-Port-v* and Pathname-v* where applicable?
This would make it easier to cut 'n paste to retrieval tools like
Mosaic, lynx, ncftp, ...
And couldn't we remove the "Access-" prefix or add a generic
one to Format-v*, Size-v*, Language-v*, ..., too, for generalizing?
How is the Source: field being used? Free text information? URI?
URL?
Author-(USER*): "may be repeated as often as necessary"
Does one have to add a -v*, so to have
Author-Name-v0: Author One
Author-Name-v1: Author Two
This would allow for a proper grouping of the information which
otherwise require some "order" or the field to be grouped correctly.
However this does interfere with the other *-v* fields, as one could
assume these *-vN form a logical grouping.
6) Inconsistencies between template definitions and examples:
3.7.1: Host-Name: vs. Name:
Alias: vs. Preferred-Name:
3.7.2: Host-Name: vs. Name:
Alias: vs. Preferred-Name:
Organization-Type: should be Owner-Organization-Type:
Record-Last-Modified-(USER*) vs. Record-Last-Modified:
3.8.3. in Example 2:
where is Address: defined?
2.8.4 in Examples 1 and 2:
where is Abstract: defined?
Bye
\Maex
--
______________________________________________________________________________
Markus Stumpf Markus.Stumpf@Informatik.TU-Muenchen.DE
http://www.informatik.tu-muenchen.de/~stumpf/
- Re: New IAFA Draft Markus Stumpf