From: peter@ferranti.com (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: Your chance to contribute to new POSIX archive format
Date: 27 Jul 1992 22:15:09 -0700
Organization: Xenix Support, FICC
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: peter@ferranti.com (Peter da Silva)

I'm not familiar with the ISO1001 format, but I would like to suggest a textual
self-documenting format, like RFC822. You don't need to put the actual field
names in every file header if you establish a property file at the beginning of
the archive. For example:

	FieldCodeset: ASCII
	FieldSeparator: <0A>

[ these two would be required for the initial header, and need to be in an
  agreed on language. ]

	HeaderLength: 96
	BodyLength: 0
	Common: HeaderLength,BodyLength,FileName,ModificationTime,Owner

[ This establishes the common fields until the next Common field ]

	2746
	13995
	usr/local/src/pax/Makefile
	19920723.194516.0001
	peter

[ These are the header length, body length, filename, etcetera for the first
  file ]

	FileComment: Remember to edit this for local architecture[...]

[ This is a part of the file system on the originating system. Would probably
  end up in usr/local/src/pax/.Unresolved/Makefile on UNIX ]

	#!/bin/make
	[...]

This should require a minimal amount of additional space, and would be
indefinitely extensible. Older versions of the archive program could
discard unknown headers, or stick them in a file somewhere for later
messing around with. It should also be relatively easy to treat as a fixed
record length format.

> 	- Support for >32 bit systems

Inherent.

> 	- Be extensible, to allow for future support of security information,
> 	  contiguous files, system management information, special files,
> 	  larger field sizes for dates, times, file lengths, etc.

Inherent.

> 	- Support portability of file, user, group names and other
> 	  file information across machines of differing codesets and/or
> 	  locales (i.e. it should work on ASCII, EBCDIC, ISO 10646 and
> 	  Shift-JIS systems alike).

With the caveat that a standard character set be used for the first two fields.

> 	- The archive must be able to be stored on as many media types
> 	  as possible, including but not limited to 9-track and streaming 
> 	  tape, diskette, CDROM, ftp files, etc.

Inherent.

> 		- Encryption of individual files in the archive

Simple extension: new file header.

> 		- Compression of individual files in the archive

Ditto.

> 		- Translation of file contents between differing
> 		  codesets (i.e. format only needs to handle translation
> 		  of file *names*, etc)

Ditto. ( add Body-Type )

> 		- Storage of filesystem specific information (such as inodes)

Ditto.

> 		- Direct mailability of the archive file (without translation,
> 		  such as through uuencode)

Probably ditto, assuming no magic in the bodies or lines that are too long
for mail.

This is obviously not a complete proposal. I would appreciate feedback and
suggestions, and if they seem positive I'll go ahead and write a real proposal
up. The intellectual property status and usage of RFC822 is presumably not
going to be a problem.

-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180


Volume-Number: Volume 28, Number 64