Re: new iafa draft

Larry Masinter <> Fri, 12 January 1996 19:52 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa13871; 12 Jan 96 14:52 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13867; 12 Jan 96 14:52 EST
Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa10953; 12 Jan 96 14:52 EST
Received: (from daemon@localhost) by (8.6.10/8.6.9) id OAA27241 for iafa-out; Fri, 12 Jan 1996 14:48:17 -0500
Received: from (mocha.Bunyip.Com []) by (8.6.10/8.6.9) with SMTP id OAA27234 for <>; Fri, 12 Jan 1996 14:47:44 -0500
Received: from alpha.Xerox.COM by with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17737 (mail destined for; Fri, 12 Jan 96 14:47:32 -0500
Received: from ([]) by with SMTP id <15409(10)>; Fri, 12 Jan 1996 11:47:00 PST
Received: by id <2733>; Fri, 12 Jan 1996 11:46:18 -0800
In-Reply-To: Jon Knight's message of Fri, 12 Jan 1996 02:10:44 -0800 <>
Subject: Re: new iafa draft
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Larry Masinter <>
Message-Id: <>
Date: Fri, 12 Jan 1996 11:46:05 PST
Precedence: bulk

> I've a feeling that all the URC/metadata efforts are going to hit this 
> problem where you want to keep things simple for new users but still 
> offer a reasonable complete set of attributes (or an upgrade path to 
> another format) for more advanced cataloguers.

I think the goal is to make URCs do for bibliographic data what HTML
did for documents: raise the least common denominator, while not
displacing the high end. 

Now you can expect almost anyone to deal with something in HTML across
platform, rather than ASCII text. On the other hand, some applications
will continue to need SGML or PDF or proprietary software for dealing
with more complex or specialized situations.

I think of IAFA filling the same role as gopher: it's good to get it
documented and it should play a role in defining the followon, too.