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

Markus Stumpf <stumpf@informatik.tu-muenchen.de> Mon, 11 July 1994 19:00 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08340; 11 Jul 94 15:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08335; 11 Jul 94 15:00 EDT
Received: from mocha.bunyip.com by CNRI.Reston.VA.US id aa18631; 11 Jul 94 15:00 EDT
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA05327 on Mon, 11 Jul 94 13:52:00 -0400
Received: from sifon.CC.McGill.CA by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA05316 (mail destined for /usr/lib/sendmail -odq -oi -fiafa-request iafa-out) on Mon, 11 Jul 94 13:51:00 -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 NAA04330 for <iafa@cc.mcgill.ca>; Mon, 11 Jul 1994 13:50:54 -0400
Received: from hprbg5.informatik.tu-muenchen.de ([131.159.0.200]) by tuminfo2.informatik.tu-muenchen.de with SMTP id <326469>; Mon, 11 Jul 1994 19:50:38 +0200
Received: by hprbg5.informatik.tu-muenchen.de id <311458>; Mon, 11 Jul 1994 19:50:12 +0100
Subject: Re: Comments on draft-ietf-iiir-publishing-01.txt
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Markus Stumpf <stumpf@informatik.tu-muenchen.de>
To: Martijn Koster <m.koster@nexor.co.uk>
Date: Mon, 11 Jul 1994 20:50:00 +0200
Cc: iafa@cc.mcgill.ca, m.koster@nexor.co.uk, bajan@bunyip.com, maex@leo.org
In-Reply-To: <94Jul11.190848mesz.85435@hpsystem2.informatik.tu-muenchen.de> from "Martijn Koster" at Jul 11, 94 08:06:30 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: 3719
Message-Id: <94Jul11.195012mesz.311458@hprbg5.informatik.tu-muenchen.de>

Martijn Koster writes:

|> [ on handles ]
|>> Would there any problem allowing URIs (or URLs) as handles?
|>> Thus I could simply use
|>> 
|>> Author-Handle:	http://www.leo.org/~stumpf/
|>> 
|>> 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.
|>
|>But the records may be used off-line, and then you're in trouble.
|>I think having URI as a PERSON attribute gives you that functionality
|>while still allowing other info to be carried in-place. But we do need
|>something to matchup those handles.

Hmmm ... I can't see the point.
If I'm offline and I have a handle of whatever kind, I'll probably need
a online connection to "resolve" the handle. If the handle is simply a
record in a IAFA then you'll need ftp to get the file.
And I don't think that Handle and the other tags are exclusive.
I usually add Name and Email at all, but for further and uptodate
information the Handle may be usuful.

|>> 3.8.4
|>> 
|>> [re ordering of attributes]

|>Fine, but it needs to explicitly stated in the standard. And this

Right.

|>requires the identification of a naming field (as not everything has
|>-Name)

Hmmm ... think it concerns the AFA-OBJECT types, as only there there
is the sentence that "Author-(USER*)" may be repeated as often as necessary.

|> Of course an alternative (an easier to parse) solution is use a
|>numbering scheme ala -v*

I also would prefer that (and never got any reaction to that proposal).

|> Author1-Home-Phone: +1 800 555 1212
|> Author1: Crosby
|> Author2: Stills
|> Author2-Home-Phone: +1 415 234 5678
|> Author3: Nash

However I think this should be contructed as

Author-Name-v1:	Crosby
Author-Home-Phone-v1: +1 800 555 1212
Author-Name-v2:	Stills
Author-Home-Phone-v2: +1 415 234 5678
Author-Name-v3:	Nash

|>I feel OBJECT is a bit too general; for example an ISBN isn't going to
|>be available for most network-based objects. But in general, where
|>similar sets of attributes are used a cluster would be nice (role on
|>X.500 oidtables :) The reason I'm not too pushy on that is that I
|>don't want to corrections to the draft to become so extensive it will
|>be kicked back by the RFC edittor.

Ok ... I think we can live without this, too.
With having the ability to put e.g.
#Local-URL:	ftp://.....
in the file, this is also an easy way to contruct a URL for our local
archive.
All I wanted to avoid is the work to find the local entry and construct
local URL from all the different tags.
If people accept the AFA idea and write AFA files with maybe 10 entries
for Location, Access-Host, ... this will become tricky. But we need
to find the "local" record to contruct correct references from our
database to our (local) files.

|>>  ACKNOWLEDGEMENTS
|>
|>What I want to know is, where are all those people? The only input on
|>this list seems to come from three people :-(

Some of those other people had some reasonable part in the discussion
on this list about 1 - 1 1/2 years ago and I think some I don't know
from this list have been on the IETF meetings.

However I mainly see *input* from two people and sometimes some rare
comments from Alan. ;-)

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