X3T9.2/87-166 Revision 1 LASER MAGNETIC STORAGE MEMO INTERNATIONAL COMPANY ______________________________________________________________________________ Optical Storage Division 12 October 1987 To: SCSI Standards Committee X3T9.2 Jeff Stai, Optical Sections Editor From: Paul Boulay (303) 593-4323 Subject: Comments on Optical Sections of SCSI-2 Ref: X3T9.2/87-146 Revision 1. Revision 1 Note: This revised version is based on the comments received from Jeff Stai on revision 0. The things that he deemed purely editorial are mentioned but without the supporting arguments. This exchange took place via the SCSI Bulletin Board. Overall, the referenced document represents a considerable improvement in the state of chapters 12, 13 and 15 of the draft SCSI-2 standard. This note suggests a few minor changes and poses some questions of the editor and the committee as a whole. 1.) Making use of the generic Direct Access descriptions is an acceptable idea in order to ensure consistency. I wonder if the definition of the BLANK CHECK error -- especially the previously unwritten block part -- would be objectionable to the representatives of the magnetic disk firms. I suggest that we at least add a note to the chapter 8 item to say that this Sense Key is only for Optical devices. Otherwise, I think we invite incompatibility within the magnetic media world. (Mag disks create Media Error in similar situations.) (I'd be willing to back the caveat out if a magnetic disk firm comes up with a good value-added definition of BLANK CHECK and asks for it.) 2.) Mandatory Commands for WORM and RO devices (sections 12 and 13). I believe that these commands should be required in all SCSI-2 Optical Devices: Inquiry 12h Read 28h Read Capacity 25h Release 17h (Unit and 3rd Party only) Request Sense 03h Reserve 16h (Unit and 3rd Party only) Send Diagnostic 1Dh (Self Test only) Test Unit Ready 00h Write 2Ah (but not for RO devices) Without these commands sections 12 and 13 are a throwback to SCSI-1. One of the initial reasons for creating the SCSI-2 effort was to formalize the CCS principles and apply then across the board. 3.) If there is to be a separate section in the SCSI-2 document for CD-ROM, is there any need for the RO device type? 4.) In the rewrite of the Media Scan command the statement that the implementation of Reverse Scan Direction is optional has been dropped. Why? This feature may be very cumbersome to implement in some devices or may result in unreasonable delays. There is ample precedent for stating in the standard that implementation of command features is optional - for instance, extent reservations. I believe that the statement that allows for optional implementation of this bit should be retained. (The same argument applies to the ASA bit but since that is defined as advisory the implementation of a binary search or other advanced algorithm can be interpreted as optional.) (Jeff's comments on this indicate that this is an across-the-board problem and cites optional features of optional commands that are not stated as such and are generally understood to be optional. I think that we need to identify all the discrete optional features in the spec and define a way - implemented options page? - for the host to discover those present. This is a lot of work.) 5.) In the last paragraph of the Media Scan command, the description of the Number of Blocks to Scan field, a "may" was changed to "shall". I think "may" is appropriate unless "... or until the Media Scan criteria is satisfied" is added. (Jeff agreed to research this matter.) 6.) In the Mode Select description of enable blank check (EBC) of zero, delete "or an UPDATE BLOCK command" and add a new sentence: "An UPDATE BLOCK command shall not result a CHECK CONDITION with a BLANK CHECK Sense Key due to block(s) not being previously written." There may be a better way to say this without the double negative. 7.) The definition of Read Updated Block (1st paragraph) seems to preclude transfer of generation zero data. How about: "The READ UPDATED BLOCK command requests that the target transfer data for specified generations of a logical block(s) to the initiator." The order in which the several generations of data for a single block is returned is not clear from the 15.1.8.1 description. The problem, for me, stems from the two definitions of "increasing generation addresses" as given by the "Latest" bit. For the Single Generation Data option (15.1.8.2), what is the desired response if, for some block, the requested generation does not exist? Is this a BLANK CHECK ?? For the Maximum Generation Data Block option (15.1.8.3) is the transfer length field an allocation length? In this mode the generation address field is -- Ignored? Reserved? (Jeff agreed to wordsmith the section further to make these points less ambiguous.) 8.) In the Update Block command, the new text at the end of the first page, "This standard does not define ...", if EBC is one the required result is defined as a BLANK CHECK. Isn't it? IF EBC is zero, the statement is probably true due to the several ways to implement the Update Block. In response to the editors question about the rationale for the Recovered Error indication on reading an updated block. This came out of the Optical working group meeting in Colorado Springs about 9 months ago. For WORM devices, there's an implicit guarantee of unalterability. The Update Block invalidates this assertion without a mandatory reporting of transfer of modified data. (The Recovered Error return could be limited to WORM devices except that some WORM type devices may choose to use the Optical Devices command set and peripheral device type. The Recovered Error requirement could be tied to the media type reported by an Optical Devices implementation.) 9.) In the Verify and Write and Verify commands, I'd suggest that the verification criteria given as the same criteria as for a Read when no explicit Verify parameters are received. (I have been informed that the working group meeting in Minneapolis decided that vendor unique was necessary in this case for magnetic media. I agree that the Optical should use the same words.)