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