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