** This is the quasi-official and semi-temporary T13 email list server. **
At the risk of being repetitive, let me summarize a few facts because
including them in paragraph form seems to be confusing some people.
- ATAPI operated as an SFF SSWG from November 1993 through December 1994
- ATAPI operated as an X3T10 Working Group from January to December 1995
- ATAPI operated as a T13 Working Group beginning January 1996
The SFF Committee was responsible for:
- Development and distribution of SFF Rev 1.2
- Development and distribution of SFF-8029 (addendum to Rev 1.2)
These two specifications were combined into Rev 2.0 by the X3T10 ATAPI
Working Group and Rev 2.0 was not shown to the SFF Committee before it was
presented to X3T10 in May 1995. SFF transferred formal control of 8020
documentation to X3T10 during the meeting.
Rev 2.0 was never distributed outside of those physically present at the
X3T10 meeting. It was declared unacceptable for distribution because the
editor had included overlap without member authorization.
X3T10 voted to continue work on an SFF-8020i specification as a service to
industry during the period when ATAPI was to be broken apart into different
standards.
- Development of Rev 2.5 was done by X3T10
- Distribution of Rev 2.5 was done by SFF
- Development of Rev 2.6 was done by X3T10
- Distribution of Rev 2.6 was done by SFF
Let me repeat the only point I have been trying to make since this thread
started:
The revisions of 8020 which have been named as the cause
of so much grief were not developed by SFF.
SFF distributed these revisions at X3T10's request because
there was no way for X3T10 to do so as a single document.
- The SFF Committee was responsible for the technical content of
SFF-8020 Rev 1.2.
- The SFF Committee was NOT responsible for the technical content
of any later revision of SFF-8020 such as Rev 2.5 and Rev 2.6.
- - - - - - - - - - - - - - - - - - - -
> And finally I would like to say that the only time comments I sent to
> a document editor were ignored was in the case of SFF-8020.
Okay Hale, explain how that bears any resemblance whatsoever to SFF ignoring
you.
Feel free to go ahead and blame the editor, just don't blame, indict or
otherwise paint the SFF Committee with tar for something it did not do.
> I made many comments, mostly in private emails to the editors of SFF-8020.
That qualifies as private correspondence.
Blame the editor, don't blame the SFF Committee.
> I don't care what the "official" record shows. I know the problems I
> complained about and I know when I complained about them. It was long
> before SFF forwarded SFF-8020 to X3T10.
And why don't you care about the official record?
Your rhetoric of blaming SFF for ignoring the ATAPI faults is totally
unjustified and has simply worn very thin with me. It is the only reason
this thread started in the first place.
- There are records on the activities you were involved with at SFF in
1994, which was SFF-8019 for high capacity disk drives. That ended
in May, when the contents were incorporated into ATA-2.
- There are no records of any ATAPI activity other than two emails in
August on ATAPI.
> Most of my emails were sent
> from Seagate since I was a Seagate employee at the time.
If they were all private communications you had with editor Devon Worrel
they are not relevant to what the SFF Committee did or did not do.
If they were to SFF, then produce them. Otherwise, I have what I understand
to be the entire set of email traffic to the ATAPI reflector in 1994, and
these are the only two from you.
Subject: PIO Mode 3+ ATA Host Adapters and ATAPI
Subject: interrrupting a command in ata-2
> It does not matter what happened back in 1994.
It always matters when the truth is misrepresented.
Let's make a deal:
- Show me copies of correspondence to SFF in 1994 that was ignored
or
- Stop claiming SFF ignored the problems you discovered in ATAPI
Either way is satisfactory to me.
- - - - - - - - - - - - - - - - - - - -
> So, when somebody comes in and says that there are problems with the
> ATAPI spec as Hale did, the chair can play "politics" as he did and
> ignore him so that we end up with problems as we did?
That comment is both crass and offensive as well as absolutely wrong.
- The Chair cannot ignore anyone without running the risk of offending
everyone.
- Input can only be ignored if the majority of members present want to
ignore it
If you are referring to the SFF Chair, get your facts straight.
- Hale never submitted any comments to the SFF Committee.
- Hale never brought any items to the attention of the SFF Chair.
- Hale said his 1994 emails were private correspondence to the editor.
The reality:
- The two emails Hale sent to the ATAPI reflector in 1994 were
informative and explanatory of capabilities in ATA/ATA-2
- The three emails Hale sent to the ATAPI reflector in January
1995 were to the X3T10 ATAPI Working Group
Below is the email of Hale's comments on ATAPI, many of which were not
technical, but editorial. These comments went to the X3T10 ATAPI working
group, not the SFF ATAPI SSWG.
- - - - - - - - - - - - - - - - - - - -
> YIKES, Dal! Don't even MENTION SFF-8020i Rev 2.5 !!! THAT Rev is
> what screwed everybody!
It is my belief that Rev 2.5 would never have been published as-is if the
SFF Committee had still been in control of ATAPI, but there is no way to
prove that one way or the other.
> At least SFF-8020i Rev 2.6 fixed the DASP/PDIAG soft reset thingy!
The X3T10 ATAPI Working Group did do some things right.
The little 'i' on the end of the number is the clue to knowing SFF did not
develop a specification, and it is unfortunate that many who know better
often overlook/ignore it. The practice of naming Information Specifications
as INF-8xxx helped a great deal to make the distinction more obvious.
- - - - - - - - - - - - - - - - - - - -
Recognize that what existed in 1995 was a truly unfortunate situation:
a) The SFF Committee had transferred control of ATAPI to X3T10
b) X3T10 was the SCSI Committee, and the X3T10 members relied on the
participants in the ATAPI Working Group.
c) ATAPI was an interim project at X3T10 because it would ultimately
be transferred to the T13 committee that was being formed
d) X3T10 had no way to apply the same safeguards to Rev 2.5 and Rev 2.6
as would have been appropriate for a standard
In conclusion:
- SFF-8020 Rev 1.2 was published during a period when the ATA hard disk
vendors did not participate or contribute to ATAPI
- The SFF Committee never ignored input from any individual during the
14 months that ATAPI operated as an SFF SSWG.
- Not one piece of traffic over this reflector has produced any data
that changes the above facts.
Can we please put this to rest?
Dal
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Date: Sat Jan 21, 1995 11:07 pm PST
From: Hale Landis
MBX: [EMAIL PROTECTED]
Subject: comments on ATAPI spec
In addition to the changes that may be needed to the ATAPI
specification to be compliant with ATA-2/ATA-3 (like device 1
only configurations), perhaps the following should also be
considered:
* Removable of references to the terms "IDE" and "Enhanced IDE".
These are vendor specific and are not used in the ATA
standards.
* Change references to "task file" to the ATA names, either
"Command Block" or "Control Block". The term "task file" is
not used in the ATA standards.
* Make it more clear that the "task file" commands used by ATAPI
devices conform to all aspects of the ATA command execution
protocol, status presentation and error presentation. I find
it too easy to interpret the ATAPI specification to mean that
an ATAPI device could use the ATAPI layout of the error
register when reporting an error on a "task file" command.
* The ATA standards do not use the terms "drive", "master" and
"slave". These terms have been replaced by "device", "device
0" and "device 1". An example is the "Execute Device
Diagnostics" command.
* The term "Vendor Unique" should be changed to "Vendor
Specific".
* The Door Lock and Door Unlock commands are Vendor Specific in
ATA-2/ATA-3. This is not expected to change since the
removable device industry does not have a standard
implementation for these commands. Yet section 4.5.2.1 of the
ATAPI specification makes reference to the functions of these
ATA commands as if there was an ATA specified implementation.
If ATAPI wants these ATA commands to function in some specific
manner in ATAPI, then ATAPI should fully define that
functionality.
* ATAPI section 5.6 has several misleading statements or
statements that conflict with ATA-2/ATA-3:
- ATA-2/ATA-3 does not have a DSC bit in the Status register.
The old ATA-1 DSC bit is currently defined as follows:
"Bit4 is not defined. Prior to this standard, this bit
indicated that the device was on track. This bit may be used
for other purposes in future standards."
This would appear to be a significant difference in
ATA and ATAPI definitions of this status bit.
- The description of what happens when an ATA command is
interrupted by a new ATA command is incorrect (perhaps the
method described in ATAPI is what WD ATA drives do but it
certainly is not what most other vendor's ATA drives do).
Plus, this description does not agree with ATA-2/ATA-3.
ATA-2/ATA-3 says that a command can only be interrupted by a
reset.
* And, for now, one final question... How are we going to keep
ATAPI and ATA in sync when there is more than one ATAPI
standard? How can we endose ATAPI as being ATA compliant or
ATA co-functional when there may be multiple ATAPI
specifications using different definitions? For example, most
of the items above also apply to the QIC ATAPI Streaming Tape
document.
--
\\===============\\=======================\\
\\ Hale Landis \\ 303-548-0567 \\
// Niwot, CO USA // [EMAIL PROTECTED] //
//===============//=======================//
--
If you have any questions or wish to unsubscribe send a
message to Hale Landis, [EMAIL PROTECTED] To post to
this list server send your message to [EMAIL PROTECTED]
For questions concerning Thistle Grove Industries or TGI's
list services please send email to [EMAIL PROTECTED]
