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/
- Re: Draft progression Alan Emtage
- Re: Draft progression Alan Emtage
- Re: Draft progression Markus Stumpf
- Re: Draft progression Alan Emtage
- Re: Draft progression Martijn Koster
- Re: Draft progression Markus Stumpf
- Re: Draft progression Martijn Koster
- Re: Draft progression Alan Emtage
- Re: Draft progression Markus Stumpf