Re: multipart objects - directories

Markus Stumpf <stumpf@informatik.tu-muenchen.de> Fri, 20 May 1994 00:34 UTC

Received: from ietf.nri.reston.va.us 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 mocha.bunyip.com by CNRI.Reston.VA.US id aa22773; 19 May 94 20:34 EDT
Received: by mocha.bunyip.com (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 mocha.bunyip.com 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 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 SAA00431 for <iafa@cc.mcgill.ca>; Thu, 19 May 1994 18:50:24 -0400
Received: from hprbg5.informatik.tu-muenchen.de ([131.159.0.200]) by tuminfo2.informatik.tu-muenchen.de with SMTP id <326476>; Fri, 20 May 1994 00:50:12 +0200
Received: by hprbg5.informatik.tu-muenchen.de 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 <stumpf@informatik.tu-muenchen.de>
To: Alan Emtage <bajan@bunyip.com>
Date: Fri, 20 May 1994 01:49:54 +0200
Cc: iafa@cc.mcgill.ca
In-Reply-To: <9405080028.AA06313@mocha.bunyip.com> 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: <94May20.004957mesz.311418@hprbg5.informatik.tu-muenchen.de>

I wrote:
|>>Some "Template-Type: SOFTWARE" e.g. comes in more than one part, like e.g.
|>>   some.gz.aa
|>>   some.gz.ab
|>>   some.gz.ac
|>>   [ ... ]
|>>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 
|>/<blah>/some.gz.a[a-c]. 

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.

        Record-Last-Modified-(USER*):
                                Contact information about person last
                                modifying this record


        Record-Last-Modified-Date:
                                The date the last time this record was
                                modified

        Record-Last-Verified-(USER*):
                                Contact information of person or group
                                last verifying that this record was
                                accurate

        Record-Last-Verified-Date:
                                The date the last time this record was
                                verified

        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
                                included

        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
    Admin-Handle:		http://some.host/~user/
    Pathname-v0:		/pub/rec/movies/mpegs/
    Access-Method-v0:		Anonymous FTP
    Access-Host-Name-v0:	cinema.virtuale.org


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 
|>:-)

*grmbl*
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 :((

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