No.
We "all" acknowledge that IP1394 will provide _a_ 1394 printing
solution, and that it will exist on the cable.
The motion was made at the December meeting (and tabled until the
January meeting) for the PWG to pursue only a 1284.4 over SBP-2
solution. In light of the SBP-2 only proposal which Alan and I
presented at the January meeting, the motion was withdrawn.
The issue came up of, 'if the solutions we're proposing are as
heavy as an IP1394 solution, then why not just use IP1394?'
As a result, I chased down the information about one company's
implementation and shared the _rough_ numbers. The results,
IP1394 is signficicantly larger than even a combined initiator/
target SBP-2 solution. So, an SBP-2 (or DPP) style solution
is not pointless.
> This is a very important decision, and I have not heard anything
>
> "official" about it. (Did I miss something in one of the meetings ?
>
> I apologize if I did.)
>
> IP over1394 ?, thin protocol(DPP)?, AVC? ...
>
> Nothing negative about SBP-2, I just want to take I thing at a time.
>
>
>
> On the other hand, if we decide to use 1284.4, the natural way of thinking
>
> technically is to come up with a "glue" ( or SBP-2 subset, which was once
>
> proposed but turned down) between 1284.4 and 1394, since 1284.4
>
> and SBP-2 has overlapping functionality.
>
> I don't think anyone is planning on doing that.
I already did that. I tried to explain (in a previous posting)
what the SBP-2 subset would have to provide for that solution.
The result was a solution which also allowed SBP-2 to be used
_without_ 1284.4 if each service was modeled as a separate unit
directory, and each instance was modeled as a separate login.
So, I presented an SBP-2 only solution at the January meeting.
> I would like to consider supporting B, IF we have decided to use
>
> SBP-2 for PC printing.
>
> Eric' s note about Taigate and native-bridge was very convincing,
>
> and I also think the same kind of situationt applies fro the printing world.
>
>
>
> The HPT proposal, along with Alan's January proposal are 2 details
>
> of the "B" work, which is similar to the direction the strorage protocol
>
> went from Tailgate to native-bridge, which I think is the natural way of
>
> thinking purely technically.
>
>
>
> Ats Nakamura
-- Greg Shue Hewlett-Packard Company Office Products Division gregs@sdd.hp.com ----------------------------------------------------------------