Re: URCs and IAFA templates

Martijn Koster <m.koster@nexor.co.uk> Thu, 13 October 1994 10:54 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00961; 13 Oct 94 6:54 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00957; 13 Oct 94 6:54 EDT
Received: from mocha.Bunyip.Com by CNRI.Reston.VA.US id aa03096; 13 Oct 94 6:54 EDT
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29661 on Thu, 13 Oct 94 04:24:50 -0400
Received: from lancaster.nexor.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29657 (mail destined for /usr/lib/sendmail -odq -oi -furi-request uri-out) on Thu, 13 Oct 94 04:24:44 -0400
Message-Id: <9410130824.AA29657@mocha.bunyip.com>
Received: from nexor.co.uk (actually host victor.nexor.co.uk) by lancaster.nexor.co.uk with SMTP (PP); Thu, 13 Oct 1994 09:23:52 +0100
To: Sally Hambridge <sallyh@ludwig.intel.com>
Cc: iafa@cc.mcgill.ca, uri@bunyip.com
Subject: Re: URCs and IAFA templates
In-Reply-To: Your message of "Fri, 30 Sep 1994 13:47:35 PDT." <9409302047.AA21757@Ludwig.intel.com>
Date: Thu, 13 Oct 1994 09:23:43 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Martijn Koster <m.koster@nexor.co.uk>

> IAFA Folks:  We on the URI list see relation between IAFA
> templates and URCs. 

Larry Masinter <masinter@parc.xerox.com>; asked us about this
a while back:

bajan@bunyip.com (Alan Emtage) wrote in reply:

| > Does anyone want to conjecture the likely relationship between URCs
| > and IAFA templates?
| 
| It has been sort-of assumed that the data elements defined within IAFA
| would be used in URCs if in fact these kind of data element names were
| used. I don't think that we can say more than that. Certainly the syntax
| of the larger structures (templates) would be in appropriate since these
| things are in part expected to be constructed by humans and thus don't
| conform to the strictures required for a true protocol.

I myself replied:

) Overall it seem the IAFA templates are more descriptive and geared to
) users deciding about applicability (yellow-pages style), and URC's
) are more for automatic use in a lookup/resolution service for specific
) objects.
) 
) There are some parsing differences between IAFA and the current URC
) spec:
) - there seems to be no whitespace between field and value,
) - URI's are used in IAFA, URL's etc are used in URC's.
) - In URC's fields have precedence rules, and it seems that a "UR" line
)   must be followed by relevant extra fields. This is not so in
)   IAFA.
) 
) Other than that, I think the URC and IAFA records have similarites
) that can be taken advantage of by indexing software. Similarly, a URC
) service could analyse IAFA templates to create intial databases.
) 
) I suggest that when extra URC fields become required, equivalent IAFA
) ones are used.
) 
) IAFA cannot "include" URC's because of the parsing problems mentioned
) above. Of course individual data elements can be added.
) 
) The IAFA templates draft does not rely on non-RFC documents, and is
) rather static. The URC's are still very much in a research stage. I
) think it'd be a mistake to try and incorporate them ito the IAFA
) templates, but I expect future URC RFC's might eventually replace
) IAFA, either as spec, or simply by usage. Then again, maybe not.

I must admit though I'm behind on the URC's...

> Since we are beginning to move forward with the URC draft,

We are also getting very close to a new IAFA draft...

> would it be useful to discuss the templates in that light?  Perhaps
> set up a test environment which would produce some positive
> discussion and get us all moving forward?
>
> Any other suggestions for pooling these and trying to get
> everything to work together?  (What a conecpt!)

If both IAFA and URC's have similar data elements, and parseable
formats, then interworking should be easy :-)

-- Martijn
__________
Internet: m.koster@nexor.co.uk
X-400: C=GB; A= ; P=Nexor; O=Nexor; S=koster; I=M
X-500: c=GB@o=NEXOR Ltd@cn=Martijn Koster
Telephone: +44 115 9 520576
WWW: http://web.nexor.co.uk/mak/mak.html