Hitoshi Sekine writes:
> Saying just 1284.4 over SBP-2 may cause some confusions. Have
> you described what is inefficient to stack overlapping
> functionality and tried to remove it from 1284.4 over SBP-2? Is
> supporting socket interface included in the latest proposal? If
> you have, I am sorry. My manager didn't allow me to travel to
> Maui, however I loved to be there. Can you update the latest
> status or a meeting memo in Maui? I need catching up you.
[Greg Shue]
If anything is removed from 1284.4 or SBP-2 for a combined solution,
then the driver(s) for the protocol(s) affected cannot be used.
They are no longer the standard protocols.
The proposal I made at the January PWG meeting placed no requirements
or restrictions on the API. Sockets may be supported.
Kazuhiro Hirata asks:
> Alan or Greg, why did you choose SBP-2 based profile rather than 1284.4
> at Jan. PWG?
[Greg Shue]
There are several reasons for choosing SBP-2 rather than 1284.4:
1. SBP-2 is defined and exists.
2. SBP-2 is preferred by Microsoft and Apple.
3. It already addresses the issue of access control and reconnect
4. The PWG already expressed preference against a 1284.4 only solution.
5. The Unit Architecture provides independent access to multiple services.
6. I wanted to prove to myself whether or not it was feasable!
Brian Batchelder writes:
> Actually, I am currently leaning towards SBP-2, but we must use
> it in a way that allows clients to be clients, servers to be
> servers, and both to exist on every device. This probably means
> implementing both target and initiator (targiator) functionality
> on each device. If the chip implementations available today
> don't optimally support targiators, well, we won't be optimal
> until they are fixed. However, I was pleased to read Michael
> Teener's message in which he indicated that targiators should be
> quite possible.
[Greg Shue]
Good job Brian!
I agree that we must use SBP-2 in a way that allows clients to
be clients, and servers to be servers, and both to exist on
every device.
The coined terms "targitator" and "targiator" may get confusing
as they have been used slightly differently. In one case it
refers to an transport connection composed of cross-SBP-2-logins.
The other case refers to a device which provides both SBP-2
initiator libraries and SBP-2 target libraries.
Good Job Michael! I completely agree that any device should be
capable of support both SBP-2 initiator and SBP-2 target functionality.
The HW assists are not required.
-- Greg Shue Hewlett-Packard Company Office Products Division gregs@sdd.hp.com ----------------------------------------------------------------