home *** CD-ROM | disk | FTP | other *** search
/ ftp.cdrom.com/pub/cdrom/ / cdrom.tar / cdrom / rockridge / rrg.08 < prev    next >
Text File  |  1992-08-19  |  12KB  |  414 lines
  1. .br
  2. .pn 1
  3. .PH ""
  4. .fp 1 R
  5. .fp 2 I
  6. .fp 3 B
  7. .po 1i
  8. .ll 6.5i
  9. .hy 14
  10. .S 10
  11. .OF "''Page %'October 19, 1990'"
  12. .EF "'October 19, 1990'Page %''"
  13. .ds HF 3 3
  14. .ds HP 13 9
  15. .HM I 1
  16. .SP 1
  17. .br
  18. .S 17
  19. .B
  20. .ce 1
  21. Rock Ridge Group Goals Document
  22. .R
  23. .SP 1
  24. .S 11 14
  25. .H 1 "\ Purpose"
  26. .sp -.5
  27. This document has the following purposes:
  28. .AL a 9 1
  29. .LI
  30. establish and document common goals for group participants
  31. .LI
  32. define a charter for the technical working group
  33. .LI
  34. act as tool for gaining consensus within participating companies
  35. .LI
  36. act as tool for gaining consensus within non-participating companies;
  37. this document may serve as the first formal release from the group
  38. .LI
  39. communicate our group's intentions and interest with respect to the
  40. CD-WO ad hoc group and other groups
  41. .LE
  42. .H 1 "\ Executive Summary"
  43. .sp -.5
  44. The companies participating in the Rock Ridge Group CD-ROM initiative
  45. desire the ability to use a CD-ROM as a\fI complete\fP implementation
  46. of X/Open filesystem directories.  This would allow CD-ROM technology
  47. to be used for
  48. .sp -.5
  49. .ML + 5 1
  50. .LI
  51. software distribution in a heterogeneous environment
  52. .LI
  53. on-line access to CD-ROM executable, data and library files
  54. .LI
  55. database distribution in a heterogeneous environment
  56. .br
  57. without restrictions in a complete X/Open environment
  58. .LE
  59. .SP 1
  60. Today, there is no commonly agreed CD-ROM format for accomplishing these
  61. goals.  The purpose of the Rock Ridge initiative is to create and agree
  62. upon a common format that meets the needs presented above while maintaining
  63. compatibility with the installed base of ISO 9660:88 CD-ROM hardware and
  64. software.
  65. .sp .5
  66. The remainder of this document provides further information on the goals
  67. of the group.
  68. .H 1 "\ Desired Benefits from different viewpoints"
  69. .in 5.5
  70. Publisher
  71. .br
  72. .in 0
  73. .in 8
  74. Provide product distribution via 1 disc to all platforms--
  75. .br
  76. The publisher should not be required to tailor CD-ROM products to
  77. different delivery platforms (PC vs X/Open vs.\ OS/2 servers).
  78. .in 0
  79. .sp .5
  80. .in 5.5
  81. OS Vendor
  82. .in 0
  83. .br
  84. .in 8
  85. Minimize software investment; single initial investment and reduce
  86. ongoing investments.
  87. .br
  88. Allow one software solution which meets all X/Open needs.
  89. .br
  90. Provide full X/Open File information.
  91. .br
  92. Allow future extensions for security purposes.
  93. .br
  94. Discourage ad hoc file format solutions.
  95. .br
  96. Allow current software applications to run without modification
  97. using a CD-ROM.
  98. .br
  99. .in 0
  100. .in 5.5
  101. .bp
  102. Customers
  103. .in 0
  104. .br
  105. .in 8
  106. Allow 1 disc to be used for all types of platforms.
  107. .br
  108. Provide delivery of file data in a heterogeneous environment.
  109. .br
  110. Provide access to all of a disc's data via ISO 9660:88 file data.
  111. .br
  112. Optimize performance for operations involving X/Open extensions.
  113. .in 0
  114. .sp .5
  115. .H 1 "\ \ Motivations for solving the problem co-operatively, not individually"
  116. .br
  117. .in 1.5
  118. Single vendor solutions are no longer a viable strategy in today's business
  119. climate.
  120. .sp .5
  121. Third party X/Open software vendors (ISV's) want to minimize
  122. the business risk of moving to CD-ROM as a new distribution format.
  123. They want a single solution for the open systems market, not multiple
  124. solutions or sub-solutions.
  125. .sp .5
  126. Facilitate ISV expansion to support X/Open systems current DOS and
  127. Macintosh CD-ROM publishers.
  128. .sp .5
  129. Provide the basis for creating an international standard.
  130. .in 0
  131. .H 1 "\ \ \ Definition of terms"
  132. .in 4.5
  133. \'file data\', \'file information\', \'information\' - the data contained within a 
  134. file.
  135. .br
  136. \'file attributes\' - the name of the file, dates associated with the data,
  137. permission modes, etc.
  138. .in 0
  139. .H 1 "\ \ Goals"
  140. .AL 1 13 1
  141. .LI
  142. Information interchange
  143. .br
  144. .in +2.4
  145. Maintain the ISO 9660:88 information interchange capability between all
  146. ISO 9660:88 and Rock Ridge systems.
  147. .in 0
  148. .sp .5
  149. .LI
  150. File attribute interchange
  151. .br
  152. .in +2.4
  153. Allow interchange of file attribute information amoung X/Open class systems.
  154. The following file attributes should be supported as defined by
  155. X/Open: UID, GID, mode bits, major and minor device, UID, and GID numbers
  156. by receiving systems shall be provided.
  157. .in 0
  158. .sp .5
  159. .LI
  160. Complete
  161. .br
  162. .in +2.4
  163. The format standard should meet the needs of distribution X/Open file data
  164. and file attribute information.  No additional or optional tagged fields
  165. shall be required to deliver file information required for complete X/Open
  166. systems.
  167. .in 0
  168. .sp .5
  169. .LI
  170. Execution
  171. .br
  172. .in +2.4
  173. The format shall allow direct execution of software from the CD-ROM in a
  174. heterogeneous environment.
  175. .in 0
  176. .sp .5
  177. .LI
  178. Full backwards compatibility
  179. .br
  180. .in +2.4
  181. All file data on discs conforming to these extensions must be accessible on
  182. current Microsoft CD-ROM extensions version 2.1 and other current
  183. ISO-9660:88/level 1 interchange drivers.
  184. .sp .5
  185. .bp
  186. Discs conforming to this specification must meet the requirements of the
  187. proposed XCDR API [Philips]. (Assuming adoption of XCDR by X/Open.)
  188. .in 0
  189. .sp .5
  190. .LI
  191. File names
  192. .br
  193. .in +2.4
  194. Extremely long name lengths shall be possible.  Name lengths as long as
  195. possible shall be handled in an optimal manner.
  196. .sp .5
  197. \`Reader makes right\' interchange: it is the responsibility of the
  198. receiving system to modify names as needed.
  199. .sp .5
  200. Support of ISO 8859/1:87 character set for file names and allow for
  201. support of future character set standards.
  202. .in 0
  203. .sp .5
  204. .LI
  205. Path names
  206. .br
  207. .in +2.4
  208. Extremely long path names shall be possible.
  209. A system independent method for defining pathname components shall
  210. be provided.  There shall not be any limitations on directory depth.
  211. .in 0
  212. .sp .5
  213. .LI
  214. Application Programming Interfaces
  215. .br
  216. .in +2.4
  217. No impact on X/Open system APIs including XCDR.  If necessary, an
  218. additional API will be proposed.
  219. .in 0
  220. .sp .5
  221. .LI
  222. Service Interfaces
  223. .br
  224. .in +2.4
  225. Same as the following sections in XPG 3 v2 [88].
  226. .br
  227. 2.1.19 Directory
  228. .br
  229. 2.1.20 Directory Entry including symbolic links
  230. .br
  231. 2.1.26 Empty Directory
  232. .br
  233. 2.1.32 File
  234. .br
  235. 2.1.33 File Access Permissions
  236. .br
  237. 2.1.37 File Hierarchy
  238. .br
  239. 2.1.38 File Mode
  240. .br
  241. 2.1.39 Filename except, allow lomger names. See VI.6.
  242. .br
  243. 2.1.43 File Permission Bits
  244. .br
  245. 2.1.46 File Times Update as defined for read-only filesystems
  246. .br
  247. 2.1.71 Portable Filename Character Set-- use XPG 3 specified ISO 8859/1
  248. character set except no reserved characters
  249. .in 0
  250. .sp .5
  251. .LI 
  252. Performance
  253. .br
  254. .in +2.4
  255. The format shall be optimized for on-line access to a disc's executable,
  256. data and library files.  In addition, the format shall optimize for
  257. directory information access.
  258. .in 0
  259. .LE
  260. .bp
  261. .H 1 "\ \ Non-Goal"
  262. .sp -.5
  263. .in 4.5
  264. Common Application data format.  We do not seek to define a common data
  265. format.  For example, requiring ASN.1 descriptions of file data.  Binary
  266. executable formats are also outside the scope of the Rock Ridge Group.
  267. .in 0
  268.  
  269. Reference
  270. .TS
  271. expand;
  272. l lw(5.3i).
  273. [Philips]    T{
  274. .ad b
  275. X/Open CD-ROM Support Component (XCDR). Version 2, June 1990.
  276. This document is available from Hans de Jong, Philips Information
  277. Systems.  Telephone +31 55 43 27 74.
  278. T}
  279. .TE
  280. Appendix
  281.  
  282. The appendix contains additional information that may be of interest
  283. to the reader.
  284.  
  285. Discussion of information interchange goal.  Reference: VI.1.
  286. .br
  287. We define two types of information interchange between platforms.
  288. .br
  289. .in 4.5
  290. Alternative 1 - Common file system format and all file data can be read
  291. by all platforms.
  292. .br
  293. Alternative 2 - Common file system format and all file data can be read
  294. by some platforms.
  295.  
  296. Alternative 1: This type of interchange maintains the original ISO 9660:88
  297. concept of \"...[enabling] information to be interchanged between
  298. different systems...\" [Section 1, ISO 9660:88].
  299.  
  300. This type of data interchange assures the accessibility of files in a
  301. heterogeneous work group environment.  Any type of platform connected
  302. to a common LAN would be able to access all of the information on a
  303. disc, no matter the type of disc server.
  304.  
  305. This type of data interchange encourages the creation of \"open\"
  306. applications whose data is available to all users.
  307.  
  308. Counter argument: some architects feel that it would be desirable for
  309. the file labeled \`start\' to refer to different file information
  310. dependent on the machine type or architecture.  The user would only
  311. have to invoke \`start\' no matter his or her machine type.
  312.  
  313. But this would make information inaccessible in many circumstance.
  314. In addition, the same effect can be gained within the X/Open market
  315. by writing a single \`shell script\' which used the uname(1) command to
  316. execute the correct binary file.
  317.  
  318. It may be difficult or impossible for a common shell script to probe
  319. for and correctly handle the needs of X/Open, DOS, and other types of
  320. systems.
  321. .bp
  322. Alternative 2:  This type of interchange would allow the CD-ROM to
  323. contain files which are available to soem but not all types of receiving
  324. platforms.  For example, in a network environment, an X/Open platform
  325. which acted as a server might not be able to export DOS files on a
  326. CD-ROM disc to the networked DOC PC's since the files would be
  327. invisible to the X/Open platform.
  328. .in 0
  329.  
  330. Discussion of File attribute interchange goal.  Reference: VI.2.
  331. .br
  332. .in 2
  333. UID and GID mapping between values stored on the disc and values used by
  334. a particular X/Open system are defined by the XCDR proposal.  Per section
  335. VI.5, XCDR's mechanisms shall be used whenever possible.
  336. .in 0
  337.  
  338. Discussion of Execution goal.  Reference: VI.4.
  339. .br
  340. .in 2
  341. Execution of software directly from a CD-ROM disc without first copying
  342. the software to magnetic disc is desirable for several reasons:
  343.  
  344. Ease of use: no installation of the software onto magnetic disc means that
  345. the use can \"load and go\" his or her software.  By providing a complete
  346. By providing a complete runtime environment on the CD-ROM, a publisher can
  347. reduce the complexity of installations.  This application would not have
  348. to be adapted to a specific system's file layout.
  349.  
  350. Ease of documentation: A CD-ROM can contain many software packages which
  351. are frequently used or which are meant as demonstration/trial applications.
  352. Direct execution allows the user to demonstrate or use low-usage applications
  353. without having to load then unload an application each time it is used.
  354. .in 0
  355.  
  356. .in 4
  357. No consumption of magnetic disc resources: often, magnetic disc resources 
  358. are highly constrained on an operational system.  Direct execution from the
  359. CD-ROM means that magnetic disc space does not need to be planned,
  360. allocated or consumed before using software.
  361. .in 0
  362.  
  363. Discussion of Backwards compatibility goal.  Reference: VI.5.
  364. .br
  365. .in 2
  366. Backwards compatibility with current ISO 9660:88 hardware and software
  367. is required for the following reasons:
  368. .in 0
  369. .br
  370. .in 4
  371. It is unrealistic to expect that the embedded base of current CD-ROM
  372. drives will be updated to take advantage of a new CD-ROM format
  373. specification.  Discs produced using this specification must be readable
  374. by the installed base or publishers will not make use of it.
  375.  
  376. Maintaining compatibility will reduce ISV concerns about migrating to 
  377. use a new disc format.
  378.  
  379. Publishers wish to leverage their ISO 9660:88 experience and expertise.
  380. .br
  381. .in 0
  382. .bp
  383. Discussion of File name goal.  Reference: VI.6.
  384. .br
  385. .in 2
  386. Character and byte counts may be different when a multibyte character set
  387. is used.
  388. In particular, the \`space\' and \`solidus\' (/) characters may be used
  389. without restriction in file names.  Also, any number (including none)
  390. \`full stop\' (.) characters may be used.
  391. .br
  392. Character names are from ISO 8859/1:87.
  393. .in 0
  394.  
  395. Discussion of Path names goal.  Reference: VI.7.
  396. .br
  397. .in 2
  398. Path names shall not be stored as a single character string that 
  399. reserves some character such as \`solidus\' (/) as a separator.
  400. Directory depths for X/Open systems are often very deep.  For example,
  401. the widely used X11 window system from MIT includes directories that
  402. are 11 steps deep.
  403. .in 0
  404.  
  405. Discussion of Performance goal.  Reference: VI.10.
  406. .br
  407. .in 2
  408. Directory information access should be optimized by physically
  409. placing all directory informaton in one area.  Directory
  410. information (file dates, etc) should not only be physically near
  411. near the file information.
  412. .in 0
  413. .br
  414.