Definition of Mandatory and Optional Features in SAM - resend
Gene_Milligan at notes.seagate.com
Wed Aug 31 15:06:35 PDT 1994
>2. Features are supported by standards and implementations. A
> standard supports a feature by specifying how the feature shall
> be implemented. An implementation supports a feature if the
> feature is implemented in accordance with the standard.
"Supported" is a loaded word. The correct word for this observation regarding
the standard in my mind is "defined". The correct view for the other portion is
"A product provides a compliant feature if the feature is implemented in
accordance with the standard." My product can support a feature by not hanging
the bus when the feature is invoked even if I do not implement the feature. I
certainly do not support the feature if I don't implement the feature and hang
the bus if it is invoked. This comment analogously applies to other of Charles
observations but I will not repeat it.
In the operative part of his memo Charles wrote:
>Given the above, I propose that text be added to SAM specifying the
>1. A conflict between standards shall be resolved according to the
> following precedence:
> Other command standards
> Protocol standards
> Interconnect standards
This would be an excellent idea if we had defined SAM first, CAM, second, SPC
third, OCS fourth, Protocol standards fifth, Interconnects, sixth, and
Applications last. My comment is offered in regard to mandatory and optional.
(No matter how many votes we may muster, SAM can not define Isochronous as
mandatory and sue the Interconnect standards save 1394 and FDDI (for now - stay
tuned to FC and SSA).
If the conflict is addressing redundant definitions or overlapping definitions
I would support having a precedence statement but bowing to silicon I would
make it Interconnect standards, SAM, Other command standards (OCS) , SPC, and
Protocol standards the order of precedence. The reason I put OCS ahead of SPC
is that in SCSI-2 we firmly established the precedent of including necessary
deviations of nearly common commands in the device type command sections. For a
while we were on a path that might have eliminated the need to specialize, but
it looks like we have loaded SPC up with stuff like changer command s that will
probably end up with differences when applied to real applications. I think if
you argue for SPC to take precedent you are just assuming there will be no
>2. A standard supports a feature if the standard specifies how the
> feature is to be implemented.
No, a standard is voted down if it specifies how the feature is to be
implemented. A standard defines a feature appropriately such that differing
implementations will work interoperably with each other as long as they comply
with the standard.
>3. A standard requires a feature if it supports the feature and
> requires that the feature be implemented and required by all
> subsidiary standards.
This is a rather long definition of "Mandatory".
>4. A standard shall require all mandatory features defined by a
> controlling standard (obvious but probably needs to be said).
This just shakes the confidence of people who think they know what "required"
and "mandatory" mean.
>1. "shall" -- Identifies a mandatory feature to be supported by an
> implementation subject to the standard and by required by all
> subsidiary standards.
Replace "subject to" with "claiming compliance with" and delete everything
after "standard". We don't actually have the concept of subsidiary standards.
The standards referred to as subsidiary are actually just standards which may
if their developer's wish call out another (i.e. superior) standard as being a
Normative reference. The tone of all Charles is offering appears to be a
The remaining items are too convoluted for me to comment on. The standards
should merely indicate what is mandatory and what is optional within the given
standard. It is up to application profiles, purchase specifications and/or
implementors to determine which of the standards and options play together.
Obviously since the implementors are energetically supporting the development
of the standards they will be keeping the interplay in mind while choosing
between mandatory and optional.
Gene Milligan -- Gene_Milligan at notes.seagate.com
Seagate Technology - 920 Disc Drive - Scotts Valley, CA 95066 USA
Main Phone 408-438-6550 - Email Problems postmaster at notes.seagate.com
Technical Support: BBS 408-438-8771 Fax 408-438-8137 Voice 408-438-8222
### OGATE Version 8 message trace and attachment information:
### MsgFileName: m:\mgate\outbound\70.MSG
### Org Date: 08-31-94 03:03:32 PM
### From: Gene Milligan at SEAGATE
### To: scsi @ wichitaks.ncr.com @ internet
### Subject: Re: Definition of Mandatory and Optional Features in SAM - resend
### Attachments: none
More information about the T10