home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.28 / text0057.txt < prev    next >
Encoding:
Text File  |  1992-08-17  |  5.7 KB  |  166 lines
  1. Submitted-by: david@mks.com (David Rowley)
  2.  
  3. Here is your chance to enlighten and improve the world.  Help us to
  4. create and standardize the best archive format in the known universe,
  5. and maybe even get your name in a future IEEE Standard.
  6.  
  7. The IEEE POSIX.2 working group is currently undertaking an effort to
  8. create a new PAX archive format to support the additional file
  9. information that historical utilities such as tar and cpio cannot
  10. represent.
  11.  
  12. We intend to make this a 3rd archive format for the PAX utility, which
  13. currently provides an interface to the tar and cpio formats.
  14.  
  15. The group is working with ISO 1001 as a starting point, trying to retain
  16. full compatibility with that format, while extending it as required.
  17. ISO 1001 is a tape-based record-oriented format, historically used by
  18. large systems to store data on 9-track tape.  It is an ASCII,
  19. 80-character per record based format, allowing data portions to be
  20. arbitrary data, and of arbitrary length.  The compatibility with older
  21. environments, the fact that it is a well-recognized format that many
  22. installations and engineers have familiarity with along with the
  23. format's extensibility were the reasons for the group initially choosing
  24. this format.
  25.  
  26. While some work has been done on this format, the group is by no means
  27. unanimously sold on the suitability of ISO 1001 format.  It is large,
  28. contains wasted space due to the fixed-length header and volume records,
  29. discusses media-specific notions such as tape marks (although these are
  30. not used in the proposed PAX format), and has been around since the
  31. early fixed-length record-based days of computing.
  32.  
  33. In order to make sure we are not overlooking something better, we are
  34. soliciting alternate proposals for this archive format.  The following
  35. requirements should be addressed:
  36.  
  37.     - Support for >32 bit systems
  38.  
  39.     - Be extensible, to allow for future support of security information,
  40.       contiguous files, system management information, special files,
  41.       larger field sizes for dates, times, file lengths, etc.
  42.  
  43.     - Support portability of file, user, group names and other
  44.       file information across machines of differing codesets and/or
  45.       locales (i.e. it should work on ASCII, EBCDIC, ISO 10646 and
  46.       Shift-JIS systems alike).
  47.  
  48.     - The archive must be able to be stored on as many media types
  49.       as possible, including but not limited to 9-track and streaming 
  50.       tape, diskette, CDROM, ftp files, etc.
  51.  
  52. Non-Goals:
  53.  
  54.     The following are *not* goals of this format, but requests to
  55.     increase the scope of this effort will be entertained to include
  56.     items of interest.
  57.  
  58.         - Encryption of individual files in the archive
  59.  
  60.         - Compression of individual files in the archive
  61.  
  62.         - Translation of file contents between differing
  63.           codesets (i.e. format only needs to handle translation
  64.           of file *names*, etc)
  65.  
  66.         - Storage of filesystem specific information (such as inodes)
  67.  
  68.         - Direct mailability of the archive file (without translation,
  69.           such as through uuencode)
  70.  
  71. NOTE:  PLEASE READ THE FOLLOWING REQUIREMENTS FROM THE   I  E  E  E
  72.  
  73.     In order for the working group to consider a proposal, IEEE must
  74.     have full rights to freely copy, reproduce and otherwise make use
  75.     of, the written and intellectual contents of the proposal.  IEEE
  76.     must then, if the proposal is adopted, be able to copyright the
  77.     work as part of an approved standard.  So, if you want to retain
  78.     *any* exclusive rights to the format, don't submit it!
  79.  
  80.     While we would like to see as many proposals as possible, the
  81.     IEEE and the POSIX.2 working group make no commitments to
  82.     support any or all of the proposals offered.
  83.  
  84.     (This legalese courtesy of an overly litigious society)
  85.  
  86. Format of Proposals:
  87.  
  88.     Please include the following in your proposal:
  89.  
  90.         - Your name and contact information (e-mail if possible)
  91.  
  92.         - The intellectual property status of the proposal and
  93.           the format described in the proposal
  94.  
  95.         - Technical information on the format, including
  96.           definition of terms, data formats, etc.
  97.  
  98.         - A description of how the proposed format could be
  99.           extended to handle new, and as yet unknown, file
  100.           types, etc.
  101.  
  102.         - Comments on experience with the format, including
  103.           strong points, weaknesses, etc.
  104.  
  105.         - A brief description of the history of the format and
  106.           current users.
  107.  
  108.         - Any known comparison between the suitability of the
  109.           proposed format and ISO 1001
  110.  
  111. While comments on the suitability of the ISO 1001 format will be
  112. welcomed, we would much prefer constructive proposals of alternate
  113. formats.
  114.  
  115. Timeframe:
  116.  
  117.     While the process of standardizing the format will take a fair
  118.     bit of time (likely finished by Fall '93, early '94), the sooner
  119.     the proposal is received, the sooner it will sway the collective
  120.     opinion of the working group.   So hurry, send now, send often.
  121.     All proposals received in time for the October POSIX meeting
  122.     (see below) will be considered at that meeting.
  123.  
  124. Please send all comments, questions and of course, proposals, to 
  125.  
  126.         David Rowley
  127.         MKS, Inc.
  128.         35 King St. North
  129.         Waterloo, Ontario
  130.         CANADA
  131.         N2P 2W9 
  132.         david@mks.com
  133.         Tel: 519 884-2251
  134.         Fax: 519 884-8861
  135. or
  136.         Mark Brown
  137.         IBM
  138.         11400 Burnet Rd.
  139.         Austin, Texas 78758
  140.         Mailstop: 9582
  141.         mbrown@testsys.austin.ibm.com
  142.         Tel: 512 838-3926
  143.  
  144. Other/additional ways of participating:
  145.  
  146.     Join the POSIX.2 Working Group!  Come out to POSIX meetings and
  147.     contribute your insight and knowledge.  The next meeting will
  148.     be held in Utrecht, The Netherlands on October 19-23.  POSIX.2
  149.     will be meeting on October 22nd and 23rd.  (Most POSIX meetings
  150.     are held in the US).  For more information, please contact:
  151.  
  152.         Secretary
  153.         IEEE Standards Board
  154.         445 Joes Lane, PO Box 1331
  155.         Piscataway, NJ
  156.         08855-1331
  157.  
  158. -- 
  159. David Rowley
  160. Mortice Kern Systems Inc.
  161. 35 King Street North, Waterloo, ON, Canada N2J 2W9
  162. 519/884-2251, FAX 519/884-8861, david@mks.com
  163.  
  164. Volume-Number: Volume 28, Number 59
  165.  
  166.