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