Re: Draft progression

[Martijn Koster <[e-mail]>]

Markus wrote:

> Martijn Koster <[e-mail]> 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
__________
Internet: [e-mail]
X-400: C=GB; A= ; P=Nexor; O=Nexor; S=koster; I=M
X-500: c=GB@o=NEXOR Ltd@cn=Martijn Koster
WWW: http://web.nexor.co.uk/mak/mak.html