legal but rude
Robert Snively
rsnively at brocade.com
Mon Feb 24 06:35:41 PST 2003
* From the T10 Reflector (t10 at t10.org), posted by:
* Robert Snively <rsnively at brocade.com>
*
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C2DC12.01A70400
Content-Type: text/plain
Sounds like time for somebody to take on the task
of creating some profiles.
Bob
> -----Original Message-----
> From: JimMcGrath at oaktech.com [ mailto:JimMcGrath at oaktech.com
]
> Sent: Friday, February 21, 2003 4:13 PM
> To: JimMcGrath at oaktech.com
> Cc: LAVARRE at iomega.com; owner-t10 at t10.org; t10 at t10.org
> Subject: Re: legal but rude
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * JimMcGrath at oaktech.com
> *
>
>
>
>
>
>
> BTW, I agree with Pat and Ken that just compliance to a
> standard is not
> adequate for a good supplier - one needs also to look into
> the particulars
> of your target customers. But this can be quite different
> from designing
> to "what everyone knows." And while designing above and beyond the
> requirements of a standard is a good practice, designing at least to a
> standard is really a necessary practice in this interoperable world.
>
> That's my biggest objection - the belief that some parties in
> the industry
> (e.g. host manufacturers) don't need to adhere to a
> documented standard
> like everyone else. In theory the interface standards are
> equally binding
> on host and device. In practice hosts often feel able to
> ignore a standard
> entirely.
>
> The block size issue is actually a good example. If
> "everyone knows" that
> you cannot use a block size > 4Kbytes, then why is not that
> in the standard
> (afterall, we put in lots of limits)? I suspect the issue is
> either the
> fact that it is NOT an "everyone knows" item, or it is one,
> but no one with
> that knowledge bothers to contributes to standards
> development. On this
> particular issue I suspect the former, but in other cases it
> could very
> well be the latter. In either case, I would place a lesser
> share of the
> blame on device developers.
>
> Jim
>
>
>
>
>
>
> JimMcGrath at oaktec
>
>
> h.com To:
> LAVARRE at iomega.com
>
> Sent by: cc:
> owner-t10 at t10.org, t10 at t10.org
>
> owner-t10 at t10.org Subject: Re:
> legal but rude
>
>
>
>
>
>
>
> 02/21/2003 01:08
>
>
> PM
>
>
>
>
>
>
>
>
>
>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * JimMcGrath at oaktech.com
> *
>
>
>
>
>
>
> Pat,
>
> That problem is with the "everyone knows" that hosts expect
> block sizes to
> be <= 4KBytes. As you point out, that is not generally
> documented anywhere
> (in, for instance, a standard), and so it is not clear that "everyone
> knows." Indeed, the reason why devices have standards to
> begin with is
> that it is not reasonable to expect all host designers to know what
> "everyone knows" about devices. So it is with respect to
> device designers
> with respect to hosts.
>
> Bottom line is that the purposes of documents is to, well, document.
> Unless something is documented, it is not reasonable to
> expect designers to
> magically "know" about something (especially if it is debatable as to
> whether that knowledge is actually true). It is certainly
> not reasonable
> to expect a procurement organization to request compliance with "what
> everyone knows" (as opposed to a standard) to insure compatibility.
>
> Jim
>
>
>
>
>
> "Pat LaVarre"
>
> <LAVARRE at iomega.c To: <t10 at t10.org>
>
> om> cc:
>
> Sent by: Subject:
> legal but rude
>
> owner-t10 at t10.org
>
>
>
> 02/21/2003 10:28
>
> AM
>
>
>
>
>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Pat LaVarre" <LAVARRE at iomega.com>
> *
> By the way, I find a number of engineers find the "legal but
> rude" concept
> difficult to learn.
>
> Anybody got a better way to explain it?
>
> The kind of design I mean by this phrase includes choosing
> plug 'n play
> descriptors, such as op x12 Inquiry data, formed strictly in
> accord with
> the merely public merely standard paper specs ... that in fact don't
> interoperate well because they aren't normal. Of course I
> can't easily
> discuss any real & current examples, but here's an analogous
> hypothetical.
>
> Suppose someone actually built a device with an op x12 Inquiry that
> returned x00 DASD as the byte 0 & x1F PDT
> (PeripheralDeviceType) but then
> responded to op x25 ReadCapacity with a blockLength larger
> than x1000 B =
> 4KiB.
>
> All the paper specs say this is utterly legit. But if you actually go
> build such a thing, the host i/o chokes, because "everyone
> knows" that the
> block size of any HDD is supposed to be as small or smaller
> than a virtual
> memory page, and "almot everyone knows" that the block size
> of x00 DASD is
> supposed to be x200 B = 512 B = 0.5KiB.
>
> I say the device and the host here are being "rude". This
> other engineer
> said only the host was "rude", because the paper spec covers
> the device, so
> the device is "legal", and there is no paper spec for the host. I say
> neither would have got caught being rude if the other had
> been polite. I
> say we know they are mutually rude because the system breaks,
> despite half
> of the system, the device, being completely legal by any
> reasonable reading
> of the merely public merely standard paper specs.
>
> What can this engineer be thinking, to say only the host is rude?
>
> How can I explain that the device here is equally rude?
>
> Cluelessly, curiously, thankfully yours, and a Happy Friday
> to you, Pat
> LaVarre
>
> P.S. If by chance I err and some paper spec does tell us that
> block size
> other than 0.5 KiB isn't legal for PDT = x00 DASD, that
> rather misses the
> point. The point is we can tell it's rude before we even ask if it's
> legal.
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
------_=_NextPart_001_01C2DC12.01A70400
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
RE: legal but rude Sounds like time for somebody to take on the task
of creating some profiles. Bob > -----Original Message-----
> From: JimMcGrath at oaktech.com [mailto:JimMcGrath at oaktech.com]
> Sent: Friday, February 21, 2003 4:13 PM
> To: JimMcGrath at oaktech.com
> Cc: LAVARRE at iomega.com; owner-t10 at t10.org; t10 at t10.org
> Subject: Re: legal but rude
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * JimMcGrath at oaktech.com
> *
>
>
>
>
>
>
> BTW, I agree with Pat and Ken that just compliance to a
> standard is not
> adequate for a good supplier - one needs also to look into
> the particulars
> of your target customers. But this can be quite different
> from designing
> to ;what everyone knows.; And while designing above and beyond the
> requirements of a standard is a good practice, designing at least to a
> standard is really a necessary practice in this interoperable world.
>
> That's my biggest objection - the belief that some parties in
> the industry
> (e.g. host manufacturers) don't need to adhere to a
> documented standard
> like everyone else. In theory the interface standards are
> equally binding
> on host and device. In practice hosts often feel able to
> ignore a standard
> entirely.
>
> The block size issue is actually a good example. If
> ;everyone knows; that
> you cannot use a block size > 4Kbytes, then why is not that
> in the standard
> (afterall, we put in lots of limits)? I suspect the issue is
> either the
> fact that it is NOT an ;everyone knows; item, or it is one,
> but no one with
> that knowledge bothers to contributes to standards
> development. On this
> particular issue I suspect the former, but in other cases it
> could very
> well be the latter. In either case, I would place a lesser
> share of the
> blame on device developers.
>
> Jim
>
>
>
>
>
>
> JimMcGrath at oaktec
>
>
> h.com To:
> LAVARRE at iomega.com
>
> Sent by: cc:
> owner-t10 at t10.org, t10 at t10.org
>
> owner-t10 at t10.org Subject: Re:
> legal but rude
>
>
>
>
>
>
>
> 02/21/2003 01:08
>
>
> PM
>
>
>
>
>
>
>
>
>
>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * JimMcGrath at oaktech.com
> *
>
>
>
>
>
>
> Pat,
>
> That problem is with the ;everyone knows; that hosts expect
> block sizes to
> be <= 4KBytes. As you point out, that is not generally
> documented anywhere
> (in, for instance, a standard), and so it is not clear that ;everyone
> knows.; Indeed, the reason why devices have standards to
> begin with is
> that it is not reasonable to expect all host designers to know what
> ;everyone knows; about devices. So it is with respect to
> device designers
> with respect to hosts.
>
> Bottom line is that the purposes of documents is to, well, document.
> Unless something is documented, it is not reasonable to
> expect designers to
> magically ;know; about something (especially if it is debatable as to
> whether that knowledge is actually true). It is certainly
> not reasonable
> to expect a procurement organization to request compliance with ;what
> everyone knows; (as opposed to a standard) to insure compatibility.
>
> Jim
>
>
>
>
>
> ;Pat LaVarre;
>
> <LAVARRE at iomega.c To: <t10 at t10.org>
>
> om> cc:
>
> Sent by: Subject:
> legal but rude
>
> owner-t10 at t10.org
>
>
>
> 02/21/2003 10:28
>
> AM
>
>
>
>
>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * ;Pat LaVarre; <LAVARRE at iomega.com>
> *
> By the way, I find a number of engineers find the ;legal but
> rude; concept
> difficult to learn.
>
> Anybody got a better way to explain it?
>
> The kind of design I mean by this phrase includes choosing
> plug 'n play
> descriptors, such as op x12 Inquiry data, formed strictly in
> accord with
> the merely public merely standard paper specs ... that in fact don't
> interoperate well because they aren't normal. Of course I
> can't easily
> discuss any real & current examples, but here's an analogous
> hypothetical.
>
> Suppose someone actually built a device with an op x12 Inquiry that
> returned x00 DASD as the byte 0 & x1F PDT
> (PeripheralDeviceType) but then
> responded to op x25 ReadCapacity with a blockLength larger
> than x1000 B =
> 4KiB.
>
> All the paper specs say this is utterly legit. But if you actually go
> build such a thing, the host i/o chokes, because ;everyone
> knows; that the
> block size of any HDD is supposed to be as small or smaller
> than a virtual
> memory page, and ;almot everyone knows; that the block size
> of x00 DASD is
> supposed to be x200 B = 512 B = 0.5KiB.
>
> I say the device and the host here are being ;rude;. This
> other engineer
> said only the host was ;rude;, because the paper spec covers
> the device, so
> the device is ;legal;, and there is no paper spec for the host. I say
> neither would have got caught being rude if the other had
> been polite. I
> say we know they are mutually rude because the system breaks,
> despite half
> of the system, the device, being completely legal by any
> reasonable reading
> of the merely public merely standard paper specs.
>
> What can this engineer be thinking, to say only the host is rude?
>
> How can I explain that the device here is equally rude?
>
> Cluelessly, curiously, thankfully yours, and a Happy Friday
> to you, Pat
> LaVarre
>
> P.S. If by chance I err and some paper spec does tell us that
> block size
> other than 0.5 KiB isn't legal for PDT = x00 DASD, that
> rather misses the
> point. The point is we can tell it's rude before we even ask if it's
> legal.
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
------_=_NextPart_001_01C2DC12.01A70400--
More information about the T10
mailing list