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/
- Re: Draft progression Alan Emtage
- Re: Draft progression Alan Emtage
- Re: Draft progression Markus Stumpf
- Re: Draft progression Alan Emtage
- Re: Draft progression Martijn Koster
- Re: Draft progression Markus Stumpf
- Re: Draft progression Martijn Koster
- Re: Draft progression Alan Emtage
- Re: Draft progression Markus Stumpf