Re: multipart objects - directories

Markus Stumpf <> Fri, 20 May 1994 00:34 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa14469; 19 May 94 20:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14465; 19 May 94 20:34 EDT
Received: from by CNRI.Reston.VA.US id aa22773; 19 May 94 20:34 EDT
Received: by (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29970 on Thu, 19 May 94 18:50:49 -0400
Received: from sifon.CC.McGill.CA by with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29962 (mail destined for /usr/lib/sendmail -odq -oi -fiafa-request iafa-out) on Thu, 19 May 94 18:50:27 -0400
Received: from ( []) by sifon.CC.McGill.CA (8.6.8/8.6.6) with SMTP id SAA00431 for <>; Thu, 19 May 1994 18:50:24 -0400
Received: from ([]) by with SMTP id <326476>; Fri, 20 May 1994 00:50:12 +0200
Received: by id <311418>; Fri, 20 May 1994 00:49:57 +0100
Subject: Re: multipart objects - directories
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Markus Stumpf <>
To: Alan Emtage <>
Date: Fri, 20 May 1994 01:49:54 +0200
In-Reply-To: <> from "Alan Emtage" at May 8, 94 02:28:48 am
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 5038
Message-Id: <>

I wrote:
|>>Some "Template-Type: SOFTWARE" e.g. comes in more than one part, like e.g.
|>>   some.gz.aa
|>>   some.gz.ab
|>>   [ ... ]
|>>How would you describe this with the methods given in the current draft?
|>>One template for each of the parts? This is kinda ugly and hard to maintain.
|>>But I couldn't find any provisions for such multipart objects.

Alain said:
|>Hmmm. I certainly don't think that there should be a template for each one 
|>of these things. That's going to be a nightmare to compse and maintain. In 
|>addition, the fact that someone may split something up (to get it through 
|>mail or USENET for example) has little or no bearing on this. How about we 
|>solve this problem with just putting a wildcard (say "*") at the end of the 
|>"Pathname" and so for the above you'd say Pathname: /<blah>/some.gz.* or 

Splitting up was just an example. How about having diff/patch files?
Then the '*' solution might become difficult. And it would become more
complicated to use the information on a remote site to e.g. construct
URLs as the directory information might not be available and URLs
don't allow wildcards.

|>>The other problem is with providing information about directories.
|>>Assume a directory named /pub/comp/security. The directory should contain
|>>security related information regarding the computer area.
|>>IMHO it would be useful to have a AFA-OBJECT called DIRECTORY to describe
|>>the contents of a directory.

|>That's a good idea... I suppose that this would be most related to the 
|>current "DOCUMENT" type? Would you like to suggest the the elements you'd 
|>like to see in there?

Fields relevant to directories:

        Template-Type:		See above list
        Title:                  Title of the object
        Admin-(USER*):    Description/contact information about the
                                administrators/maintainers of the object.
                                These fields may be repeated as often as
                                is necessary.

                                Contact information about person last
                                modifying this record

                                The date the last time this record was

                                Contact information of person or group
                                last verifying that this record was

                                The date the last time this record was

        Description:            Description (that is, "abstract" in the
                                case of documents) of the object.

        Copyright:              The copyright statement. Any additional
                                information on the copying policy may be

        Keywords:               Appropriate keywords for this object

        Access-Protocol-v*:     Method of access to this object (eg,
                                anonymous FTP, Gopher etc.) as well as
                                the host on which it resides. Also any
                                additional information needed to access
                                the object. 

        Access-Host-Name-v*:    Host on which to access the object

        Access-Host-Port-v*:    Port on which to access the object. This
                                may be implied by the Access-Protocol and
                                so not be necessary

        Pathname-v*:            The full pathname of this object. This is
                                operating system specific. This is not
                                required if naming scheme 2 is used

    Template-Type:		DIRECTORY
    Title:			some movies encoded in MPEG format
    Pathname-v0:		/pub/rec/movies/mpegs/
    Access-Method-v0:		Anonymous FTP

Although I did use the Pathname, Access-Method, Access-Host-Name
fields I am rather unhappy that there is no "URL-v*" field for
methods that are currently supported by the URI/URL drafts.
This would make handling such entries IMHO much easier.

|>list. A few people have written, mainly typos and formatting corrections 
|>rather than anything else. I guess that means that the document is perfect 

just had a quick look at "draft-ietf-iafa-publishing-01.txt" and most
of the typos and formatting problems I'd sent in are still there,
and none of the proposals I'd made are in :((

 Markus Stumpf                        Markus.Stumpf@Informatik.TU-Muenchen.DE