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/