<<We really want that 1284 ID to be in a plain vanilla text leaf instead of a
private format string. And we really want it in the unit directory, because
Win2000 isn't going to know about feature directories, etc.>>
I think everyone is agreed on this; perhaps there is a quibble over whether a
directory entry with some key value, X, points directly to a textual
descriptor leaf or whether a textual descriptor entry (with key value 0x81)
immediately follows the aforementioned directory and points to a textual
descriptor leaf.
I thought that since 1394 PWG is new work that we should eliminate the middle
man and point directly to the textual descriptor leaf (see 7.3 in
IDT_r01.pdf).
In a message dated 99-03-05 20:42:08 EST, gleclair@agentz.com writes:
<<Is it considered acceptable to use that key since SBP-2 does not define it?
It seems the use of the key 3Fh is defined by the Unit Spec_ID and not the
Command set spec ID.>>
Greg raises important questions.
NO, it is NOT OK for a vendor to appropriate the use of a configuration ROM
key for its own use and definition. This is a poor precedent upon which to
emnbark; it paves the way for interoperability difficulties in the future.
What if remote SBP or isochronous SBP or some other future SBP standard wishes
to use key 0x3F? It is reserved for future standardization by NCITS! And it's
not so unlikely that it would be needed, when you consider that keys 0x37
through 0x3C, inclusive, are already defined by SBP-2.
Before considering possible solutions to the problem of 0x3F it's necessary to
understand the enumeration process within Windows better.
I think (Georgios, please correct me if I'm wrong) that Windows looks for
Unit_Spec_ID 0x00 609E, Unit_SW_Version 0x01 0483, Command_Set_Spec_ID 0x00
609E and Command_Set 0x01 04D8; if and only if all four of those conditions
are true it looks for a directory entry whose 2-bit key_type field is ignored,
whose 6-bit key_value is 0x3F and whose 24-bit value field is ignored and then
uses the textual descriptor leaf addressed by the immediately following
textual descriptor entry (key value 0x81) to obtain a 1284 device ID string
that identifies the correct driver.
It's worth mentioning that the Command_Set value of 0x01 04D8 identifies the
device as a disk that conforms to the T10 Reduced Block Commands (RBC) draft
standard!
The reason for mentioning this exacting level of detail is to make very clear
the circumstances under which a 0x3F entry (or functional equivalent) is
relevant to device driver loads in Windows. I think it is important ONLY if
you (the printer vendor) are planning to communicate with your 1394 PWG device
by raw I/O commands via the SCSIPRNT driver.
If a printer vendor intends to ship a custom driver and enumerator, there is
no need to use a 0x3F entry to locate a 1284 device ID string. The question of
the "best" location for a 1284 device ID string can be left to the 1394 PWG
who can in turn advise Microsoft of what's needed in a Windows service pack to
address the new devices.
Which brings us back to the matter of 0x3F. I think the best thing to do is to
associate the 1284 device ID string with the Logical_Unit_Number entry (key
value 0x14). Greg LeClair and John Fuller have already recommended this
approach, in principle. Immediately follow this entry with a textual
descriptor entry (key value 0x81) to point to the 1284 device ID string. This
requires a change to "frozen" code----but I cannot see dire conseqeuences as a
result of changing a constant 0x3F to a constant 0x14 in already working code!
This is the miniscule extent of the code change required. I think the
precedent of using 0x3F in a noncompliant way is sufficiently ill-advised that
it presents a strong argument to make an exception. I also think Microsoft's
flexibility to accommodate this change would demonstrate its commitment to
help create solutions rather than problems.
Regards,
Peter Johansson
Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA 94707
(510) 527-3926
(510) 527-3856 FAX
pjohansson@aol.com