Re: about use of AFA format

Markus Stumpf <> Sun, 28 August 1994 10:37 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa00758; 28 Aug 94 6:37 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00754; 28 Aug 94 6:37 EDT
Received: from [] by CNRI.Reston.VA.US id aa02530; 28 Aug 94 6:37 EDT
Received: by (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13801 on Sun, 28 Aug 94 06:14:16 -0400
Received: from sifon.CC.McGill.CA by with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13796 (mail destined for /usr/lib/sendmail -odq -oi -fiafa-request iafa-out) on Sun, 28 Aug 94 06:13:57 -0400
Received: from ( []) by sifon.CC.McGill.CA (8.6.8/8.6.6) with SMTP id GAA16148 for <>; Sun, 28 Aug 1994 06:13:54 -0400
Received: from unknown ([]) by with SMTP id <326474>; Sun, 28 Aug 1994 12:13:39 +0200
Received: by id <231647>; Sun, 28 Aug 1994 12:13:18 +0200
Path: stumpf
X-Orig-Sender: USENET Newssystem <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Markus Stumpf <>
Newsgroups: lists.iafa
Subject: Re: about use of AFA format
Date: Sun, 28 Aug 1994 12:13:16 +0200
Organization: Technische Universitaet Muenchen, Germany
Lines: 111
Message-Id: <33pnvs$>
References: <33lofj$>
X-Newsreader: NN version 6.5.0 #5 (NOV) (Rafal Maszkowski) writes:

>      3.6.3 MISCELLANEOUS
>      The following is a list of generic data element subcomponents used
>      when referring to particular resources. These can be added to any
>      of the templates described below.

>Can they be added many times? I guess not..

I don't know if I understand you right.
There are two naming schemes (3.4.1, 3.4.2).
3.8.3 (SERVICE information) contains:
[...] Filename for this index file (Naming scheme 1): AFA-SERVICE
[...] any number of these files may exist in the archive.

So it is pretty valid to have a file like ("minimal form" ;)) ):
Template-Type:	SERVICE
Title:		WAIS database of the IAFA templates in our FTP archive
URI-v0:		gopher://
URI-v1:		wais://
Description:	all the IAFA templates for software and documentation are
	fed into a fulltext database that is updated every night

Template-Type:	SERVICE
Title:		WAIS database on the files in the WWW area
URI:		wais://
Description:	all HTML files on our WWW server are fed in a fulltext
	database that is updated every night.

>It would be convenient to have multiple Description-v* and URI-v* (and
>others) in SERVICE template.

I agree that URI should be a variant field, too, as one resource may
be accessible through various mechanisms (the most common I think is
currently that the same information is accessible through gopher, http
and ftp).
But I don't see the need for a variant description field.

>The same with mailing lists - the running list itself and its archive
>isn't exatly the same but I would prefer to have information about
>subscribing and ftp achives URIs, listserv archive URI and comment,
>gopher archives URIs and News group URI in one template. Mailing list
>and Usenet group where is it gatewayed to are obviously equivalent.

Why don't you put the additional information in the Description: field?
And please note that there is a Template-Type: MAILARCHIVE and USENET
which allows exactly for the the archiving of mailing-lists and
newsgroup archives.
You could e.g. have a file (scheme 2) fishlovers.AFA:
Template-Type: SERVICE
Title: 	       fishlovers
Admin-Name:    Ima Adams
Registration:  Send mail to the administrative address with your
 	       own email address requesting addition
Description:   Discussion list for people who love fish of all types
    	       This list is archived at
	       and also accessible via gopher at
	       gopher:// This mailing-list
	       is also gatewayed to the USENET group
Keywords:      fish, aquarium, marine, freshwater, saltwater
Access-Policy: Any Internet user may subscribe to this mailing list

Template-Type:	MAILARCHIVE
Title:		fishlovers
URI-v0:		gopher://
Keywords:       fish, aquarium, marine, freshwater, saltwater
Description:	This is an automatically maintained archive of all mails
		sent to the fishlovers mailing list.

However, here too, one could make URI a variant in the SERVICE template
and allow for adding e.g. a

>Another use of multiple URI-v*s etc. would be in LARCHIVE.

I don't think so. With the LARCHIVE file the placement in the file
structure is significant! Thus I think the URI is unique anyways.

>The order of the fields is not specified (if I'm not wrong). It is
>good because I'd like to have always Title field as the first one

Hmmmm ... I thought we had the convention that Template-Type: has
to be the first field and for all others the order is free, but I
can't find it anymore in the draft.

But I found something other:
    3.4 FILE NAMING (3rd paragraph)
    3.4.2 (2)
Is there any reason to prohibit multiple records with naming scheme 2??
As in the above example with the SERVICE and MAILARCHIVE I think it may
be very useful to allow for more than one record even with scheme 2.
Having > 5 such lists and archives would make it easier to maintain that way,
than with scheme 1 and one big file.
Also in 3.4 (3rd paragraph) is "[...] one large file containing all templates".
I can't see that fit even with scheme 1, as there is no type independent
name for such a file with scheme 1.

 Markus Stumpf                        Markus.Stumpf@Informatik.TU-Muenchen.DE