Re: Draft progression

Markus Stumpf <stumpf@informatik.tu-muenchen.de> Thu, 25 August 1994 00:35 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11595; 24 Aug 94 20:35 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11591; 24 Aug 94 20:35 EDT
Received: from mocha.Bunyip.Com by CNRI.Reston.VA.US id aa22375; 24 Aug 94 20:35 EDT
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16632 on Wed, 24 Aug 94 19:42:51 -0400
Received: from sifon.CC.McGill.CA by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16627 (mail destined for /usr/lib/sendmail -odq -oi -fiafa-request iafa-out) on Wed, 24 Aug 94 19:42:46 -0400
Received: from tuminfo2.informatik.tu-muenchen.de (root@tuminfo2.informatik.tu-muenchen.de [131.159.0.81]) by sifon.CC.McGill.CA (8.6.8/8.6.6) with SMTP id TAA17245 for <iafa@cc.mcgill.ca>; Wed, 24 Aug 1994 19:42:43 -0400
Received: from hprbg5.informatik.tu-muenchen.de ([131.159.0.200]) by tuminfo2.informatik.tu-muenchen.de with SMTP id <326455>; Thu, 25 Aug 1994 01:42:27 +0200
Received: by hprbg5.informatik.tu-muenchen.de id <311457>; Thu, 25 Aug 1994 01:42:17 +0100
Subject: Re: Draft progression
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Markus Stumpf <stumpf@informatik.tu-muenchen.de>
To: Alan Emtage <bajan@bunyip.com>
Date: Thu, 25 Aug 1994 02:42:11 +0200
Cc: m.koster@nexor.co.uk, iafa@cc.mcgill.ca
In-Reply-To: <9408241711.AA13040@mocha.bunyip.com> from "Alan Emtage" at Aug 24, 94 07:11:09 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Length: 4751
Message-Id: <94Aug25.014217mesz.311457@hprbg5.informatik.tu-muenchen.de>

Hello Alan, hello Martijn,

Just finished my finals, so I have some more time now :)))

Thanks for adding my name to the masthead. Could you please change
"University of Munich" to "Munich University of Technology" ???
The are two unis in Munich and the "University of Munich" is the other
one ;)

|>	I have reviewed your comments about the current draft. You bring
|>up a set of interesting points which I think require resolution. The
|>question is can we make any significant changes to the document at this
|>point, or do we have to keep certain things the way they are in order to
|>preserve installed base? Since we are now starting to use the IAFA
|>templates here, this is something that concerns me.

We are now at about 6200 template files with various draft levels :/
We will have to convert them all, too :/

But I think we should get as much changes as possible in the next draft.
If we'll find some time within the next week to have some discussion on
the interesting points, we could get it in the next draft. I don't know
of any other site/institution besides our FTP-server and Martijn's ALIWEB
that use IAFA currently, so the changes should not do any harm to others.
And I think it's better and easier to change it now than later.

First some quick corrections:
--------------------
3.6.3 MISCELLANEOUS

could we please drop "Short-Title:".

there is a
	URN		Uniform Resource Identifier
I am currently not uptodate with the URI mailing list, but I think
this should read URI, as URI is used throughout the rest of the draft.

--------------------
3.7.2 LARCHIVE

in the example

Owner-Organization:	should read	Owner-Organization-Name:
Organization-Type:	should read	Owner-Organization-Type:
Record-Last-Modified:	should be splitted
				Record-Last-Modified-Name:
				Record-Last-Modified-Email:

--------------------
3.8.3 SERVICES

in example 1

Template-Type: SERVICES	should read	Template-Type: SERVICE
Last-Modified-Name:	should read	Record-Last-Modified-Name:
Last-Modified-Email:	should read	Record-Last-Modified-Email:
Last-Modified-Date:	should read	Record-Last-Modified-Date:

in example 2

Template-Type: SERVICES	should read	Template-Type: SERVICE

--------------------
3.8.4 DOCUMENTS, ...

example 1:

Abstract:		should read	Description:
Access-Method:		doesn't show up in the description of the fields
Last-Revision-Date: and Library-Catalog are variant fields, shouldn't
they get a -v?: ?? Or can one omit the -v* if it applies to all variations?

example 2:

Abstract:		should read	Description:
and Abstract: is there two times.
There is also an Access-Method-v0: (see above)
--------------------

------------------------------------------------------------------------
------------------------------------------------------------------------

Some suggestions I *really* would like to have :)

1) could we please make URI a variant field and allow it to be a shorthand
   for Access-Host-Name, Access-Host-Port, Access-Method and Location?

2) 3.8.4
   [ ... ] Suggestions for this types include
   [ ... ] Other names may be constructed as necessary

   I think the draft should be a bit more specific if one is completely
   free to add new types oneself or if it is thought as "may be added in
   future releases of this document".

These are the changes I think shouldn't ne too hard to do.

If we dare and go one step on, I'd suggest a new cluster OBJECT which
would take fields like
Format: Size: Language: Character-Set: ISBN: ISSN: Protocol: Host-Name:
Host-Port: Pathname: Library-Catalog: Method: URI:
that really apply to a specific "object" that shares a same functionality
but maybe e.g. a binary for suns, decs, hps, sgi, or source code, or
as in the example it may be the same book in different encodings or
languages. But then all of the above fields may be different, while the
Author:, Admin, Description fields would be the same.
It would also allow for the admin of the records to specify various
locations of the same piece of software. Some people usually upload
their sources not only to one but 2 or three ftp servers. Providing
this information already in the AFA file could help harvesting processes
detect duplicates ... this is even more true if the AFA files would contain
a more or less complete list of the mirror sites.
I know this is getting less important as soon as there are better directory
services and UR* get widely spread, but I think this will take some time
and in the meantime this would be a cheap mechanism to jump in.

	\Maex
-- 
______________________________________________________________________________
 Markus Stumpf                        Markus.Stumpf@Informatik.TU-Muenchen.DE 
                                http://www.informatik.tu-muenchen.de/~stumpf/