Re: Draft progression

Martijn Koster <> Tue, 30 August 1994 09:33 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa00861; 30 Aug 94 5:33 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00857; 30 Aug 94 5:33 EDT
Received: from mocha.Bunyip.Com by CNRI.Reston.VA.US id aa02069; 30 Aug 94 5:33 EDT
Received: by (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07927 on Tue, 30 Aug 94 04:35:21 -0400
Received: from sifon.CC.McGill.CA by with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07916 (mail destined for /usr/lib/sendmail -odq -oi -fiafa-request iafa-out) on Tue, 30 Aug 94 04:34:51 -0400
Received: from ( []) by sifon.CC.McGill.CA (8.6.8/8.6.6) with ESMTP id EAA25747 for <>; Tue, 30 Aug 1994 04:34:44 -0400
Message-Id: <199408300834.EAA25747@sifon.CC.McGill.CA>
Received: from (actually host by with SMTP (PP); Tue, 30 Aug 1994 09:34:21 +0100
To: Markus Stumpf <>
Subject: Re: Draft progression
In-Reply-To: Your message of "Sun, 28 Aug 1994 23:10:58 +0200." <33quh2$>
Date: Tue, 30 Aug 1994 09:34:12 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Martijn Koster <>

Markus wrote:

> Martijn Koster <> writes:
> >Markus, if you need a script to do that one one file system let me know...
> Okay, I'll contact you as soon as the draft is nailed down :))

I'm going to regret this, I can feel it ;-)
> Hmmm... I think using the Access-* fields should still be an option.
> This would allow for specifying services that don't have a method
> registered with the URL yet. (Like IMAP for the moment; but one could
> already have e.g. a mailarchive accessible via IMAP)

Agreed, but it should explicitly mentioning that it is only a fallback
option where a URL isn't available.
> >> address prefixed by "mailto:". 
> I am a bit unhappy about that, too. But I like it on the other side ;/
> Maybe we could make the use of a URI and thus the mailto: optional?
> Shouldn't be hard for the parser to check for a leading mailto: and
> it won't break the currently existing entries.

Could do, but it seems confusing.
> Yup, mailing lists are a SERVICE.
> But I have mentioned a type DIRECTORY to describe the contents of a
> directory in global. One could use LARCHIVE, but I think that would
> be a bit too much.
> A user asked we, whether he could use a type of FONT for describing
> publically available fonts, which become more and more available with Macs
> and Amigas and have always been there in e.g. TeX archives. This probably
> requires an additional field for the type of the font ("times roman bold 12")
> .
> However I don't know too much about fonts and typesetting and my english
> isn't so good that I would dare to suggest a field name ... maybe it could
> go to Description anyway.

Hmmm... it seems useful. But I would like to not to go too far for
this version of the draft -- otherwise we'll never finalise it. A FONT
is a kind of SOFTWARE, I can imagine some people would like types for
EDITTOR, OPERATINGSYSTEM, DEVICEDRIVER etc. We need to stop somewhere,
and a FONT seems just outised the high-level, internet service
oriented types.

> >Do we need 'the companion document "Data Element Templates for
> >Internet Information Objects" [8]'?
> I like the idea to have a document where all the templates are
> listed with all allowed fields. This would help new supporters
> to start, as they'd only have to take the template, fill in the
> fields and voila. It would also be useful for writing simple interactive
> scripts for generating forms.

I plan to do both, the question was if it should be
 a) as an appendix in the document (very big)
 b) as a separate informational RFC (which need not stop finalising this one)
 c) not in the standard, but in a publicly available file

I'd say c) for starters, and then b) if the RFC edittor will have it.

> An idea I had today:
> How about adding a field  "Template-Encoding:"  to all templates?
> The value could be in MIME format. All I found on the encoding used
> for the index files is section 3, 4th paragraph, and that is rather
> vague. I like the idea to have e.g. the Description in text/html format.
> However the predefined encoding should be text/plain.
> The encoding information should of course be restricted to the use
> with "text" entries like Description, Title, Copyright, ...

I know people often want this, but it sounds like a big complication
to me: not all systems can handle all encodings, you might want
different encodings for different attributes in the same record; this
can get real messy. I think the main strength of the IAFA templates is
its simplicity, I wouldn't like to see that copmpromised.

-- Martijn
X-400: C=GB; A= ; P=Nexor; O=Nexor; S=koster; I=M
X-500: c=GB@o=NEXOR Ltd@cn=Martijn Koster