document X3T9.2/90-003 R2 TO: X3T9.2 Committee (SCSI) FROM: Gerry Houlder (Seagate) SUBJECT: SCSI-1 and CCS Implementation on SCSI-2 Target While trying to decide what SCSI-2 features had to be deleted from a SCSI-2 target when its "operating definition" is changed to SCSI-1, I realized that the SCSI-1 wording "A reserved bit, byte, or field shall be set to zero or in accordance with a future extension to this standard" allows any SCSI-2 feature to legally be present in a SCSI-1 implementation. We need to choose "de facto" definitions of CCS and SCSI-1. The following table attempts to list the features that may cause compatibility problems and proposes which operating definitions (SCSI-1, CCS, SCSI-2) the feature is allowed (Y) or not allowed (N) to be implemented in. If such a list can be agreed upon by the committee, perhaps it can be included in the SCSI-2 standard in an appendix or an implementors note in the CHANGE DEFINITION command. Rev. 1: The table has been reduced to only those features which have to change to avoid compatibility problems, per discussions at Jan. 9-10 Working Group Meeting. FEATURE SCSI1 CCS SCSI2 Single Bit Selection Y Y Y# Selection without ATN Y Y Y# Target initiated SDTR, WDTR messages N N Y Asynchronous Event Notification N N Y EXTENDED CONTINGENT ALLEGIANCE Condition N N Y INQUIRY Command - EVPD bit (VITAL PRODUCT DATA) N N Y - VPD PAGE CODE N N Y - Feature supported bits: N N Y AENC, TRMIOP, RELADR, WBUS32, WBUS16, SYNC, LINKED, CMDQUE, SFTRES - ANSI VERSION Field 1 1 2 - RESPONSE DATA FORMAT Field 0 1 2 REQUEST SENSE Command - Return 4 bytes if LENGTH = 0 Y Y N - Return 0 bytes if LENGTH = 0 N N Y Y# means that SCSI-2 doesn't say what the target should do but says initiators shouldn't use these selection modes. Since target response isn't defined in SCSI-2, I believe the target must act as defined in SCSI-1. This is better than being "creative" and defining some new response.