Re: Draft progression

Markus Stumpf <stumpf@informatik.tu-muenchen.de> Sun, 28 August 1994 21:34 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03206; 28 Aug 94 17:34 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03202; 28 Aug 94 17:34 EDT
Received: from mocha.Bunyip.Com by CNRI.Reston.VA.US id aa10392; 28 Aug 94 17:34 EDT
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16263 on Sun, 28 Aug 94 17:12:16 -0400
Received: from sifon.CC.McGill.CA by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16255 (mail destined for /usr/lib/sendmail -odq -oi -fiafa-request iafa-out) on Sun, 28 Aug 94 17:12:06 -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 RAA06147 for <iafa@cc.mcgill.ca>; Sun, 28 Aug 1994 17:12:03 -0400
Received: from unknown ([131.159.0.176]) by tuminfo2.informatik.tu-muenchen.de with SMTP id <326563>; Sun, 28 Aug 1994 23:11:52 +0200
Received: by hpsystem1.informatik.tu-muenchen.de id <231647>; Sun, 28 Aug 1994 23:11:10 +0200
To: iafa@cc.mcgill.ca
Path: stumpf
X-Orig-Sender: USENET Newssystem <news@hpsystem1.informatik.tu-muenchen.de>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Markus Stumpf <stumpf@informatik.tu-muenchen.de>
Newsgroups: lists.iafa
Subject: Re: Draft progression
Date: Sun, 28 Aug 1994 23:10:58 +0200
Organization: Technische Universitaet Muenchen, Germany
Lines: 92
Message-Id: <33quh2$i82@hpsystem1.informatik.tu-muenchen.de>
References: <33kiie$m4r@hpsystem1.informatik.tu-muenchen.de>
Nntp-Posting-Host: hphalle0.informatik.tu-muenchen.de
Cc: m.koster@nexor.co.uk, bajan@bunyip.com, maex@leo.org
X-Newsreader: NN version 6.5.0 #5 (NOV)

Martijn Koster <m.koster@nexor.co.uk>; writes:

>> > We are now at about 6200 template files with various draft levels :/
>> > We will have to convert them all, too :/
>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 :))

>Alan Emtage writes:
>> Done. I have removed Access-Host-Name, Access-Host-Port and
>> Access-Method, Host-Name and Host-Port as well as Protocol. They are now
>> all under URI (which is variant). Location has been modified to be
>> Source-URI and Destination-URI and are variant.

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)

>Alan Emtage writes:
>> I have made some changes in the Email conventions as well. They are now
>> to be specified as a Email URL, which is the same as a standard email
>> 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.

[ on 3.8.4 and allowed types ]
>> However, we should make sure that we've covered all the bases here
>> and that we haven't left any major object type out.
>Difficult, but yes. You mentioned mailing lists, don't they fall under 
>SERVICE? It needs Regstration etc.

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.

>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.

>In 3.4 scheme 2 disallows multiple records. Is that really required?
>I can imagine needing one 'widgets' file in my widgets directory,
>with records for related mailing lists, services, documents, and
>people.

I vote for removing this restriction, too.

>Do we want to make whitespace after the colon after a field name
>optional? I suggest yes.

Agreed ;)

>Re Short-Title, I suggest taking them out of the cluster, and add them
>to any relevant templates (only DOCUMENT?).

Agreed ;)

>I think 3.7.2 needs Host-Name as well as Host-Alias...

Agreed ;)


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, ...

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