P1394 Mail Archive: Re: P1394> PWG printer profile impression

Re: P1394> PWG printer profile impression

Greg Shue (gregs@sdd.hp.com)
Wed, 17 Dec 1997 17:01:30 -0800 (PST)

Ats says:
> This is why I(PWG-C) am concerned about the scope of
> this "glue"(and profile), and PWG-C work.
> I just wanted to clarify the relationship between
> PWG work and PWG-C work
>
> > I *do* think that what we have specified
> > so far could easily be employed by any
> > 1394 device, no matter how small and
> > simple. But there is much work to be done
>
> I may be missing something, but my understanding
> is the only things specified (proposed)
> so far (from the document and discussion)
> is usage of SBP-2, the need to define contents of
> the CDB, and that this CDB should be generic.
> (not 1284.4 specific)

[Greg S]
I don't think you are missing anything.
I also think you have a valid concern.
The decision was already made that the PWG 1394 subcommittee
would not try to solve the direct-print protocol,
but that it would be left to the PWG-C.

Randy's observation about weight of what is defined
so far may be valid. With respect to what to use
for the direct-print protocol, though, it is
simply an option which the PWG-C has available
to them.

Ats says:
> While speaking about CDBs,
> once the CDB definition become generic,
> there wil have to be some mechanism to distingush
> the layer above it.
>
> 1) decoding a defined header at the beginning of the CDB
> 2) preparing differnt login entry points for each session
> others....

[Greg S]
Yes, The decoding is routing information to go to the appropriate
transport.

On the phone conference we have already defined that
each transport stack requires it's own (data-link layer) login.
I'm not sure whether that applies to each instance of a
transport protocol, or simply to each type of transport
protocol.

> If the CDB definition is 1284.4 specific, of course
> it will not be necessary.
> Does this "glue" really need to support anything
> other than 1284.4 ?

[Greg S]
It's not required to support anything else at this point,
but further discussion is needed to understand the need
behind a connectionless transport. If a connectionless
transport were built upon the same SBP-2 behavior, then
routing would be needed.

> Am I missing something ?
>
> Ats

-- 
Greg Shue
Hewlett-Packard Company
Office Products Division			gregs@sdd.hp.com
----------------------------------------------------------------