Re: Comments on draft-ietf-iiir-publishing-01.txt

Markus Stumpf <> Sat, 09 July 1994 18:49 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa02162; 9 Jul 94 14:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02158; 9 Jul 94 14:49 EDT
Received: from by CNRI.Reston.VA.US id aa08204; 9 Jul 94 14:49 EDT
Received: by (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01690 on Sat, 9 Jul 94 14:05:21 -0400
Received: from sifon.CC.McGill.CA by with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01681 (mail destined for /usr/lib/sendmail -odq -oi -fiafa-request iafa-out) on Sat, 9 Jul 94 14:04:47 -0400
Received: from ( []) by sifon.CC.McGill.CA (8.6.8/8.6.6) with SMTP id OAA28977 for <>; Sat, 9 Jul 1994 14:04:37 -0400
Received: from ([]) by with SMTP id <326489>; Sat, 9 Jul 1994 20:04:24 +0200
Received: by id <231522>; Sat, 9 Jul 1994 20:04:09 +0100
Path: stumpf
X-Orig-Sender: USENET Newssystem <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Markus Stumpf <>
Newsgroups: lists.iafa
Subject: Re: Comments on draft-ietf-iiir-publishing-01.txt
Date: Sat, 9 Jul 1994 21:03:58 +0200
Organization: Technische Universitaet Muenchen, Germany
Lines: 254
Message-Id: <2vmoqe$>
References: <2uv0dg$>
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
X-Newsreader: NN version 6.5.0 #5 (NOV)

Sorry it took me so long to comment, but I am rather busy learning
for my finals, so ... :/

Martijn Koster <>; writes:

>I look forward to your comments,

Here we go :)
I'd like to add a few comments to your posting as well as a few
things I'd like to see.
(If not stated otherwise I totally agree with Martijn's statements)


>It seems to me that Organization-Name and Organization-Type do not fit
>into the template very well, where are the other ORGANIZATION*
>elements, especially Handle? I suggest explicitly mentioning
>ORGANIZATION* elements can be part of USER*, or adding an element

I second that. If there shall be some organizational attachment to
a USER cluster we should have the full ORGANIZATION* elements.
Thus I'd also suggest to exchange 3.6.1 and 3.6.2

However, why is 3.6.1 named "INDIVIDUALS AND *GROUPS*" ??
I can't the GROUPS fit very well into the USER cluster. And if we
don't assume a organization to be commercial (as I do usually ;) )
I think they'll better fit with the ORGANIZATION cluster and the
sections should be



I think this section may be completely deleted.
There is no relevant information that is not repeated later on in the
exact template definitions and may lead INHO to confusion.


>What is the relationship between Title, Short-Title, and things like
>Name in normal templates?  Are Title and Short-Title recommended for
>all templates, if not what point is really served by them being there?

I always had problems with this, too.
I think Shot-Title is unnecessary, als we have Title and Description
and so Title could be used for short infos and Description for longer ones.
BUT: Title mainly applies to the DOCUMENT type. All other types would
better do with a Name tag. This tag is also used with all but the OBJECT
types. I don't kniw whether it would be valid in good english to speak of
the name of a document instead of the title (in Germany it would ;)) )
but if, I'd like to see the use of Name instead of Title in all templates.
This would make it also simpler to parse.



>The definition for *-Location-v* mentions a URL for the first time,
>without definition or reference. I suggest these become "URI", or
>preferrable, the entire document uses URL's.

This is my fault as I have created the template and the example. :)


3.8.1, 2.1 and other places

>I feel a bit unhappy about the use of handles without giving any indication
>of how they are to be used other than :

>> NOTE: A handle should be used in preference to a fully expanded entry
>>  in those situations where a handle for an individual, group or
>>  organization can be obtained and subsequently resolved by some other
>>  (external) method (directory service).

>There should be an indication of uniqueness, are Handles supposed to be
>unique withing a multi-record document, a site, or world-wide.

Would there any problem allowing URIs (or URLs) as handles?
Thus I could simply use


and on this page you'll probably find (or at least should find) all the
information that usually is in the USER* cluster. Most of the organizations,
groups or individuals I've checked have such "HOME pages", so it will
be a good start.
Allowing URIs for Handles is IMHO also a good start as it is flexible
and may be changed to a URI poiting to some kind of directory service
some time in the future.



>Why serviceS when everything else is singular?

Hehe ... asked this twice but never got any reaction ...
I'd like to have the "s" deleted, too!!



>Author-(USER*), Admin-(USER*) "may be repeated as often as necesarry"
>Hmmm... Why are these for multiple people here, and not anywhere else?
>How can we parse this, when you don't know where one person begins
>and another ends, e.g.
>   Author-Name: Martijn Koster
>   Author-Email:
>When parsing IAFA templates, what should one do with duplicate fields
>normally? I consider them an error.

We had this with my question about authors of e.g. songs.

Alan Emtage wrote:
ae> Now we have a potential problem. Which home phone number belongs to which 
ae> Author? My only solution is to put an ordering. In cases like this when *you 
ae> are dealing with the same object* and you have repeated fields that have to 
ae> be associated, positional association is the only thing that I can see 
ae> working. So, in the example above, since we have an Author-Home-Phone we 
ae> associate it with the last Author-Name previous to it. 
ae> Now, we have to be very careful how we specify this. Take this example:
ae> Template-Type: SOUND
ae> Title: Southern Cross
ae> Author-Home-Phone: +1 800 555 1212
ae> Author: Crosby
ae> Author: Stills
ae> Author-Home-Phone: +1 415 234 5678
ae> Author: Nash
ae> Since we have not made the "Author-Name" special signficance, what does line 
ae> #3 associate with? You'd probably guess line #4 but since we haven't defined 
ae> an author can we be sure that it is to associate with "Crosby" ?
ae> I suggest the following. For the "clusters" we define that the -Name field 
ae> must be first within the cluster to disambiguate the above.

Think this is a good and workable solution. Same as Template-Type has
to be the first in a template file *-Name: should have to be the first
in a USER* cluster. Same should apply to ORGANIZATION* as well.



I think Martijn deserves his name is added :)

> Bibliography:

A reference to ALIWEB or a paper on aliweb should be added too, as this 
is the first widely used service making use of IAFA.
(sorry I am at home and wading through my references via a 2400 modem is
no fun)


And here a few comments I haven't seen in Martijn's mail.

As told many times before we make heavy use of IAFA for our anonymous
ftp archive ( We now have about 5000 (!) template
types (some more, some less filled with information). As soon as
the LSM -> AFA converter works this number will raise a lot, again.

We currently use this information for providing a HTMLized access to
our archive via and creating a
wais database gopher:// (we're working
on a better access for the database).

For all this services and especially for the user it is of big help
to have all the relevant information for a object available for
cut 'n paste.

Currently we only have Access-Protocol, Access-Host-Name, Access-Host-Port
and Pathname. (I wonder why Pathname has no Access- prefix?).
The example also has a Access-Method which is not listed in the definition.

Why can't we define another cluster called OBJECT and have it:


One would then have three choices:
1) URI:		for easy access and cut 'n paste
2) Method:	a textual description
3) Protocol, Host-Name, Host-Port, Pathname:	for better known
		access methods that don't have assigned a URL type yet.

in the AFA-OBJECT then have a 
or even simpler a

Same applies to the SERVICE type, too.



Abstract isn't listed in the definition part but used in the examples.
I think Description is fine and also used throughout all other templates
so Abstract should be deleted.



> [ ... ] Suggestions for this types include
> [ ... ]
> Other names may be constructed as necessary.

How do I have to read this?
Am I free to e.g. create a new type FONT, pick up some data elements that
would fit from section 3.8.4 and voila we have a new Template-Type ??

(FONT is e.g. something that I'd missed lately, when some Type-1 fonts
were archived and the archivers brought up the question what Template-Type
to use)


That's it for now ...

Have a nice weekend

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