From gleclair at agentz.com  Thu Jul  2 12:42:13 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Config ROM doc posted - Web Site update
Message-ID: <01BDA59D.B53A7E80.gleclair@agentz.com>

Hi all.

The web site was just updated with the config ROM proposal.

If it's acceptable, then Alan can merge it into the spec after Monterey.

Cheers,

Greg LeClair



From gleclair at agentz.com  Thu Jul  2 12:50:02 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Agenda for Monterey
Message-ID: <01BDA59E.C94E2740.gleclair@agentz.com>


Following is current idea for an agenda in Monterey. 

	1. OUI issue - How to publish the profile

	2. Transport Command Set proposal review

	3. Configuration ROM proposal review

	4. Profile review - turn those pages......

Other suggestions / comments welcome.

Have a great 4th everyone! See you in Monterey.

Regards,
Greg LeClair


From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Thu Jul  2 13:34:22 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Agenda for Monterey
In-Reply-To: <01BDA59E.C94E2740.gleclair@agentz.com>
Message-ID: <H0000d930f932694@MHS>

begin 777 1.txt
M4F5C96EV960Z(&9R;VT@<&%L<F5L,2YH<"YC;VT@*'!A;')E;#$N:'`N8V]M
M(%LQ-2XX,2XQ-C@N,3!=*2!B>2!V96YU<RYR;W-E+FAP+F-O;2!W:71H($53
M3510("@X+C<N,2\X+C<N,R!425,@-2XP($]P96YM86EL*2!I9"!*04$P,#DU
M."!F;W(@/&%L86Y?8F5R:V5M84!H<"UR;W-E=FEL;&4M;VTR+F]M+FAP+F-O
M;3X[(%1H=2P@,B!*=6P@,3DY."`P.3HU-#HT-"`M,#<P,"`H4$14*0I296-E
M:79E9#H@9G)O;2!L:7-T<RYU;F1E<G-C;W)E+F-O;2`H=7-C;W)E+3$N;78N
M8V]M(%LQ.3DN,3(U+C@U+C,P72D*"6)Y('!A;')E;#$N:'`N8V]M("@X+C@N
M-B\X+C@N-71I<RD@=VET:"!%4TU44"!I9"!*04$R,C4Q.3L*"51H=2P@,B!*
M=6P@,3DY."`P.3HU-#HS."`M,#<P,"`H4$14*0I296-E:79E9#H@9G)O;2!L
M;V-A;&AO<W0@*&1A96UO;D!L;V-A;&AO<W0I(&)Y(&QI<W1S+G5N9&5R<V-O
M<F4N8V]M("@X+C<N-2\X+C<N,RD@=VET:"!33510(&ED($U!03(W.3,Q.R!4
M:'4L(#(@2G5L(#$Y.3@@,3(Z-30Z,S$@+3`T,#`@*$5$5"D*4F5C96EV960Z
M(&)Y('!W9RYO<F<@*&)U;&M?;6%I;&5R('8Q+C4I.R!4:'4L(#(@2G5L(#$Y
M.3@@,3(Z-3,Z,C@@+3`T,#`*4F5C96EV960Z("AF<F]M(&1A96UO;D!L;V-A
M;&AO<W0I(&)Y(&QI<W1S+G5N9&5R<V-O<F4N8V]M("@X+C<N-2\X+C<N,RD@
M:60@34%!,C<W.#0@9F]R('`Q,SDT+6]U=&=O:6YG.R!4:'4L(#(@2G5L(#$Y
M.3@@,3(Z-3,Z,#0@+3`T,#`@*$5$5"D*365S<V%G92U)1#H@/#`Q0D1!-3E%
M+D,Y-$4R-S0P+F=L96-L86ER0&%G96YT>BYC;VT^"D9R;VTZ($=R96=O<GD@
M3&5#;&%I<B`\9VQE8VQA:7)`86=E;G1Z+F-O;3X*4F5P;'DM5&\Z(")G;&5C
M;&%I<D!A9V5N='HN8V]M(B`\9VQE8VQA:7)`86=E;G1Z+F-O;3X*5&\Z("(G
M,3,Y-"!05T<G(B`\<#$S.31`<'=G+F]R9SX*4W5B:F5C=#H@4#$S.30^($%G
M96YD82!F;W(@36]N=&5R97D*1&%T93H@5&AU+"`R($IU;"`Q.3DX(#`Y.C4P
M.C`R("TP-S`P"D]R9V%N:7IA=&EO;CH@2F%Y1V5E($-O;6UU;FEC871I;VYS
M"E@M36%I;&5R.B!-:6-R;W-O9G0@26YT97)N970@12UM86EL+TU!4$D@+2`X
M+C`N,"XT,C$Q"D5N8V]D:6YG.B`Q-R!415A4"E-E;F1E<CH@<#$S.30M;W=N
+97)`<'=G+F]R9PIN
`
end

     See 4.1 - 4.5
     
     Alan


______________________________ Reply Separator _________________________________
Subject: P1394> Agenda for Monterey
Author:  Non-HP-gleclair (gleclair@agentz.com) at HP-Roseville,uugw3
Date:    7/2/98 9:50 AM


     
Following is current idea for an agenda in Monterey. 
     
        1. OUI issue - How to publish the profile
     
        2. Transport Command Set proposal review
     
        3. Configuration ROM proposal review
     
        4. Profile review - turn those pages......
        
          4.1) Rev 0.40 is changed to approach what we decided at the May PWG. 
          4.2) We need to discuss error recovery.
          4.3) Need a statement which defines the behavior if a target has 
          communication and it is configured for unidirectional (in the opposite 
          direction) or the appropriate ORB is not found in bi-directional?
          4.4) Need to discuss the issues list. Some have been resolved. Should 
          we remove them from the doc or state the resolution for a running 
          history?
          4.5) Definition of function is one of the latest I saw go by and needs 
          discussion.

Other suggestions / comments welcome.

Have a great 4th everyone! See you in Monterey.

Regards,
Greg LeClair

From atsnaka at bsd.canon.co.jp  Fri Jul  3 06:33:07 1998
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Config ROM doc posted - Web Site update
In-Reply-To: <01BDA59D.B53A7E80.gleclair@agentz.com>
Message-ID: <199807031018.TAA06408@bsdmail.bsd.canon.co.jp>


Hi,

Few comments on the config ROM document.

1) 7.2.5 Instance Directory
     - The key type/key value concatination for function_class is planned to be 19h, not 18h

2) 9.2 OUI
    - The function_class values are (planned to be ) defined by IEEE p1212r (section 7.2.5), so
       function_class value is not a OUI value.

Below is just an opinion.

3) 7.1.5 Unit directory
      - It says,"Compliant devices shall implement at least one unit directory in the format...."
         An informative sentence on what one unit direcotry stands for would help readers.
        Something like, "One unit directory will represent one target compliant with this profile." 

Thanks.

Ats


At 09:42 98/07/02 -0700, Gregory LeClair wrote:
> Hi all.
> 
> The web site was just updated with the config ROM proposal.
> 
> If it's acceptable, then Alan can merge it into the spec after Monterey.
> 
> Cheers,
> 
> Greg LeClair
> 
> 
> 
> 

-----------------------------------------
Atsushi Nakamura
-----------------------------------------

BJ Technology Development 22,
Canon Inc.

53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211

tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------

From gleclair at agentz.com  Mon Jul  6 02:57:05 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Config ROM doc posted - Web Site update
Message-ID: <01BDA8A7.B6F116A0@gleclair.vip.best.com>


>Ats Nakamura wrote:

>1) 7.2.5 Instance Directory
>    - The key type/key value concatination for function_class is planned to be 19h, not 18h

I'll fix this one.

>2) 9.2 OUI
>    - The function_class values are (planned to be ) defined by IEEE p1212r (section 7.2.5), so
>       function_class value is not a OUI value.

I think this issue gets back to whether there is a function class listing in 1212r. TBD


>Below is just an opinion.
>
>3) 7.1.5 Unit directory
>      - It says,"Compliant devices shall implement at least one unit directory in the format...."
>         An informative sentence on what one unit direcotry stands for would help readers.
>        Something like, "One unit directory will represent one target compliant with this profile." 

Agreed. I think we need to add something a little more concrete on the ConfigROM structure.


Cheers,
Greg L.


From jfuller at MICROSOFT.com  Mon Jul 13 13:28:55 1998
From: jfuller at MICROSOFT.com (John Nels Fuller)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Ways to do parameter setup
Message-ID: <FD8F41F04D35D111899600805F19A16C0B3D9A80@red-msg-48.dns.microsoft.com>

Hi everyone,

I talked to George C. about the three possible ways we were considering for
setting connection parameters:

1.	Using command-set dependant management commands.  There is no way
for the class driver to cause the SBP-2 driver to send these, so I guess
they are out.

2.	Using additional registers in the command agent register block.
There is no way for the class driver to discover these addresses or to
deliver requests directly to the 1394 bus driver, so again no luck.

3.	Using commands in the normal command stream.  This will work (as we
knew in Monterey), so we'll have to figure out a way to ensure that the in
and out queues are both idle when they are issued (but we really needed to
do that for 1 & 2 as well).

_____________________
John Nels Fuller
Software Design Engineer, Windows NT
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (425) 703-3863
Fax: (425) 93 MSFAX


From gregs at sdd.hp.com  Mon Jul 13 19:41:13 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Ways to do parameter setup
In-Reply-To: <FD8F41F04D35D111899600805F19A16C0B3D9A80@red-msg-48.dns.microsoft.com> from "John Nels Fuller" at Jul 13, 98 10:28:55 am
Message-ID: <199807132341.QAA18133@hpsdlgj1.sdd.hp.com>

> 
> Hi everyone,
> 
> I talked to George C. about the three possible ways we were considering for
> setting connection parameters:
> 
> 1.	Using command-set dependant management commands.  There is no way
> for the class driver to cause the SBP-2 driver to send these, so I guess
> they are out.

Too bad.

> 2.	Using additional registers in the command agent register block.
> There is no way for the class driver to discover these addresses or to
> deliver requests directly to the 1394 bus driver, so again no luck.

Oh well.

> 3.	Using commands in the normal command stream.  This will work (as we
> knew in Monterey), so we'll have to figure out a way to ensure that the in
> and out queues are both idle when they are issued (but we really needed to
> do that for 1 & 2 as well).

Any progress on getting the Device Type to be dependent on Command_Set?


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From ewa at apple.com  Mon Jul 13 21:40:03 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Ways to do parameter setup
Message-ID: <B1D00555-1E00B@17.219.108.14>

Since I have not been participating, I want to be careful not to
criticize.  But I agree with Greg - it seems like good SBP-2
services should not get in the way of natural communication with
a device.  It sounds like Windows' services make some assumptions
or simplifications that may be too limiting.

In Mac OS, the SBP-2 services are merged with the basic 1394
services.  SBP-2 is not a separate layer that hides 1394; instead
SBP-2 services are available alongside basic 1394 services.  So a
driver can use efficient SBP-2 transfers, while still directly
accessing a device through 1394 (if it wants to).  Maybe this is
also true in Windows, but from the restrictions John mentioned,
it sounds like there may be room for improvement.

It would be a shame to define awkward or inefficient peripheral
protocols just because of software limitataions in an OS.  Software
can always be fixed, while poor protocols seem to have long lives.

--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.      408-974-8187
--------------------------------------

>> Hi everyone,
>> 
>> I talked to George C. about the three possible ways we were considering
for
>> setting connection parameters:
>> 
>> 1.	Using command-set dependant management commands.  There is no way
>> for the class driver to cause the SBP-2 driver to send these, so I guess
>> they are out.
>
>Too bad.
>
>> 2.	Using additional registers in the command agent register block.
>> There is no way for the class driver to discover these addresses or to
>> deliver requests directly to the 1394 bus driver, so again no luck.
>
>Oh well.
>
>> 3.	Using commands in the normal command stream.  This will work (as we
>> knew in Monterey), so we'll have to figure out a way to ensure that the
in
>> and out queues are both idle when they are issued (but we really needed
to
>> do that for 1 & 2 as well).
>
>Any progress on getting the Device Type to be dependent on Command_Set?
>
>
>-- 
>Greg Shue
>Hewlett-Packard Company
>All-in-One Division			        gregs@sdd.hp.com
>----------------------------------------------------------------





From georgioc at microsoft.com  Mon Jul 13 21:56:59 1998
From: georgioc at microsoft.com (George Chrysanthakopoulos)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Ways to do parameter setup
Message-ID: <5BF896CAFE8DD111812400805F1991F705440FEA@red-msg-08.dns.microsoft.com>

?
now i dont know how secure MacOS is but we really dont like to give access
to raw devices up to ANY service/user up in user mode or even higer layer
drivers.  I

in any case, as john said, having control commands in the command stream is
a perfectly good way to do it. Defining bunch of more registers and bloating
the core transport sounds like a bad design, not the other way around.

we do allow passthrough to a device and the lower sbp2 driver can whack the
device directly using our 1394 api. However we dont expose that device
specific functionality up to our class driver. They dont need to know hacky
methods of configuring the device.

We layer:
command set class driver
Transports
Bus specific drivers
hw specific drivers


thanx
g

> -----Original Message-----
> From:	Eric Anderson [SMTP:ewa@apple.com]
> Sent:	Monday, July 13, 1998 6:40 PM
> To:	p1394@pwg.org
> Cc:	George Chrysanthakopoulos; John Nels Fuller; Greg Shue
> Subject:	Re: P1394> Ways to do parameter setup
> 
> Since I have not been participating, I want to be careful not to
> criticize.  But I agree with Greg - it seems like good SBP-2
> services should not get in the way of natural communication with
> a device.  It sounds like Windows' services make some assumptions
> or simplifications that may be too limiting.
> 
> In Mac OS, the SBP-2 services are merged with the basic 1394
> services.  SBP-2 is not a separate layer that hides 1394; instead
> SBP-2 services are available alongside basic 1394 services.  So a
> driver can use efficient SBP-2 transfers, while still directly
> accessing a device through 1394 (if it wants to).  Maybe this is
> also true in Windows, but from the restrictions John mentioned,
> it sounds like there may be room for improvement.
> 
> It would be a shame to define awkward or inefficient peripheral
> protocols just because of software limitataions in an OS.  Software
> can always be fixed, while poor protocols seem to have long lives.
> 
> --------------------------------------
> Eric Anderson            ewa@apple.com
> Apple Computer, Inc.      408-974-8187
> --------------------------------------
> 
> >> Hi everyone,
> >> 
> >> I talked to George C. about the three possible ways we were considering
> for
> >> setting connection parameters:
> >> 
> >> 1.	Using command-set dependant management commands.  There is no way
> >> for the class driver to cause the SBP-2 driver to send these, so I
> guess
> >> they are out.
> >
> >Too bad.
> >
> >> 2.	Using additional registers in the command agent register block.
> >> There is no way for the class driver to discover these addresses or to
> >> deliver requests directly to the 1394 bus driver, so again no luck.
> >
> >Oh well.
> >
> >> 3.	Using commands in the normal command stream.  This will work (as we
> >> knew in Monterey), so we'll have to figure out a way to ensure that the
> in
> >> and out queues are both idle when they are issued (but we really needed
> to
> >> do that for 1 & 2 as well).
> >
> >Any progress on getting the Device Type to be dependent on Command_Set?
> >
> >
> >-- 
> >Greg Shue
> >Hewlett-Packard Company
> >All-in-One Division			        gregs@sdd.hp.com
> >----------------------------------------------------------------
> 
> 
> 

From georgioc at microsoft.com  Mon Jul 13 21:59:42 1998
From: georgioc at microsoft.com (George Chrysanthakopoulos)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Ways to do parameter setup
Message-ID: <5BF896CAFE8DD111812400805F1991F705440FEB@red-msg-08.dns.microsoft.com>

once again, pritning should come to terms with the fact that if use the core
sbp2 protocol correctly(even if it means being alittle bit creative without
resorting in bloating with abuncg of regs) it provides enough for you to
work with and create great 1394 implementations.

Device type is command set specifc.  we need to see hw. 

thanx
g

> -----Original Message-----
> From:	Greg Shue [SMTP:gregs@sdd.hp.com]
> Sent:	Monday, July 13, 1998 4:41 PM
> To:	John Nels Fuller
> Cc:	p1394@pwg.org; George Chrysanthakopoulos
> Subject:	Re: P1394> Ways to do parameter setup
> 
> > 
> > Hi everyone,
> > 
> > I talked to George C. about the three possible ways we were considering
> for
> > setting connection parameters:
> > 
> > 1.	Using command-set dependant management commands.  There is no way
> > for the class driver to cause the SBP-2 driver to send these, so I guess
> > they are out.
> 
> Too bad.
> 
> > 2.	Using additional registers in the command agent register block.
> > There is no way for the class driver to discover these addresses or to
> > deliver requests directly to the 1394 bus driver, so again no luck.
> 
> Oh well.
> 
> > 3.	Using commands in the normal command stream.  This will work (as we
> > knew in Monterey), so we'll have to figure out a way to ensure that the
> in
> > and out queues are both idle when they are issued (but we really needed
> to
> > do that for 1 & 2 as well).
> 
> Any progress on getting the Device Type to be dependent on Command_Set?
> 
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------

From gregs at sdd.hp.com  Tue Jul 14 11:30:19 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Ways to do parameter setup
In-Reply-To: <5BF896CAFE8DD111812400805F1991F705440FEB@red-msg-08.dns.microsoft.com> from "George Chrysanthakopoulos" at Jul 13, 98 06:59:42 pm
Message-ID: <199807141530.IAA20246@hpsdlgj1.sdd.hp.com>


So the PWG command set device_type == PRINTER doesn't have to match
the value used by SCSI, right?

Thanks!  That was always annoying.

I didn't think you would need hardware to verify that change.
It seems easy enough to mock up an SBP-2 unit directory on
another PC node.

- GregS

> once again, pritning should come to terms with the fact that if use the core
> sbp2 protocol correctly(even if it means being alittle bit creative without
> resorting in bloating with abuncg of regs) it provides enough for you to
> work with and create great 1394 implementations.
> 
> Device type is command set specifc.  we need to see hw. 
> 
> thanx
> g


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From georgioc at microsoft.com  Tue Jul 14 13:42:43 1998
From: georgioc at microsoft.com (George Chrysanthakopoulos)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Ways to do parameter setup
Message-ID: <5BF896CAFE8DD111812400805F1991F705440FF6@red-msg-08.dns.microsoft.com>

we need hw to start making 1394 printing real instead of just talking about
it.
I also need a spec that sets the new device types according to a a NEW
command set which i have yet to see.
thanx
g

-----Original Message-----
From: Greg Shue [mailto:gregs@sdd.hp.com]
Sent: Tuesday, July 14, 1998 8:30 AM
To: George Chrysanthakopoulos
Cc: p1394@pwg.org
Subject: Re: P1394> Ways to do parameter setup



So the PWG command set device_type == PRINTER doesn't have to match
the value used by SCSI, right?

Thanks!  That was always annoying.

I didn't think you would need hardware to verify that change.
It seems easy enough to mock up an SBP-2 unit directory on
another PC node.

- GregS

> once again, pritning should come to terms with the fact that if use the
core
> sbp2 protocol correctly(even if it means being alittle bit creative
without
> resorting in bloating with abuncg of regs) it provides enough for you to
> work with and create great 1394 implementations.
> 
> Device type is command set specifc.  we need to see hw. 
> 
> thanx
> g


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From gregs at sdd.hp.com  Mon Jul 20 13:05:11 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Revised PWG1394 Cmd Set
Message-ID: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>


Grettings all,

As I have thought about many of the issues and simplifications
discussed at the July PWG 1394 meeting, I have tried to create
an overview of the resulting command set.  Before I start modifying
the Command Set proposal, I would like to hear any concerns you have
with the revisions.  The overview follows.  Please respond with 
any feedback before Friday 7/24/98.  I will try to have the
revised Command Set proposal ready by 8/5/98.  (I cannot have
it ready a full 2 weeks before the August meeting.)  Thank you
for your feedback.


PWG SBP-2-based Transport Command Set
7/20/98

With:
  - the restrictions imposed by the Microsoft SBP-2 implementation
  - the desire from Randy Turner (Sharp) for Open & Close commands
  - the removal of Vendor-specific extension mechanisms
  - the relabeling of commands with more descriptive names

the command set transforms into:

  TRANSPORT_STATUS   {GET_PARAMETER w/ all params tags}

                     Only valid on T2I data queue, only valid
                     when in an Unopened Connection state.

  TRANSPORT_OPEN     {SET PARAMETER LIST w/ all settable parameters}

                     Contains all "Negotiated" parameter values.
                     Only valid on I2T data queue, only valid
                     when in an Unopened Connection state.

  TRANSPORT_CLOSE    {SET PARAMETER LSIT w/ only Mode parameter}

                     Closed direction inferred from queue_id bit.
                     Valid on both queues. Invalid only in the
                     UnOpened Connection state.

  TRANSPORT_I2T_DATA {FETCH_DATA}

                     Valid only on I2T data queue.  Valid only
                     in the Opened Connection state.  Valid only
                     while the queue is open.

  TRANSPORT_T2I_DATA {STORE_DATA}

                     Valid only on T2I data queue.  Valid only
                     in the Opened Connection state.  Valid only
                     while the queue is open.

the Command Set Model of Use becomes:

   Login event ---->    UnOpened Conn  [ TRANSPORT_STATUS is OK
			|                TRANSPORT_OPEN is OK
			|                All other cmds is ERROR ]
 _______________________|
 |
 +-- TRANSPORT_OPEN ->  Opened Conn    [ TRANSPORT_STATUS is ERROR
                        |   ^ ^          TRANSPORT_CLOSE is OK
                        |   | |          TRANSPORT_I2T_DATA is OK if
                        |   | |            I2T direction is Open
                        |   | |          TRANSPORT_T2I_DATA is OK if
                        |   | |            T2I direction is Open
			|   | |          TRANSPORT_OPEN is ERROR
 _______________________|   | |
 |||                        | |
 ||+- TRANSPORT_CLOSE (I2T) + |
 ||    && T2I still open      |
 ||                           |
 |+-- TRANSPORT_CLOSE (T2I) --+
 |     && I2T still open
 |
 +- TRANSPORT_CLOSE -> Closed Conn     [ TRANSPORT_STATUS is ERROR
     | I2T & T2I closed                  TRANSPORT_CLOSE is OK
     |                                   TRANSPORT_I2T_DATA is ERROR
     |                                   TRANSPORT_T2I_DATA is ERROR
     +---> Logout                        TRANSPORT_OPEN is ERROR

The variables associated with TRANSPORT_STATUS become:

  A)  MAX_TASK_SET_SIZE  (16 bits unsigned int,
                                  2 is minimum;
                                  2^14-1 is maximum)
  B)  MAX_I2T_DATA_SIZE  (31 bits unsigned int)
  C)  MAX_T2I_DATA_SIZE  (31 bits unsigned int)
  D)  STREAM_COMPLETION  ( 8 bits unsigned int)
  E)  CONNECTION_STATE   ( 2 bits unsigned int
                                  0 => I2T CLOSED, T2I CLOSED;
                                  1 => I2T OPEN,   T2I CLOSED;
                                  2 => I2T CLOSED, T2I OPEN;
                                  3 => I2T OPEN,   T2I OPEN;)

The target needs to communicate the following specific events
to the initiator even in the case that no commands are queued.

  - UNIT ATTENTION: logical unit was reset outside of this Login

  - Target has closed a communication direction and will reject
     further TRANSPORT_?2?_DATA commands for that direction.
     When all directions are closed, then target is should
     Logout ASAP.  (The target shall only successfully execute
     TRANSPORT_STATUS commands.)

  Since an initiator can not leave a TRANSPORT_T2I_DATA command
  enqueued when the T2I direction is closed, this data must be
  communicated via the Unsolicited Status mechanism.  Also, since
  an Initiator may not even exist on the bus (due to a transient
  link interruption) when either of these events happens, they
  must be buffered.


Now, error recovery for when a target detects an ACK Timeout on a
Status FIFO write requires some special considerations.  When
this condition happens the initiator and target may be
out-of-sync with each other, and the SBP-2 protocol does not
provide a mechanism for the initiator to determine that the
condition exists.  The problem breaks down to two issues:

  Initiator Detection:
    Because this condition is expected to happen _extremely_
    infrequently, it is expected that a Bus Reset mechanism
    is a reasonable way of forcing the initiator to resynchronize
    with the target.

  Recovery:
    To recover from this condition, the target needs to infer
    whether or not the initiator received the completion notification(s).

      If the initiator did, the target may release the resources
      or take the appropriate action assocaited with the command(s).

      If the initiator did not, the target must determine whether
      or not the same command (sequence, and associated data) is
      restored to the execution queue.

	If the same sequence is not restored to the front of the
        queue, then the target should ignore all previous commands
        and re-execute them.

	If the same sequence is restored, then the target need
	not reprocess the entire command and data block.  It
	simply needs to know where it left off within the
	transfers.

    This makes it reasonable to employ a command tag, used to
    uniquely identify each previously active command within the
    implicilty aborted task set, and new commands which were not
    in the previously active task set.

    Unfortunately, SBP-2 requires targets to support the ABORT TASK
    function, and the process described for aborting tasks causes
    previously valid commands to be turned into Dummy ORBs.  This
    effectively removes the command tag from the ORB, so the
    queue's Execution Agent no longer sees command tags as
    sequential even if they were assigned sequentially.

      It may be reasonable for a target to enforce seeing
      sequential command tags in order to recover from this
      situation.  If the queue's Execution Agent completed
      all commands in that queue with a status of "ABORTED -
      UNEXPECTED COMMAND TAG VALUE", then the initiator has
      a chance to recover from the situation.  This also means
      that an ABORT TASK function causes all successive commands
      on the associated queue to be aborted without affecting
      the other queue.
      
    This brings us to the following policies:

      A)  A target shall enforce sequential command tag values.
      B)  Initial command tag values shall be established by the
            first command placed on each queue.
      C)  ABORT TASK shall indirectly cause the rest of the
            command queue to be aborted without affecting
            the other command queue.
      D)  Initiators shall retire a command tag until
            it receives a successful completion notification
            for a following command on the associated queue.
            Once that following successful notification has
            been received, the command tag may be reused.
      E)  Targets shall invalidate a command tag when
            the completion notification for the associated
            ORB has been succesfully acknowledged.

    These policies allow the target to use the algorithm below
    to recover synchronization:

      If the target is not in a missing status FIFO ACK error
      recovery situation, it shall examine the command at the
      head of the queue and:

        process it if it is either the first command enqueued
        on this queue since Login, or has a command tag immediately
        following the one of the last successfully completed command.

        otherwise, abort it.

      If the target is in a missing status FIFO ACK error
      recovery situation, it shall examine the command at the
      head of the queue and:

	If the command tag matches the one of the unacknowledged
	command, it shall make sure the command is processed and
	resend the completion notification.

	Else if the command tag follows the one of the
	unacknowledged command, it shall ASSUME the completion
	notification was successfully received by the initiator
	and that the ACK transmission was lost.  The pending
	command shall be implicilty acknowledged by the new
	command, and completed by the target.

        Else the target shall abort it.
-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From fumiona at venus.dtinet.or.jp  Thu Jul 23 09:09:46 1998
From: fumiona at venus.dtinet.or.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Revised PWG1394 Cmd Set
In-Reply-To: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
References: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
Message-ID: <98072322090601.AKG5A71@smtp.venus.dti.ne.jp>

Dear Greg,

1. Is a "command tag" same as a "transaction number" ?

2. Do you really believe a target device can fail to 
   receive an ack-packet?

3. I would like to suggest three commands listed below;
	TRANSPORT_I2T_ABORT
	TRANSPORT_T2I_ABORT
	TRANSPORT_ORB_RELEASE

3.1. TRANSPORT_I2T_ABORT
	An initiator requests a target to stop ORB fetching, 
	and solicits the target to reply STATUS block when
	the last ORB had been executed.

3.2. TRANSPORT_T2I_ABORT
	A target requests an initiator to stop appending new
	ORBs on outstanding linked list. The initiator may
	invoke "close" command when it received STATUS bock
	associated with the last ORB.

3.3. TRANSPORT_ORB_RELEASE
	A target request an initiator to release specified ORB
	without completion STATUS block.

Fumio Nagasaka
>
>Grettings all,
>
>As I have thought about many of the issues and simplifications
>discussed at the July PWG 1394 meeting, I have tried to create
>an overview of the resulting command set.  Before I start modifying
>the Command Set proposal, I would like to hear any concerns you have
>with the revisions.  The overview follows.  Please respond with 
>any feedback before Friday 7/24/98.  I will try to have the
>revised Command Set proposal ready by 8/5/98.  (I cannot have
>it ready a full 2 weeks before the August meeting.)  Thank you
>for your feedback.
>
>
>PWG SBP-2-based Transport Command Set
>7/20/98
>
>With:
>  - the restrictions imposed by the Microsoft SBP-2 implementation
>  - the desire from Randy Turner (Sharp) for Open & Close commands
>  - the removal of Vendor-specific extension mechanisms
>  - the relabeling of commands with more descriptive names
>
>the command set transforms into:
>
>  TRANSPORT_STATUS   {GET_PARAMETER w/ all params tags}
>
>                     Only valid on T2I data queue, only valid
>                     when in an Unopened Connection state.
>
>  TRANSPORT_OPEN     {SET PARAMETER LIST w/ all settable parameters}
>
>                     Contains all "Negotiated" parameter values.
>                     Only valid on I2T data queue, only valid
>                     when in an Unopened Connection state.
>
>  TRANSPORT_CLOSE    {SET PARAMETER LSIT w/ only Mode parameter}
>
>                     Closed direction inferred from queue_id bit.
>                     Valid on both queues. Invalid only in the
>                     UnOpened Connection state.
>
>  TRANSPORT_I2T_DATA {FETCH_DATA}
>
>                     Valid only on I2T data queue.  Valid only
>                     in the Opened Connection state.  Valid only
>                     while the queue is open.
>
>  TRANSPORT_T2I_DATA {STORE_DATA}
>
>                     Valid only on T2I data queue.  Valid only
>                     in the Opened Connection state.  Valid only
>                     while the queue is open.
>
>the Command Set Model of Use becomes:
>
>   Login event ---->    UnOpened Conn  [ TRANSPORT_STATUS is OK
>			|                TRANSPORT_OPEN is OK
>			|                All other cmds is ERROR ]
> _______________________|
> |
> +-- TRANSPORT_OPEN ->  Opened Conn    [ TRANSPORT_STATUS is ERROR
>                        |   ^ ^          TRANSPORT_CLOSE is OK
>                        |   | |          TRANSPORT_I2T_DATA is OK if
>                        |   | |            I2T direction is Open
>                        |   | |          TRANSPORT_T2I_DATA is OK if
>                        |   | |            T2I direction is Open
>			|   | |          TRANSPORT_OPEN is ERROR
> _______________________|   | |
> |||                        | |
> ||+- TRANSPORT_CLOSE (I2T) + |
> ||    && T2I still open      |
> ||                           |
> |+-- TRANSPORT_CLOSE (T2I) --+
> |     && I2T still open
> |
> +- TRANSPORT_CLOSE -> Closed Conn     [ TRANSPORT_STATUS is ERROR
>     | I2T & T2I closed                  TRANSPORT_CLOSE is OK
>     |                                   TRANSPORT_I2T_DATA is ERROR
>     |                                   TRANSPORT_T2I_DATA is ERROR
>     +---> Logout                        TRANSPORT_OPEN is ERROR
>
>The variables associated with TRANSPORT_STATUS become:
>
>  A)  MAX_TASK_SET_SIZE  (16 bits unsigned int,
>                                  2 is minimum;
>                                  2^14-1 is maximum)
>  B)  MAX_I2T_DATA_SIZE  (31 bits unsigned int)
>  C)  MAX_T2I_DATA_SIZE  (31 bits unsigned int)
>  D)  STREAM_COMPLETION  ( 8 bits unsigned int)
>  E)  CONNECTION_STATE   ( 2 bits unsigned int
>                                  0 => I2T CLOSED, T2I CLOSED;
>                                  1 => I2T OPEN,   T2I CLOSED;
>                                  2 => I2T CLOSED, T2I OPEN;
>                                  3 => I2T OPEN,   T2I OPEN;)
>
>The target needs to communicate the following specific events
>to the initiator even in the case that no commands are queued.
>
>  - UNIT ATTENTION: logical unit was reset outside of this Login
>
>  - Target has closed a communication direction and will reject
>     further TRANSPORT_?2?_DATA commands for that direction.
>     When all directions are closed, then target is should
>     Logout ASAP.  (The target shall only successfully execute
>     TRANSPORT_STATUS commands.)
>
>  Since an initiator can not leave a TRANSPORT_T2I_DATA command
>  enqueued when the T2I direction is closed, this data must be
>  communicated via the Unsolicited Status mechanism.  Also, since
>  an Initiator may not even exist on the bus (due to a transient
>  link interruption) when either of these events happens, they
>  must be buffered.
>
>
>Now, error recovery for when a target detects an ACK Timeout on a
>Status FIFO write requires some special considerations.  When
>this condition happens the initiator and target may be
>out-of-sync with each other, and the SBP-2 protocol does not
>provide a mechanism for the initiator to determine that the
>condition exists.  The problem breaks down to two issues:
>
>  Initiator Detection:
>    Because this condition is expected to happen _extremely_
>    infrequently, it is expected that a Bus Reset mechanism
>    is a reasonable way of forcing the initiator to resynchronize
>    with the target.
>
>  Recovery:
>    To recover from this condition, the target needs to infer
>    whether or not the initiator received the completion notification(s).
>
>      If the initiator did, the target may release the resources
>      or take the appropriate action assocaited with the command(s).
>
>      If the initiator did not, the target must determine whether
>      or not the same command (sequence, and associated data) is
>      restored to the execution queue.
>
>	If the same sequence is not restored to the front of the
>        queue, then the target should ignore all previous commands
>        and re-execute them.
>
>	If the same sequence is restored, then the target need
>	not reprocess the entire command and data block.  It
>	simply needs to know where it left off within the
>	transfers.
>
>    This makes it reasonable to employ a command tag, used to
>    uniquely identify each previously active command within the
>    implicilty aborted task set, and new commands which were not
>    in the previously active task set.
>
>    Unfortunately, SBP-2 requires targets to support the ABORT TASK
>    function, and the process described for aborting tasks causes
>    previously valid commands to be turned into Dummy ORBs.  This
>    effectively removes the command tag from the ORB, so the
>    queue's Execution Agent no longer sees command tags as
>    sequential even if they were assigned sequentially.
>
>      It may be reasonable for a target to enforce seeing
>      sequential command tags in order to recover from this
>      situation.  If the queue's Execution Agent completed
>      all commands in that queue with a status of "ABORTED -
>      UNEXPECTED COMMAND TAG VALUE", then the initiator has
>      a chance to recover from the situation.  This also means
>      that an ABORT TASK function causes all successive commands
>      on the associated queue to be aborted without affecting
>      the other queue.
>      
>    This brings us to the following policies:
>
>      A)  A target shall enforce sequential command tag values.
>      B)  Initial command tag values shall be established by the
>            first command placed on each queue.
>      C)  ABORT TASK shall indirectly cause the rest of the
>            command queue to be aborted without affecting
>            the other command queue.
>      D)  Initiators shall retire a command tag until
>            it receives a successful completion notification
>            for a following command on the associated queue.
>            Once that following successful notification has
>            been received, the command tag may be reused.
>      E)  Targets shall invalidate a command tag when
>            the completion notification for the associated
>            ORB has been succesfully acknowledged.
>
>    These policies allow the target to use the algorithm below
>    to recover synchronization:
>
>      If the target is not in a missing status FIFO ACK error
>      recovery situation, it shall examine the command at the
>      head of the queue and:
>
>        process it if it is either the first command enqueued
>        on this queue since Login, or has a command tag immediately
>        following the one of the last successfully completed command.
>
>        otherwise, abort it.
>
>      If the target is in a missing status FIFO ACK error
>      recovery situation, it shall examine the command at the
>      head of the queue and:
>
>	If the command tag matches the one of the unacknowledged
>	command, it shall make sure the command is processed and
>	resend the completion notification.
>
>	Else if the command tag follows the one of the
>	unacknowledged command, it shall ASSUME the completion
>	notification was successfully received by the initiator
>	and that the ACK transmission was lost.  The pending
>	command shall be implicilty acknowledged by the new
>	command, and completed by the target.
>
>        Else the target shall abort it.
>-- 
>Greg Shue
>Hewlett-Packard Company
>All-in-One Division			        gregs@sdd.hp.com
>----------------------------------------------------------------
>

---
Fumio Nagasaka
EPSON Software Deveopment Lab., Inc.
voice: +81 268 25-4111

From shimura at pure.cpdc.canon.co.jp  Fri Jul 24 11:34:11 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:38 2009
Subject: P1394> MAX_?2?_DATA_SIZE(Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
References: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
Message-ID: <199807241534.AAA23522@origin.pure.cpdc.canon.co.jp>


>   B)  MAX_I2T_DATA_SIZE  (31 bits unsigned int)
>   C)  MAX_T2I_DATA_SIZE  (31 bits unsigned int)

It is still not clear for me what is specified for initiator and/or
target by these parameters.

Size of the "buffer" referred by data_descriptor field of an ORB will
be determined along with requesting client of the initiator. Once the
ORB is appended to task list, access right to the "buffer" is granted
to the target, and the "buffer" looks like (remote) receiving/sending
buffer of the target. The target can access any part of the "buffer"
within the address range of the "buffer" in arbitrary size unit the
target wants to handle.

I think the size of the "buffer" referred by the ORB and the size
unit that target processes the "buffer" are independent of each other.

Could you explain why these parameters need to go across the wire?

Akihiro Shimura

On Mon, 20 Jul 1998 10:05:11 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:

> 
> Grettings all,
> 
> As I have thought about many of the issues and simplifications
> discussed at the July PWG 1394 meeting, I have tried to create
> an overview of the resulting command set.  Before I start modifying
> the Command Set proposal, I would like to hear any concerns you have
> with the revisions.  The overview follows.  Please respond with 
> any feedback before Friday 7/24/98.  I will try to have the
> revised Command Set proposal ready by 8/5/98.  (I cannot have
> it ready a full 2 weeks before the August meeting.)  Thank you
> for your feedback.
> 
> 
> PWG SBP-2-based Transport Command Set
> 7/20/98
> 
> With:
>   - the restrictions imposed by the Microsoft SBP-2 implementation
>   - the desire from Randy Turner (Sharp) for Open & Close commands
>   - the removal of Vendor-specific extension mechanisms
>   - the relabeling of commands with more descriptive names
> 
> the command set transforms into:
> 
>   TRANSPORT_STATUS   {GET_PARAMETER w/ all params tags}
> 
>                      Only valid on T2I data queue, only valid
>                      when in an Unopened Connection state.
> 
>   TRANSPORT_OPEN     {SET PARAMETER LIST w/ all settable parameters}
> 
>                      Contains all "Negotiated" parameter values.
>                      Only valid on I2T data queue, only valid
>                      when in an Unopened Connection state.
> 
>   TRANSPORT_CLOSE    {SET PARAMETER LSIT w/ only Mode parameter}
> 
>                      Closed direction inferred from queue_id bit.
>                      Valid on both queues. Invalid only in the
>                      UnOpened Connection state.
> 
>   TRANSPORT_I2T_DATA {FETCH_DATA}
> 
>                      Valid only on I2T data queue.  Valid only
>                      in the Opened Connection state.  Valid only
>                      while the queue is open.
> 
>   TRANSPORT_T2I_DATA {STORE_DATA}
> 
>                      Valid only on T2I data queue.  Valid only
>                      in the Opened Connection state.  Valid only
>                      while the queue is open.
> 
> the Command Set Model of Use becomes:
> 
>    Login event ---->    UnOpened Conn  [ TRANSPORT_STATUS is OK
> 			|                TRANSPORT_OPEN is OK
> 			|                All other cmds is ERROR ]
>  _______________________|
>  |
>  +-- TRANSPORT_OPEN ->  Opened Conn    [ TRANSPORT_STATUS is ERROR
>                         |   ^ ^          TRANSPORT_CLOSE is OK
>                         |   | |          TRANSPORT_I2T_DATA is OK if
>                         |   | |            I2T direction is Open
>                         |   | |          TRANSPORT_T2I_DATA is OK if
>                         |   | |            T2I direction is Open
> 			|   | |          TRANSPORT_OPEN is ERROR
>  _______________________|   | |
>  |||                        | |
>  ||+- TRANSPORT_CLOSE (I2T) + |
>  ||    && T2I still open      |
>  ||                           |
>  |+-- TRANSPORT_CLOSE (T2I) --+
>  |     && I2T still open
>  |
>  +- TRANSPORT_CLOSE -> Closed Conn     [ TRANSPORT_STATUS is ERROR
>      | I2T & T2I closed                  TRANSPORT_CLOSE is OK
>      |                                   TRANSPORT_I2T_DATA is ERROR
>      |                                   TRANSPORT_T2I_DATA is ERROR
>      +---> Logout                        TRANSPORT_OPEN is ERROR
> 
> The variables associated with TRANSPORT_STATUS become:
> 
>   A)  MAX_TASK_SET_SIZE  (16 bits unsigned int,
>                                   2 is minimum;
>                                   2^14-1 is maximum)
>   B)  MAX_I2T_DATA_SIZE  (31 bits unsigned int)
>   C)  MAX_T2I_DATA_SIZE  (31 bits unsigned int)
>   D)  STREAM_COMPLETION  ( 8 bits unsigned int)
>   E)  CONNECTION_STATE   ( 2 bits unsigned int
>                                   0 => I2T CLOSED, T2I CLOSED;
>                                   1 => I2T OPEN,   T2I CLOSED;
>                                   2 => I2T CLOSED, T2I OPEN;
>                                   3 => I2T OPEN,   T2I OPEN;)
> 
> The target needs to communicate the following specific events
> to the initiator even in the case that no commands are queued.
> 
>   - UNIT ATTENTION: logical unit was reset outside of this Login
> 
>   - Target has closed a communication direction and will reject
>      further TRANSPORT_?2?_DATA commands for that direction.
>      When all directions are closed, then target is should
>      Logout ASAP.  (The target shall only successfully execute
>      TRANSPORT_STATUS commands.)
> 
>   Since an initiator can not leave a TRANSPORT_T2I_DATA command
>   enqueued when the T2I direction is closed, this data must be
>   communicated via the Unsolicited Status mechanism.  Also, since
>   an Initiator may not even exist on the bus (due to a transient
>   link interruption) when either of these events happens, they
>   must be buffered.
> 
> 
> Now, error recovery for when a target detects an ACK Timeout on a
> Status FIFO write requires some special considerations.  When
> this condition happens the initiator and target may be
> out-of-sync with each other, and the SBP-2 protocol does not
> provide a mechanism for the initiator to determine that the
> condition exists.  The problem breaks down to two issues:
> 
>   Initiator Detection:
>     Because this condition is expected to happen _extremely_
>     infrequently, it is expected that a Bus Reset mechanism
>     is a reasonable way of forcing the initiator to resynchronize
>     with the target.
> 
>   Recovery:
>     To recover from this condition, the target needs to infer
>     whether or not the initiator received the completion notification(s).
> 
>       If the initiator did, the target may release the resources
>       or take the appropriate action assocaited with the command(s).
> 
>       If the initiator did not, the target must determine whether
>       or not the same command (sequence, and associated data) is
>       restored to the execution queue.
> 
> 	If the same sequence is not restored to the front of the
>         queue, then the target should ignore all previous commands
>         and re-execute them.
> 
> 	If the same sequence is restored, then the target need
> 	not reprocess the entire command and data block.  It
> 	simply needs to know where it left off within the
> 	transfers.
> 
>     This makes it reasonable to employ a command tag, used to
>     uniquely identify each previously active command within the
>     implicilty aborted task set, and new commands which were not
>     in the previously active task set.
> 
>     Unfortunately, SBP-2 requires targets to support the ABORT TASK
>     function, and the process described for aborting tasks causes
>     previously valid commands to be turned into Dummy ORBs.  This
>     effectively removes the command tag from the ORB, so the
>     queue's Execution Agent no longer sees command tags as
>     sequential even if they were assigned sequentially.
> 
>       It may be reasonable for a target to enforce seeing
>       sequential command tags in order to recover from this
>       situation.  If the queue's Execution Agent completed
>       all commands in that queue with a status of "ABORTED -
>       UNEXPECTED COMMAND TAG VALUE", then the initiator has
>       a chance to recover from the situation.  This also means
>       that an ABORT TASK function causes all successive commands
>       on the associated queue to be aborted without affecting
>       the other queue.
>       
>     This brings us to the following policies:
> 
>       A)  A target shall enforce sequential command tag values.
>       B)  Initial command tag values shall be established by the
>             first command placed on each queue.
>       C)  ABORT TASK shall indirectly cause the rest of the
>             command queue to be aborted without affecting
>             the other command queue.
>       D)  Initiators shall retire a command tag until
>             it receives a successful completion notification
>             for a following command on the associated queue.
>             Once that following successful notification has
>             been received, the command tag may be reused.
>       E)  Targets shall invalidate a command tag when
>             the completion notification for the associated
>             ORB has been succesfully acknowledged.
> 
>     These policies allow the target to use the algorithm below
>     to recover synchronization:
> 
>       If the target is not in a missing status FIFO ACK error
>       recovery situation, it shall examine the command at the
>       head of the queue and:
> 
>         process it if it is either the first command enqueued
>         on this queue since Login, or has a command tag immediately
>         following the one of the last successfully completed command.
> 
>         otherwise, abort it.
> 
>       If the target is in a missing status FIFO ACK error
>       recovery situation, it shall examine the command at the
>       head of the queue and:
> 
> 	If the command tag matches the one of the unacknowledged
> 	command, it shall make sure the command is processed and
> 	resend the completion notification.
> 
> 	Else if the command tag follows the one of the
> 	unacknowledged command, it shall ASSUME the completion
> 	notification was successfully received by the initiator
> 	and that the ACK transmission was lost.  The pending
> 	command shall be implicilty acknowledged by the new
> 	command, and completed by the target.
> 
>         Else the target shall abort it.
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------
> 

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

From shimura at pure.cpdc.canon.co.jp  Fri Jul 24 11:51:09 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:38 2009
Subject: P1394> CONNECTION_STATE(Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
References: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
Message-ID: <199807241551.AAA23539@origin.pure.cpdc.canon.co.jp>


>   E)  CONNECTION_STATE   ( 2 bits unsigned int

I do not think it is necessary for the initiator to control connection
of each direction separately at transport level.

I suppose the initiator can do it by not issuing either
TRANSPORT_I2T_DATA or TRANSPORT_T2I_DATA command, while
uni-directional target may want to declare its capability.

Because we are providing bi-directional transport, I think, whether
clients use it as uni-directional or bi-directional is up to the
clients.

Any suggestions?

Akihiro Shimura

On Mon, 20 Jul 1998 10:05:11 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:

> 
> Grettings all,
> 
> As I have thought about many of the issues and simplifications
> discussed at the July PWG 1394 meeting, I have tried to create
> an overview of the resulting command set.  Before I start modifying
> the Command Set proposal, I would like to hear any concerns you have
> with the revisions.  The overview follows.  Please respond with 
> any feedback before Friday 7/24/98.  I will try to have the
> revised Command Set proposal ready by 8/5/98.  (I cannot have
> it ready a full 2 weeks before the August meeting.)  Thank you
> for your feedback.
> 
> 
> PWG SBP-2-based Transport Command Set
> 7/20/98
> 
> With:
>   - the restrictions imposed by the Microsoft SBP-2 implementation
>   - the desire from Randy Turner (Sharp) for Open & Close commands
>   - the removal of Vendor-specific extension mechanisms
>   - the relabeling of commands with more descriptive names
> 
> the command set transforms into:
> 
>   TRANSPORT_STATUS   {GET_PARAMETER w/ all params tags}
> 
>                      Only valid on T2I data queue, only valid
>                      when in an Unopened Connection state.
> 
>   TRANSPORT_OPEN     {SET PARAMETER LIST w/ all settable parameters}
> 
>                      Contains all "Negotiated" parameter values.
>                      Only valid on I2T data queue, only valid
>                      when in an Unopened Connection state.
> 
>   TRANSPORT_CLOSE    {SET PARAMETER LSIT w/ only Mode parameter}
> 
>                      Closed direction inferred from queue_id bit.
>                      Valid on both queues. Invalid only in the
>                      UnOpened Connection state.
> 
>   TRANSPORT_I2T_DATA {FETCH_DATA}
> 
>                      Valid only on I2T data queue.  Valid only
>                      in the Opened Connection state.  Valid only
>                      while the queue is open.
> 
>   TRANSPORT_T2I_DATA {STORE_DATA}
> 
>                      Valid only on T2I data queue.  Valid only
>                      in the Opened Connection state.  Valid only
>                      while the queue is open.
> 
> the Command Set Model of Use becomes:
> 
>    Login event ---->    UnOpened Conn  [ TRANSPORT_STATUS is OK
> 			|                TRANSPORT_OPEN is OK
> 			|                All other cmds is ERROR ]
>  _______________________|
>  |
>  +-- TRANSPORT_OPEN ->  Opened Conn    [ TRANSPORT_STATUS is ERROR
>                         |   ^ ^          TRANSPORT_CLOSE is OK
>                         |   | |          TRANSPORT_I2T_DATA is OK if
>                         |   | |            I2T direction is Open
>                         |   | |          TRANSPORT_T2I_DATA is OK if
>                         |   | |            T2I direction is Open
> 			|   | |          TRANSPORT_OPEN is ERROR
>  _______________________|   | |
>  |||                        | |
>  ||+- TRANSPORT_CLOSE (I2T) + |
>  ||    && T2I still open      |
>  ||                           |
>  |+-- TRANSPORT_CLOSE (T2I) --+
>  |     && I2T still open
>  |
>  +- TRANSPORT_CLOSE -> Closed Conn     [ TRANSPORT_STATUS is ERROR
>      | I2T & T2I closed                  TRANSPORT_CLOSE is OK
>      |                                   TRANSPORT_I2T_DATA is ERROR
>      |                                   TRANSPORT_T2I_DATA is ERROR
>      +---> Logout                        TRANSPORT_OPEN is ERROR
> 
> The variables associated with TRANSPORT_STATUS become:
> 
>   A)  MAX_TASK_SET_SIZE  (16 bits unsigned int,
>                                   2 is minimum;
>                                   2^14-1 is maximum)
>   B)  MAX_I2T_DATA_SIZE  (31 bits unsigned int)
>   C)  MAX_T2I_DATA_SIZE  (31 bits unsigned int)
>   D)  STREAM_COMPLETION  ( 8 bits unsigned int)
>   E)  CONNECTION_STATE   ( 2 bits unsigned int
>                                   0 => I2T CLOSED, T2I CLOSED;
>                                   1 => I2T OPEN,   T2I CLOSED;
>                                   2 => I2T CLOSED, T2I OPEN;
>                                   3 => I2T OPEN,   T2I OPEN;)
> 
> The target needs to communicate the following specific events
> to the initiator even in the case that no commands are queued.
> 
>   - UNIT ATTENTION: logical unit was reset outside of this Login
> 
>   - Target has closed a communication direction and will reject
>      further TRANSPORT_?2?_DATA commands for that direction.
>      When all directions are closed, then target is should
>      Logout ASAP.  (The target shall only successfully execute
>      TRANSPORT_STATUS commands.)
> 
>   Since an initiator can not leave a TRANSPORT_T2I_DATA command
>   enqueued when the T2I direction is closed, this data must be
>   communicated via the Unsolicited Status mechanism.  Also, since
>   an Initiator may not even exist on the bus (due to a transient
>   link interruption) when either of these events happens, they
>   must be buffered.
> 
> 
> Now, error recovery for when a target detects an ACK Timeout on a
> Status FIFO write requires some special considerations.  When
> this condition happens the initiator and target may be
> out-of-sync with each other, and the SBP-2 protocol does not
> provide a mechanism for the initiator to determine that the
> condition exists.  The problem breaks down to two issues:
> 
>   Initiator Detection:
>     Because this condition is expected to happen _extremely_
>     infrequently, it is expected that a Bus Reset mechanism
>     is a reasonable way of forcing the initiator to resynchronize
>     with the target.
> 
>   Recovery:
>     To recover from this condition, the target needs to infer
>     whether or not the initiator received the completion notification(s).
> 
>       If the initiator did, the target may release the resources
>       or take the appropriate action assocaited with the command(s).
> 
>       If the initiator did not, the target must determine whether
>       or not the same command (sequence, and associated data) is
>       restored to the execution queue.
> 
> 	If the same sequence is not restored to the front of the
>         queue, then the target should ignore all previous commands
>         and re-execute them.
> 
> 	If the same sequence is restored, then the target need
> 	not reprocess the entire command and data block.  It
> 	simply needs to know where it left off within the
> 	transfers.
> 
>     This makes it reasonable to employ a command tag, used to
>     uniquely identify each previously active command within the
>     implicilty aborted task set, and new commands which were not
>     in the previously active task set.
> 
>     Unfortunately, SBP-2 requires targets to support the ABORT TASK
>     function, and the process described for aborting tasks causes
>     previously valid commands to be turned into Dummy ORBs.  This
>     effectively removes the command tag from the ORB, so the
>     queue's Execution Agent no longer sees command tags as
>     sequential even if they were assigned sequentially.
> 
>       It may be reasonable for a target to enforce seeing
>       sequential command tags in order to recover from this
>       situation.  If the queue's Execution Agent completed
>       all commands in that queue with a status of "ABORTED -
>       UNEXPECTED COMMAND TAG VALUE", then the initiator has
>       a chance to recover from the situation.  This also means
>       that an ABORT TASK function causes all successive commands
>       on the associated queue to be aborted without affecting
>       the other queue.
>       
>     This brings us to the following policies:
> 
>       A)  A target shall enforce sequential command tag values.
>       B)  Initial command tag values shall be established by the
>             first command placed on each queue.
>       C)  ABORT TASK shall indirectly cause the rest of the
>             command queue to be aborted without affecting
>             the other command queue.
>       D)  Initiators shall retire a command tag until
>             it receives a successful completion notification
>             for a following command on the associated queue.
>             Once that following successful notification has
>             been received, the command tag may be reused.
>       E)  Targets shall invalidate a command tag when
>             the completion notification for the associated
>             ORB has been succesfully acknowledged.
> 
>     These policies allow the target to use the algorithm below
>     to recover synchronization:
> 
>       If the target is not in a missing status FIFO ACK error
>       recovery situation, it shall examine the command at the
>       head of the queue and:
> 
>         process it if it is either the first command enqueued
>         on this queue since Login, or has a command tag immediately
>         following the one of the last successfully completed command.
> 
>         otherwise, abort it.
> 
>       If the target is in a missing status FIFO ACK error
>       recovery situation, it shall examine the command at the
>       head of the queue and:
> 
> 	If the command tag matches the one of the unacknowledged
> 	command, it shall make sure the command is processed and
> 	resend the completion notification.
> 
> 	Else if the command tag follows the one of the
> 	unacknowledged command, it shall ASSUME the completion
> 	notification was successfully received by the initiator
> 	and that the ACK transmission was lost.  The pending
> 	command shall be implicilty acknowledged by the new
> 	command, and completed by the target.
> 
>         Else the target shall abort it.
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------
> 

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

From gregs at sdd.hp.com  Fri Jul 24 12:32:52 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:38 2009
Subject: P1394> MAX_?2?_DATA_SIZE(Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807241534.AAA23522@origin.pure.cpdc.canon.co.jp> from "Akihiro Shimura" at Jul 25, 98 00:34:11 am
Message-ID: <199807241632.JAA15696@hpsdlgj1.sdd.hp.com>


It was acknowledged at the July meeting that these parameters
do NOT need to go across the wire in order to have a functioning
protocol.

A strong desire was expressed to have these parameters go
across the wire in order for initiator and target to more
effeciently use their respective memory resources.  These
are there as a concession to that desire.

MAX_I2T_DATA_SIZE indicates the maximum amount of
target-to-initiator data the target can buffer and retransmit for
this connection across an 

  MAX_T2I_DATA_SIZE is the maximum amount of target-to-initiator
  data the target will buffer and retransmit across this
  connection if the Task is implicilty or explicitly aborted
  (e.g.  Bus Reset or TASK SET ABORT).  Any memory allocated by
  the initiator beyond this amount is wasted, since it will never
  be used.  Similarly, if an initiator only provides memory
  buffers much smaller than those indicated by the target, the
  target may be able to manage it's internal memory more
  effeciently.

  MAX_I2T_DATA_SIZE is there for symmetry.

Greg Shue, HP

Akihiro Shimura wrote:

> >   B)  MAX_I2T_DATA_SIZE  (31 bits unsigned int)
> >   C)  MAX_T2I_DATA_SIZE  (31 bits unsigned int)
> 
> It is still not clear for me what is specified for initiator and/or
> target by these parameters.
> 
> Size of the "buffer" referred by data_descriptor field of an ORB will
> be determined along with requesting client of the initiator. Once the
> ORB is appended to task list, access right to the "buffer" is granted
> to the target, and the "buffer" looks like (remote) receiving/sending
> buffer of the target. The target can access any part of the "buffer"
> within the address range of the "buffer" in arbitrary size unit the
> target wants to handle.
> 
> I think the size of the "buffer" referred by the ORB and the size
> unit that target processes the "buffer" are independent of each other.
> 
> Could you explain why these parameters need to go across the wire?
> 
> Akihiro Shimura


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From gregs at sdd.hp.com  Fri Jul 24 13:07:25 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:38 2009
Subject: P1394> CONNECTION_STATE(Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807241551.AAA23539@origin.pure.cpdc.canon.co.jp> from "Akihiro Shimura" at Jul 25, 98 00:51:09 am
Message-ID: <199807241707.KAA15733@hpsdlgj1.sdd.hp.com>


As I thought about your observation, the only case which might
need CONNECTION_STATE is when the connection is opened
unidirecitonally.  I suppose unidirectional communication could
be determined from the MAX_I2T_DATA_SIZE and MAX_T2I_DATA_SIZE
parameters.  We need one or the other for this case.

If this is the only case, then I'll remove CONNECTION_STATE
and keep both MAX_I2T_DATA_SIZE and MAX_T2I_DATA_SIZE.

Can anyone else think of a case where the message or stream
transport needs to go from bi- to uni-directional before closing?
If so, respond before 8/3/98 or else I'll remove it from the
command set proposal.

- Greg Shue, HP

Akihiro Shimura wrote:

> 
> >   E)  CONNECTION_STATE   ( 2 bits unsigned int
> 
> I do not think it is necessary for the initiator to control connection
> of each direction separately at transport level.
> 
> I suppose the initiator can do it by not issuing either
> TRANSPORT_I2T_DATA or TRANSPORT_T2I_DATA command, while
> uni-directional target may want to declare its capability.
> 
> Because we are providing bi-directional transport, I think, whether
> clients use it as uni-directional or bi-directional is up to the
> clients.
> 
> Any suggestions?


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From bob at sismicro.com  Fri Jul 24 13:36:11 1998
From: bob at sismicro.com (Robert Morford)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Revised PWG1394 Cmd Set
References: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
Message-ID: <35B8C60B.1C04D19B@sismicro.com>

Greg Shue wrote:
>
> The target needs to communicate the following specific events
> to the initiator even in the case that no commands are queued.
> 
>   - UNIT ATTENTION: logical unit was reset outside of this Login
> 
>   - Target has closed a communication direction and will reject
>      further TRANSPORT_?2?_DATA commands for that direction.
>      When all directions are closed, then target is should
>      Logout ASAP.  (The target shall only successfully execute
>      TRANSPORT_STATUS commands.)

Does this statement imply that the initiator doesn't need to
do a logout if it does both TRANSPORT_CLOSE(I2T) and (T2I)?
Perhaps you could reword "then target is should Logout ASAP"
to "Initiator should Logout ASAP" (since there are no other
valid actions).

-- 
Bob Morford (bob@sismicro.com)
SIS Microelectronics, Inc.
A Subsidiary of Aspec Technology, Inc.
1831 Lefthand Cir., Suite #E
Longmont, CO 80501
303-776-1667 x226

From gregs at sdd.hp.com  Fri Jul 24 13:45:38 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Revised PWG1394 Cmd Set
In-Reply-To: <98072322090601.AKG5A71@smtp.venus.dti.ne.jp> from "Fumio Nagasaka" at Jul 23, 98 10:09:46 pm
Message-ID: <199807241745.KAA15773@hpsdlgj1.sdd.hp.com>


Fumio Nagasaka wrote:
> 
> 1. Is a "command tag" same as a "transaction number" ?

It's the same idea, but at a different scope.  As I was
working out the draft I knew we needed to uniquely identfy
each command, no matter what sequence it arrived in.  These
didn't degrade to being sequential until parameters could
only be read before openning a connection.

(Otherwise we may end up with the problem of needing to
read a parameter to do error recovery before we can continue.
The command to read a parameter gets put into the command
stream before continuing the previously aborted commands.
Does this command get the first sequence number expected
by the target and associated with a previously queued command,
or does it get a tag which may be out-of-sequence?)

> 2. Do you really believe a target device can fail to 
>    receive an ack-packet?

Yes.  Do I really believe that a target device can fail to
receive an ack-packet without receiving a bus reset?  Yes,
but it's _extremely_ unlikely unless it's during product
development.  In that case, all bets are off.  :-)

> 3. I would like to suggest three commands listed below;
> 	TRANSPORT_I2T_ABORT
> 	TRANSPORT_T2I_ABORT
> 	TRANSPORT_ORB_RELEASE
> 
> 3.1. TRANSPORT_I2T_ABORT
> 	An initiator requests a target to stop ORB fetching, 
> 	and solicits the target to reply STATUS block when
> 	the last ORB had been executed.

I probably don't understand this one.

  Since we're using the UNORDERED model, all the ORBs on the
  task list have been fetched by the target as soon as they
  are placed on it.  There is no point to issuing this command.

  This command would really need to be issued as a vendor-specific
  Management Agent command, since it needs to be executed
  asynchronously to the two ordered execution queues or
  else a third queue needs to be defined.

  Using the ABORT TASK management function defined by SBP-2
  beginning with the last task in the queue will do the same
  thing if you want a queue-specific function.  

I don't think this provides any additional usefulness and
significantly changes the device model.  What am I missing?

> 
> 3.2. TRANSPORT_T2I_ABORT
> 	A target requests an initiator to stop appending new
> 	ORBs on outstanding linked list. The initiator may
> 	invoke "close" command when it received STATUS bock
> 	associated with the last ORB.

I don't understand this one either.

  A target knows what is the last ORB on the queue when the
  target's transport client gives the appropriate indication.

  We can make a target capable of indicating a direction close
  synchronous with a TRANSPORT_T2I_DATA completion.  All subsequent
  TRANSPORT_T2I_DATA commands are completed with a status of
  connection closed.

I don't see the need for this command either.  Can you explain
this one better?

> 3.3. TRANSPORT_ORB_RELEASE
> 	A target request an initiator to release specified ORB
> 	without completion STATUS block.

"I don't understand this one either."

  This command would really need to be issued as a vendor-specific
  Management Agent command, since it needs to be executed
  asynchronously to the two ordered execution queues or
  else a third queue needs to be defined.

  This sounds identical to ABORT TASK.

What am I missing?

I don't want to re-invent and re-implement SBP-2.  The goal is
to supplement it as little as possible.

-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From gregs at sdd.hp.com  Fri Jul 24 13:48:24 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Revised PWG1394 Cmd Set
In-Reply-To: <35B8C60B.1C04D19B@sismicro.com> from "Robert Morford" at Jul 24, 98 10:36:11 am
Message-ID: <199807241748.KAA15785@hpsdlgj1.sdd.hp.com>

> 
> Greg Shue wrote:
> >
> > The target needs to communicate the following specific events
> > to the initiator even in the case that no commands are queued.
> > 
> >   - UNIT ATTENTION: logical unit was reset outside of this Login
> > 
> >   - Target has closed a communication direction and will reject
> >      further TRANSPORT_?2?_DATA commands for that direction.
> >      When all directions are closed, then target is should
> >      Logout ASAP.  (The target shall only successfully execute
> >      TRANSPORT_STATUS commands.)
> 
> Does this statement imply that the initiator doesn't need to
> do a logout if it does both TRANSPORT_CLOSE(I2T) and (T2I)?
> Perhaps you could reword "then target is should Logout ASAP"
> to "Initiator should Logout ASAP" (since there are no other
> valid actions).

Hmm, did I say this was a "rough" draft?
If not, I should have.  Good catch.  Thanks.  :-)

> -- 
> Bob Morford (bob@sismicro.com)
> SIS Microelectronics, Inc.
> A Subsidiary of Aspec Technology, Inc.
> 1831 Lefthand Cir., Suite #E
> Longmont, CO 80501
> 303-776-1667 x226


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From bob at sismicro.com  Fri Jul 24 17:03:29 1998
From: bob at sismicro.com (Robert Morford)
Date: Wed May  6 14:00:38 2009
Subject: STREAM_COMPLETION (Was Re: P1394> Revised PWG1394 Cmd Set)
References: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
Message-ID: <35B8F6A1.8DE24F2D@sismicro.com>

Greg Shue wrote:
>
> The variables associated with TRANSPORT_STATUS become:
> 
>   A)  MAX_TASK_SET_SIZE  (16 bits unsigned int,
>                                   2 is minimum;
>                                   2^14-1 is maximum)
>   B)  MAX_I2T_DATA_SIZE  (31 bits unsigned int)
>   C)  MAX_T2I_DATA_SIZE  (31 bits unsigned int)
>   D)  STREAM_COMPLETION  ( 8 bits unsigned int)
>   E)  CONNECTION_STATE   ( 2 bits unsigned int
>                                   0 => I2T CLOSED, T2I CLOSED;
>                                   1 => I2T OPEN,   T2I CLOSED;
>                                   2 => I2T CLOSED, T2I OPEN;
>                                   3 => I2T OPEN,   T2I OPEN;)

Greg -

You didn't discuss the STREAM_COMPLETION variable in your
"Revised PWG1394 CMD Set note, although I'm guessing it's 
related to the question I raised (and my subsequent action 
item) about whether there needs to be some negotiation over 
strategies for pre-maturely completing stream-oriented ORBs. 
(See page 8 of PWG 1394 Transport Command Set Proposal Rev. 
0c:  TO BE DETERMINED - When else should a target complete 
this command? (e.g. "Flush" requested from target's 
transport client; the target can no longer retain the data 
for retransmission).)

The Store Data Command Response status block provides
a field called "residue".  The Command Set Proposal
indicates that the meaning of "residue" depends upon
whether "message-based communication" is being used
or "stream-based communication" is being used between
host and device.  As I understand it, "message-based
communication" implies that the initiator knows when
the target has data to send, but doesn't necessarily
know the length of the data.  For the target, the
size of the data is reasonably predicable.  "Stream-based 
communication" allows more initiation on the part of
the target, so that the initiator must post a Store
Data ORB, to support the possibility that the target
will have data to transfer.

I think the question to be answered is whether there needs
to be negotiation between target and initiator (or maybe
just information from target to initiator) over when, under 
stream-based comm., the target is allowed to complete the 
Store Data Orb.  As I thought about this, the only reasons
that I identified for termination were application 
related.  And the application (transport client in the
device) seemed to have it's own good reason.

So, what was the intent for the STREAM_COMPLETION
variable?  Is there something I'm missing related
to the early completion of Store Data Commands
for stream-based communication?

-- 
Bob Morford (bob@sismicro.com)
SIS Microelectronics, Inc.
A Subsidiary of Aspec Technology, Inc.
1831 Lefthand Cir., Suite #E
Longmont, CO 80501
303-776-1667 x226

From shimura at pure.cpdc.canon.co.jp  Mon Jul 27 09:59:14 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:38 2009
Subject: P1394> MAX_?2?_DATA_SIZE(Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807241632.JAA15696@hpsdlgj1.sdd.hp.com>
References: <199807241534.AAA23522@origin.pure.cpdc.canon.co.jp> <199807241632.JAA15696@hpsdlgj1.sdd.hp.com>
Message-ID: <199807271359.WAA19952@origin.pure.cpdc.canon.co.jp>


On Fri, 24 Jul 1998 09:32:52 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:

> It was acknowledged at the July meeting that these parameters
> do NOT need to go across the wire in order to have a functioning
> protocol.
> 
> A strong desire was expressed to have these parameters go
> across the wire in order for initiator and target to more
> effeciently use their respective memory resources.  These
> are there as a concession to that desire.

So, these two parameters do not specify the transport behavior itself
and are only referenced by client application of the initiator, right?

If so, your descriptions seem to me to be misleading.
I feel the descriptions of these parameters sound like followings,
though I am still not sure these descriptions make sense.

  MAX_I2T_DATA_SIZE indicates the maximum amount of
  initiator-to-target data the client of target is willing to receive
  in one buffer. This parameter does not limit buffer size itself,
  and may be reported to the client of initiator.
  If this value is zero, target shall reject TRANSPORT_I2T_DATA
  command.

  MAX_T2I_DATA_SIZE indicates the maximum amount of
  target-to-initiator data the client of target is willing to send in
  one buffer. This parameter does not limit buffer size itself, and
  may be reported to the client of initiator.
  If this value is zero, target shall reject TRANSPORT_T2I_DATA
  command.

>   MAX_T2I_DATA_SIZE is the maximum amount of target-to-initiator
>   data the target will buffer and retransmit across this
>   connection if the Task is implicilty or explicitly aborted
>   (e.g.  Bus Reset or TASK SET ABORT).  Any memory allocated by

>From the error recovery model we discussed, above value may be
smaller than the size of buffer pointed by the ORB, and may minimally
be payload size of block transaction.

>   the initiator beyond this amount is wasted, since it will never
>   be used.  Similarly, if an initiator only provides memory
>   buffers much smaller than those indicated by the target, the
>   target may be able to manage it's internal memory more
>   effeciently.

On the other hand, above statement implies the size of buffer pointed
by the ORB itself.

So, this description seems to me to be conflicting.

I may be still missing something. Any suggestion?

Akihiro Shimura

>   MAX_I2T_DATA_SIZE is there for symmetry.
> 
> Greg Shue, HP
> 
> Akihiro Shimura wrote:
> 
> > >   B)  MAX_I2T_DATA_SIZE  (31 bits unsigned int)
> > >   C)  MAX_T2I_DATA_SIZE  (31 bits unsigned int)
> > 
> > It is still not clear for me what is specified for initiator and/or
> > target by these parameters.
> > 
> > Size of the "buffer" referred by data_descriptor field of an ORB will
> > be determined along with requesting client of the initiator. Once the
> > ORB is appended to task list, access right to the "buffer" is granted
> > to the target, and the "buffer" looks like (remote) receiving/sending
> > buffer of the target. The target can access any part of the "buffer"
> > within the address range of the "buffer" in arbitrary size unit the
> > target wants to handle.
> > 
> > I think the size of the "buffer" referred by the ORB and the size
> > unit that target processes the "buffer" are independent of each other.
> > 
> > Could you explain why these parameters need to go across the wire?
> > 
> > Akihiro Shimura
> 
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------
> 

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.


From shimura at pure.cpdc.canon.co.jp  Mon Jul 27 10:01:05 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Recovery (Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
References: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
Message-ID: <199807271401.XAA19959@origin.pure.cpdc.canon.co.jp>


On Mon, 20 Jul 1998 10:05:11 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:
(snip)
>   Recovery:
(snip)
>     Unfortunately, SBP-2 requires targets to support the ABORT TASK
>     function, and the process described for aborting tasks causes
>     previously valid commands to be turned into Dummy ORBs.  This
>     effectively removes the command tag from the ORB, so the
>     queue's Execution Agent no longer sees command tags as
>     sequential even if they were assigned sequentially.

As far as I understand, in Monterey, we have discussed to make the
range of sequence identifier fairly larger than the range of
MAX_TASK_SET_SIZE to make it possible for target to determine, from
the sign of distance between two sequence identifiers (target is
expecting and specified by initiator), whether initiator is
synchronized, behind by missing packet or ahead by Abort Task.

The fairly large range of sequence identifier may not be enough for
the target to handle the gap between sequence identifiers caused by
Abort Task because the gap may infinitely grow.

The initiator is already limiting the number of ORB's not to exceed
maximum reorderable number.
By making this condition a little severe, I think we can avoid
unrecoverable situation without retry interaction between initiator
and target.

The descriptive condition will be as follows;

  The initiator limits 
    the number of ORB's not to exceed maximum reorderable number,
    "AND"
    to append the ORB that has sequence identifier target can identify
    as ahead from last completed one.
  "OR"
  If there is no outstanding ORB for the queue, the initiator appends
  ORB that has sequence identifier adjusted to the next number of last
  completed one.

The conditional expression will be as follows;

  IF ((Number of outstanding ORB for the queue)
      <= (MAX_TASK_SET_SIZE - n))
     AND
     ((((appending sequence id)-(last completed sequence id)) MOD (2^m))
      < (2^(m-1)))
  THEN append ORB with (appending sequence id)
  ELSE
  IF ((Number of outstanding ORB for the queue) = 0)
  THEN adjust (appending sequence id) to (last completed sequence
  id) + 1 and append ORB, 

  where "n" is room for another queue, and "m" is number of bit of
  sequence id.
  
If the target finds initiator is ahead, target can simply update
recorded identifier with the new value specified by the initiator.

So, I do not think the following policy (and so on) is necessary.

>       A)  A target shall enforce sequential command tag values.

Am I missing something?

Akihiro Shimura
--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.


From gregs at sdd.hp.com  Mon Jul 27 11:48:56 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:38 2009
Subject: STREAM_COMPLETION (Was Re: P1394> Revised PWG1394 Cmd Set)
In-Reply-To: <35B8F6A1.8DE24F2D@sismicro.com> from "Robert Morford" at Jul 24, 98 02:03:29 pm
Message-ID: <199807271548.IAA22002@hpsdlgj1.sdd.hp.com>


> Greg -
> 
> You didn't discuss the STREAM_COMPLETION variable in your
> "Revised PWG1394 CMD Set note, although I'm guessing it's 
> related to the question I raised (and my subsequent action 
> item) about whether there needs to be some negotiation over 
> strategies for pre-maturely completing stream-oriented ORBs. 
> (See page 8 of PWG 1394 Transport Command Set Proposal Rev. 
> 0c:  TO BE DETERMINED - When else should a target complete 
> this command? (e.g. "Flush" requested from target's 
> transport client; the target can no longer retain the data 
> for retransmission).)

You are correct.  I didn't.  It should be in a final draft.


> host and device.  As I understand it, "message-based
> communication" implies that the initiator knows when
> the target has data to send, but doesn't necessarily
> know the length of the data.

The model we have been using is that a message is a
bounded set of data to be transferred within one ORB.
It is to be transferred as a composite whole, and may
be transferred at any time.  The idea is best described
as a "reliable point-to-point datagram service".  So the
receiver doesn't know when a message will come or how
long it is.  It just knows the maximum length of any single
message, and that the whole message will be transferred
within one ORB.  The size of the message is limited by
primarily by the command set used, and otherwise limited
by the packet negotiation size (if the command set takes
care of de/fragmentation).

> "Stream-based 
> communication" allows more initiation on the part of
> the target, so that the initiator must post a Store
> Data ORB, to support the possibility that the target
> will have data to transfer.

A STORE DATA (or TRANSPORT_I2T_DATA) ORB will have to
be posted whether it's a message or stream connection.
It's the only means to move data from the Target to the
Initiator.  :-)

> I think the question to be answered is whether there needs
> to be negotiation between target and initiator (or maybe
> just information from target to initiator) over when, under 
> stream-based comm., the target is allowed to complete the 
> Store Data Orb.  As I thought about this, the only reasons
> that I identified for termination were application 
> related.  And the application (transport client in the
> device) seemed to have it's own good reason.

This is the essence of the issue.  In Stream-based communication,
a target could complete an ORB:

  as soon as _any_ data is available (possibly wasting bus
    bandwidth)

  only when it must (full or target internally blocked because
    output must be sent before proceeding).

  or anywhere in between.

> So, what was the intent for the STREAM_COMPLETION
> variable?  Is there something I'm missing related
> to the early completion of Store Data Commands
> for stream-based communication?

If commands are completed immediately, then extra bus
bandwidth is consumed for having to requeue additional
ORBs.

Does this help?

> -- 
> Bob Morford (bob@sismicro.com)
> SIS Microelectronics, Inc.
> A Subsidiary of Aspec Technology, Inc.
> 1831 Lefthand Cir., Suite #E
> Longmont, CO 80501
> 303-776-1667 x226
> 


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From bob at sismicro.com  Mon Jul 27 12:05:44 1998
From: bob at sismicro.com (Robert Morford)
Date: Wed May  6 14:00:38 2009
Subject: STREAM_COMPLETION (Was Re: P1394> Revised PWG1394 Cmd Set)
References: <199807271548.IAA22002@hpsdlgj1.sdd.hp.com>
Message-ID: <35BCA558.D2B7FC2@sismicro.com>

Greg Shue wrote:
>
> > I think the question to be answered is whether there needs
> > to be negotiation between target and initiator (or maybe
> > just information from target to initiator) over when, under
> > stream-based comm., the target is allowed to complete the
> > Store Data Orb.  As I thought about this, the only reasons
> > that I identified for termination were application
> > related.  And the application (transport client in the
> > device) seemed to have it's own good reason.
> 
> This is the essence of the issue.  In Stream-based communication,
> a target could complete an ORB:
> 
>   as soon as _any_ data is available (possibly wasting bus
>     bandwidth)
> 
>   only when it must (full or target internally blocked because
>     output must be sent before proceeding).
> 
>   or anywhere in between.

It seems that the second case must be determined by the application 
(transport client).  If you allow the application to decide, then
is there really any point in negotiation?

Was this the point of "STREAM_COMPLETION" or did you have something
else in mind?

-- 
Bob Morford (bob@sismicro.com)
SIS Microelectronics, Inc.
A Subsidiary of Aspec Technology, Inc.
1831 Lefthand Cir., Suite #E
Longmont, CO 80501
303-776-1667 x226

From gregs at sdd.hp.com  Mon Jul 27 12:26:16 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:38 2009
Subject: P1394> MAX_?2?_DATA_SIZE(Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807271359.WAA19952@origin.pure.cpdc.canon.co.jp> from "Akihiro Shimura" at Jul 27, 98 10:59:14 pm
Message-ID: <199807271626.JAA22234@hpsdlgj1.sdd.hp.com>

> 
> 
> On Fri, 24 Jul 1998 09:32:52 -0700 (PDT)
> Greg Shue <gregs@sdd.hp.com> wrote:
> 
> > It was acknowledged at the July meeting that these parameters
> > do NOT need to go across the wire in order to have a functioning
> > protocol.
> > 
> > A strong desire was expressed to have these parameters go
> > across the wire in order for initiator and target to more
> > effeciently use their respective memory resources.  These
> > are there as a concession to that desire.
> 
> So, these two parameters do not specify the transport behavior itself
> and are only referenced by client application of the initiator, right?

Perhaps the better description is that these parameters _clarify_
transport behavior.  They communicate how the data can/will be moved
across the wire.  This information can be used by both the target
and intiator protocol drivers in order to more efficiently manage
it's own resources.  If this information was not communicated,
the behavior of information transfer across the wire would still
be the same, but much more memory may be reserved for buffering than
is ever used.

> I feel the descriptions of these parameters sound like followings,
> though I am still not sure these descriptions make sense.
> 
>   MAX_I2T_DATA_SIZE indicates the maximum amount of
>   initiator-to-target data the client of target is willing to receive
>   in one buffer. This parameter does not limit buffer size itself,
>   and may be reported to the client of initiator.
>   If this value is zero, target shall reject TRANSPORT_I2T_DATA
>   command.
> 
>   MAX_T2I_DATA_SIZE indicates the maximum amount of
>   target-to-initiator data the client of target is willing to send in
>   one buffer. This parameter does not limit buffer size itself, and
>   may be reported to the client of initiator.
>   If this value is zero, target shall reject TRANSPORT_T2I_DATA
>   command.

Essentially, you are correct.  These parameters only make sense
when you start to consider memory usage optimizations on both intiator
and target ends.  Without these numbers (other than for zero/non-zero
values), memory could be very unequally allocated by each end.

> >   MAX_T2I_DATA_SIZE is the maximum amount of target-to-initiator
> >   data the target will buffer and retransmit across this
> >   connection if the Task is implicilty or explicitly aborted
> >   (e.g.  Bus Reset or TASK SET ABORT).  Any memory allocated by
> 
> >From the error recovery model we discussed, above value may be
> smaller than the size of buffer pointed by the ORB, and may minimally
> be payload size of block transaction.

I don't think that an SBP-2 target can require that the same
physical memory be tied to a requeued TRANSPORT_T2I_DATA ORB.
So a target must assume that the memory does NOT contain any
previously written data, and so must rewrite the entire valid
contents.  The size of the acutal data being transported may
always be less than the indicated MAX_T2I_DATA_SIZE (unless
the max size is 1 Byte!).  The actual minimum valid data size
is 1 byte.  It still takes a 1 quadlet transaction.

> On the other hand, above statement implies the size of buffer pointed
> by the ORB itself.

Yes, the MAX size is the maximum size of the buffer pointed to
by the ORB itself.

> So, this description seems to me to be conflicting.
> 
> I may be still missing something. Any suggestion?

Yes, can someone else try to describe this?  Unfortunately, I am
as confused with your misunderstandings as you are with my
descriptions!

> Akihiro Shimura


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From gregs at sdd.hp.com  Mon Jul 27 13:13:31 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Recovery (Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807271401.XAA19959@origin.pure.cpdc.canon.co.jp> from "Akihiro Shimura" at Jul 27, 98 11:01:05 pm
Message-ID: <199807271713.KAA22270@hpsdlgj1.sdd.hp.com>


Akihiro Shimura wrote:

> The initiator is already limiting the number of ORB's not to exceed
> maximum reorderable number.

(... number of ORBs in the active task set...)

> By making this condition a little severe, I think we can avoid
> unrecoverable situation without retry interaction between initiator
> and target.
> 
> The descriptive condition will be as follows;
> 
>   The initiator limits 
>     the number of ORB's not to exceed maximum reorderable number,
>     "AND"
>     to append the ORB that has sequence identifier target can identify
>     as ahead from last completed one.
>   "OR"
>   If there is no outstanding ORB for the queue, the initiator appends
>   ORB that has sequence identifier adjusted to the next number of last
>   completed one.
> 
> The conditional expression will be as follows;
> 
>   IF ((Number of outstanding ORB for the queue)
>       <= (MAX_TASK_SET_SIZE - n))

(... the first part is always true!)

>      AND
>      ((((appending sequence id)-(last completed sequence id)) MOD (2^m))
>       < (2^(m-1)))
>   THEN append ORB with (appending sequence id)
>   ELSE
>   IF ((Number of outstanding ORB for the queue) = 0)
>   THEN adjust (appending sequence id) to (last completed sequence
>   id) + 1 and append ORB, 
> 
>   where "n" is room for another queue, and "m" is number of bit of
>   sequence id.

Unfortunately, the target isn't going to always recieve
sequence numbers which are monotonically increasing.  This is
the consequence of an ABORT_TASK applied to the middle of
a queue.  The "sequence number" space has suddenly become
sparse!

Suddenly a sequence number space >> MAX_TASK_SET_SIZE doesn't
guarantee that we can detect order in an error recovery
situation.  Both ends may differ as to where they believe the
"last completed sequence number" is!

> If the target finds initiator is ahead, target can simply update
> recorded identifier with the new value specified by the initiator.
>
> Am I missing something?

I think so.  Start aborting single tasks from the middle of a
queue and watch what happens to the "sequence numbers" from the
target's perspective.

SBP-2 requires the support of ABORT TASK.

-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From gregs at sdd.hp.com  Mon Jul 27 13:27:32 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:38 2009
Subject: STREAM_COMPLETION (Was Re: P1394> Revised PWG1394 Cmd Set)
In-Reply-To: <35BCA558.D2B7FC2@sismicro.com> from "Robert Morford" at Jul 27, 98 09:05:44 am
Message-ID: <199807271727.KAA22290@hpsdlgj1.sdd.hp.com>

Bob Morford (bob@sismicro.com) wrote:

> Greg Shue wrote:
> >
> > > I think the question to be answered is whether there needs
> > > to be negotiation between target and initiator (or maybe
> > > just information from target to initiator) over when, under
> > > stream-based comm., the target is allowed to complete the
> > > Store Data Orb.  As I thought about this, the only reasons
> > > that I identified for termination were application
> > > related.  And the application (transport client in the
> > > device) seemed to have it's own good reason.
> > 
> > This is the essence of the issue.  In Stream-based communication,
> > a target could complete an ORB:
> > 
> >   as soon as _any_ data is available (possibly wasting bus
> >     bandwidth)
> > 
> >   only when it must (full or target internally blocked because
> >     output must be sent before proceeding).
> > 
> >   or anywhere in between.
> 
> It seems that the second case must be determined by the application 
> (transport client).  If you allow the application to decide, then
> is there really any point in negotiation?
> 
> Was this the point of "STREAM_COMPLETION" or did you have something
> else in mind?

The point was some policy needed to be defined to have consistent
implementations.  I just couldn't make the call on my own about
where that responsibility lies or what the policy should be.
If the policy becomes that the target will pass along as much
data as it can as quickly as it can it may be sufficient.  (Though
we could end up with many small transactions rather than a few large
ones when data trickles out.)

As long as you can get people to agree on something, it's probably
fine with me.  :-)


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From shimura at pure.cpdc.canon.co.jp  Mon Jul 27 18:49:16 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Recovery (Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807271713.KAA22270@hpsdlgj1.sdd.hp.com>
References: <199807271401.XAA19959@origin.pure.cpdc.canon.co.jp> <199807271713.KAA22270@hpsdlgj1.sdd.hp.com>
Message-ID: <199807272249.HAA20510@origin.pure.cpdc.canon.co.jp>

See comment below,

On Mon, 27 Jul 1998 10:13:31 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:

> Akihiro Shimura wrote:
> 
> > The initiator is already limiting the number of ORB's not to exceed
> > maximum reorderable number.
> 
> (... number of ORBs in the active task set...)
> 
> > By making this condition a little severe, I think we can avoid
> > unrecoverable situation without retry interaction between initiator
> > and target.
> > 
> > The descriptive condition will be as follows;
> > 
> >   The initiator limits 
> >     the number of ORB's not to exceed maximum reorderable number,
> >     "AND"
> >     to append the ORB that has sequence identifier target can identify
> >     as ahead from last completed one.
> >   "OR"
> >   If there is no outstanding ORB for the queue, the initiator appends
> >   ORB that has sequence identifier adjusted to the next number of last
> >   completed one.
> > 
> > The conditional expression will be as follows;
> > 
> >   IF ((Number of outstanding ORB for the queue)
> >       <= (MAX_TASK_SET_SIZE - n))
> 
> (... the first part is always true!)

The initiator is responsible to make the first part true. The
condition represents the way initiator decides to append ORB or not.

> >      AND
> >      ((((appending sequence id)-(last completed sequence id)) MOD (2^m))
> >       < (2^(m-1)))
> >   THEN append ORB with (appending sequence id)
> >   ELSE
> >   IF ((Number of outstanding ORB for the queue) = 0)
> >   THEN adjust (appending sequence id) to (last completed sequence
> >   id) + 1 and append ORB, 
> > 
> >   where "n" is room for another queue, and "m" is number of bit of
> >   sequence id.
> 
> Unfortunately, the target isn't going to always recieve
> sequence numbers which are monotonically increasing.  This is
> the consequence of an ABORT_TASK applied to the middle of
> a queue.  The "sequence number" space has suddenly become
> sparse!

Above condition
> >      ((((appending sequence id)-(last completed sequence id)) MOD (2^m))
> >       < (2^(m-1)))
prevents the sequence number distance to become "too" apart for the
target to distinguish the initiator is ahead or behind.

> Suddenly a sequence number space >> MAX_TASK_SET_SIZE doesn't
> guarantee that we can detect order in an error recovery
> situation.  Both ends may differ as to where they believe the
> "last completed sequence number" is!

The "last completed sequence number" means the number the
"initiator" is recognizing.
Because (a sequence number space >> MAX_TASK_SET_SIZE) does not
guarantee successful detection, additional condition is necessary
to safely append ORB.

The distance between "last completed sequence id(that initiator is
recognizing)" and "appending sequence id(initiator is going to
append ORB with this id)" is always greater than the distance
between "the sequence id target derives from ORB" and "the sequence
id target is expecting to derive".
This makes target detect ahead or behind successfully.

> > If the target finds initiator is ahead, target can simply update
> > recorded identifier with the new value specified by the initiator.
> >
> > Am I missing something?
> 
> I think so.  Start aborting single tasks from the middle of a
> queue and watch what happens to the "sequence numbers" from the
> target's perspective.

>From this observation, I have made additional condition.

> 
> SBP-2 requires the support of ABORT TASK.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------
> 

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

From fumiona at venus.dtinet.or.jp  Mon Jul 27 20:26:16 1998
From: fumiona at venus.dtinet.or.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Revised PWG1394 Cmd Set
In-Reply-To: <199807241745.KAA15773@hpsdlgj1.sdd.hp.com>
References: <199807241745.KAA15773@hpsdlgj1.sdd.hp.com>
Message-ID: <98072809243001.AKG35F1@smtp.venus.dti.ne.jp>

Greg Shue wrote:
>
>Fumio Nagasaka wrote:
>
>> 3.1. TRANSPORT_I2T_ABORT
>> 	An initiator requests a target to stop ORB fetching, 
>> 	and solicits the target to reply STATUS block when
>> 	the last ORB had been executed.
>
>I probably don't understand this one.
>
>  Since we're using the UNORDERED model, all the ORBs on the
>  task list have been fetched by the target as soon as they
>  are placed on it.  There is no point to issuing this command.
>
>  This command would really need to be issued as a vendor-specific
>  Management Agent command, since it needs to be executed
>  asynchronously to the two ordered execution queues or
>  else a third queue needs to be defined.
>
>  Using the ABORT TASK management function defined by SBP-2
>  beginning with the last task in the queue will do the same
>  thing if you want a queue-specific function.  
>
>I don't think this provides any additional usefulness and
>significantly changes the device model.  What am I missing?
>
You are missing one point;
Let me come back to your first note.

Greg Shue wrote:

GS>
GS>Now, error recovery for when a target detects an ACK Timeout on a
GS>Status FIFO write requires some special considerations.  When
GS>this condition happens the initiator and target may be
GS>out-of-sync with each other, and the SBP-2 protocol does not
GS>provide a mechanism for the initiator to determine that the
GS>condition exists.  The problem breaks down to two issues:

SBP-2 protocol *does* provide a mechanism to show this status.
An AGENT_STATE register has two bit to describe status.

In this case "SBP-2 Specification Rev.4" is saying, the fetch agent
shall transition to state DEAD. See page 62 "Transition Any:F5".
The only way to recover from this state, the initiator need to
write data on AGENT_RESET register.

Your scenario cause an impression that the target device shall
be responsible for recovery. However, SBP-2 specification requires
the initiator to be responsible in this case.

SBP-2>State F5: Dead. The dead state is a unique state that preserves fetch agent information in the
SBP-2>AGENT_STATE and ORB_POINTER registers. Writes to any fetch agent register except AGENT_RESET
SBP-2>shall have no effect while in state F5.

After AGENT_RESET the initiator need to inquire what is the
last ORB consumed by the target. In my idea, the initiator
shall invoke TRANSPORT_I2T_ABORT command to receive reply
from the target.

---
Fumio Nagasaka
EPSON Software Deveopment Lab., Inc.
voice: +81 268 25-4111

From shimura at pure.cpdc.canon.co.jp  Tue Jul 28 10:06:29 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Recovery (Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807272249.HAA20510@origin.pure.cpdc.canon.co.jp>
References: <199807271713.KAA22270@hpsdlgj1.sdd.hp.com> <199807272249.HAA20510@origin.pure.cpdc.canon.co.jp>
Message-ID: <199807281406.XAA29403@origin.pure.cpdc.canon.co.jp>


I forgot to describe the accurate condition "target" detects whether
the initiator is ahead, synchronized or behind.

Target uses the following condition;

  Put DistT = 
    ((sequence id specified in ORB)-(expecting sequence id)) mod (2^m)

  IF ((DistT) >= (2^(m-1)) THEN initiator is behind
  ELSE IF (0<DistT<(2^(m-1)) THEN initiator is ahead
  ELSE initiator is synchronized


Following figure shows the relationship between each sequence id.

"Initiator"    (last completed)          (going to append)
                v(S1)                     v(S2)
                |                         |

"Target"             (expecting)     (specified in ORB)  
                      v(S3)          v(S4)
                      |              |
                      |<--------da------->|
                |   | |
"Target(ahead)"    (specified in ORB)  
                    v(S4)
                  ->| |<- db
                  
S1-S4 represents the sequence IDs.

By the initiator's condition, (S2-S1) mod (2^m) < (2^(m-1)).
Because the initiator is recognizing that S1 is completed, 
0 < (S3-S1) mod (2^m) < (2^(m-1)).
Thus, the distance "da" in above figure, (S2-S3) mod (2^m) < 2^(m-1).
So, target recognizes S2 as ahead.

If the initiator is behind, S4 will be between S1 and S3 as show
above "Target(ahead)".
Because (S3-S4) mod (2^m) < (2^(m-1)), the distance "db" in above
figure, (S4-S3) mod (2^m) >= (2^(m-1)).
So, target recognizes S4 as behind.

I think this method makes target free from reporting "ABORTED" status
and makes initiator free from taking recovery actions due to the
identifier gap.

Akihiro Shimura

On Tue, 28 Jul 1998 07:49:16 +0900 (JST)
Akihiro Shimura <shimura@pure.cpdc.canon.co.jp> wrote:

> See comment below,
> 
> On Mon, 27 Jul 1998 10:13:31 -0700 (PDT)
> Greg Shue <gregs@sdd.hp.com> wrote:
> 
> > Akihiro Shimura wrote:
> > 
> > > The initiator is already limiting the number of ORB's not to exceed
> > > maximum reorderable number.
> > 
> > (... number of ORBs in the active task set...)
> > 
> > > By making this condition a little severe, I think we can avoid
> > > unrecoverable situation without retry interaction between initiator
> > > and target.
> > > 
> > > The descriptive condition will be as follows;
> > > 
> > >   The initiator limits 
> > >     the number of ORB's not to exceed maximum reorderable number,
> > >     "AND"
> > >     to append the ORB that has sequence identifier target can identify
> > >     as ahead from last completed one.
> > >   "OR"
> > >   If there is no outstanding ORB for the queue, the initiator appends
> > >   ORB that has sequence identifier adjusted to the next number of last
> > >   completed one.
> > > 
> > > The conditional expression will be as follows;
> > > 
> > >   IF ((Number of outstanding ORB for the queue)
> > >       <= (MAX_TASK_SET_SIZE - n))
> > 
> > (... the first part is always true!)
> 
> The initiator is responsible to make the first part true. The
> condition represents the way initiator decides to append ORB or not.
> 
> > >      AND
> > >      ((((appending sequence id)-(last completed sequence id)) MOD (2^m))
> > >       < (2^(m-1)))
> > >   THEN append ORB with (appending sequence id)
> > >   ELSE
> > >   IF ((Number of outstanding ORB for the queue) = 0)
> > >   THEN adjust (appending sequence id) to (last completed sequence
> > >   id) + 1 and append ORB, 
> > > 
> > >   where "n" is room for another queue, and "m" is number of bit of
> > >   sequence id.
> > 
> > Unfortunately, the target isn't going to always recieve
> > sequence numbers which are monotonically increasing.  This is
> > the consequence of an ABORT_TASK applied to the middle of
> > a queue.  The "sequence number" space has suddenly become
> > sparse!
> 
> Above condition
> > >      ((((appending sequence id)-(last completed sequence id)) MOD (2^m))
> > >       < (2^(m-1)))
> prevents the sequence number distance to become "too" apart for the
> target to distinguish the initiator is ahead or behind.
> 
> > Suddenly a sequence number space >> MAX_TASK_SET_SIZE doesn't
> > guarantee that we can detect order in an error recovery
> > situation.  Both ends may differ as to where they believe the
> > "last completed sequence number" is!
> 
> The "last completed sequence number" means the number the
> "initiator" is recognizing.
> Because (a sequence number space >> MAX_TASK_SET_SIZE) does not
> guarantee successful detection, additional condition is necessary
> to safely append ORB.
> 
> The distance between "last completed sequence id(that initiator is
> recognizing)" and "appending sequence id(initiator is going to
> append ORB with this id)" is always greater than the distance
> between "the sequence id target derives from ORB" and "the sequence
> id target is expecting to derive".
> This makes target detect ahead or behind successfully.
> 
> > > If the target finds initiator is ahead, target can simply update
> > > recorded identifier with the new value specified by the initiator.
> > >
> > > Am I missing something?
> > 
> > I think so.  Start aborting single tasks from the middle of a
> > queue and watch what happens to the "sequence numbers" from the
> > target's perspective.
> 
> >From this observation, I have made additional condition.
> 
> > 
> > SBP-2 requires the support of ABORT TASK.
> > 
> > -- 
> > Greg Shue
> > Hewlett-Packard Company
> > All-in-One Division			        gregs@sdd.hp.com
> > ----------------------------------------------------------------
> > 
> 
> --
>  Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
>  Office Imaging System Promotion Project
>  CANON INC.
> 

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

From list at listme.com  Thu Jul 30 03:45:26 1998
From: list at listme.com (list@listme.com)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Your Search Engine Listing
Message-ID: <199807300745.DAA18823@listme.com>

To: p1394@pwg.org 

     Is your site listed with the top search engines?  ListMe will 
     list you with 50 search engines and indexes for $90. 
     Satisfaction guaranteed! 

Search engines are the only way most people have to find internet sites.
But if your site is not listed, no one will find it.

ListMe will submit your site for listing in the top 50 search engines for $90.

Here's how it works:

1.  Complete and return the form below.

2.  We'll post your site to 50 search engines within two business days, and 
we'll send you a submission report when we're finished.

3.  Pay nothing now.  We'll send you an invoice after we've completed the posting.
Your satisfaction is guaranteed!

These are permanent listings.  The $90 is a one-time fee.

WHICH SEARCH ENGINES?

Here's the list:

Infoseek, Lycos, Excite, Alta Vista,  Galaxy, HotBot, Magellan, Open 
Text Web Index, Web Crawler, BizWeb, New Riders WWW Yellow Pages, 
YelloWWWeb, True North, Northern Light, LinkMonster, The Weekly Bookmark, 
Seven Wonders, Jayde Online Directory, Starting Point, Web 100, Web Walker, 
New Page List, PeekABoo, One World Plaza, PageHost A-Z, Net-Announce, 
Project Cool, Where2Go, World Wide Business Yellow Pages, Sserv, 
Wow! Web Wonders!, WWW Worm, JumpCity, The Galactic Galaxy, TurnPike, 
Unlock:The Information Exchange, Your WebScout, Manufacturers Information 
Network, Net Happenings, Net Mall, Web World  Internet Directory, 
InfoSpace, BC Internet, BizCardz Business Directory, Scrub The Web,  
WebVenture, Hotlist, What's New, WhatUSeek, JumpLink, Linkcentre Directory. 

ORDER FORM (or use our convenient on-line order form at "www.listme.com")

Hit the REPLY button on your e-mail program and fill out the following information.
 (This information will be posted to the search engines/indexes):


Contact name: 
Company Name:
Address:
City:              State/Prov:     Zip/Postal Code: 
Telephone: 
Fax: 
Email address: 

Contact e-mail address (in case we have questions about this order): 

URL:  http://
Site Title: 
Description (250 characters): 

Key words (250 characters, in descending order of importance):

If  billing a different address, please complete the following:

Addressee: 
Company Name:
Address:
City:              State/Prov:     Zip/Postal Code: 
Telephone: 
Fax: 
Email address: 

TERMS

Terms are net 15 days from date of invoice.

______________________________________________________________________
ListMe, Inc.
1127 High Ridge Road - Suite 184
Stamford CT 06905
Phone: (203) 326-8519
Fax:   (203) 322-4505
E-mail: list@listme.com
URL: www.listme.com

From shimura at pure.cpdc.canon.co.jp  Fri Jul 31 01:20:20 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:38 2009
Subject: P1394> MAX_?2?_DATA_SIZE(Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807271626.JAA22234@hpsdlgj1.sdd.hp.com>
References: <199807271359.WAA19952@origin.pure.cpdc.canon.co.jp> <199807271626.JAA22234@hpsdlgj1.sdd.hp.com>
Message-ID: <199807310520.OAA09352@origin.pure.cpdc.canon.co.jp>


Thank you for the explanation.

I am now a little clear on this topic (, I hope).

Originally, it was very questionable for me that the target must
resend the "entire" buffer though the target is sending data over
very reliable (acknowledged) 1394 transactions.

If the initiator can keep the contents of buffer, the target only
needs to resend outstanding transaction(s).
I thought this avoids redundant re-transmission on the wire while
allowing utilization of buffer beyond the target resource.

Whether the initiator keeps the contents of buffer or not depends on
the underlying implementation on the initiator (i.e. interpretation
on the buffer's "direction" bit set to one).

So I would like to propose an enhancement to the recovery model based
on the "MAX_T2I_DATA_SIZE" to take advantage of shared memory model
while keeping independence of implementations.

The enhancement is based on negotiated MAX_T2I_DATA_SIZE reflecting
initiator's preference.

The definition of MAX_T2I_DATA_SIZE will look like following;

  MAX_T2I_DATA_SIZE provided by the target indicates the maximum unit
  of target-to-initiator data the target can guarantee to hold and
  re-send in case of recovering requeued TRANSPORT_T2I_DATA command.
  Initiator may set this parameter value smaller than the value
  provided by the target. The value zero specified by the initiator
  indicates that the target needs not to guarantee to hold and
  re-send data beyond 1394 transaction.
  Target shall guarantee to hold and re-send data up to this
  (negotiated) parameter size.
  Responsibility to hold the contents of buffer beyond this parameter
  size belongs to the initiator.
  The initiator shall avoid to issue TRANSPORT_T2I_DATA command which
  has associated buffer larger than this parameter in case that the
  buffer contents may not be held.
 
Though this enhancement will not be optimal in the spirit of shared
memory model, I think almost the same result will be derived by this
enhancement.

Ueda-san from Canon will make a presentation on this enhancement at
upcoming Toronto meeting.

BTW, MAX_I2T_DATA_SIZE parameter seems not to be useful at all for
both ends, and should be gone. Any objections?

Akihiro Shimura

On Mon, 27 Jul 1998 09:26:16 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:

> > On Fri, 24 Jul 1998 09:32:52 -0700 (PDT)
> > Greg Shue <gregs@sdd.hp.com> wrote:
> > 
> > > It was acknowledged at the July meeting that these parameters
> > > do NOT need to go across the wire in order to have a functioning
> > > protocol.
> > > 
> > > A strong desire was expressed to have these parameters go
> > > across the wire in order for initiator and target to more
> > > effeciently use their respective memory resources.  These
> > > are there as a concession to that desire.
> > 
> > So, these two parameters do not specify the transport behavior itself
> > and are only referenced by client application of the initiator, right?
> 
> Perhaps the better description is that these parameters _clarify_
> transport behavior.  They communicate how the data can/will be moved
> across the wire.  This information can be used by both the target
> and intiator protocol drivers in order to more efficiently manage
> it's own resources.  If this information was not communicated,
> the behavior of information transfer across the wire would still
> be the same, but much more memory may be reserved for buffering than
> is ever used.
> 
> > I feel the descriptions of these parameters sound like followings,
> > though I am still not sure these descriptions make sense.
> > 
> >   MAX_I2T_DATA_SIZE indicates the maximum amount of
> >   initiator-to-target data the client of target is willing to receive
> >   in one buffer. This parameter does not limit buffer size itself,
> >   and may be reported to the client of initiator.
> >   If this value is zero, target shall reject TRANSPORT_I2T_DATA
> >   command.
> > 
> >   MAX_T2I_DATA_SIZE indicates the maximum amount of
> >   target-to-initiator data the client of target is willing to send in
> >   one buffer. This parameter does not limit buffer size itself, and
> >   may be reported to the client of initiator.
> >   If this value is zero, target shall reject TRANSPORT_T2I_DATA
> >   command.
> 
> Essentially, you are correct.  These parameters only make sense
> when you start to consider memory usage optimizations on both intiator
> and target ends.  Without these numbers (other than for zero/non-zero
> values), memory could be very unequally allocated by each end.
> 
> > >   MAX_T2I_DATA_SIZE is the maximum amount of target-to-initiator
> > >   data the target will buffer and retransmit across this
> > >   connection if the Task is implicilty or explicitly aborted
> > >   (e.g.  Bus Reset or TASK SET ABORT).  Any memory allocated by
> > 
> > >From the error recovery model we discussed, above value may be
> > smaller than the size of buffer pointed by the ORB, and may minimally
> > be payload size of block transaction.
> 
> I don't think that an SBP-2 target can require that the same
> physical memory be tied to a requeued TRANSPORT_T2I_DATA ORB.
> So a target must assume that the memory does NOT contain any
> previously written data, and so must rewrite the entire valid
> contents.  The size of the acutal data being transported may
> always be less than the indicated MAX_T2I_DATA_SIZE (unless
> the max size is 1 Byte!).  The actual minimum valid data size
> is 1 byte.  It still takes a 1 quadlet transaction.
> 
> > On the other hand, above statement implies the size of buffer pointed
> > by the ORB itself.
> 
> Yes, the MAX size is the maximum size of the buffer pointed to
> by the ORB itself.
> 
> > So, this description seems to me to be conflicting.
> > 
> > I may be still missing something. Any suggestion?
> 
> Yes, can someone else try to describe this?  Unfortunately, I am
> as confused with your misunderstandings as you are with my
> descriptions!
> 
> > Akihiro Shimura
> 
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------
> 

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

From shimura at pure.cpdc.canon.co.jp  Fri Jul 31 01:29:27 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:38 2009
Subject: STREAM_COMPLETION (Was Re: P1394> Revised PWG1394 Cmd Set)
In-Reply-To: <199807271727.KAA22290@hpsdlgj1.sdd.hp.com>
References: <35BCA558.D2B7FC2@sismicro.com> <199807271727.KAA22290@hpsdlgj1.sdd.hp.com>
Message-ID: <199807310529.OAA09515@origin.pure.cpdc.canon.co.jp>


> > >   as soon as _any_ data is available (possibly wasting bus
> > >     bandwidth)

Because transport does not have any knowledge about stream boundary,
I think transport should not have its own completion policy beyond
the flow control, and should follow the client's policy.

For a target, it will be straightforward to follow the client's early
completion request by issuing early completion status to the
initiator.

On the other hand, I think we need some consideration in case of
client's early completion request on the initiator side.
Because SBP-2 works with message queuing (linked list of ORBs) and
initiator does not have knowledge of the place where the target is
executing, the early completion will not be able to be handled within
the initiator, and early completion request needs to go across the
wire to the target.

My concern here is that if we can use "ABORT TASK" management
function for this purpose or we need "TERMINATE TASK" management
function which has gone from the latest SBP-2 specification.

Is there any suggestion?

Akihiro Shimura

On Mon, 27 Jul 1998 10:27:32 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:

> Bob Morford (bob@sismicro.com) wrote:
> 
> > Greg Shue wrote:
> > >
> > > > I think the question to be answered is whether there needs
> > > > to be negotiation between target and initiator (or maybe
> > > > just information from target to initiator) over when, under
> > > > stream-based comm., the target is allowed to complete the
> > > > Store Data Orb.  As I thought about this, the only reasons
> > > > that I identified for termination were application
> > > > related.  And the application (transport client in the
> > > > device) seemed to have it's own good reason.
> > > 
> > > This is the essence of the issue.  In Stream-based communication,
> > > a target could complete an ORB:
> > > 
> > >   as soon as _any_ data is available (possibly wasting bus
> > >     bandwidth)
> > > 
> > >   only when it must (full or target internally blocked because
> > >     output must be sent before proceeding).
> > > 
> > >   or anywhere in between.
> > 
> > It seems that the second case must be determined by the application 
> > (transport client).  If you allow the application to decide, then
> > is there really any point in negotiation?
> > 
> > Was this the point of "STREAM_COMPLETION" or did you have something
> > else in mind?
> 
> The point was some policy needed to be defined to have consistent
> implementations.  I just couldn't make the call on my own about
> where that responsibility lies or what the policy should be.
> If the policy becomes that the target will pass along as much
> data as it can as quickly as it can it may be sufficient.  (Though
> we could end up with many small transactions rather than a few large
> ones when data trickles out.)
> 
> As long as you can get people to agree on something, it's probably
> fine with me.  :-)
> 
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------
> 

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

From shimura at pure.cpdc.canon.co.jp  Fri Jul 31 01:41:26 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:38 2009
Subject: P1394> ABORTED - UNEXPECTED ... (Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
References: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
Message-ID: <199807310541.OAA09620@origin.pure.cpdc.canon.co.jp>


On Mon, 20 Jul 1998 10:05:11 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:
(snip)
>       It may be reasonable for a target to enforce seeing
>       sequential command tags in order to recover from this
>       situation.  If the queue's Execution Agent completed
>       all commands in that queue with a status of "ABORTED -
>       UNEXPECTED COMMAND TAG VALUE", then the initiator has
>       a chance to recover from the situation.  This also means
>       that an ABORT TASK function causes all successive commands
>       on the associated queue to be aborted without affecting
>       the other queue.

I have a question about actions taken by the initiator.

I suppose that if the target's agent finds this situation, target
enters from 'execute' state to 'abort all subsequent commands' state
(in order not to execute the commands still not fetched).
The initiator will wait until target aborts all subsequent commands
destined to the queue.
(Target may be executing commands destined to another queue at this
moment.)

After all subsequent commands are aborted, the initiator will requeue
aborted commands with properly assigned sequence ids. 
I think, initiator "needs to" restore target's agent state to
'execute' without affecting the execution of another queue at this
point.

How does target find the initiator recovered from the
situation? (I may be misunderstanding the process.)

In the model I described in previous mails, the initiator does not
take recovery action at all.

Because descriptive explanation may make it hard to be well
understood, I am preparing some slides for explanation.

Ueda-san from Canon will make a presentation for this alternative
model at upcoming Toronto meeting.

Akihiro Shimura
--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

From gregs at sdd.hp.com  Tue Aug  4 22:20:16 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Revised PWG1394 Cmd Set
In-Reply-To: <98072809243001.AKG35F1@smtp.venus.dti.ne.jp> from "Fumio Nagasaka" at Jul 28, 98 09:26:16 am
Message-ID: <199808050220.TAA28805@hpsdlgj1.sdd.hp.com>


Fumio Nagasaka wrote:
> 
> Greg Shue wrote:
> >
> >Fumio Nagasaka wrote:
> >
> >> 3.1. TRANSPORT_I2T_ABORT
> >> 	An initiator requests a target to stop ORB fetching, 
> >> 	and solicits the target to reply STATUS block when
> >> 	the last ORB had been executed.
> >
> >I probably don't understand this one.
> >
> >  Since we're using the UNORDERED model, all the ORBs on the
> >  task list have been fetched by the target as soon as they
> >  are placed on it.  There is no point to issuing this command.
> >
> >  This command would really need to be issued as a vendor-specific
> >  Management Agent command, since it needs to be executed
> >  asynchronously to the two ordered execution queues or
> >  else a third queue needs to be defined.
> >
> >  Using the ABORT TASK management function defined by SBP-2
> >  beginning with the last task in the queue will do the same
> >  thing if you want a queue-specific function.  
> >
> >I don't think this provides any additional usefulness and
> >significantly changes the device model.  What am I missing?
> >
> You are missing one point;
> Let me come back to your first note.
> 
> Greg Shue wrote:
> 
> GS>
> GS>Now, error recovery for when a target detects an ACK Timeout on a
> GS>Status FIFO write requires some special considerations.  When
> GS>this condition happens the initiator and target may be
> GS>out-of-sync with each other, and the SBP-2 protocol does not
> GS>provide a mechanism for the initiator to determine that the
> GS>condition exists.  The problem breaks down to two issues:
> 
> SBP-2 protocol *does* provide a mechanism to show this status.
> An AGENT_STATE register has two bit to describe status.
> 
> In this case "SBP-2 Specification Rev.4" is saying, the fetch agent
> shall transition to state DEAD. See page 62 "Transition Any:F5".
> The only way to recover from this state, the initiator need to
> write data on AGENT_RESET register.

Good point, but that status requires the intiator go look for it.
How will the initiator know to go look for it?

Here's another one for consideration:

  Since a fetch agent may be processing transactions for multiple
  Tasks simultaneously (since split-transactions), which ORB is
  the ORB_POINTER supposed to reference?  And when is it set?
  SPB-2 Rev 4 doesn't say.  It really is written to a sequential
  execution model.

  SBP-2 Rev 4, p 62 also says (just above State F5:)  The fetch
  agent __may__ also be instructed to transition to the dead
  state as a result of an error in command execution detection by
  the device server.

If the SBP-2 target driver provides a hook to transition the
fetch agent to the DEAD state at any point in time, and if the
ORB_POINTER value is provided in that interface, then we might be
able to use the ORB_POINTER register.  Unfortunately, I'm not
sure if this functionality is a requirement.

> Your scenario cause an impression that the target device shall
> be responsible for recovery. However, SBP-2 specification requires
> the initiator to be responsible in this case.

I don't see it as the target is responsible for _recovery_, but
it is responsible for _detection_ and _indication_.  A Bus Reset
by itself doesn't recover from the situation, it just indicates
that something is drastically wrong.

The problem we have is how to get the initiator to take any sort
of recovery action.  SBP-2 expects that this will be detected by
some mechanism independent of the 'target' module.  The expected
mechanism is a timeout.  At the May PWG 1394 meeting (?), another
mechanism of Bus Reset was suggested.

Any other suggestions?

-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From Nagasaka.Fumio at exc.epson.co.jp  Tue Aug  4 23:34:19 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Revised PWG1394 Cmd Set
Message-ID: <01376112D7AFD011911E0020AF70BEC51163C0@cpuex1.ued.epson.co.jp>

Greg Shue wrote:

	GS> The problem we have is how to get the initiator to take any sort
	GS> of recovery action.  SBP-2 expects that this will be detected by
	GS> some mechanism independent of the 'target' module.  The expected
	GS> mechanism is a timeout.  At the May PWG 1394 meeting (?),
another
	GS> mechanism of Bus Reset was suggested.

The Annex E of SBP-2 Specification Rev.4 is describing;

<<<
E.4 Status FIFO write request
When the target detects a missing acknowledgement after a write to an
initiator?s status FIFO, it should
take no error recovery actions. Any target resources allocated to the ORB
should be released by the
target. The initiator is expected to discover the error by means of a
higher-level mechanism, such as a
command time-out and to initiate appropriate error recovery. The nature of
the error recovery undertaken
by the initiator likely depends whether or not the target processes ORB?s
and returns their status in order,
but in any event is beyond the scope of this description.
>>>

I was missing this section when I sent previous e-mail.
In my idea, a print spooler in the initiator shall detect time out.
Then this initiator shall write AGENT_RESET register or RESET_START
register. Writing RESET_START register will cause the target
same effect as "power reset". In addition to, in this case,...

SBP-2 E.4 >Any target resources allocated to the ORB should be released by
thetarget.

...so, ORB_POINTER is unusable to examine the last ORB which
was consumed. Thus this initiator shall ask the target to report the last
ORB
address utilizing higher level command sounds like "TRANSPORT_I2T_ABORT".

-------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp

> -----Original Message-----
> From:	Greg Shue [SMTP:gregs@sdd.hp.com]
> Sent:	Wednesday, August 05, 1998 11:20 AM
> To:	Nagasaka Fumio
> Cc:	p1394@pwg.org
> Subject:	Re: P1394> Revised PWG1394 Cmd Set
> 
> 
> Fumio Nagasaka wrote:
> > 
> > Greg Shue wrote:
> > >
> > >Fumio Nagasaka wrote:
> > >
> > >> 3.1. TRANSPORT_I2T_ABORT
> > >> 	An initiator requests a target to stop ORB fetching, 
> > >> 	and solicits the target to reply STATUS block when
> > >> 	the last ORB had been executed.
> > >
> > >I probably don't understand this one.
> > >
> > >  Since we're using the UNORDERED model, all the ORBs on the
> > >  task list have been fetched by the target as soon as they
> > >  are placed on it.  There is no point to issuing this command.
> > >
> > >  This command would really need to be issued as a vendor-specific
> > >  Management Agent command, since it needs to be executed
> > >  asynchronously to the two ordered execution queues or
> > >  else a third queue needs to be defined.
> > >
> > >  Using the ABORT TASK management function defined by SBP-2
> > >  beginning with the last task in the queue will do the same
> > >  thing if you want a queue-specific function.  
> > >
> > >I don't think this provides any additional usefulness and
> > >significantly changes the device model.  What am I missing?
> > >
> > You are missing one point;
> > Let me come back to your first note.
> > 
> > Greg Shue wrote:
> > 
> > GS>
> > GS>Now, error recovery for when a target detects an ACK Timeout on a
> > GS>Status FIFO write requires some special considerations.  When
> > GS>this condition happens the initiator and target may be
> > GS>out-of-sync with each other, and the SBP-2 protocol does not
> > GS>provide a mechanism for the initiator to determine that the
> > GS>condition exists.  The problem breaks down to two issues:
> > 
> > SBP-2 protocol *does* provide a mechanism to show this status.
> > An AGENT_STATE register has two bit to describe status.
> > 
> > In this case "SBP-2 Specification Rev.4" is saying, the fetch agent
> > shall transition to state DEAD. See page 62 "Transition Any:F5".
> > The only way to recover from this state, the initiator need to
> > write data on AGENT_RESET register.
> 
> Good point, but that status requires the intiator go look for it.
> How will the initiator know to go look for it?
> 
> Here's another one for consideration:
> 
>   Since a fetch agent may be processing transactions for multiple
>   Tasks simultaneously (since split-transactions), which ORB is
>   the ORB_POINTER supposed to reference?  And when is it set?
>   SPB-2 Rev 4 doesn't say.  It really is written to a sequential
>   execution model.
> 
>   SBP-2 Rev 4, p 62 also says (just above State F5:)  The fetch
>   agent __may__ also be instructed to transition to the dead
>   state as a result of an error in command execution detection by
>   the device server.
> 
> If the SBP-2 target driver provides a hook to transition the
> fetch agent to the DEAD state at any point in time, and if the
> ORB_POINTER value is provided in that interface, then we might be
> able to use the ORB_POINTER register.  Unfortunately, I'm not
> sure if this functionality is a requirement.
> 
> > Your scenario cause an impression that the target device shall
> > be responsible for recovery. However, SBP-2 specification requires
> > the initiator to be responsible in this case.
> 
> I don't see it as the target is responsible for _recovery_, but
> it is responsible for _detection_ and _indication_.  A Bus Reset
> by itself doesn't recover from the situation, it just indicates
> that something is drastically wrong.
> 
> The problem we have is how to get the initiator to take any sort
> of recovery action.  SBP-2 expects that this will be detected by
> some mechanism independent of the 'target' module.  The expected
> mechanism is a timeout.  At the May PWG 1394 meeting (?), another
> mechanism of Bus Reset was suggested.
> 
> Any other suggestions?
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------

From gregs at sdd.hp.com  Wed Aug  5 17:18:31 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Revised PWG1394 Cmd Set
In-Reply-To: <01376112D7AFD011911E0020AF70BEC51163C0@cpuex1.ued.epson.co.jp> from "Nagasaka Fumio" at Aug 5, 98 12:34:19 pm
Message-ID: <199808052118.OAA00831@hpsdlgj1.sdd.hp.com>


Fumio Nagasaka wrote:
> In my idea, a print spooler in the initiator shall detect time out.

That's fine if the initiator's transport client is a print spooler,
but what about other higher layer apps such as:
   a Status/Event Monitor?
   a file transfer protocol?
   a scanning app?

We're working on a generic protocol.  I don't want to impose any
more requirements on the application than does TCP.  TCP itself
takes care of timeout/lost link detection.  I think this protocol
should also.  Once detection by the initiator's protocol driver is
taken care of, then recovery is easy.  Have we now ended up with
a case where the initiator's side needs to poll for FETCH_AGENT status
or do we let the node hosting the target side generate a Bus Reset?

> SBP-2 E.4 >Any target resources allocated to the ORB should be released by
> thetarget.
> 
> ...so, ORB_POINTER is unusable to examine the last ORB which
> was consumed. Thus this initiator shall ask the target to report the last
> ORB
> address utilizing higher level command sounds like "TRANSPORT_I2T_ABORT".

I don't think so.  The ORB_POINTER register can still point to
the offending ORB.  The ORB itself can no longer be referenced
by the target.  Since it is in the initiator's memory space, the
initiator can still examine it.

-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From Nagasaka.Fumio at exc.epson.co.jp  Wed Aug  5 22:14:34 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Revised PWG1394 Cmd Set
Message-ID: <01376112D7AFD011911E0020AF70BEC51163D8@cpuex1.ued.epson.co.jp>

	Fumio Nagasaka wrote:
> In my idea, a print spooler in the initiator shall detect time out.

OK, forget my brain damaged idea. But still we don?t have cool answers.
Any session layer beyond SBP-2 can detect this error. Then what shall we do?
Examining ORB_POINTR requires an initiator to do effort as same as
issuing a transport command. Doesn?t it?

--------------------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to  <mailto:nagasaka.fumio@exc.epson.co.jp> nagasaka.fumio@exc.epson.
co.jp

	-----Original Message-----
	From:	Greg Shue [SMTP:gregs@sdd.hp.com]
	Sent:	Thursday, August 06, 1998 6:19 AM
	To:	Nagasaka Fumio
	Cc:	p1394@pwg.org
	Subject:	Re: P1394> Revised PWG1394 Cmd Set


	Fumio Nagasaka wrote:
	> In my idea, a print spooler in the initiator shall detect time
out.

	That's fine if the initiator's transport client is a print spooler,
	but what about other higher layer apps such as:
	   a Status/Event Monitor?
	   a file transfer protocol?
	   a scanning app?

	We're working on a generic protocol.  I don't want to impose any
	more requirements on the application than does TCP.  TCP itself
	takes care of timeout/lost link detection.  I think this protocol
	should also.  Once detection by the initiator's protocol driver is
	taken care of, then recovery is easy.  Have we now ended up with
	a case where the initiator's side needs to poll for FETCH_AGENT
status
	or do we let the node hosting the target side generate a Bus Reset?

	> SBP-2 E.4 >Any target resources allocated to the ORB should be
released by
	> thetarget.
	> 
	> ...so, ORB_POINTER is unusable to examine the last ORB which
	> was consumed. Thus this initiator shall ask the target to report
the last
	> ORB
	> address utilizing higher level command sounds like
"TRANSPORT_I2T_ABORT".

	I don't think so.  The ORB_POINTER register can still point to
	the offending ORB.  The ORB itself can no longer be referenced
	by the target.  Since it is in the initiator's memory space, the
	initiator can still examine it.

	-- 
	Greg Shue
	Hewlett-Packard Company
	All-in-One Division			        gregs@sdd.hp.com
	----------------------------------------------------------------

From gregs at sdd.hp.com  Thu Aug  6 12:45:09 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Revised PWG1394 Cmd Set
In-Reply-To: <01376112D7AFD011911E0020AF70BEC51163D8@cpuex1.ued.epson.co.jp> from "Nagasaka Fumio" at Aug 6, 98 11:14:34 am
Message-ID: <199808061645.JAA06132@hpsdlgj1.sdd.hp.com>


Fumio Nagasaka wrote:
> > In my idea, a print spooler in the initiator shall detect time out.
> 
> OK, forget my brain damaged idea. But still we don$B!G(Jt have cool answers.
> Any session layer beyond SBP-2 can detect this error. Then what shall we do?
> Examining ORB_POINTR requires an initiator to do effort as same as
> issuing a transport command. Doesn$B!G(Jt it?

I wouldn't call it "brain damaged", just focused on a narrow
application space.  :-)

Issuing a transport command is much more intrusive to the system
than examining the AGENT_STATE and ORB_POINTER registers, because
it now requires it's own sequence number, and it can't be put on
the queue until the condition is corrected!

So, just for review:

  - Any identified errors other than a lost Ack on a status FIFO write
    either have a retry alogrithm described in SBP-2, or cause
    a status FIFO write to report the error.

  - All identified errors cause the Fetch Engine to transition to
    the DEAD state, and cause the entire task set to be cleared.

  - Because we are dealing with parallel-execution rather than
    just out-of-order, we must clarify what value ends up in the
    ORB_POINTER register when the Fetch Engine is in the DEAD state.

  ? The process used by an initiator to recover when it finds
    the Fetch Engine in the DEAD state without a cause written to
    the status FIFO is to construct a linked list of the pending
    ORBs and queue it up on the Task List.

  - Because the PWG Transport Requirements identify the transport as
    "reliable" and "Connection-oriented" and the undocumented transport
    model is TCP, the following options come to mind:

      1) The stall detection could be left up to the Transport
	 Client.  Any clients which do not provide this detection
	 (via a timeout) would get hung in this condition until
	 something caused a Bus Reset.

      2) The stall detection could be handled by the initiating
	 node's PWG protocol layer.  It could either be done by:
           - a timeout (negotiated reconnect interval?) on target
             activity, causing the initiator to look at the
             AGENT_STATE register.
           - the target's node generating a Bus Reset
           - ???

I believe strongly that this detection should NOT be forced on
the Transport Client or above.  I also believe that human
intervention must not be required to recover from this condition.
Any target inactivity detection must occur within a
target-dependent timeout, because different functions and
technologies have different constraints.  (e.g.  ink jet dry
times, scanner bulb color stability, media sitting over fusers.)

Can somebody model or better yet measure the frequency of this error?
If it really is extreemely low, then let's just let the target
node generate a Bus Reset.  Otherwise let's put in a heart-beat
write to the Status FIFO using Unsolicited Status.

I think we need to choose one at the next meeting and be done
with it.  We're only looking for a solution for the first
revision of this protocol.

-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From shimura at pure.cpdc.canon.co.jp  Fri Aug  7 06:14:31 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Revised PWG1394 Cmd Set
In-Reply-To: <199808061645.JAA06132@hpsdlgj1.sdd.hp.com>
References: <01376112D7AFD011911E0020AF70BEC51163D8@cpuex1.ued.epson.co.jp> <199808061645.JAA06132@hpsdlgj1.sdd.hp.com>
Message-ID: <199808071014.TAA01352@origin.pure.cpdc.canon.co.jp>

Greg,

I think reading AGENT_STATE register (may be periodically) is very
similar to heart-beat, isn't it?

Because the error is (accidentally) occurred during the
communication between only two nodes, I think bus reset may be too
sacrificed for entire bus as a first recovery step.

Am I missing something?

Akihiro Shimura

On Thu, 6 Aug 1998 09:45:09 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:

> 
> Fumio Nagasaka wrote:
> > > In my idea, a print spooler in the initiator shall detect time out.
> > 
> > OK, forget my brain damaged idea. But still we don?t have cool answers.
> > Any session layer beyond SBP-2 can detect this error. Then what shall we do?
> > Examining ORB_POINTR requires an initiator to do effort as same as
> > issuing a transport command. Doesn?t it?
> 
> I wouldn't call it "brain damaged", just focused on a narrow
> application space.  :-)
> 
> Issuing a transport command is much more intrusive to the system
> than examining the AGENT_STATE and ORB_POINTER registers, because
> it now requires it's own sequence number, and it can't be put on
> the queue until the condition is corrected!
> 
> So, just for review:
> 
>   - Any identified errors other than a lost Ack on a status FIFO write
>     either have a retry alogrithm described in SBP-2, or cause
>     a status FIFO write to report the error.
> 
>   - All identified errors cause the Fetch Engine to transition to
>     the DEAD state, and cause the entire task set to be cleared.
> 
>   - Because we are dealing with parallel-execution rather than
>     just out-of-order, we must clarify what value ends up in the
>     ORB_POINTER register when the Fetch Engine is in the DEAD state.
> 
>   ? The process used by an initiator to recover when it finds
>     the Fetch Engine in the DEAD state without a cause written to
>     the status FIFO is to construct a linked list of the pending
>     ORBs and queue it up on the Task List.
> 
>   - Because the PWG Transport Requirements identify the transport as
>     "reliable" and "Connection-oriented" and the undocumented transport
>     model is TCP, the following options come to mind:
> 
>       1) The stall detection could be left up to the Transport
> 	 Client.  Any clients which do not provide this detection
> 	 (via a timeout) would get hung in this condition until
> 	 something caused a Bus Reset.
> 
>       2) The stall detection could be handled by the initiating
> 	 node's PWG protocol layer.  It could either be done by:
>            - a timeout (negotiated reconnect interval?) on target
>              activity, causing the initiator to look at the
>              AGENT_STATE register.
>            - the target's node generating a Bus Reset
>            - ???
> 
> I believe strongly that this detection should NOT be forced on
> the Transport Client or above.  I also believe that human
> intervention must not be required to recover from this condition.
> Any target inactivity detection must occur within a
> target-dependent timeout, because different functions and
> technologies have different constraints.  (e.g.  ink jet dry
> times, scanner bulb color stability, media sitting over fusers.)
> 
> Can somebody model or better yet measure the frequency of this error?
> If it really is extreemely low, then let's just let the target
> node generate a Bus Reset.  Otherwise let's put in a heart-beat
> write to the Status FIFO using Unsolicited Status.
> 
> I think we need to choose one at the next meeting and be done
> with it.  We're only looking for a solution for the first
> revision of this protocol.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------
> 

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

From gleclair at agentz.com  Tue Aug 11 03:17:10 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Web site update
Message-ID: <01BDC4BD.626E49E0.gleclair@agentz.com>




The latest update to the command set proposal has been posted to the web site.

http://www.pwg.org/p1394/

SBP-2 Transport Command Set Proposal - Rev. 0d [Shue]
ftp://ftp.pwg.org/pub/pwg/p1394/mtg081798/pwgcmd0d.pdf

I think this is on the top of the list for agenda items in Toronto.

Any other topics people would like to add to the agenda?

Please advise.

Thanks,
Greg




From shimura at pure.cpdc.canon.co.jp  Tue Aug 11 21:02:16 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Document for Error Recovery supporting GAP (Was Re: ABORTED - UNEXPECTED ...)
In-Reply-To: <199807310541.OAA09620@origin.pure.cpdc.canon.co.jp>
References: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com> <199807310541.OAA09620@origin.pure.cpdc.canon.co.jp>
Message-ID: <199808120102.KAA02877@origin.pure.cpdc.canon.co.jp>

Hello, All,

I have made a model and example document for the error recovery
model supporting abort task gap.

Though new command set proposal contains similar descriptions, I
feel yet another explanation especially for a corner case may help
understanding.

Because I will not be able to attend Toronto meeting, Ueda-san from
Canon will explain the model.

Please find attached document.

Regards,

Akihiro Shimura

On Fri, 31 Jul 1998 14:41:26 +0900 (JST)
Akihiro Shimura <shimura@pure.cpdc.canon.co.jp> wrote:

> Because descriptive explanation may make it hard to be well
> understood, I am preparing some slides for explanation.
> 
> Ueda-san from Canon will make a presentation for this alternative
> model at upcoming Toronto meeting.

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: SeqIdGap.pdf
Type: application/octet-stream
Size: 29910 bytes
Desc: not available
Url : http://www.pwg.org/archives/p1394/attachments/19980812/b2073913/SeqIdGap.obj
From gregs at sdd.hp.com  Tue Aug 11 21:16:22 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:38 2009
Subject: P1394> Document for Error Recovery supporting GAP (Was Re: ABORTED - UNEXPECTED ...)
In-Reply-To: <199808120102.KAA02877@origin.pure.cpdc.canon.co.jp> from "Akihiro Shimura" at Aug 12, 98 10:02:16 am
Message-ID: <199808120116.SAA06911@hpsdlgj1.sdd.hp.com>



I'm sorry to find out that you won't be at the next meeting.
Thank you for the additional document and presentation.
I am depending on them to fill out the error recovery
portion of the command set proposal.

> Hello, All,
> 
> I have made a model and example document for the error recovery
> model supporting abort task gap.
> 
> Though new command set proposal contains similar descriptions, I
> feel yet another explanation especially for a corner case may help
> understanding.
> 
> Because I will not be able to attend Toronto meeting, Ueda-san from
> Canon will explain the model.
> 
> Please find attached document.
> 
> Regards,
> 
> Akihiro Shimura


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From gleclair at agentz.com  Thu Aug 13 02:38:54 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:38 2009
Subject: FW: P1394> Web site update - alternate location
Message-ID: <01BDC64A.5F191200.gleclair@agentz.com>

Sorry if you have not been able to get the Command set doc from the PWG web server.

I placed a copy of the file in a temporary location on an alternate server.

The URL is: http://www.agentz.com/1394pwg/pwgcmd0d.pdf

Please let me know if you have problems.

Greg



-----Original Message-----
From:	Gregory LeClair [SMTP:gleclair@agentz.com]
Sent:	Tuesday, August 11, 1998 12:17 AM
To:	'1394 PWG'
Subject:	P1394> Web site update




The latest update to the command set proposal has been posted to the web site.

http://www.pwg.org/p1394/

SBP-2 Transport Command Set Proposal - Rev. 0d [Shue]
ftp://ftp.pwg.org/pub/pwg/p1394/mtg081798/pwgcmd0d.pdf

I think this is on the top of the list for agenda items in Toronto.

Any other topics people would like to add to the agenda?

Please advise.

Thanks,
Greg




From shimura at pure.cpdc.canon.co.jp  Thu Aug 13 06:01:03 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:39 2009
Subject: P1394> T2I Recovery Enhancement Proposal Document (Was Re: MAX_?2?_DATA_SIZE)
In-Reply-To: <199807310520.OAA09352@origin.pure.cpdc.canon.co.jp>
References: <199807271626.JAA22234@hpsdlgj1.sdd.hp.com> <199807310520.OAA09352@origin.pure.cpdc.canon.co.jp>
Message-ID: <199808131001.TAA28640@origin.pure.cpdc.canon.co.jp>

Hello, All,

I've made a recovery enhancement proposal document for
TRANSPORT_T2I_DATA command and its parameter to clarify the model.
This document also contains brief example usage.

Ueda-san from Canon will explain this model at Toronto meeting on
my behalf, too.

Please find attached document.

Regards,

Akihiro Shimura

On Fri, 31 Jul 1998 14:20:20 +0900 (JST)
Akihiro Shimura <shimura@pure.cpdc.canon.co.jp> wrote:

> Thank you for the explanation.
> 
> I am now a little clear on this topic (, I hope).
> 
> Originally, it was very questionable for me that the target must
> resend the "entire" buffer though the target is sending data over
> very reliable (acknowledged) 1394 transactions.
> 
> If the initiator can keep the contents of buffer, the target only
> needs to resend outstanding transaction(s).
> I thought this avoids redundant re-transmission on the wire while
> allowing utilization of buffer beyond the target resource.
> 
> Whether the initiator keeps the contents of buffer or not depends on
> the underlying implementation on the initiator (i.e. interpretation
> on the buffer's "direction" bit set to one).
> 
> So I would like to propose an enhancement to the recovery model based
> on the "MAX_T2I_DATA_SIZE" to take advantage of shared memory model
> while keeping independence of implementations.
> 
> The enhancement is based on negotiated MAX_T2I_DATA_SIZE reflecting
> initiator's preference.
> 
> The definition of MAX_T2I_DATA_SIZE will look like following;
> 
>   MAX_T2I_DATA_SIZE provided by the target indicates the maximum unit
>   of target-to-initiator data the target can guarantee to hold and
>   re-send in case of recovering requeued TRANSPORT_T2I_DATA command.
>   Initiator may set this parameter value smaller than the value
>   provided by the target. The value zero specified by the initiator
>   indicates that the target needs not to guarantee to hold and
>   re-send data beyond 1394 transaction.
>   Target shall guarantee to hold and re-send data up to this
>   (negotiated) parameter size.
>   Responsibility to hold the contents of buffer beyond this parameter
>   size belongs to the initiator.
>   The initiator shall avoid to issue TRANSPORT_T2I_DATA command which
>   has associated buffer larger than this parameter in case that the
>   buffer contents may not be held.
>  
> Though this enhancement will not be optimal in the spirit of shared
> memory model, I think almost the same result will be derived by this
> enhancement.
> 
> Ueda-san from Canon will make a presentation on this enhancement at
> upcoming Toronto meeting.
> 
> BTW, MAX_I2T_DATA_SIZE parameter seems not to be useful at all for
> both ends, and should be gone. Any objections?
> 
> Akihiro Shimura

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: MaxT2Isz.pdf
Type: application/octet-stream
Size: 8678 bytes
Desc: not available
Url : http://www.pwg.org/archives/p1394/attachments/19980813/31f55746/MaxT2Isz.obj
From fumiona at venus.dti.ne.jp  Tue Sep  1 12:15:55 1998
From: fumiona at venus.dti.ne.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:39 2009
Subject: P1394> 1394 Timers?
In-Reply-To: <H0000d930fdb0c80@MHS>
References: <H0000d930fdb0c80@MHS>
Message-ID: <199809011610.BAA03465@smtp1.dti.ne.jp>

Hanging read ORB release timer;

When an initiator assume a target will reply 500 bytes,
but the target device only replies 300 bytes, then this
input ORB will not be completed. The initiator is waiting
for 200 bytes as rest of the contents. If we do not have
any timer to detect this situation and if the transport
layer software does not resolve hanging ORB to avoid input
pipe stalling, a higher level client software need to solve
this problem.

One possible solution for the problem is that the transport
software of the target fills padding data (null data) when
this timer over runs, and the target force to complete this
input ORB, and also the target shall reply the valid length
of data in the input buffer.

However I do not feel that we need to define this timer.

Because I prefer to design a predictable transport like CBT.
If we choose a CBT style solution, the target may ask the
initiator to provide credit to receive data from the target.
Then the target sends a packet which contains length field
of valid data length and real data itself.  Thus I believe
timer design depends upon whether we can define predictable
transport or not. Actually IEEE 1284.4 does not require to
have this sort of timer, because it does not need to assume
a communication pipe to be stalled.

Fumio

Alan wrote:
>August 25, 1998
>
>This is a call for discussion on Timers for the 1394 Image Profile.
>At the last meeting we attempted to address this issue and only identified 3 
>timers. Are there others we missed? Please submit comments and suggestions.
>
>1) Reconnect Timer - This one is taken care of by SBP-2 as part of the Login 
>process.
>
>2) Management ORB Timer - When the Initiator writes a Management ORB address to 
>the Management Agent Register, how long should it wait for a response to be 
>written to the management ORBs status fifo? How is the timeout value determined 
>and communicated?
>
>3) Abort Task Set Timer - An Abort Task Set may issued by an Initiator in 
>response to Target Inactivity. How is the timeout value determined and 
>communicated?
>
>Any other timers that we did not include at the last meeting?
>
>
>

---
Fumio Nagasaka
EPSON Software Deveopment Lab., Inc.
voice: +81 268 25-4111

From fumiona at venus.dti.ne.jp  Wed Sep  2 11:41:51 1998
From: fumiona at venus.dti.ne.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:39 2009
Subject: [PP1394:00315] Re: P1394> 1394 Timers?
In-Reply-To: <199809011657.JAA04024@hpsdlgj1.sdd.hp.com>
References: <199809011657.JAA04024@hpsdlgj1.sdd.hp.com>
Message-ID: <199809021536.AAA28437@smtp1.dti.ne.jp>

Thank you Greg,

>Incidently, this transport should already be as predictable as
>1284.4.

This is the answer I was waiting for.
If 1394 PWG transport is as predictable as 1284.4,
then we shall remove descriptions which are describing
two queues model in 1394 PWG profile. Because these
descriptions are implementation issue and beyond the
specification. In addition to this, if our transport
is as predictable as 1284.4, then why do we need to describe
something about two queues model. The forward direction
(I to T) transaction and the reverse direction (T to I)
transaction will not be stalled. If so, we do not need
to assume a target to have two independent queues.

Also 1394 PWG profile describes in "1. Scope".
(reformatted)
>This document specifies the communications profile and device
>communications command set for imaging devices attached to
>the IEEE 1394 High Speed Serial Bus.

>SBP-2 provides multiple, concurrent, independent connections
>which do not preclude concurrent operation of other protocol
>stacks; is data, application, and OS independent In order
>to meet the requirements for imaging devices, SBP-2 must be
>supplemented by a device profile, which specifies:

>Information supplemental to the IEEE 1394 and SBP-2
>specifications are provided in this document.
> * a policy to be used for maintaining device access across
>   "transient" link interruptions
> * a model of use for maintaining guaranteed, in-order data
>   deliver across "transient" link interruptions
> *a command set which supports
>      * independent, bi-directional, half-duplex communication
>      * data tagging of an associated data payload
>      * ability for either end of a connection to close the
>        connection at any time

The current command set does not meet the scope of 1394
PWG profile. Because the command set does not allow for
either end of a connection to close the connection at
any time. Also the current command set does not describe
the way to support multiple host connectivity. Actually
when a host A is printing to a target B utilizing LUN #1,
then the other host C cannot login to receive status of
the target B. Or the fetch agent of the target B shall
implement multiple login capability to allow the host C
to login to receive status, while the host A is printing.

I felt only two commands;
   - TRANSPORT_I2T_DATA
   - TRANSPORT_T2I_DATA
is required to develop data link layer for printing. And
any OS vender may use IEEE P1284.4 or MLC 3.x over this
data link layer to make a predictable multiple logical
channel supportive transport layer. I beleive 1284.4 is
beyond the specification of 1394 PWG command set. But 1394
PWG cannot forbid any OS vender to use 1284.4 over the data
link layer defined by 1394 PWG. Why do we need to define
something quite new from scratch? IEEE P1284.4 is one of
the excellent result from our PWG and it is very new.

I had experienced my proposal 1284.4 over SBP-2 was
eliminated through 1394 PWG discussion. Thus I realized
we need to define something better than 1284.4. However
for me, current commands set seems to be more poor than
1284.4.

                  |  1284.4      |  1394 PWG cmd set  |
------------------|--------------|--------------------|
Multiple Logical  |     YES      |         NO         |
   channels       |              | or YES/w LUNs      |
open/close from   |     YES      |         NO         |
     both peer    |              |                    |
predicatble       |     YES      |         YES        |
API for WinSock2  |     YES      |         NO         |
standardization   | 99% ALREADY  |       NOT YET      |
Multi Host support|      NO      |         NO         |
                  |or YES/w LUNs | or YES/w LUNs      |
------------------------------------------------------|

The chair man shall drive our discussion to clear pros/cons
of these idea;
1) something already existing over SBP-2 as data link
2) new command set now we are discussing over SBP-2

And 1394 PWG profile shall clear the method to support
multiple hosts connectivity. Design for the timer is
less priority. We will be able to define timer
requirements later, when we've got a real model of
transaction.

I don't feel my opinion bring us several month back to
the confusion. If the current model is not suitable for
current protocol driver provided in existing consumer PC OS,
we need to pay great effort to develop new device drivers.
And these effort will easily take several months to write,
to test and to debug new software. May be, my job becomes
more busy as code developer. :-) Thus we shall choose better
way to ship real products into the market.


Greg wrote:
>
>Fumio!  Are you serious about this timer?  You know as well as I
>do that:
>
>  - There is no need for the target to send all the data
>    requested by the initiator before completing the request,
>    since the _residual_ field will indicate the difference.
>    Padding bytes are not necessary.
>
>(and as discussed at the August meeting and a bit on the
>reflector(?))
>  - The target is at liberty to complete the ORB at it's
>    own discretion.  Since there is no reason for the
>    transport to hold it open for long periods of time
>    after it has moved some data, it should complete it
>    soon after moving all the data which was pending.
>
>This means there is no _need_ for a hanging read ORB timeout at
>the transport layer.  If one happened to be used, then it would
>need to be sensitive to the expected completion time of an ORB.
>Since the transport specifies a hanging TRANSPORT_T2I_DATA ORB to
>exist at all times, this ORB may not be completed for hours.  If
>this is a problem with current SBP-2 implementations, then we
>need to raise that issue.
>
>Incidently, this transport should already be as predictable as
>1284.4.
>
>If an initiator-side application is expecting "500" bytes to be
>returned by the target, and wishes to maintain a timeout for that
>transfer, then this is beyond the scope of the transport.
>
>- Greg Shue, HP
>
>Fumio wrote:
>> Hanging read ORB release timer;
>> 
>> When an initiator assume a target will reply 500 bytes,
>> but the target device only replies 300 bytes, then this
>> input ORB will not be completed. The initiator is waiting
>> for 200 bytes as rest of the contents. If we do not have
>> any timer to detect this situation and if the transport
>> layer software does not resolve hanging ORB to avoid input
>> pipe stalling, a higher level client software need to solve
>> this problem.
>> 
>> One possible solution for the problem is that the transport
>> software of the target fills padding data (null data) when
>> this timer over runs, and the target force to complete this
>> input ORB, and also the target shall reply the valid length
>> of data in the input buffer.
>> 
>> However I do not feel that we need to define this timer.
>> 
>> Because I prefer to design a predictable transport like CBT.
>> If we choose a CBT style solution, the target may ask the
>> initiator to provide credit to receive data from the target.
>> Then the target sends a packet which contains length field
>> of valid data length and real data itself.  Thus I believe
>> timer design depends upon whether we can define predictable
>> transport or not. Actually IEEE 1284.4 does not require to
>> have this sort of timer, because it does not need to assume
>> a communication pipe to be stalled.
>> 
>> Fumio
>> 
>> Alan wrote:
>> >August 25, 1998
>> >
>> >This is a call for discussion on Timers for the 1394 Image Profile.
>> >At the last meeting we attempted to address this issue and only identified 3 
>> >timers. Are there others we missed? Please submit comments and suggestions.
>> >
>> >1) Reconnect Timer - This one is taken care of by SBP-2 as part of the Login 
>> >process.
>> >
>> >2) Management ORB Timer - When the Initiator writes a Management ORB address to 
>> >the Management Agent Register, how long should it wait for a response to be 
>> >written to the management ORBs status fifo? How is the timeout value determined 
>> >and communicated?
>> >
>> >3) Abort Task Set Timer - An Abort Task Set may issued by an Initiator in 
>> >response to Target Inactivity. How is the timeout value determined and 
>> >communicated?
>> >
>> >Any other timers that we did not include at the last meeting?
>> >
>> >
>> >
>> 
>> ---
>> Fumio Nagasaka
>> EPSON Software Deveopment Lab., Inc.
>> voice: +81 268 25-4111
>> 
>
>
>-- 
>Greg Shue
>Hewlett-Packard Company
>All-in-One Division			        gregs@sdd.hp.com
>----------------------------------------------------------------
>

---
Fumio Nagasaka
EPSON Software Deveopment Lab., Inc.
voice: +81 268 25-4111

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Wed Sep  2 11:51:32 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:39 2009
Subject: P1394> November PWG Meeting
Message-ID: <H0000d930fe74147@MHS>

Hello PWG Members,

I have started planning our Meetings in November.

Unfortunately the meeting space in Phoenix was limited and the one Hotel 
that did have rooms, was not willing to accommodate our billing process.

The good news is that I was able to secure space at the Tucson Marriott 
University Park in Tucson Arizona (still in the southwest near Phoenix and 
closer to Nogales).
http://www.marriott.com/marriott/TUSUP/

Also it seems that the southwest is popular in November, I think a lot of folks 
like to get away from the Snow, so we would do well to make reservations early.

I should have more details in the next week or two.
Feel free to ping now if you want, with the usual information

Name:
Meetings you will attend:
If staying at the Marriott: Arrival & Departure Date

Regards,
Alan



From fumiona at venus.dti.ne.jp  Wed Sep  2 21:54:46 1998
From: fumiona at venus.dti.ne.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:39 2009
Subject: [PP1394:00329] Re: P1394> 1394 Timers?
In-Reply-To: <199809021710.KAA24412@hpsdlgj1.sdd.hp.com>
References: <199809021710.KAA24412@hpsdlgj1.sdd.hp.com>
Message-ID: <199809030149.KAA24771@smtp1.dti.ne.jp>

At first, my proposal 1284.4 over SBP-2 was eliminated by
voting in this January. Thus I will not suggest same idea
again. In February meeting I actually realized my idea was
bad and I stopped to say 1284.4 over SBP-2. So I did other
effort to edit WhitePaper to show existing 1394 driver
structure in a consumer PC OS. And 1284.4 design discussed
in different PWG group is obviously beyond the 1394 PWG
command set specification.

I am just saying one existing transport design seems to be
better than current 1394 PWG commands set. We need to do
more effort. If someone improve the design and persuade me
to realize 1394 command set is better, I willingly agree
with the idea. If not, my idea is the 1394 PWG command set
shall be a data link layer to be utilized with other
transport command set.

For example, usb printing class design seems to be providing
something convenient data link layer which is flexible to
meet higher protocol layer. I am not sure whether someone
had developed already, but may be someone can apply 1284.4
over usb printing class. Usb printing class design is
providing two bi-directional communication queue, bulk-in,
bulk-out and default pipe. And one bi-directional queue is
applicable for data session and the other is applicable for
transport control. One bi-directional communication pipe may
be enough to meet 1284.4. But in this thread, I have no
urge to say something about usb, thus I will stop to say more
about usb in here. I prefer 1394 :-)

Greg Shue wrote:
>Let's look at some other characteristics:
>  effecient:            LESS                |  MUCH MORE
>  -> Bus Utilization:  low to moderate      |  high
>                       (credit pkts aren't) |
>  -> Max size transfer:  64KBytes           | 2 GBytes - 1

I agree with you, but 64kB is max_length of one packet
delivered from a peer to the other peer. The title "Max size
transfer" may cause misunderstanding for someone who are
subscribing our reflector without knowledge about 1284.4.

>  -> Max amt of data
>     queuable:           as much memory as     max (negotiated) size
>                         allocated by device   transfer * MAX_TASK_SET_SIZE - 1

Ok, if you say "queeable", the max size queuable in memory
cannot exceed max size of memory allocated by Operating System.
Thus your description is misleading the discussion.
Our scanner OS will not allocate 2 GB for queuable memory
space. :-) This is just a specification writing technique.

>                         for that connection
>  -> Processing overhead: MUCH MORE         | LESS

Agreed. Thank you! good pont.

>
>  Defined SBP-2           No                | Yes
>  command set

This is one benefit of 1284.4. IEEE P1284.4 is pure transport.
I mean 1284.4 is abstracted from any data link layer and it
does not have any dependency for data link design. If you
want to say your commands have some dependency for SBP-2
in words "defined SBP-2 command set", I feel it is better
to develop command set which does not have any dependency on
data link layer. We are defining transport layer.

>1284.4 is insufficient by itself as a data link.
>Without a description of an SBP-2 command set,
>target device model, Config ROM description,
>and model of use, you have an incomplete solution.

Let's clear the points;
I'm not saying I would like to use 1284.4 over SBP-2.
This idea was eliminated in February. I am saying that we
shall develop something better than 1284.4 to utilize
SBP-2, or something just a data link layer which is
applicable for transport protocol. But in later case
each vendor need to choose or develop higher layer to
apply this data link. Thus I prefer first idea. We shall
develop something more effective than 1284.4 to utilize
SBP-2. May be Greg is thinking current command set
is better thna aother, but I am thinking we need to pay
more effort to exceed even 1284.4.

>
>Fumio Nagasaka wrote:
>> >Incidently, this transport should already be as predictable as
>> >1284.4.
>> 
>> This is the answer I was waiting for.
>> If 1394 PWG transport is as predictable as 1284.4,
>> then we shall remove descriptions which are describing
>> two queues model in 1394 PWG profile. Because these
>> descriptions are implementation issue and beyond the
>> specification. In addition to this, if our transport
>> is as predictable as 1284.4, then why do we need to describe
>> something about two queues model. The forward direction
>> (I to T) transaction and the reverse direction (T to I)
>> transaction will not be stalled. If so, we do not need
>> to assume a target to have two independent queues.
>
>The services provided by the command set are the same as provided by a
>1284.4 connection.  Separate logins provide separate channels.
>The big question in my mind is how many services and instances
>are combined in one UNIT.  There is at least one path forward
>simply by defining each service instance is a separate unit.
>There may be other reasonable options.
>
>As far as predictability of the transport goes, you must not have
>done much debugging of 1284.4 communications.  The exact sequence
>of packets going across the wire is not predictable.  Neither is
>the sequence if IP packets going to an Ethernet node.
>
>The reason for providing the "two queues" descriptions on the command
>set is because we must describe how to use SBP-2 and what the contents
>of the CDB mean.  Removing the description of "two queues" from
>the profile is equivalent to removing the concept of "credit"
>from 1284.4.
>
>The "two queues" is a conceptual description.  There is nothing
>that requires that an implementation actually maintains two
>distinct queues.  It could do it using a single linked list
>and searching through the list each time.  It just must behave
>as though it were maintaining two distinct queues.  This description
>is what gives it some degree of predictability.
>
>As far as "stalling" goes, the I2T direction and T2I direction
>could be stalled simply by the initiator not providing ORBs.
>What is prevented is that the data flow will not be blocked by
>_other_ communication.
>
>> The current command set does not meet the scope of 1394
>> PWG profile. Because the command set does not allow for
>> either end of a connection to close the connection at
>> any time.
>
>The command set by itself could never meet the scope of the
>profile.  If it did, it would be the entire profile.
>
>In the command set, the concept of a "closed connection" is
>distinct from a "Logout".  The transport client within the target
>can "close" a connection (or either direction of a connection) at
>any time.  When an ORB is queued for a "closed" direction, that
>status is returned in the completion notification of the ORB.
>
>> Also the current command set does not describe
>> the way to support multiple host connectivity.
>
>That is beyond the scope of the command set.  The command set
>describes how to manage one connection.  Multi-host connectivity
>may be (and should be) addressed elsewhere in the profile.
>
>> Actually
>> when a host A is printing to a target B utilizing LUN #1,
>> then the other host C cannot login to receive status of
>> the target B. Or the fetch agent of the target B shall
>> implement multiple login capability to allow the host C
>> to login to receive status, while the host A is printing.
>
>This is beyond the scope of the command set.  Your example is
>true if the "status" service is done as a separate LUN instead of
>a separate service found in a different Unit directory.
>
>Also, I'd recommend using LUN #0 since it must be supported.  :-)
>
>> I felt only two commands;
>>    - TRANSPORT_I2T_DATA
>>    - TRANSPORT_T2I_DATA
>> is required to develop data link layer for printing. And
>> any OS vender may use IEEE P1284.4 or MLC 3.x over this
>> data link layer to make a predictable multiple logical
>> channel supportive transport layer.
>
>I would not recommend you using MLC 3.x for anything.  Using
>P1284.4 is an option, and we discussed this in the PWG many, many
>months ago and _voted_ against going that direction.  If you'd
>like to do independent work and present a written proposal at the
>next meeting, please feel free to, but that issue has been
>addressed.
>
>> I had experienced my proposal 1284.4 over SBP-2 was
>> eliminated through 1394 PWG discussion. Thus I realized
>> we need to define something better than 1284.4. However
>> for me, current commands set seems to be more poor than
>> 1284.4.
>> 
>>                   |  1284.4      |  1394 PWG cmd set  |
>> ------------------|--------------|--------------------|
>> Multiple Logical  |     YES      |         NO         |
>>    channels       |              | or YES/w LUNs      |
>
>And yes with multiple Units!
>
>> open/close from   |     YES      |         NO         |
>>      both peer    |              |                    |
>See above comment, the answer is YES for PWG, to exactly
>the same degree that it would be for 1284.4 over ??? over SBP-2.
>
>> predicatble       |     YES      |         YES        |
>> API for WinSock2  |     YES      |         NO         |
>When was this a transport requirement?
>
>> standardization   | 99% ALREADY  |       NOT YET      |
>OK, show me the standard document.
>
>> Multi Host support|      NO      |         NO         |
>>                   |or YES/w LUNs | or YES/w LUNs      |
>> ------------------------------------------------------|
>
>Let's look at some other characteristics:
>  effecient:            LESS                |  MUCH MORE
>  -> Bus Utilization:  low to moderate      |  high
>                       (credit pkts aren't) |
>  -> Max size transfer:  64KBytes           | 2 GBytes - 1
>  -> Max amt of data
>     queuable:           as much memory as     max (negotiated) size
>                         allocated by device   transfer * MAX_TASK_SET_SIZE - 1
>                         for that connection
>  -> Processing overhead: MUCH MORE         | LESS
>
>  Defined SBP-2           No                | Yes
>  command set
>
>> The chair man shall drive our discussion to clear pros/cons
>> of these idea;
>> 1) something already existing over SBP-2 as data link
>> 2) new command set now we are discussing over SBP-2
>
>I doubt the chair would re-open a closed issue without
>a written complete proposal.
>
>1284.4 is insufficient by itself as a data link.
>Without a description of an SBP-2 command set,
>target device model, Config ROM description,
>and model of use, you have an incomplete solution.
>
>> And 1394 PWG profile shall clear the method to support
>> multiple hosts connectivity. Design for the timer is
>> less priority. We will be able to define timer
>> requirements later, when we've got a real model of
>> transaction.
>
>We already have a real model of transaction.
>I haven't heard any other complaints about it.
>
>-- 
>Greg Shue
>Hewlett-Packard Company
>All-in-One Division			        gregs@sdd.hp.com
>----------------------------------------------------------------
>

---
Fumio Nagasaka
EPSON Software Deveopment Lab., Inc.
voice: +81 268 25-4111

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Thu Sep  3 17:20:37 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:39 2009
Subject: [PP1394:00331] Re: P1394> 1394 Timers?
In-Reply-To: <199809031635.JAA25392@hpsdlgj1.sdd.hp.com>
Message-ID: <H0000d930fe97ab5@MHS>

A non-text attachment was scrubbed...
Name: 1.txt
Type: application/octet-stream
Size: 2013 bytes
Desc: not available
Url : http://www.pwg.org/archives/p1394/attachments/19980903/e7f0d54e/1.obj
-------------- next part --------------
     
Wow! I am lost in the drift of this whole thread?

Does any of this still actually address timers?

Can someone summarize the salient points in a new topic?

Is there anything actionable for the profile?

Help....

Alan

______________________________ Reply Separator _________________________________
Subject: Re: [PP1394:00331] Re: P1394> 1394 Timers?
Author:  gregs-at-sdd (gregs@sdd.hp.com) at HP-Roseville,mimegw3
Date:    9/3/98 9:36 AM


Fumio Nagasaka wrote:
> I am just saying one existing transport design seems to be 
> better than current 1394 PWG commands set. We need to do
> more effort. If someone improve the design and persuade me 
> to realize 1394 command set is better, I willingly agree
> with the idea. If not, my idea is the 1394 PWG command set 
> shall be a data link layer to be utilized with other
> transport command set.
     
When looking at a total solution, I don't see how the combination 
of (1284.4 + <data link cmd set> + SBP-2 + 1394) is "better"
than what we have currently defined.  The <data link cmd set> 
would be slightly simpler than our current proposal, but
it requires much more complexity to do 1284.4.  We'll end 
up with a much more efficient and lighter weight protocol.
     
> Greg Shue wrote:
> >  -> Max amt of data
> >     queuable:           as much memory as     max (negotiated) size
> >                         allocated by device   transfer * MAX_TASK_SET_SIZE -
 1
> 
> Ok, if you say "queeable", the max size queuable in memory
> cannot exceed max size of memory allocated by Operating System. 
> Thus your description is misleading the discussion.
> Our scanner OS will not allocate 2 GB for queuable memory 
> space. :-) This is just a specification writing technique.
     
In the case of SBP-2, the maximum size queuable on the Task List 
cannot exceed the max size of memory allocated by the initiator's 
operating system.  These are PCs with potentially lots of memory. 
In the case of 1284.4, the maximum size which can be transferred 
without having to issue credit is limited to the smallest amount 
dedicated at either end of the cable.  For the same configuration, 
would you rather have a 2 MB total limit or a 32 KB total limit?
     
> >
> >  Defined SBP-2           No                | Yes 
> >  command set
> 
> This is one benefit of 1284.4. IEEE P1284.4 is pure transport. 
> I mean 1284.4 is abstracted from any data link layer and it
> does not have any dependency for data link design. If you 
> want to say your commands have some dependency for SBP-2 
> in words "defined SBP-2 command set", I feel it is better
> to develop command set which does not have any dependency on 
> data link layer. We are defining transport layer.
     
Nope, we are defining a complete stack up through the transport 
layer.  This means we must also define the "data link" layer and 
how to glue them together.  Without an SBP-2 command set, there 
is no SBP-2 based solution.
     
> Let's clear the points;
> I'm not saying I would like to use 1284.4 over SBP-2.
> This idea was eliminated in February. I am saying that we 
> shall develop something better than 1284.4 to utilize
> SBP-2, or something just a data link layer which is 
> applicable for transport protocol. But in later case
> each vendor need to choose or develop higher layer to
> apply this data link. Thus I prefer first idea. We shall 
> develop something more effective than 1284.4 to utilize 
> SBP-2. May be Greg is thinking current command set
> is better thna aother, but I am thinking we need to pay 
> more effort to exceed even 1284.4.
     
I'll agree with the first option.  And I think we are already 
doing that.  Specifically, what do you think needs to be improved 
or addressed?
     
The second option is counter-productive.  We're trying to 
come up with standards here.
     
-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division                             gregs@sdd.hp.com 
----------------------------------------------------------------
From atsnaka at bsd.canon.co.jp  Thu Sep  3 20:18:30 1998
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:39 2009
Subject: [PP1394:00331] Re: P1394> 1394 Timers?
In-Reply-To: <199809031635.JAA25392@hpsdlgj1.sdd.hp.com>
References: <199809030149.KAA24771@smtp1.dti.ne.jp>
Message-ID: <4.0.1-J.19980904091453.00f1ad90@172.20.108.5>

While I was ctching up with the thread, 
I noticed that this is going out ONLY on the PWG-C reflector,
not p1394@pwg.org.

Is there something wrong with the PWG reflector (or my mailer) ?????

Ats

At 01:36 98/09/04 +0900, Greg Shue wrote:
> Fumio Nagasaka wrote:
> > I am just saying one existing transport design seems to be
> > better than current 1394 PWG commands set. We need to do
> > more effort. If someone improve the design and persuade me
> > to realize 1394 command set is better, I willingly agree
> > with the idea. If not, my idea is the 1394 PWG command set
> > shall be a data link layer to be utilized with other
> > transport command set.
> 
> When looking at a total solution, I don't see how the combination
> of (1284.4 + <data link cmd set> + SBP-2 + 1394) is "better"
> than what we have currently defined.  The <data link cmd set>
> would be slightly simpler than our current proposal, but
> it requires much more complexity to do 1284.4.  We'll end
> up with a much more efficient and lighter weight protocol.
> 
> > Greg Shue wrote:
> > >  -> Max amt of data
> > >     queuable:           as much memory as     max (negotiated) size
> > >                         allocated by device   transfer * MAX_TASK_SET_SIZE - 1
> > 
> > Ok, if you say "queeable", the max size queuable in memory
> > cannot exceed max size of memory allocated by Operating System.
> > Thus your description is misleading the discussion.
> > Our scanner OS will not allocate 2 GB for queuable memory
> > space. :-) This is just a specification writing technique.
> 
> In the case of SBP-2, the maximum size queuable on the Task List
> cannot exceed the max size of memory allocated by the initiator's
> operating system.  These are PCs with potentially lots of memory.
> In the case of 1284.4, the maximum size which can be transferred
> without having to issue credit is limited to the smallest amount
> dedicated at either end of the cable.  For the same configuration,
> would you rather have a 2 MB total limit or a 32 KB total limit?
> 
> > >
> > >  Defined SBP-2           No                | Yes
> > >  command set
> > 
> > This is one benefit of 1284.4. IEEE P1284.4 is pure transport.
> > I mean 1284.4 is abstracted from any data link layer and it
> > does not have any dependency for data link design. If you
> > want to say your commands have some dependency for SBP-2
> > in words "defined SBP-2 command set", I feel it is better
> > to develop command set which does not have any dependency on
> > data link layer. We are defining transport layer.
> 
> Nope, we are defining a complete stack up through the transport
> layer.  This means we must also define the "data link" layer and
> how to glue them together.  Without an SBP-2 command set, there
> is no SBP-2 based solution.
> 
> > Let's clear the points;
> > I'm not saying I would like to use 1284.4 over SBP-2.
> > This idea was eliminated in February. I am saying that we
> > shall develop something better than 1284.4 to utilize
> > SBP-2, or something just a data link layer which is
> > applicable for transport protocol. But in later case
> > each vendor need to choose or develop higher layer to
> > apply this data link. Thus I prefer first idea. We shall
> > develop something more effective than 1284.4 to utilize
> > SBP-2. May be Greg is thinking current command set
> > is better thna aother, but I am thinking we need to pay
> > more effort to exceed even 1284.4.
> 
> I'll agree with the first option.  And I think we are already
> doing that.  Specifically, what do you think needs to be improved
> or addressed?
> 
> The second option is counter-productive.  We're trying to
> come up with standards here.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------
>  
-----------------------------------------
Atsushi Nakamura
-----------------------------------------

BJ Technology Development 22,
Canon Inc.

53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211

tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------

From don at lexmark.com  Fri Sep  4 07:38:28 1998
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:39 2009
Subject: P1394> Test
Message-ID: <199809041139.AA03562@interlock2.lexmark.com>

I am testing the PWG's 1394 printing reflector..... please ignore.

Don



From gregs at sdd.hp.com  Wed Sep  2 13:47:16 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:39 2009
Subject: P1394> TARGET RESET & Unit/LU/Profile interactions
Message-ID: <199809021747.KAA25581@hpsdlgj1.sdd.hp.com>


Hi all,

At the end of the last meeting I agreed to raise the following
issue on the reflector...

One of the areas still requiring clarification is the mapping
of transport and target transport clients into SBP-2 Units and
Logical Units.  This is an area where the SCSI roots of SBP-2
have really impacted our efforts.

 - Looking at the draft SCSI-3 ARCHITECTURE MODEL -2 (SAM-2) rev
   0.3, I find that "Each SCSI-3 protocol standard shall specify
   the response to a target reset event including the conditions
   under which a target hard reset shall be executed.

 - Looking at SBP-2, rev 4, we find TARGET RESET affects all
   logged-in initiators (to any logical unit within the Unit).

Some questions which need to be answered are:

 a) How is TARGET RESET used by drivers n commercial operating
    systems?  (Both non-embedded and embedded?)
    
 b) Can we define how broadly (or narrowly) the TARGET RESET event
    affects a device using our transport?

    If so, how should it be defined?

    If not, does this mean that we must use one Unit directory
    for each possible instance of a service?

Ideas, anyone?



-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From fumiona at venus.dti.ne.jp  Mon Sep  7 11:08:46 1998
From: fumiona at venus.dti.ne.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:39 2009
Subject: [PP1394:00335] Re: P1394> 1394 Timers?
In-Reply-To: <199809040134.SAA12880@hpsdlgj1.sdd.hp.com>
References: <199809040134.SAA12880@hpsdlgj1.sdd.hp.com>
Message-ID: <199809071503.AAA21383@coral.ocn.ne.jp>

Thank you Greg, for your good summarizing,

Alan, Randy I was sorry may be you are confused as I
did not separate these two thread.

1. Timer issue
Greg explained the 1394 PWG transport is predictable
as same as CBT (Credit Based Transport). Thus I understood
a timer to detect a hanging read ORB is not required.
However the T to I transaction will easily be stalled
when the initiator does not provide any input ORBs.

Greg Shue:
> As far as "stalling" goes, the I2T direction and T2I direction
> could be stalled simply by the initiator not providing ORBs.
> What is prevented is that the data flow will not be blocked by
> _other_ communication.

Thus we at 1394 PWG shall describe a method to force an
initiator to provides ORBs without utilizing unsolicited
status from the target. Because some operating system does
not support this functionality.

2. Transport requirements

Greg Shue:
> I suggested that he create a written alternate proposal for the
> next PWG meeting, so that his concerns get raised.

Yes, I will.

Greg Shue and Fumio Nagasaka:
fn> gs>
fn> gs>  Defined SBP-2           No                | Yes
fn> gs>  command set
fn> 
fn> This is one benefit of 1284.4. IEEE P1284.4 is pure transport.
fn> I mean 1284.4 is abstracted from any data link layer and it
fn> does not have any dependency for data link design. If you
fn> want to say your commands have some dependency for SBP-2
fn> in words "defined SBP-2 command set", I feel it is better
fn> to develop command set which does not have any dependency on
fn> data link layer. We are defining transport layer.

gs>
gs> Nope, we are defining a complete stack up through the transport
gs> layer.  This means we must also define the "data link" layer and
gs> how to glue them together.  Without an SBP-2 command set, there
gs> is no SBP-2 based solution.

When we are defining a data link layer which is applicable
for other transport protocol,  then may be open/close/move
data I2T or move data T 2I/ are enough  functions  in this
layer. However if you say we are defining "a complete stack
up through the transport layer", then we shall provide
services to ease a session layer to find or to use facilities
provided in the 1394 PWG peripherals. So we shall provide
some higher service capability and functions abstracted
from SBP-2 transaction.

To give a simple example, "Universal Serial Bus (USB) Device
Class Definition for Printing Device" is defining two
interesting "Class Specific Requests" GET_DEVICE_ID and
GET_PORT_STATUS. The first request makes it easy for the
session layer to get 1284 PnP ID from a printer. The later
request fakes the session layer as if the transport is
providing a conventional 8 bit printer port. Actually
these requests are really usable for a PortMonitor developer
who is working for some existing PC OS(s).

A SBP-2/1394 PWG supportive printer provides 1284 PnP ID in a
configuration ROM. So a higher level protocol driver
may read textual descriptor from the configuration ROM.
But this method has a strong dependency for 1394 bus
system. If the transport layer protocol driver has a
function which reports 1284 PnP ID to higher level
protocol driver, the higher level protocol driver would
be abstracted from 1394 Bus system. And the printer
driver developer will be able to write a common session
layer program which covers both USB and SBP-2.

Still 40% of my mind is wondering these description
shown above seems to be inconsistent. Because still
I am not sure what Greg is saying as "a complete stack
up through the transport layer". It seems to be very
big scope. We shall just design a transport layer.



Greg Shue:
>
>> I agree. I'm lost too. I thought my previous email got lost....
>> 
>> Randy
>
>Welcome to topic drift ...
>
>The topic was timeouts.  No one has come up with any other ones
>than those listed by Alan, so no additional action items exist
>for the draft.
>
>In the course of discussion, Fumio expressed his concern that
>the current proposal is no better (or possibly even worse)
>than a 1284.4-based solution.  He also thought that we were
>defining a transport layer, rather than a transport stack.
>
>I suggested that he create a written alternate proposal for the
>next PWG meeting, so that his concerns get raised.
>
>
>-- 
>Greg Shue
>Hewlett-Packard Company
>All-in-One Division			        gregs@sdd.hp.com
>----------------------------------------------------------------
>

---
Fumio Nagasaka
EPSON Software Deveopment Lab., Inc.
voice: +81 268 25-4111

From hitoshis at MICROSOFT.com  Tue Sep  8 01:46:09 1998
From: hitoshis at MICROSOFT.com (Hitoshi Sekine)
Date: Wed May  6 14:00:39 2009
Subject: P1394> FW: Profile 24. Login
Message-ID: <FD8F41F04D35D111899600805F19A16C0642FC7D@RED-MSG-48>

> This statement is no longer true in NT5 as long as the device returns
> device_type 2 or 3.
> 
> 24 Login
> Microsoft has implemented their SBP-2 driver to do a login on power up and
> not logout until the PC is shut down. Though this is provided for within
> the SBP-2 specification, it requires devices, which may be shared among
> multiple PCs to support multiple logins to a single service, even if the
> different PCs cannot simultaneously use the service.
> 
> Can imaging devices (which want to take advantage of the shared nature of
> 1394) tolerate the resource requirements to operate on a multiple
> Microsoft O/S host configuration? 
> 
Thanks,
Hitoshi

From gregs at sdd.hp.com  Tue Sep  8 12:33:49 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:39 2009
Subject: P1394> PWG Profile Scope (was 1394 Timers?)
In-Reply-To: <199809071503.AAA21383@coral.ocn.ne.jp> from "Fumio Nagasaka" at Sep 8, 98 00:12:13 am
Message-ID: <199809081633.JAA18693@hpsdlgj1.sdd.hp.com>

Fumio Nagasaka:
> Thus we at 1394 PWG shall describe a method to force an
> initiator to provides ORBs without utilizing unsolicited
> status from the target. Because some operating system does
> not support this functionality.

We did.  We said it was required by the spec.  Any driver
which does not supply an outstanding TRANSPORT_T2I_DATA command
on an open (T2I) queue is non-compliant.

> 2. Transport requirements
> 
> Greg Shue:
> > I suggested that he create a written alternate proposal for the
> > next PWG meeting, so that his concerns get raised.
> 
> Yes, I will.
> 
> Greg Shue and Fumio Nagasaka:
> fn> gs>
> fn> gs>  Defined SBP-2           No                | Yes
> fn> gs>  command set
> fn> 
> fn> This is one benefit of 1284.4. IEEE P1284.4 is pure transport.
> fn> I mean 1284.4 is abstracted from any data link layer and it
> fn> does not have any dependency for data link design. If you
> fn> want to say your commands have some dependency for SBP-2
> fn> in words "defined SBP-2 command set", I feel it is better
> fn> to develop command set which does not have any dependency on
> fn> data link layer. We are defining transport layer.
> 
> gs>
> gs> Nope, we are defining a complete stack up through the transport
> gs> layer.  This means we must also define the "data link" layer and
> gs> how to glue them together.  Without an SBP-2 command set, there
> gs> is no SBP-2 based solution.
> 
> When we are defining a data link layer which is applicable
> for other transport protocol,  then may be open/close/move
> data I2T or move data T 2I/ are enough  functions  in this
> layer. However if you say we are defining "a complete stack
> up through the transport layer", then we shall provide
> services to ease a session layer to find or to use facilities
> provided in the 1394 PWG peripherals. So we shall provide
> some higher service capability and functions abstracted
> from SBP-2 transaction.

Or provide it in Config ROM.  Nothing says that it must be
done on top of SBP-2.

> A SBP-2/1394 PWG supportive printer provides 1284 PnP ID in a
> configuration ROM. So a higher level protocol driver
> may read textual descriptor from the configuration ROM.
> But this method has a strong dependency for 1394 bus
> system...

So does a 1284 negotiation for Device ID.
So does whatever process is necessary to extract the Device ID
from USB.  The "strong dependency" of the method is not
a reasonable argument.


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From don at lexmark.com  Mon Sep 14 15:26:47 1998
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:39 2009
Subject: P1394> Mailing Lists
Message-ID: <199809141927.AA13984@interlock2.lexmark.com>

The mailing lists are back up and running.  Just to test everything out, I have
sent this mail to ALL the mailing lists.  If you get this mail on one list and
not on another you think you should be on then I suggest you resubscribe by
sending e-mail to:

majordomo@pwg.org

with the body of the note containing

subscribe <list-name>

when <list-name> is the name of the list you wish to subscribe to.  You can
include multiple subscriptions in the same note.

Thanks for your patience during this transfer.

**********************************************
* Don Wright                 don@lexmark.com *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************




From gregs at sdd.hp.com  Mon Sep 14 16:13:46 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:39 2009
Subject: P1394> TARGET RESET & Unit/LU/Profile interactions
Message-ID: <199809142013.NAA18566@hpsdlgj1.sdd.hp.com>

Hi all,

At the end of the last meeting I agreed to raise the following
issue on the reflector...

One of the areas still requiring clarification is the mapping
of transport and target transport clients into SBP-2 Units and
Logical Units.  This is an area where the SCSI roots of SBP-2
have really impacted our efforts.

 - Looking at the draft SCSI-3 ARCHITECTURE MODEL -2 (SAM-2) rev
   0.3, I find that "Each SCSI-3 protocol standard shall specify
   the response to a target reset event including the conditions
   under which a target hard reset shall be executed.

 - Looking at SBP-2, rev 4, we find TARGET RESET affects all
   logged-in initiators (to any logical unit within the Unit).

Some questions which need to be answered are:

 a) How is TARGET RESET used by drivers n commercial operating
    systems?  (Both non-embedded and embedded?)
    
 b) Can we define how broadly (or narrowly) the TARGET RESET event
    affects a device using our transport?

    If so, how should it be defined?

    If not, does this mean that we must use one Unit directory
    for each possible instance of a service?

Ideas, anyone?



-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From gregs at sdd.hp.com  Mon Sep 14 18:01:36 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:39 2009
Subject: P1394> TARGET RESET & Unit/LU/Profile interactions
In-Reply-To: <35FD80BB.6A92296C@sharplabs.com> from "Randy Turner" at Sep 14, 98 01:46:52 pm
Message-ID: <199809142201.PAA18639@hpsdlgj1.sdd.hp.com>



"Should" doesn't matter, since the behavior of TARGET RESET is defined
by SBP-2, Rev 4, in section 10.4.4.  The problem is we are stuck with
the defined behavior.

- Greg S.

Randy Turner wrote:
> 
> Shouldn't a target reset from a particular initiator abort all existing login sessions that have been established from the initiator
> of the target reset to the target itself. Note I'm implying that other login sessions from other initiators would not be affected.
> Note this is our OWN transport semantics and might not apply to any other transport currently in use. The original logical unit and
> config information would not be changed (if it's ok to make that assumption).
> 


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From gregs at sdd.hp.com  Tue Sep 15 12:06:00 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:39 2009
Subject: P1394> TARGET RESET & Unit/LU/Profile interactions
In-Reply-To: <199809150508.WAA23993@mail.pacifier.com> from "Randy Turner" at Sep 14, 98 10:05:01 pm
Message-ID: <199809151606.JAA20589@hpsdlgj1.sdd.hp.com>


Discussions about how to map between units & logical units and
functions & services & service instances given this interaction,
and any other issues related to this behavior that I haven't
noted.  I was primarily raising awareness of the issue.

GregS

> 
> 
> If SBP-2 mandates what we do with a target reset, then I'm not sure what
> you are asking for in your original mail...(?)
> 
> Randy


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Tue Sep 15 16:04:57 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:39 2009
Subject: P1394> 1394 PWG Spec rev 0.52
Message-ID: <H0000d930ff86d7e@MHS>

     Hello,
     
     The latest spec is out on the web. 
     
     I did the major edits, added the command set, and updated 
     the issues list.
     
     I did not finish all of the minor edits.
     
     I expect that we will review the spec and issues in Savannah.
     
     Also did not add config ROM.
     
     Get the spec now at ftp://www.pwg.org/pub/pwg-in
     
     regards,
     Alan


From gleclair at agentz.com  Mon Sep 21 12:55:13 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:39 2009
Subject: P1394> Additional proposal posted
Message-ID: <01BDE545.EDA416E0.gleclair@agentz.com>

Fumio Nagasaka has written a proposal for the 1394 PWG transport command set.

The PDF file has been uploaded at:

ftp://ftp.pwg.org/pub/pwg/p1394/mtg092898/proposal-cmd-1a.pdf


This is proposed after reviewing new profile (Rev. 0.52). It addresses 
some points in the current proposal. Thus it is also a proposal for the 
1394 PWG command set.


Regards,
Greg


From gleclair at agentz.com  Mon Sep 21 14:27:24 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:39 2009
Subject: P1394> Proposal Issue
Message-ID: <01BDE552.CEFE6760.gleclair@agentz.com>

I've received notice that some people have had problems with the 
proposal recieved from Nagasaka-san.

I'll work with him to repost a fixed version.

Regards,
Greg


From gleclair at best.com  Sun Sep 27 21:06:12 1998
From: gleclair at best.com (Gregory LeClair)
Date: Wed May  6 14:00:39 2009
Subject: P1394> Agenda and Meeting start time
Message-ID: <01BDEA41.88B85EC0@gleclair.vip.best.com>

Agenda for Savannah Meeting:

1. Administrivia (Wright)
2. Presentation for command set proposal (Nagasaka) 
3. Profile 0.52 review (Berkema) 
4. Config ROM Issues (LeClair) 
	- PWG OUI
	- IEEE 1212 Status

Meeting Start Time:
My departure has been delayed. I will be in Savannah at approximately 
10 - 10:30 AM on Monday. Please start the meeting at your convenience.


Greg


 

From gleclair at best.com  Sun Sep 27 20:55:53 1998
From: gleclair at best.com (Gregory LeClair)
Date: Wed May  6 14:00:39 2009
Subject: P1394> Updated copy of proposal posted
Message-ID: <01BDEA41.86A0C960@gleclair.vip.best.com>

An updated copy of the proposal by Fumio Nagasaka has been uploaded.

The PDF file has been uploaded at:

ftp://ftp.pwg.org/pub/pwg/p1394/mtg092898/proposal-cmd-1a.pdf


This is proposed after reviewing new profile (Rev. 0.52). It addresses 
some points in the current proposal. Thus it is also a proposal for the 
1394 PWG command set.


Regards,
Greg


From gleclair at best.com  Mon Sep 28 17:36:12 1998
From: gleclair at best.com (Gregory LeClair)
Date: Wed May  6 14:00:39 2009
Subject: P1394> Meeting Minutes from Monterey - July
Message-ID: <01BDEAED.64FEA280@gleclair.vip.best.com>

===============================================


Meeting Attendees

Takashi Isoda	Canon
Osamu Hirata	Canon
Akihiro Shimura	Canon
Lee Farrell	Canon Information Systems
Greg LeClair 	Epson   (1394 PWG Chairman)
Fumio Nagasaka	Seiko Epson 
Atsushi Uchino	Seiko Epson
Brian Batchelder	Hewlett Packard
Alan Berkema	Hewlett Packard
Scott Bonar	Hewlett Packard
Eric Clement	Hewlett Packard
Laurie Lasslo	Hewlett Packard
Greg Shue	Hewlett Packard
Kwang Kim	Hitachi
Yuji Sasaki	Japan Computer Industry
Brian Nagy	Kodak
Jerry Thrasher	Lexmark
Don Wright	Lexmark
John Fuller	Microsoft
Frank Zhao	Panasonic
Randy Turner	Sharp
Bob Morford	SIS Microelectronics
Anthony Fung	ST Micro Electronics
Peter Groz	ST Micro Electronics
Harry Hvostov	ST Micro Electronics


Administrivia

Don Wright gave the next PWG meeting details:
August 17-21
Toronto Marriott at Eaton Centre 
525 Bay Street
Toronto, Ontario, Canada M5G 2L2
$175CN (about $120 US)
Registration deadline is July 24, 1998

Future PWG weekly schedules will be as follows:
  1394 PWG on Monday and Tuesday
  MIB meetings on Tuesday evening (if needed)
  PWG Plenary meetings on Wednesday morning
  IPP on Wednesday afternoon and Thursday morning
  SDP on Thursday afternoon
  UPD on Friday

Greg LeClair presented the 1394 PWG meeting goals and proposed agenda
topics:
  OUI Issues
  Transport Command Set
  Config ROM Review
  Profile Review
  Updates


OUI Issues

Greg LeClair asked if we need to have an OUI for the 1394 PWG Profile?

The group did not resolve this issue, but a few attendees suggested that
the IEEE 1212 group should maintain the list of Function Classes. Greg
said that this topic was raised at the previous 1212 meeting, but no
conclusion was reached at that meeting. Further discussions were
deferred.


Error Recovery Model

Isoda-san gave a presentation on his ideas for supporting error
recovery. His main requirements are that the Initiator shall keep the
contents of the data buffers associated with the ORBs in the linked
list, and maintain the correspondence of the data buffers to a Sequence
Identifier. The Target must guarantee that it does not execute any data
or command twice.

Greg Shue asked if the proposal addresses both writing from the
Initiator as well as writing from the Target. Isoda-san suggested that
it does address both, but he is more confident about the Initiator
writing recovery.

Isoda-san claims that we should maintain a Sequence Id for the ORBs. As
part of the proposal, he explained that it is not necessary for every
ORB to have a status notification sent. It is adequate to send status
for a subset of the ORBs. Specifically, if a Sequence Id can be a
maximum of 2n-1, it is necessary to have at least one status sent for
every group of n ORBs that have been sent since the previous status.

He showed that, based on the requeuing of ORBs, the Target can determine
if the Initiator has received the most recently sent status block. He
also said that if a Sequence Id is not used, the Target cannot determine
if the Initiator has received the status block or not.

A few people commented that the idea of a "sliding window" of ORB
sequences was a good one. 

During discussion of the proposal, Randy Turner said that he believes we
should keep negotiation of buffer size. 

Brian Batchelder asked if anyone could evaluate the benefit (in terms of
performance efficiency) gained by reducing the number of notification
status blocks sent. The only comment was that "it really depends on the
size of the data buffers."


Transport Command Set

Greg Shue referenced his proposal document, PWG 1394 Transport Command
Set Proposal Revision 0c. (This document is available at
ftp://ftp.pwg.org/pub/pwg/p1394/mtg070698/pwgcmd0c.pdf.) He provided a
quick overview of the document and each of the open issues including
those items in the document that are identified as "to be determined."
The major discussion items and any conclusions reached are given below.
(The discussions were not sequential as the paragraphs below might
imply.)

[NOTE:	Greg LeClair captured additional issues that were raised. His
list should be included in the minutes.]


Queues

Should the usage of each queue be specified (e.g. Read and Write) or
left arbitrary? Should we allow a vendor to extend the number of queues
within a single Login? 

Brian Batchelder suggested that if an implementer would like to extend
the number of queues, it should be accomplished by additional Logins. He
suggests that we should limit a given Login to a (simple) bi-directional
communication "pipe." (The idea of two independent queues was originally
proposed because SBP-2 doesn't inherently support this capability.)

The group agreed to limit the number of queues to 2; one for
Initiator-to-Target transfer and one for Target-to-Initiator transfer.
It is intended that the group will focus on providing the equivalent of
a bi-directional transport.

Should we eliminate the queue (q) bit, and just use the direction (d)
bit only? Is it a reasonable assumption that the direction is equivalent
to the queue id? It was decided that this issue is dependent on error
recovery, and it was deferred. 


Notification

There was a long discussion about the problems that can occur if a
status notification (or its acknowledgment) can be lost. There was also
some doubt expressed about the frequency of this condition ever
happening. If it is an extremely unlikely event, perhaps it is better to
simplify the recovery process as much as possible. 

Should we set the notify bit to one (1) for every ORB? Do we need to
always notify completion of every ORB? Greg Shue points out that we are
using the unordered model of the SBP-2 specification. A direct
implication of this is that every ORB must have completion notification.
A "well-partitioned," layered SBP-2 driver does not have sufficient
knowledge about the ORBs in the queue when using an unordered model. If
the driver did have this knowledge (by examining the q bit, for
example), it would be considered "munging" (combining) the different
layers.

After looking at the latest SBP-2 specification, this issue is not
(apparently) explicitly addressed. There is no clear statement that says
the Initiator must set the notify bit when using the unordered model.
Greg Shue would like to make an explicit statement about this in the PWG
Profile document. He identified three possible alternatives:
  1. Require an Initiator to set the notify bit on every ORB
  2. Require the Target to always give completion notification
  3. Allow for the possibility of "monolithic" (multi-layered)
SBP-drivers to be implemented without saying anything additional beyond
what is already specified in the SBP-2 specification 

After more discussion, the group agreed that the PWG Profile document
would not make any additional, explicit statements on this issue other
than to follow the SBP-2 specification.


Extensibility

To what degree should we provide extensibility? Do we really need to
support a mechanism for vendor-specific transport commands? 

As stated above, the group agreed to limit the number of queues to 2.
The number of queues is not extensible.

Shimura-san suggested that vendor-specific commands could be useful as a
method to fix bugs. Most of the other attendees felt that this was not a
good enough reason to include support for vendor-specific commands. It
was suggested that vendor feature differentiation could (and should?) be
achieved at higher levels. 

The group agreed that a Command OUI is not necessary (at least for this
version of the Profile.) No vendor-specific commands or parameters will
be supported. Any extensions will only be possible through the PWG
standards group by revision of the document. 


Parameters

When can parameters be set and/or changed? 

Because the SBP-2 Login is not extensible, Randy Turner suggests that
the PWG Profile should include a Login Response, followed by an exchange
of additional parameters. He also pointed out that both the Target and
the Initiator should know each other's capabilities -- at least to help
resource allocation efficiency. It was suggested that the commands Get
Param and Set Param List should be executed before data transfer,
similar to a "connect" process. This suggestion was later expanded to an
Open command that could establish other items that would be necessary
for managing a connection. 

ACTION:  Randy volunteered to write up an example that would explain
this concept.


Error Recovery 

Should we include a Sequence Id for the ORBs? What is the scope of the
sequence number?

After a fairly brief discussion, the group agreed to use a Sequence Id
for error recovery purposes.

Brian Batchelder noted that the Target should not process more than 2n
ORBs ahead of the last ORB for which the Target received an
acknowledgment of completion status from the Initiator (where 'n' is the
bit width of the Sequence Id.) Otherwise, it is possible that the Target
could lose track of the error recovery information provided by the
Sequence Id.

A long discussion occurred about pre-fetching ORBs and the reliability
of ORB pointers after a bus reset.

Greg Shue noted that the group needs to define a unit attention status
model. However, he suggested that the topic is probably too large to
adequately address at this meeting. It was suggested that the topic be
discussed via e-mail.

A few individuals discussed the processes involved in error recovery,
based on the assumptions of the proposal given by Isoda-san. After the
discussion, John Fuller proposed that the Sequence Id should be eight
bits wide. Nagasaka-san wanted it to be 16 bits wide. After discussing
the need to have the Sequence Id be sufficiently larger than the Maximum
Task Set, the group agreed to 16 bits for the Sequence Id and 14 bits
for the Maximum Task Set size. 

What should be the initial value for the Sequence Id? Greg Shue
suggested that the initial value could be inferred based on the first
ORB on each queue after a Login or an abort task. Randy preferred that
some "initial process" be defined to ensure a specific value for the
first Sequence Id. The topic was deferred for discussion via e-mail.

John Fuller noted that the ORB Sequence Ids might have "gaps," because
of the use of Abort Task and Abort Task Set commands. This caused people
to wonder if it is necessary to generate a notification for each ORB to
handle error recovery properly. However, it was decided that Greg Shue
(and others) would spend time after the meeting to examine this question
more closely. 

ACTION:  Greg will attempt to write up a statement for discussion via
e-mail.

Randy is concerned that without a timeout value (for an ORB completion
notification), there is no way a host can know the lifetime of an ORB.
How long should an Initiator keep an ORB allocated? The group suggested
that if the Initiator wants to free the resources associated with an ORB
before the completion notification has been received, an abort task
command should be issued.

What should the timeouts be for the following items?
  abort task
  abort task set
  logical unit reset
  Target reset

The discussion of timeout values was deferred.


Open/Close Connection

Several items were put into a category of "connection meta-data" that
should be communicated and established. The items include:
  initial values for Sequence Id numbers 
  connection type
  completion policy
  maximum record size

How can a Target close a connection (i.e. unsolicited status)?

This entire topic was deferred for e-mail discussion.


Other Deferred Topics/Issues/Questions

The following items were raised during the discussions, but not directly
resolved:
  When should a Target complete the Store Data Command Response? 
  Does it make sense to use the names "Store Data" and "Fetch Data" for
commands? 
  Would it be better to just have a single "Transfer" command, with the
direction (d) bit used to indicate which way the data should be
transferred?
  Should the q bit be placed in the status block?
  Should we keep the Max Data Size Per Fetch ORB parameter?
  Should we keep the Max Data Size Per Store ORB parameter?
  What should happen to Fetch Data and Store Data commands that are in
or added to the active task set when a data flow direction is disabled?
  Maybe we could put "last acknowledged Sequence Id" in each status
block? 
  Perhaps we should add some attributes and features to the Unit
Directory? This might be a mechanism (for example) to communicate the
maximum buffer size of the Target.


Summary of Commands Discussions

Greg Shue attempted to summarize the decisions reached:
  2 queues only
  No vendor-unique extensions (for this revision)
    no CMD_OUI 
    no Parameter_OUI
  Provide only equivalent bi-directional transport
    MSG (packet) 
    Stream
  Error recovery
    16 bit increasing Sequence Ids
    14 bit size for Max Task Set
 

Remaining issues and assignments for write-ups:

  sequence # [Greg Shue]
    seeding, abort task, interactions
    notify bits and gaps in sequence
  Open/Close CMDs [Randy Turner and Greg Shue]
    parameters and encodings
    negotiated buffer sizes
    mode and completion policy [Bob Morford]
    management agent CMD support
  How will Target initiate close (unsolicited status)?
  How to communicate/clear UNIT ATTENTION?
  Timeouts [Alan Berkema]
  Is queue implied by direction bit?
  What initiates error recovery on Microsoft stack? What steps are
taken? [John Fuller]


Config ROM Review

Because Greg LeClair could not be present the second day of the meeting,
Alan Berkema attempted to lead a discussion of the CSR and Config ROM
document. (This document is available at
ftp://ftp.pwg.org/pub/pwg/p1394/mtg070698/pwg_cfgrom.pdf.) However, it
did not seem that many people read the document.  There was very little
discussion.


Imaging Device Profile Review

Alan Berkema decided that the Profile document will continue to contain
Issues and their resolutions. (This document is available at
ftp://ftp.pwg.org/pub/pwg/p1394/mtg070698/pwg_cfgrom.pdf.)

Meeting adjourned.

From gleclair at best.com  Mon Sep 28 17:36:18 1998
From: gleclair at best.com (Gregory LeClair)
Date: Wed May  6 14:00:39 2009
Subject: P1394> Meeting Minutes from Toronto - August
Message-ID: <01BDEAED.6C85D1E0@gleclair.vip.best.com>

                                  1394 PWG Minutes
                                 August 17-18, 1998
       1.
             Shigeru Ueda   Canon
             Osamu Hirata   Canon (CBM)
             Jim Schwerin   Canon (CBM)
             Lee Farrell    Canon Information
                            Systems
             Greg LeClair*  Epson
             Kazuo Nomura   Epson
             Brian          Hewlett Packard
             Batchelder
             Alan Berkema   Hewlett Packard
             Scott Bonar    Hewlett Packard
             Greg Shue      Hewlett Packard
             Jerry Thrasher Lexmark
             Don Wright     Lexmark
             Anthony Fung   ST Microelectronics
             Harry Hvostov  ST Microelectronics

       Don Wright provided the details for the next PWG meeting:
            Savannah Marriott Riverfront
            Savannah, GA 31401
            100 General McIntosh Blvd.
            Savannah, GA
            912 233-7722
            September 28-October 2
            $165 room rate

       He announced the draft meeting schedule for 1999, indicating that it
       would be discussed further at the PWG Plenary meeting on Wednesday:
            .  Jan 18-22 Maui (Joint PWG/PWG-C)
               Jan 27-29 1394TA Maui
            .  Mar 1-5   Miami
            .  Apr 12-16 New Orleans
                                              Apr. 4-9  Comdex Tokyo
            .  May 24-28 Philadelphia
                                              May 11-14 WWW8 Toronto
                                              May 10-11 W3C AC Meeting
                                              May 31-Jun 4  N+I Tokyo
                                              Jun 22-24 PC-Expo NYC
            .  Jul 5-9   Copenhagen, Denmark (other European site?)
                                              Jul 12-16 IETF Oslo
                                              Jul 14-16 Comdex Canada
            .  Aug 16-20 Alaska
            .  Sep 27-Oct 1                   Denver
            .  Nov 2-6   San Juan, Puerto Rico
                                              Nov 8-12 IETF Wash DC
                                              Nov 15-19 Comdex
            .  Dec 13-17 Los Angeles
       1394 PWG Meeting, August 17-18, 1998

       Greg LeClair presented the proposed agenda topics:
            .  GAP Control
            .  Recovery
            .  Command Set
            .  Open Profile Issues

       3.
       Ueda-san presented a few slides on the _gap control_ method used to
       maintain coordination and recovery of command processing between the
       Initiator and Target.

       He believes that the _enforced sequential command tag_ approach is
       inefficient for command set recovery, because there can be overhead
       introduced even in normal operation situations. To avoid the
       inefficiency two rules are proposed:
            .  Target determines whether the command is ahead or behind
               current position based on the sign of the distance between
               them.
            .  Initiator is responsible to keep the actual sequence of tasks
               in the task list to be recognized correctly by the target.

       Shimura-san has distributed a description of the proposal via e-mail.

       Ueda provided example cases illustrating different situations that may
       occur in an error recovery situation.

       There was some discussion about the process of aborting a task by using
       a _dummy orb_. Greg Shue explained the Abort Task Set management
       function. He feels that the Abort Task command can possibly cause
       problems. The issue about aborting a task is that there is no guarantee
       that the Initiator will actually respond to the Abort Task request.

       Greg Shue asked Ueda-san what the _normal condition_ would be that
       would cause inefficient operation. Ueda gave the example of a paper-jam
       or out-of-paper condition. After a bit of discussion, there is still
       unresolved disagreement about how frequently this situation will really
       occur_and therefore how much efficiency is really gained by the
       proposal.

       ISSUE: Once a Target's fetch agent has transitioned to a dead state,
       how long will it wait for an Initiator to do error recovery before it
       takes action on its own? How long do we stay in a dead state? This
       issue is currently felt to be beyond the scope of the specification
       because it is application specific. If it needs to be resolved at a
       higher level, we may need to provide a mechanism to achieve it.

       4.
	Recovery

       Ueda-san also gave a presentation on the Error recovery model used in
       Canon's SHPT proposal. A few optimization methods were proposed:
            .  use same physical memory for application buffers and transport
               buffers
            .  use same size buffer as 1394 transaction for error recovery




       1394 PWG Meeting, August 17-18, 1998

            .  sender can directly write data to buffer in receiver specifying
               the 1394 address

       For error recovery, the Initiator must keep the contents of the data
       buffers associated with the ORBs in the linked list, and the Target
       must guarantee not to execute any data and command twice. [The slide in
       Ueda's presentation was missing the word _not_.]

       The Initiator must guarantee that the contents of the data buffer will
       not change over a Bus Reset.

       Ueda proposes that a special value of 0 for Max_T2I_DATA_SIZE should
       indicate that the Target does not need to guarantee to hold and re-send
       data. (The Initiator will guarantee to maintain the contents over a Bus
       Reset.)

       Greg Shue pointed out that the value of zero is already used to
       indicate that no data will be transferred in that direction. He
       suggested that another (new) parameter could be defined to indicate the
       capability proposed by Ueda.

       Greg agreed that the capability to indicate to a Target that the
       Initiator will retain the data contents of a data block and its
       Sequence ID over a Bus Reset was a reasonable feature. However,
       discussion of the method for indicating this feature was deferred until
       the Command Set topic was addressed.

       Much discussion occurred about whether the contents of the page-tables
       for the buffer could be relied upon after a Bus Reset. Generally,
       people feel that the Target should re-read the page table (in case the
       pointers to the data contents have changed.)

       5.Command Set

       Greg Shue has issued revision 0d of the PWG 1394 Transport Command Set
       Proposal. He led the group in a page-by-page review of the latest
       revision, asking for comments.

       Ueda-san commented that the Open and Close Transport commands are not
       symmetrical. The Transport_Open command is issued for both queues, but
       the Transport_Close is issued for only one queue at a time. Greg
       explained that the reason for this was to allow the Initiator to
       indicate that no more writing to the write queue will occur, but
       reading will continue on the read queue.

       The group discussed whether or not Greg's reason was a valid situation.
       After not being able to identify a specific situation to justify the
       capability, the group agreed to change the Transport_Close to apply to
       both queues. However, Greg noted that once a Close is done to both
       queues, there is nothing that can be done next_except a Logout.
       Therefore, he suggests that the Transport_Close command is redundant to
       the Logout command. (Although unsolicited status could be generated
       before a Logout, it was not felt that this was a reasonable event.)
       If Transport_Close is eliminated (because it is redundant to Logout),
       this would also create an asymmetrical situation for Transport_Open.


       The Get_Transport_Capabilities command was discussed. Brian noted that
       when a Target responds with certain transport capabilities, it must
       reserve those capabilities for the duration of that Login.

       Greg LeClair suggested that we should keep the Close command to allow
       some kind of acknowledgment of the Close command. Using Logout does not
       provide any chance for a reply.

       After much discussion about the above issues, no consensus was reached,
       and the topic was deferred.

       ISSUES:
            .  Should we have a Transport_Close command of any type_either
               applicable to a single queue or both queues?
            .  What behavior should occur after a Close and after/during an
               Open?
            .  If we eliminate the Transport Close command, should the Open
               command be renamed?

       ISSUE: What should be done about the following case? An initiator opens
       a connection, carries on a conversation, closes both queues for
       communication, and then does a TARGET RESET? Presumably, this would
       allow another TRANSPORT_OPEN to be issued without having the initiator
       Logout, though it would affect all other initiators logged in to that
       target by generating a UNIT ATTENTION condition. Because we must
       support TARGET RESET to be SBP-2 compliant, this situation must be
       supported as well.

       ISSUE: Should we support ABORT TASK?

       Greg Shue points out that the Target has the option to ignore the ABORT
       TASK command_once it has fetched the ORB.

       Greg LeClair claims that if an Initiator Aborts a task, it must Abort
       all the remaining ORBs in that queue, and must resubmit them with the
       same sequence IDs.

       ISSUE: What do we do if the Target responds to an Abort Task with _I
       completed the ORB_ (instead of acknowledging it as a Dummy ORB?) This
       condition might cause the Target to process data that shouldn't have
       been. This can cause problems for a printer data stream.

       CONCLUSION: The PWG Profile will state that the client SHALL NOT issue
       an Abort Task (because we cannot guarantee the execution of an Abort
       Task request, and this might cause unpredictable behavior.) [It was
       also noted that Microsoft does not support the Abort Task capability.]
       Greg LeClair suggests that any desire to abort a large print job should
       be handled at a higher level_perhaps on a job cancel basis.

       ISSUE: Abort Task Set is used by a _soon-to-be_ commercially available
       O/S in response to a timeout condition. The group needs to examine and
       understand what the condition details are.

       The group agreed to add a new parameter to indicate that the Initiator
       will maintain data buffer content integrity across Bus Resets (to
       address the proposal made by Ueda-san earlier.)

       1394 PWG Meeting, August 17-18, 1998
       ISSUE: The Profile document should include an explicit statement on the
       padding order and the placement of data bytes less than a full quadlet
       (e.g. a diagram showing a five-byte data value.)
       MOTION: At the end of the page-by-page review, Alan Berkema made a
       motion to include the latest revision of the Command Set document into
       the Profile document. Greg Shue seconded the motion.
       Ueda-san requested that additional evaluation and changes to the
       Command Set information should still be possible. Greg LeClair (and
       others) agreed that comments and changes are still possible, but that
       the motion is primarily a convenience to the Profile editor_and an
       acknowledgment that the Command Set information is _relatively stable_.

       VOTE: The motion passed unanimously. Alan Berkema will incorporate the
       material into the next revision of the Profile document.

       ISSUE: How do we pass down Sockets implementation information into the
       Command Set? No resolution was reached on this issue.

       6. Config ROM Review and IEEE 1212r
       Greg LeClair briefly reviewed the latest activity in 1212r and
       referenced his CSR and Config ROM proposal that is posted.

       According to Greg, the FDS proposal and other discovery concepts have
       been _stabilized_ at the Bath meeting last month. (Greg noted that this
       doesn't necessarily mean that it can't become unstable in the future.)
       The group believes that there should be a class registry monitored and
       maintained by the 1212r group.

       Next meetings for 1212r are planned for September 9-10 in Chicago and
       October 15-16 in Maui.

       Alan Berkema asked if the Config ROM document is ready to be included
       into the Profile document. The group decided that we should wait until
       the document is updated to reflect the most recent 1212r activity and
       reviewed by the group.

       7. PWG Profile Document

       Alan Berkema led the group in a _page-by-page_ review of the latest
       Profile document.

       It was suggested that a re-write of the Purpose section be considered
       and proposed on the e-mail reflector for review. A few individuals felt
       that the current description is not as accurate as it could be. There
       was a question on how specific we should be in terms of addressing
       specific device classes. Should we really attempt to address all
       imaging devices_or consider separate documents for each device class?
       It was suggested that the current document be considered as a sample
       _template_ for other imaging devices_but that it focus only on the
       printer class.


       1394 PWG Meeting, August 17-18, 1998

       The definition of Queue should be changed to reflect a sequence of
       ORBs_not just a collection.

       The Config ROM block diagram (Figure 2) should be updated for accuracy.
       It was noted that Section 7 will eventually be replaced by Greg
       LeClair's document on Config ROM. The group then reviewed the Config
       ROM document contents, identifying several edits that Greg will include
       in the next revision.

       There was a long discussion about the section on Device Discovery (in
       the Config ROM document.) A concern was raised about whether a Bus
       Reset should be generated every time the device configuration changes_
       and a corresponding change to the values of the Config ROM is possible.
       (This could certainly lead to excessive bandwidth problems.) It was
       suggested that the Profile document should inform an implementor that
       any change in the Config ROM values shall not be made until the next
       Bus Reset. However, it should be worded in such a manner that does not
       encourage Bus Resets unnecessarily.

       Section 9 of the Profile document will be re-worded so that it does not
       say every command will have the ORB notify bit set to zero. Not every
       ORB needs to have its notify bit set.

       Sections 10 and 11 will get replaced by the Command Set description
       content.

       Figure 4 in Section 11.2 _ There was some concern that the diagram
       might be confusing because it has too much detail. Isoda-san was
       volunteered to change his _Whole Model_ diagram into an editable Word
       format or PowerPoint format. The group would like the diagram replaced
       by a sequence of (four?) drawings_each one showing a progression of
       detail in the communication flow between the client and server:
       client/server, 1394 PWG, _SBP-2 cloud_, and _SBP-2 details.

       Section 11.3 will be removed.

       It was suggested that Section 12 should include a reference to
       maintaining _fairness_ of access when supporting multiple Logins.

       Sections 13, 15, 18, 19, 20, and 21 will be replaced/superseded by the
       Command Set description content.

       The list of Issues contained in the Profile document (Sections 23-27)
       were very briefly reviewed and evaluated.

       The group decided that Unsolicited Status Register service will not be
       provided to a higher layer. Therefore no policy is needed.

       The Profile document will include a list of timers that should be
       defined. The discussions identified three timers:  Reconnect timer,
       Management Command response timer, and the timer used by the Initiator
       to issue an Abort Task Set due to Target inactivity. Alan will start a
       discussion via e-mail to identify any other timers that might be
       necessary.

       ACTION: Brian volunteered to write up a description clarifying the
       differences between datagram- and datastream-based services.

       1394 PWG Meeting, August 17-18, 1998

       ACTION: Alan said that he will update and issue a new version of the
       Profile by September 10.

       ACTION: Greg LeClair will maintain a prioritized _List of Active
       Issues_ for tracking and reference within the group.

       ISSUE: The Profile document should include an explicit statement on the
       padding order and the placement of data bytes less than a full quadlet
       (e.g. a diagram showing a five-byte data value.)

       8. Greg Shue believes that we are ready to (begin to) create a set of
       scenarios for testing interoperability. It was suggested that we should
       plan to discuss possible scenarios at the next meeting.

       Greg LeClair asked if any companies might be ready with a prototype for
       interoperability testing before December. Epson, HP, and Canon all
       indicated that they might have something.

	9. OUI Issues

       Greg LeClair discussed the issue of Organizationally Unique Identifiers
       (OUI):
            .  Do we need to have an OUI for the 1394 PWG Profile?
               . Cmd_Set_Spec_ID in the Unit Directory
               . possibly needed for `Printer' value of the Function_Class
                 entry in Instance Directory (formerly FDS)
               . useful as a Spec_ID for other locations
            .  Options:
               . select a standards body and get a RAC assigned OUI
               . buy OUI as 1394 PWG
                 _  maintenance and administration problems?

       Greg asked: _Would the individual companies represented at the 1394 PWG
       group be willing to contribute $$$ to pay for an OUI?_ If the group
       does buy one, how will it (and sub-identifiers) be administered,
       maintained, and managed?

       It was suggested that we obtain an OUI from the 1394 TA. However, they
       will not give one out until we have a completed document_and we agree
       to abide by their by-laws.

       MOTION: Brian Batchelder made a motion that the 1394 PWG members
       request that the PWG organization purchase an Organizationally Unique
       Identifier (OUI) from the IEEE RAC. This OUI will be maintained and
       administered by that organization.

      VOTE: The motion passed unanimously.

       Meeting adjourned.

From brianb at vcd.hp.com  Wed Oct 14 10:35:39 1998
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:39 2009
Subject: P1394> Length of Meetings
Message-ID: <4.0.1.19981013113416.00e1df10@popmail1.vcd.hp.com>

I am concerned with the shift to one day meetings for the 1394 PWG effort.  We used up all of two days at the last meeting with what I thought were mostly important presentations and discussions.  Those discussions caused an evolution in my understanding of our challenges and solutions.  We still have open issues.  Further work is required.  Due to the nature of our "real" jobs, most work seems to occur during the meetings.  I don't see that we can move to 1 day at this time, and still be able to quickly reach a viable standard.  I propose that we return to 2 day meetings and keep them focused on the remaining issues so that we can finish as soon as possible.  Besides, I JUST LOVE the Marriott...

Brian

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227


From harryl at us.ibm.com  Wed Oct 14 12:33:11 1998
From: harryl at us.ibm.com (Harry Lewis)
Date: Wed May  6 14:00:39 2009
Subject: P1394> 2-Days
Message-ID: <5030100027145711000002L012*@MHS>

oops...

I don't mind future adjustments (proposed by Brian) but have already
arranged for Novenber meeting with MIBs and IPP starting Tuesday.
I prefer sticking with the currently posted agenda for Tucson.

Harry Lewis - IBM Printing Systems

From gleclair at agentz.com  Wed Oct 14 17:18:13 1998
From: gleclair at agentz.com (Greg LeClair)
Date: Wed May  6 14:00:39 2009
Subject: P1394> Length of Meetings
Message-ID: <01BDF77F.410CB120.gleclair@agentz.com>

We can take a vote in Tucson to see if we think we'll need two days in the 
future.
My feeling is that 1 day is adequate for tasks of the working group at this 
time.

Detail level work can occur offline from the main working group meeting and 
be brought
back to the main group.

My .02 worth.

If you have a strong opinion one way or another, please let me know before 
the Tucson meeting.

NOTE: No change is planned to the date or duration of the Tucson meeting 
posted by the PWG Chair.

Regards,
Greg



-----Original Message-----
From:	Brian Batchelder [SMTP:brianb@vcd.hp.com]
Sent:	Wednesday, October 14, 1998 7:36 AM
To:	1394 PWG
Subject:	P1394> Length of Meetings

I am concerned with the shift to one day meetings for the 1394 PWG effort. 
 We used up all of two days at the last meeting with what I thought were 
mostly important presentations and discussions.  Those discussions caused 
an evolution in my understanding of our challenges and solutions.  We still 
have open issues.  Further work is required.  Due to the nature of our 
"real" jobs, most work seems to occur during the meetings.  I don't see 
that we can move to 1 day at this time, and still be able to quickly reach 
a viable standard.  I propose that we return to 2 day meetings and keep 
them focused on the remaining issues so that we can finish as soon as 
possible.  Besides, I JUST LOVE the Marriott...

Brian

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227


From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Wed Oct 14 17:36:17 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:39 2009
Subject: P1394> 2-Days
In-Reply-To: <5030100027145711000002L012@MHS>
Message-ID: <H0000d931023d0b9@MHS>

A non-text attachment was scrubbed...
Name: 1.txt
Type: application/octet-stream
Size: 938 bytes
Desc: not available
Url : http://www.pwg.org/archives/p1394/attachments/19981014/e6f39ee5/1.obj
-------------- next part --------------
     I think Tuscon is a done deal. 
     San Diego should be open to discussion.
     
     I finally have a critical mass of pings, I would hate to ask folks to 
     ping again :)
     
     regards,
     Alan


______________________________ Reply Separator _________________________________
Subject: P1394> 2-Days
Author:  Non-HP-harryl (harryl@us.ibm.com) at HP-Roseville,mimegw3
Date:    10/14/98 9:33 AM


oops...
     
I don't mind future adjustments (proposed by Brian) but have already 
arranged for Novenber meeting with MIBs and IPP starting Tuesday.
I prefer sticking with the currently posted agenda for Tucson.
     
Harry Lewis - IBM Printing Systems
From Nagasaka.Fumio at exc.epson.co.jp  Fri Oct 16 07:57:16 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:39 2009
Subject: P1394> connection for Function or Service
Message-ID: <01376112D7AFD011911E0020AF70BEC51C0FB9@cpuex1.ued.epson.co.jp>

In Savannah meeting, Brain opened SPI discussion, and it was really
productive. I would like to confirm some open issue. Actually I
would like to start e-mail discussion thread. Because as Brian 
pointed in this reflector, meeting schedule is too short (only one day),
thus I felt e-mail discussion would be helpful to clear what is
required for current profile Rev.0.52.

An UnitDir is assumed as the entity of a function, a function (ex.
a printer, or a scanner, ) may have several services, for example
job control, printing, status monitoring and finisher control.
A "Function" is an abstracted software entity of a real device.
A "Service" is an abstracted software model of an executable
instance.

                                        [Services]
UnitDir == Function (printer) -----|
                                   |-----Job Control
                                   |-----Status Monitoring
                                   |-----Printing
                                   |-----Finisher
                                   |
                                   
We've discussed three ideas listed below;
(1) an initiator logins to the function.
(2) an initiator logins to each service.
(3) hybrid solution of (1) and (2).

If we choose (2), naturally each service shall be associated
with a LUN and the initiator shall specify the selected LUN in
parameter of "login".

If we choose (1), a function shall be assumed as one LUN.
The initiator shall specify this LUN at login, and this LUN
shall provide multiplexing to support several services.

I have no urge to describe (3). This idea seems to be too
complicated for me.

Second idea is neat. And current profile (0.52) is applicable
for this model. However I am not sure whether existing PC OS
is supporting PnP of this architecture.

UnitDir ---|-- LUN
           |-- LUN
           |-- LUN
           |-- ...

Also I don't think current PC OS is supporting dynamic adding
of LUNs. Thus it is difficult to add service entity on demand.

The first idea is not neat, but may be supported even under
existing PC OS.

UnitDir ----- LUN
UnitDir ----- LUN
...

However, each service requires a multiplexed connection and
each connection requires flow control and send/receive queues.

My proposal suggested in the last meeting was describing
multiplexing, but it does not have description for flow control
of each logical channels. So my question is, shall we choose
second idea? or does anyone have better idea for (3) option?
Or is there new idea??
Thank you,
---
--------------------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to  <mailto:nagasaka.fumio@exc.epson.co.jp> nagasaka.fumio@exc.epson.
co.jp

From gregs at sdd.hp.com  Fri Oct 16 11:39:43 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:39 2009
Subject: P1394> connection for Function or Service
In-Reply-To: <01376112D7AFD011911E0020AF70BEC51C0FB9@cpuex1.ued.epson.co.jp> from "Nagasaka Fumio" at Oct 16, 98 08:57:16 pm
Message-ID: <199810161539.IAA08801@hpsdlgj1.sdd.hp.com>

> However, each service requires a multiplexed connection and
> each connection requires flow control and send/receive queues.

Whether we multiplex connections over a login or have separate
logins, each service is accessed over a connection, and each
connection requires flow control and send/receive queues.
This is a non-issue in the decision.

A larger issue with "current PC OS" implementation may be how
many outstanding requests can be supported at once by the SBP-2
driver.

-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From hitoshis at MICROSOFT.com  Fri Oct 16 14:55:37 1998
From: hitoshis at MICROSOFT.com (Hitoshi Sekine)
Date: Wed May  6 14:00:39 2009
Subject: P1394> connection for Function or Service
Message-ID: <FD8F41F04D35D111899600805F19A16C0642FEB7@RED-MSG-48>

> A larger issue with "current PC OS" implementation may be how
> many outstanding requests can be supported at once by the SBP-2
> driver.

I agree that it is a large issue with the implementation.  But, it is not
clear to me that the SBP-2 is required to handle multiple logins or
connections.  Who cases multiple connections per a single login?  I think we
should be able to handle multiple connection on a single login or multiple
logins.  These implementations are very different.

Thanks,
Hitoshi

-----Original Message-----
From: Greg Shue [mailto:gregs@sdd.hp.com]
Sent: Friday, October 16, 1998 8:40 AM
To: Nagasaka.Fumio@exc.epson.co.jp
Cc: p1394@pwg.org
Subject: Re: P1394> connection for Function or Service


> However, each service requires a multiplexed connection and
> each connection requires flow control and send/receive queues.

Whether we multiplex connections over a login or have separate
logins, each service is accessed over a connection, and each
connection requires flow control and send/receive queues.
This is a non-issue in the decision.

A larger issue with "current PC OS" implementation may be how
many outstanding requests can be supported at once by the SBP-2
driver.

-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From Nagasaka.Fumio at exc.epson.co.jp  Fri Oct 16 21:38:52 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:39 2009
Subject: P1394> connection for Function or Service
Message-ID: <01376112D7AFD011911E0020AF70BEC51C0FBA@cpuex1.ued.epson.co.jp>

	Greg Shue wrote:
	>Whether we multiplex connections over a login or have separate
	>logins, each service is accessed over a connection, and each
	>connection requires flow control and send/receive queues.
	>This is a non-issue in the decision.

	Agreed. The profile 0.52 is describing TRANSPORT_CAPABILITIES
	command to ease to support flow control. Right? However when
	we choose ?multiplex connections over a login?, then can we use
	same method? If not, do you prefer connections over multiple LUNs?

	Greg Shue wrote:
	>A larger issue with "current PC OS" implementation may be how
	>many outstanding requests can be supported at once by the SBP-2
	>driver.

	Please write some more,,, as I could not figure out what are
	?outstanding requests? on PC OS platform. Are you saying how many
	outstanding ORBs can be supported at once over multiple LUUs?

Thank you,
Fumio Nagasaka

> -----Original Message-----
> From:	Greg Shue [SMTP:gregs@sdd.hp.com]
> Sent:	Saturday, October 17, 1998 12:40 AM
> To:	Nagasaka Fumio
> Cc:	p1394@pwg.org
> Subject:	Re: P1394> connection for Function or Service
> 
> > However, each service requires a multiplexed connection and
> > each connection requires flow control and send/receive queues.
> 
> Whether we multiplex connections over a login or have separate
> logins, each service is accessed over a connection, and each
> connection requires flow control and send/receive queues.
> This is a non-issue in the decision.
> 
> A larger issue with "current PC OS" implementation may be how
> many outstanding requests can be supported at once by the SBP-2
> driver.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------

From Nagasaka.Fumio at exc.epson.co.jp  Fri Oct 16 21:39:39 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:39 2009
Subject: FW: P1394> connection for Function or Service
Message-ID: <01376112D7AFD011911E0020AF70BEC51C0FBB@cpuex1.ued.epson.co.jp>

> Hi Hitoshi,
> 
> My question is;
> If 1394 PWG chooses ?connections over multiple LUNs?, does new PC OS
> support device-enumeration which has a configuration ROM shown below?
> 
> UnitDir --->[ LUN0, LUN1, LUN2, ?]
> 
> And may our driver invoke ?Login(s)? to each LUN separately?
> 
> Thank you,
> --------------------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
> 
> -----Original Message-----
> From:	Hitoshi Sekine [SMTP:hitoshis@MICROSOFT.com]
> Sent:	Saturday, October 17, 1998 3:56 AM
> To:	'Greg Shue'; Nagasaka Fumio
> Cc:	p1394@pwg.org
> Subject:	RE: P1394> connection for Function or Service
> 
> > A larger issue with "current PC OS" implementation may be how
> > many outstanding requests can be supported at once by the SBP-2
> > driver.
> 
> I agree that it is a large issue with the implementation.  But, it is not
> clear to me that the SBP-2 is required to handle multiple logins or
> connections.  Who cases multiple connections per a single login?  I think
> we
> should be able to handle multiple connection on a single login or multiple
> logins.  These implementations are very different.
> 
> Thanks,
> Hitoshi
> 
> -----Original Message-----
> From: Greg Shue [mailto:gregs@sdd.hp.com]
> Sent: Friday, October 16, 1998 8:40 AM
> To: Nagasaka.Fumio@exc.epson.co.jp
> Cc: p1394@pwg.org
> Subject: Re: P1394> connection for Function or Service
> 
> 
> > However, each service requires a multiplexed connection and
> > each connection requires flow control and send/receive queues.
> 
> Whether we multiplex connections over a login or have separate
> logins, each service is accessed over a connection, and each
> connection requires flow control and send/receive queues.
> This is a non-issue in the decision.
> 
> A larger issue with "current PC OS" implementation may be how
> many outstanding requests can be supported at once by the SBP-2
> driver.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------

From Nagasaka.Fumio at exc.epson.co.jp  Fri Oct 16 21:40:19 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:39 2009
Subject: FW: P1394> connection for Function or Service
Message-ID: <01376112D7AFD011911E0020AF70BEC51C0FBC@cpuex1.ued.epson.co.jp>

> Hi Eric,
> 
> If 1394 PWG chooses ?connections over multiple LUNs?, does new Mac OS
> support device discovery which has a configuration ROM shown below?
> 
> UnitDir --->[ LUN0, LUN1, LUN2, ?]
> 
> And may our driver invoke ?Login(s)? to each LUN separately?
> Does Mac OS register each LUN as a separated entity in the name registry?
> Thank you,
> --------------------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
> 
> -----Original Message-----
> From:	Hitoshi Sekine [SMTP:hitoshis@MICROSOFT.com]
> Sent:	Saturday, October 17, 1998 3:56 AM
> To:	'Greg Shue'; Nagasaka Fumio
> Cc:	p1394@pwg.org
> Subject:	RE: P1394> connection for Function or Service
> 
> > A larger issue with "current PC OS" implementation may be how
> > many outstanding requests can be supported at once by the SBP-2
> > driver.
> 
> I agree that it is a large issue with the implementation.  But, it is not
> clear to me that the SBP-2 is required to handle multiple logins or
> connections.  Who cases multiple connections per a single login?  I think
> we
> should be able to handle multiple connection on a single login or multiple
> logins.  These implementations are very different.
> 
> Thanks,
> Hitoshi
> 
> -----Original Message-----
> From: Greg Shue [mailto:gregs@sdd.hp.com]
> Sent: Friday, October 16, 1998 8:40 AM
> To: Nagasaka.Fumio@exc.epson.co.jp
> Cc: p1394@pwg.org
> Subject: Re: P1394> connection for Function or Service
> 
> 
> > However, each service requires a multiplexed connection and
> > each connection requires flow control and send/receive queues.
> 
> Whether we multiplex connections over a login or have separate
> logins, each service is accessed over a connection, and each
> connection requires flow control and send/receive queues.
> This is a non-issue in the decision.
> 
> A larger issue with "current PC OS" implementation may be how
> many outstanding requests can be supported at once by the SBP-2
> driver.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------

From Nagasaka.Fumio at exc.epson.co.jp  Fri Oct 16 22:19:03 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:39 2009
Subject: P1394> connection for Function or Service
Message-ID: <01376112D7AFD011911E0020AF70BEC51C0FBD@cpuex1.ued.epson.co.jp>

Hi Eric,

If 1394 PWG chooses ?connections over multiple LUNs?, does new Mac OS
support device discovery which has a configuration ROM shown below?

UnitDir --->[ LUN0, LUN1, LUN2, ?]

And may our driver invoke ?Login(s)? to each LUN separately?
Does Mac OS register each LUN as a separated entity in the name registry?
Thank you,
--------------------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp

> -----Original Message-----
> From:	Hitoshi Sekine [SMTP:hitoshis@MICROSOFT.com]
> Sent:	Saturday, October 17, 1998 3:56 AM
> To:	'Greg Shue'; Nagasaka Fumio
> Cc:	p1394@pwg.org
> Subject:	RE: P1394> connection for Function or Service
> 
> > A larger issue with "current PC OS" implementation may be how
> > many outstanding requests can be supported at once by the SBP-2
> > driver.
> 
> I agree that it is a large issue with the implementation.  But, it is not
> clear to me that the SBP-2 is required to handle multiple logins or
> connections.  Who cases multiple connections per a single login?  I think
> we
> should be able to handle multiple connection on a single login or multiple
> logins.  These implementations are very different.
> 
> Thanks,
> Hitoshi
> 
> -----Original Message-----
> From: Greg Shue [mailto:gregs@sdd.hp.com]
> Sent: Friday, October 16, 1998 8:40 AM
> To: Nagasaka.Fumio@exc.epson.co.jp
> Cc: p1394@pwg.org
> Subject: Re: P1394> connection for Function or Service
> 
> 
> > However, each service requires a multiplexed connection and
> > each connection requires flow control and send/receive queues.
> 
> Whether we multiplex connections over a login or have separate
> logins, each service is accessed over a connection, and each
> connection requires flow control and send/receive queues.
> This is a non-issue in the decision.
> 
> A larger issue with "current PC OS" implementation may be how
> many outstanding requests can be supported at once by the SBP-2
> driver.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------

From Nagasaka.Fumio at exc.epson.co.jp  Fri Oct 16 22:19:41 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:39 2009
Subject: P1394> connection for Function or Service
Message-ID: <01376112D7AFD011911E0020AF70BEC51C0FBE@cpuex1.ued.epson.co.jp>

Hi Hitoshi,

My question is;
If 1394 PWG chooses ?connections over multiple LUNs?, does new PC OS
support device-enumeration which has a configuration ROM shown below?

UnitDir --->[ LUN0, LUN1, LUN2, ?]

And may our driver invoke ?Login(s)? to each LUN separately?

Thank you,
--------------------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp

> -----Original Message-----
> From:	Hitoshi Sekine [SMTP:hitoshis@MICROSOFT.com]
> Sent:	Saturday, October 17, 1998 3:56 AM
> To:	'Greg Shue'; Nagasaka Fumio
> Cc:	p1394@pwg.org
> Subject:	RE: P1394> connection for Function or Service
> 
> > A larger issue with "current PC OS" implementation may be how
> > many outstanding requests can be supported at once by the SBP-2
> > driver.
> 
> I agree that it is a large issue with the implementation.  But, it is not
> clear to me that the SBP-2 is required to handle multiple logins or
> connections.  Who cases multiple connections per a single login?  I think
> we
> should be able to handle multiple connection on a single login or multiple
> logins.  These implementations are very different.
> 
> Thanks,
> Hitoshi
> 
> -----Original Message-----
> From: Greg Shue [mailto:gregs@sdd.hp.com]
> Sent: Friday, October 16, 1998 8:40 AM
> To: Nagasaka.Fumio@exc.epson.co.jp
> Cc: p1394@pwg.org
> Subject: Re: P1394> connection for Function or Service
> 
> 
> > However, each service requires a multiplexed connection and
> > each connection requires flow control and send/receive queues.
> 
> Whether we multiplex connections over a login or have separate
> logins, each service is accessed over a connection, and each
> connection requires flow control and send/receive queues.
> This is a non-issue in the decision.
> 
> A larger issue with "current PC OS" implementation may be how
> many outstanding requests can be supported at once by the SBP-2
> driver.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------

From hitoshis at MICROSOFT.com  Fri Oct 16 22:37:41 1998
From: hitoshis at MICROSOFT.com (Hitoshi Sekine)
Date: Wed May  6 14:00:39 2009
Subject: P1394> connection for Function or Service
Message-ID: <FD8F41F04D35D111899600805F19A16C0642FEC6@RED-MSG-48>

Fumio,

I think it should work on any OS so.  Please send the kind of printer to me.

Thanks,
Hitoshi

-----Original Message-----
From: Nagasaka Fumio [mailto:Nagasaka.Fumio@exc.epson.co.jp]
Sent: Friday, October 16, 1998 7:20 PM
To: Hitoshi Sekine
Cc: p1394@pwg.org; 'Greg Shue'
Subject: RE: P1394> connection for Function or Service


Hi Hitoshi,

My question is;
If 1394 PWG chooses $B!H(Jconnections over multiple LUNs$B!I(J, does new PC OS
support device-enumeration which has a configuration ROM shown below?

UnitDir --->[ LUN0, LUN1, LUN2, $B!D(J]

And may our driver invoke $B!H(JLogin(s)$B!I(J to each LUN separately?

Thank you,
--------------------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp

> -----Original Message-----
> From:	Hitoshi Sekine [SMTP:hitoshis@MICROSOFT.com]
> Sent:	Saturday, October 17, 1998 3:56 AM
> To:	'Greg Shue'; Nagasaka Fumio
> Cc:	p1394@pwg.org
> Subject:	RE: P1394> connection for Function or Service
> 
> > A larger issue with "current PC OS" implementation may be how
> > many outstanding requests can be supported at once by the SBP-2
> > driver.
> 
> I agree that it is a large issue with the implementation.  But, it is not
> clear to me that the SBP-2 is required to handle multiple logins or
> connections.  Who cases multiple connections per a single login?  I think
> we
> should be able to handle multiple connection on a single login or multiple
> logins.  These implementations are very different.
> 
> Thanks,
> Hitoshi
> 
> -----Original Message-----
> From: Greg Shue [mailto:gregs@sdd.hp.com]
> Sent: Friday, October 16, 1998 8:40 AM
> To: Nagasaka.Fumio@exc.epson.co.jp
> Cc: p1394@pwg.org
> Subject: Re: P1394> connection for Function or Service
> 
> 
> > However, each service requires a multiplexed connection and
> > each connection requires flow control and send/receive queues.
> 
> Whether we multiplex connections over a login or have separate
> logins, each service is accessed over a connection, and each
> connection requires flow control and send/receive queues.
> This is a non-issue in the decision.
> 
> A larger issue with "current PC OS" implementation may be how
> many outstanding requests can be supported at once by the SBP-2
> driver.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------

From ewa at apple.com  Sat Oct 17 18:25:53 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:39 2009
Subject: FW: P1394> connection for Function or Service
Message-ID: <B24E699D-33640@17.216.20.64>

Hi everyone,

Mac OS allows any number of LUNs per device.  We will create an
entry in the "Name Registry" for each LUN and we will try to load
a driver for each LUN.

But, it is not required to use one driver per LUN.  If you like, a
single driver can control multiple LUNs.

There is no limit to the number of LUNs, number of Logins, or the
number of active ORBs that one driver can use (other than system
memory size limits, and SBP-2 rules such as one Login per LUN per
node).

I would like to suggest that multi-LUN devices in which the LUNs have
different tasks (such as status, control, data, etc.) related to the
same common goal (such as printing) should make the LUN's somehow
different.  This will help us to load the right driver for the right
LUN.  For example, each LUN could have a different device_type in
the Logical_Unit_Number entry (7.4.11 or 7.5.4).  Or you could even
use different Command Set Revisions or Spec IDs for each LUN,
depending
on what you think the best way to distinguish the functions is.  Mac
OS is very flexible - it can match drivers based on any of these LUN
criteria.  Even if you only want to use one driver for all the LUNs in
your device, it will be easier for us to find them for you if you make
them look different in one of these ways.

--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.      408-974-8187
--------------------------------------

>> Hi Eric,
>> 
>> If 1394 PWG chooses ?gconnections over multiple LUNs?h, does
new Mac OS
>> support device discovery which has a configuration ROM shown below?
>> 
>> UnitDir --->[ LUN0, LUN1, LUN2, ?c]
>> 
>> And may our driver invoke ?gLogin(s)?h to each LUN separately?
>> Does Mac OS register each LUN as a separated entity in the name
registry?
>> Thank you,
>> --------------------------------------------
>> Fumio Nagasaka
>> Epson Software Development Laboratory Inc.
>> Tel +81 268 25 4111,  Fax +81 268 25 4627
>> E-mail to nagasaka.fumio@exc.epson.co.jp
>> 
>> -----Original Message-----
>> From:	Hitoshi Sekine [SMTP:hitoshis@MICROSOFT.com]
>> Sent:	Saturday, October 17, 1998 3:56 AM
>> To:	'Greg Shue'; Nagasaka Fumio
>> Cc:	p1394@pwg.org
>> Subject:	RE: P1394> connection for Function or Service
>> 
>> > A larger issue with "current PC OS" implementation may be how
>> > many outstanding requests can be supported at once by the SBP-2
>> > driver.
>> 
>> I agree that it is a large issue with the implementation.  But, it
is not
>> clear to me that the SBP-2 is required to handle multiple logins or
>> connections.  Who cases multiple connections per a single login?  I
think
>> we
>> should be able to handle multiple connection on a single login or
multiple
>> logins.  These implementations are very different.
>> 
>> Thanks,
>> Hitoshi
>> 
>> -----Original Message-----
>> From: Greg Shue [mailto:gregs@sdd.hp.com]
>> Sent: Friday, October 16, 1998 8:40 AM
>> To: Nagasaka.Fumio@exc.epson.co.jp
>> Cc: p1394@pwg.org
>> Subject: Re: P1394> connection for Function or Service
>> 
>> 
>> > However, each service requires a multiplexed connection and
>> > each connection requires flow control and send/receive queues.
>> 
>> Whether we multiplex connections over a login or have separate
>> logins, each service is accessed over a connection, and each
>> connection requires flow control and send/receive queues.
>> This is a non-issue in the decision.
>> 
>> A larger issue with "current PC OS" implementation may be how
>> many outstanding requests can be supported at once by the SBP-2
>> driver.
>> 
>> -- 
>> Greg Shue
>> Hewlett-Packard Company
>> All-in-One Division			        gregs@sdd.hp.com
>> ----------------------------------------------------------------






From gleclair at agentz.com  Thu Oct 29 18:14:24 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:39 2009
Subject: P1394> Agenda for Tucson
Message-ID: <01BE034E.D0DE13E0.gleclair@agentz.com>

I currently have two presentations scheduled for the 1394 PWG meeting 
in Tucson.

1. 1394 Node Model - Alan Berkema
2. 1394 PWG Service Discovery - Greg LeClair
3. Profile / ConfigROM issue discussion. - Berkema / LeClair

If you have materials you would like to present, please let me know the following
ASAP:
- Subject
- Speaker
- Date to expect presentation to be posted.

NOTE: We will be meeting on Monday ONLY in Tucson.

Regards,

Greg LeClair
1394 PWG Chair
greg@erc.epson.com



From gleclair at agentz.com  Thu Oct 29 18:18:08 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:39 2009
Subject: P1394> Web Site Updated: 10/29/98
Message-ID: <01BE034F.563583C0.gleclair@agentz.com>

I just updated the web site for the first time since it was transferred.

Updates were for information from Monterey, Toronto, and Savannah
- Minutes posted
- Presentations posted

Two new presentations posted for Tucson meeting. See the proposals page:
http://www.pwg.org/p1394/proposal.htm

Regards,
Greg



From lstein at fapo.com  Fri Oct 30 12:41:19 1998
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:39 2009
Subject: P1394> December PWG  Meeting Notice
Message-ID: <4.1.19981030093305.00ab6340@pop3.fapo.com>

Hello,

This is the advance meeting notice for the December 14-18 meetings of the PWG
in San Diego, CA. 

Where:  Downtown Marriott Suites
                701 A Street
                SD, CA 92101

Reservations:   1-800-962-1367

Cutoff Date:    Monday, November 30th

Rate:           $175.00 plus tax        

Group Name:     PWG or Warp Nine Engineering

The expected meeting charge will be $30-$40 per meeting day.

Please make your reservations as soon as possible.

Don Wright will be posting, on the PWG web site, the information for the
January meeting in Maui, and the April meeting in New Orleans.

Thanks,
Larry


***************************************************************
Larry A. Stein                  Phone: (619)292-2742
President                               Fax:    (619)292-8020
Warp Nine Engineering           Web:    http://www.fapo.com
*************************************************************** 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/p1394/attachments/19981030/43a4ec17/attachment.html
From gleclair at agentz.com  Fri Oct 30 13:10:50 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:39 2009
Subject: P1394> Correction - PWG Site Update
Message-ID: <01BE0565.23188D80.gleclair@agentz.com>

Sorry, 

I didn't transfer the mtg110998 directory.

It's now in place.

Regards,
Greg


From brianb at vcd.hp.com  Wed Nov 11 13:34:39 1998
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:39 2009
Subject: P1394> 1212r Meeting with Joint PWG/PWG-C Meeting
Message-ID: <4.1.19981111102356.00a42340@popmail1.vcd.hp.com>

1394PWG & PWG-C Members,

The IEEE 1212r working group is considering holding a working meeting in between the January joint PWG/PWG-C meeting and the January 1394TA meeting.  The intent of the meeting is to review 1212r progress with the PWG, PWG-C and 1394TA, and to advance the work in progress.  We are looking for interest in such a meeting.

The joint PWG/PWG-C meeting is January 18-22.  The 1394PWG meeting is January 21-22.  The 1394TA meeting is the following week, January 27-29.  Both meetings are being held on Maui.  The 1212r meeting would be a 1 to 1-1/2 day meeting on January 25 and/or 26.  This would allow PWG/PWG-C attendees to stay the weekend and meet with 1212r.  It would also allow 1394TA attendees to come a couple of days early and meet with 1212r.

How many 1394PWG & PWG-C members would be interested in attending this meeting?

Brian Batchelder
Chair, IEEE 1212r
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From shimura at pure.cpdc.canon.co.jp  Tue Dec  8 08:11:14 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:39 2009
Subject: P1394> New command proposal for variable MAX_TASK_SET_SIZE
Message-ID: <199812081311.WAA08871@eva-00.pure.cpdc.canon.co.jp>

Hello, all,

At the last meeting, there was a discussion on the definitions of
"queue" and "connection", but I suppose there was little discussion
on "MAX_TASK_SET_SIZE" parameter along with these new definitions.

From shimura at pure.cpdc.canon.co.jp  Tue Dec  8 08:23:12 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:39 2009
Subject: P1394> New command proposal for variable MAX_TASK_SET_SIZE (Resent)
Message-ID: <199812081323.WAA08929@eva-00.pure.cpdc.canon.co.jp>

Hello, all,

I'm re-sending this message because mail delivery system seems to
misunderstand the period at the beginning of line as end of message.
I'm sorry for duplicated messages.

At the last meeting, there was a discussion on the definitions of
"queue" and "connection", but I suppose there was little discussion
on "MAX_TASK_SET_SIZE" parameter along with these new definitions.

I think there are several problems with current "MAX_TASK_SET_SIZE"
definition, that is fixed value during a login, when combined with
new "queue" and "connection" definitions because number of queues
covered by this parameter during login is not static anymore.

I've attached short document that describes problems and proposes a
solution.

Please find attached document.

I would like to discuss this issue on this list and at upcoming San
Diego meeting.

Are there any suggestions and/or comments?

Akihiro Shimura

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: VarMaxT1.pdf
Type: application/octet-stream
Size: 12642 bytes
Desc: not available
Url : http://www.pwg.org/archives/p1394/attachments/19981208/454772df/VarMaxT1.obj
From vvenkat at teil.soft.net  Wed Dec  9 09:08:40 1998
From: vvenkat at teil.soft.net (Venkatesh V)
Date: Wed May  6 14:00:39 2009
Subject: P1394> Config ROM in 1394!!!(IP over 1394)
References: <199812081323.WAA08929@eva-00.pure.cpdc.canon.co.jp>
Message-ID: <366E8468.512ACCF0@teil.soft.net>

Hi,

While reading through the draft of "IP over 1394", I
came across a register called NETWORK_CHANNELS register
.. but the draft doesnot specify where this is to be 
located ?? Is it part of Config ROM .. I mean unit space ??

Could anybody throw some light on this!!!

Thanx 
Venkatesh.

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Wed Dec  9 17:39:11 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:39 2009
Subject: P1394> 1394 Model & Command Set Proposal
Message-ID: <H0000d9310721fd8@MHS>

     1394 PWG & PWG-C Members,
     
     Please carefully review the attached document and bring a copy to San 
     Diego.
     
     It has evolved somewhat from Tuscon. Actually it has changed to allow 
     Targets to open connections. I believe it still captures the spirit of 
     what we discussed in Tuscon.
     
     I am looking forward to discussing this next week.
     
     I also ftp'd it to pwg-in as pwgpr4x.pdf on the web.
     Don, please move to the right place. (Remove pwgpr43.pdf it is a bogus 
     file transferred as ASCII)
     
     regards,
     Alan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pwgpr43.pdf
Type: application/pdf
Size: 112616 bytes
Desc: not available
Url : http://www.pwg.org/archives/p1394/attachments/19981209/86cd7cb7/pwgpr43.pdf
From jfuller at MICROSOFT.com  Fri Dec 11 14:12:31 1998
From: jfuller at MICROSOFT.com (John Nels Fuller)
Date: Wed May  6 14:00:39 2009
Subject: P1394> Config ROM in 1394!!!(IP over 1394)
Message-ID: <FD8F41F04D35D111899600805F19A16C08B1FD52@RED-MSG-48>

Hello,

NETWORK_CHANNELS is defined in IEEE P1394a, the current draft of which is
available on ftp://ftp.symbios.com/pub/standards/io/1394/P1394a.
_____________________ 
John Nels Fuller 
Program Manager, Windows 2000 
Microsoft Corporation 
One Microsoft Way 
Redmond, WA   98052-6399 
Voice: (425) 703-3863 
Fax: (425) 93 MSFAX 


-----Original Message-----
From: Venkatesh V [mailto:vvenkat@teil.soft.net]
Sent: Wednesday, December 09, 1998 6:09 AM
To: p1394@pwg.org
Subject: P1394> Config ROM in 1394!!!(IP over 1394)


Hi,

While reading through the draft of "IP over 1394", I
came across a register called NETWORK_CHANNELS register
.. but the draft doesnot specify where this is to be 
located ?? Is it part of Config ROM .. I mean unit space ??

Could anybody throw some light on this!!!

Thanx 
Venkatesh.

From gleclair at agentz.com  Sun Dec 13 15:15:23 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:39 2009
Subject: P1394> AGENDA for DEC 14-15 at San Diego,CA
Message-ID: <01BE2692.4D668E40@gleclair.vip.best.com>

1394 PWG Meeting Agenda
December 14-15, 1998
     
1. Meeting Agenda
2. Old Business
      New Proposals
	- Command for variable MAX_TASK_SET_SIZE - Shimura
	- 1394 Model & Command Set - Berkema
      Updates
	- Profile
		- Bridges
	- Config ROM
		- 1212 - Instances, keywords
		- OUI - waiting for RAC reply
3. New Business
      Topics:
      Discussion
4. Plan
      Action Items




From brianb at vcd.hp.com  Thu Dec 17 23:48:12 1998
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:39 2009
Subject: P1394> December 1212r Minutes
Message-ID: <4.1.19981214120217.009c0100@popmail1.vcd.hp.com>

Attached you will find the December 1212r minutes.  

(Greg, could you please post them to the web-site?  Thanks.)

Brian 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/p1394/attachments/19981217/fb87ac58/1212r981209.html
-------------- next part --------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder                            | Hewlett-Packard   
Connectivity Standards Architect            | 1115 SE 164th Ave. 
DeskJet Printers                            | Vancouver, WA  98684 
Phone: (360) 212-4107 | Fax: (360) 212-4227 | mailto:brianb@vcd.hp.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From atsnaka at bsd.canon.co.jp  Thu Dec 24 19:20:25 1998
From: atsnaka at bsd.canon.co.jp (Atsushi Nakamura)
Date: Wed May  6 14:00:39 2009
Subject: P1394> target initiating a Login in a non-logged in situation
Message-ID: <001e01be2f9c$5eb3d500$776a14ac@atsnaka01ii.bsd.canon.co.jp>

In San Diego, we talked about Print(Scan) trigger Solutions for a target initiating a Login 
in a non-loggged-in situation. Though we summariazed that using the 1212 messaging
mechanism was a good idea (and I agree), I have a question ;

How does the target find the SBP-2 initiator in the first place ?

As far as I know, there is no configuration ROM definition for a SBP-2 initiator.
How can a device (target) discover a SBP-2 initator device within the 1394 topology ?

Am I missing a point ?

Ats

p.s. Happy Holidays !

-----------------------------------------
Atsushi Nakamura
-----------------------------------------
BJ Technology Development 22,
Canon Inc.

53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211
tel: +81-3-44-733-6111(ext.5593)
     +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------


From atsnaka at bsd.canon.co.jp  Thu Dec 24 19:45:03 1998
From: atsnaka at bsd.canon.co.jp (Atsushi Nakamura)
Date: Wed May  6 14:00:39 2009
Subject: P1394> P1212r instance directory keywords
Message-ID: <002201be2f9f$cfea58e0$776a14ac@atsnaka01ii.bsd.canon.co.jp>

About P1212r instance directory(FDS) keywords, 

The PWG-C previously proposed several "function_classes"
to the 1212 group, before the keyword concept came out.

Tweaking them to fit the "keyword" format ('a'-'z', '0'-'9', and '-' , no spaces)
I would like to propose the following keywords to the Architecture WG 
through the DSI-WG, as a proposal from the PWG-C.

scanner
printer
fax
disk
storage
camera
modem
display
copy

video
still-image

Comments are welcome !

Ats

-----------------------------------------
Atsushi Nakamura
-----------------------------------------
BJ Technology Development 22,
Canon Inc.

53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211
tel: +81-3-44-733-6111(ext.5593)
     +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------


From rturner at sharplabs.com  Wed Jan  7 17:38:05 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Next teleconference call
Message-ID: <199712180101.RAA16592@hpsdlgj1.sdd.hp.com>

The details of the next PWG 1394 teleconference are as 
follows:


	Time:    1 PM PST
            Date:     1/12/1998  (no year 2000 problems here)
	Dialup Number: 805-240-9463
	Access Code: 216796


Randy

From rturner at sharplabs.com  Wed Jan  7 20:57:24 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Next teleconference call
Message-ID: <199712180101.RAA16592@hpsdlgj1.sdd.hp.com>

Due to numerous requests, I have moved the teleconference
call to 4 PM PST. This will be a better hour for participants
dialing in from Japan.


The rest of the details for the call are the same


	> 	Time:    4 PM PST
	>             Date:     1/12/1998  (no year 2000 problems here)
	> 	Dialup Number: 805-240-9463
	> 	Access Code: 216796


> > 

From lstein at fapo.com  Thu Jan  8 18:16:37 1998
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Monday night event
Message-ID: <199801082314.PAA24024@barley.adnc.com>

Hello Everyone attending the Hawaii meeting,


In the spirit of our once per meeting get together, I've made tentative
arrangements for Monday night (instead of Tuesday).


Whale Watch, Sunset Cuise
Monday, early evening (time TBD)


Take a cruise on a charted 36' catamaran.  
Soft drinks, beer, wine, mia-ties (SP?), and PUPU (appetizers) included!!


The whales are jumping out there and they tell me that this is the best
time of year for it.


The cost will be about $49.00 per adult, something less for kids.
Bring the spouse, friend and kids.


Please RSVP to me ASAP with the following:


# Adults
# Kids


We are limited to 49 people.


Thanks,
Larry


***************************************************************
Larry A. Stein			Phone: 	(619)292-2742
Warp Nine Engineering		Fax:	(619)292-8020
				Web: 	http://www.fapo.com
***************************************************************

From Nagasaka.Fumio at exc.epson.co.jp  Fri Jan  9 02:59:11 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:46 2009
Subject: P1394> RE: [PP1394:00137]
Message-ID: <199801082314.PAA24024@barley.adnc.com>

Thank you Alan, for your great effort updating PWG profile document.


Larry wrote: (in "P1394> December Meeting Minutes")
> H- Section 14, Multiple Logical Channels
> Routing information needs to be provided here, not .4 Channel 
information.
$B%j(J	=> PSID and SSID should be removed from the command_block


At LA meeting, we agreed to remove PSID and SSID from CDB of normal
command block ORB. However, now I would like to suggest to enclose
1284.4 supportive flag and 6 bytes 1284.4 packet header in CDB.


The reason is outlined below.
1)	IEEE 1284.4 is providing "out-of-band packet control flag" in the 
header
for 1284.4 packets.
2)	However if we does not enclose any 1284.4 information in normal 
command
block ORB. Fetch Agent needs to examine buffered data that wad 
fetched
after the fetch agent processed the ORB.
3)	Basically, out-of-band packet shall be extracted as soon as 
possible.
4)	Thus we would like to make short cut to detect out-of-band requests 
without
reading buffer space associated with each ORB.


--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


-----Original Message-----
From:	ALAN_BERKEMA@hp-roseville-om2.om.hp.com 
[SMTP:ALAN_BERKEMA@hp-roseville-om2.om.hp.com]
Sent:	Friday, January 09, 1998 7:38 AM
To:	pp1394 ML
Subject:	[PP1394:00137]


 << File: ccMail >>  << File: pwgprof.pdf >>

From atsnaka at mxa.mesh.ne.jp  Fri Jan  9 10:47:31 1998
From: atsnaka at mxa.mesh.ne.jp (Atsushi Nakamura)
Date: Wed May  6 14:00:46 2009
Subject: P1394> RE: [PP1394:00137]
Message-ID: <199801091527.AAA20984@meshsv02.tk.mesh.ad.jp>

Just for clarification;


I think we have 2 choices in defining a 
"PWG profile CDB ",


1st choice:
If we decide to define the PWG profile CDB in a way that there is 
a 1284.4 specific CDB content encapsulated in a
"generic CDB frame structure" (generic, meaning supporting various upper
layers) which is intended to support other upper layers as well as 1284.4,
we will need to define 2 things:


 1)"generic CDB frame structure"...will include header to distingush 
              actual content (ex. 1284.4, or other alternative layers)


 2)1284.4 specific CDB content  ....actual content of CDB which is 1284.4
information


2nd choice:
If we decide that the PWG profile CDB will be 1284.4 specific,
in this case we will only need to define:


1) 1284.4 specific CDB content


In either case,
1284.4 supportive flag and packet header will be included in 
1284.4 specific CDB content.
I AGREE that this 1284.4 "short-cut" may be effective 
AS LONG AS it is not defined in the "generic structure" but defined in
1284.4 
specific content definition.
    

---
Now, my opinion on making he PWG profile CDB "generic" vs making it 
"1284.4 specific".
Since SBP-2 already has a mechanism to distinguish the contents of the CDB
("command_set_spec_id" and "sw_version"), I think we do not need a "CDB
frame"
to do the same thing.
SBP-2 itself is already "generic"
I think the PWG profile should define the CDB to be 1284.4 specific.


P.S. Alan,Nagasaka-san, I apologize if this discussion is already out of
synch.
      I have not yet had time to read the updated profile.   


Atsushi Nakamura
Canon Inc.




----------
> $B:9=P?M(J : Nagasaka Fumio <Nagasaka.Fumio@exc.epson.co.jp>
> $B08@h(J : 'ALAN_BERKEMA@hp-roseville-om2.om.hp.com'
> CC : 'p1394@pwg.org'
> $B7oL>(J : P1394> RE: [PP1394:00137] 
> $BAw?.F|;~(J : 1998$BG/(J1$B7n(J9$BF|(J 16:59
> 
> Thank you Alan, for your great effort updating PWG profile document.
> 
> Larry wrote: (in "P1394> December Meeting Minutes")
> > H- Section 14, Multiple Logical Channels
> > Routing information needs to be provided here, not .4 Channel 
> information.
> $B%j(J	=> PSID and SSID should be removed from the command_block
> 
> At LA meeting, we agreed to remove PSID and SSID from CDB of normal
> command block ORB. However, now I would like to suggest to enclose
> 1284.4 supportive flag and 6 bytes 1284.4 packet header in CDB.
> 
> The reason is outlined below.
> 1)	IEEE 1284.4 is providing "out-of-band packet control flag" in the 
> header
> for 1284.4 packets.
> 2)	However if we does not enclose any 1284.4 information in normal 
> command
> block ORB. Fetch Agent needs to examine buffered data that wad 
> fetched
> after the fetch agent processed the ORB.
> 3)	Basically, out-of-band packet shall be extracted as soon as 
> possible.
> 4)	Thus we would like to make short cut to detect out-of-band requests 
> without
> reading buffer space associated with each ORB.
> 
> --------------------------------------------
> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
> 
> -----Original Message-----
> From:	ALAN_BERKEMA@hp-roseville-om2.om.hp.com 
> [SMTP:ALAN_BERKEMA@hp-roseville-om2.om.hp.com]
> Sent:	Friday, January 09, 1998 7:38 AM
> To:	pp1394 ML
> Subject:	[PP1394:00137]
> 
>  << File: ccMail >>  << File: pwgprof.pdf >>
> 


From gregs at sdd.hp.com  Fri Jan  9 16:50:31 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:46 2009
Subject: P1394> RE: [PP1394:00137]
In-Reply-To: <c=US%a=_%p=EPSON%l=CPUEX1-980109075911Z-4188@odaeex1.ODAEEX1>
Message-ID: <199801092150.NAA06836@hpsdlgj1.sdd.hp.com>

> 
> Thank you Alan, for your great effort updating PWG profile document.
> 
> Larry wrote: (in "P1394> December Meeting Minutes")
> > H- Section 14, Multiple Logical Channels
> > Routing information needs to be provided here, not .4 Channel 
> information.
> $B%j(J	=> PSID and SSID should be removed from the command_block
> 
Fumio wrote:
> At LA meeting, we agreed to remove PSID and SSID from CDB of normal
> command block ORB. However, now I would like to suggest to enclose
> 1284.4 supportive flag and 6 bytes 1284.4 packet header in CDB.
> 
> The reason is outlined below.
> 1)	IEEE 1284.4 is providing "out-of-band packet control flag" in the 
> header
> for 1284.4 packets.
> 2)	However if we does not enclose any 1284.4 information in normal 
> command
> block ORB. Fetch Agent needs to examine buffered data that wad 
> fetched
> after the fetch agent processed the ORB.
> 3)	Basically, out-of-band packet shall be extracted as soon as 
> possible.
> 4)	Thus we would like to make short cut to detect out-of-band requests 
> without
> reading buffer space associated with each ORB.


[Shue,Greg] These comments lead me to think there is some
confusion about what does "out-of-band" mean.  As I was told at
one of the PWG meetings, it means information which is
_synchronous_ to a specific point in the data stream, but is not
to be interpreted as normal data.  As such, the phrase "shall be
extracted as soon as possible" doesn't make sense to me.  Can
this be explained further?


> --------------------------------------------
> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
> 
> -----Original Message-----
> From:	ALAN_BERKEMA@hp-roseville-om2.om.hp.com 
> [SMTP:ALAN_BERKEMA@hp-roseville-om2.om.hp.com]
> Sent:	Friday, January 09, 1998 7:38 AM
> To:	pp1394 ML
> Subject:	[PP1394:00137]
> 
>  << File: ccMail >>  << File: pwgprof.pdf >>



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


From fumiona at venus.dtinet.or.jp  Fri Jan  9 19:48:06 1998
From: fumiona at venus.dtinet.or.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:46 2009
Subject: P1394> RE: [PP1394:00137]
Message-ID: <199801092150.NAA06836@hpsdlgj1.sdd.hp.com>

Hi,
Fumio wrote:
> At LA meeting, we agreed to remove PSID and SSID from CDB of normal
> command block ORB. However, now I would like to suggest to enclose
> 1284.4 supportive flag and 6 bytes 1284.4 packet header in CDB.
> 
> The reason is outlined below.
> 1)	IEEE 1284.4 is providing "out-of-band packet control flag" in the 
> header
> for 1284.4 packets.
> 2)	However if we does not enclose any 1284.4 information in normal 
> command
> block ORB. Fetch Agent needs to examine buffered data that wad 
> fetched
> after the fetch agent processed the ORB.
> 3)	Basically, out-of-band packet shall be extracted as soon as 
> possible.
> 4)	Thus we would like to make short cut to detect out-of-band requests 
> without
> reading buffer space associated with each ORB.


>[Shue,Greg] These comments lead me to think there is some
>confusion about what does "out-of-band" mean.  As I was told at
>one of the PWG meetings, it means information which is
>_synchronous_ to a specific point in the data stream, but is not
>to be interpreted as normal data.  As such, the phrase "shall be
>extracted as soon as possible" doesn't make sense to me.  Can
>this be explained further?


My colleague pointed out same thing. I misunderstood usage of
"out-of-band". But still I would like to enclose some control information
in CDB. Because current specification has problem shown below,...
1) if one data channel is stalled, the fetch agent does not pass data
toward upper layer ( in this case upper layer is CBT).
2) thus the fetch agent stops consuming data from a linked list of ORBs.
3) By the way an application would append new ORB which requests
status reply as the application need to solve the problem. (may be
new ORB uses other logical channel. But the logical channel number
is enclosed in data buffer associated with this ORB)
4) The fetch agent does not read this new data buffer, because he is
    busy. And he does not have any internal FIFO space to read new data.
5) Finally the fetch agent does not pass new request to CBT. He will
know that new ORB should be delivered to other logical channel, thus
he could do that, but he didn't.... It is too late.


We can provide ORB pre-fetch queue as the front end process, before
the fetch agent really consumes data stored in data buffer. And I believe 
that ORBs shall *not* be executed in order. And I prefer to choose
one login for one transport. Thus I want to say "A linked list of ORBs may
contain many requests to various logical channels".


"One login for one logical channel" solves this problem. However multiple
login supportive SBP-2 target is very expensive.


--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp

From gregs at sdd.hp.com  Fri Jan  9 21:29:12 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:46 2009
Subject: P1394> RE: [PP1394:00137]
In-Reply-To: <01BD1DAD.0532B980@INS28.maebashi.dtinet.or.jp>
Message-ID: <199801100229.SAA07074@hpsdlgj1.sdd.hp.com>

Hi,
Fumio wrote:
> My colleague pointed out same thing. I misunderstood usage of
> "out-of-band". But still I would like to enclose some control information
> in CDB. Because current specification has problem shown below,...
> 1) if one data channel is stalled, the fetch agent does not pass data
> toward upper layer ( in this case upper layer is CBT).
> 2) thus the fetch agent stops consuming data from a linked list of ORBs.
> 3) By the way an application would append new ORB which requests
> status reply as the application need to solve the problem. (may be
> new ORB uses other logical channel. But the logical channel number
> is enclosed in data buffer associated with this ORB)
> 4) The fetch agent does not read this new data buffer, because he is
>     busy. And he does not have any internal FIFO space to read new data.
> 5) Finally the fetch agent does not pass new request to CBT. He will
> know that new ORB should be delivered to other logical channel, thus
> he could do that, but he didn't.... It is too late.
> 
> We can provide ORB pre-fetch queue as the front end process, before
> the fetch agent really consumes data stored in data buffer. And I believe 
> that ORBs shall *not* be executed in order. And I prefer to choose
> one login for one transport. Thus I want to say "A linked list of ORBs may
> contain many requests to various logical channels".


[Shue, Greg]
As I understand it, ORB "pre-fetching" is a desirable (required?)
characteristic of out-of-order processing and out-of-order
completion.  Either there is one login for one transport, and no
multiplexing needs to be done at the SBP-2 level, or there is one
login for multiple transports, so routing information is required
in the ORB CDB (yuck!  :-).  The whole purpose of CBT is to
provide multiplexing and data pacing such that whatever data
packets are sent already have the memory space reserved at the
other end, so all packet transfers can be completed immediately.


[Shue, Greg]
I think we need to choose whether multiple transports are
supported for one login or not.  (Haven't we already decided no?)
If one transport per login, and one login per transport, then
routing is not an issue.




> "One login for one logical channel" solves this problem. However multiple
> login supportive SBP-2 target is very expensive.


[Shue, Greg]
What leads you to think that a fetch agent is expensive?  Is it
any more expensive than the CBT agent managing credit for a given
CBT channel?  My guess is that the SBP-2 fetch agent is actually
cheaper, especially since all the code to run the fetch agent
could probably be reused across all instances.  But, I may be
missing some complexity behind an SBP-2 fetch agent.


> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp





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


From fumiona at venus.dtinet.or.jp  Mon Jan 12 08:05:00 1998
From: fumiona at venus.dtinet.or.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:46 2009
Subject: P1394> RE: [PP1394:00137]
Message-ID: <199801100229.SAA07074@hpsdlgj1.sdd.hp.com>

> [Shue, Greg]
> What leads you to think that a fetch agent is expensive?  Is it
> any more expensive than the CBT agent managing credit for a given
> CBT channel?  My guess is that the SBP-2 fetch agent is actually
> cheaper, especially since all the code to run the fetch agent
> could probably be reused across all instances.  But, I may be
> missing some complexity behind an SBP-2 fetch agent.


[Nagasaka, Fumio]
May be CBT credit management for multiple channels could be
expensive from memory requirements reason. And multiple login
requires SBP-2 target to have server capabilities. A server style
program consumes many threads and memory, also it brings
complexities into software development. Actually these difficulty
would be solved by software development effort.


But as you know, Windows NT5.0 SBP-2 initiator invokes one log-in
to the target device when PC boots up. And the initiator never log-out
until an user shut down his PC. I am afraid of that log-in function of
SBP-2 is not exported to other software, in Windows NT5.0 environment.


I mentioned two reasons above. Basically single login for one CBT
is merely simple. Because, SBP-2 layer shall be a simple data path
as data link layer for the transport protocol. 
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


-----Original Message-----
From:	Greg Shue [SMTP:gregs@sdd.hp.com]
Sent:	Saturday, January 10, 1998 11:29 AM
To:	Fumio Nagasaka
Cc:	p1394@pwg.org
Subject:	P1394> RE: [PP1394:00137]




Hi,
Fumio wrote:
> My colleague pointed out same thing. I misunderstood usage of
> "out-of-band". But still I would like to enclose some control information
> in CDB. Because current specification has problem shown below,...
> 1) if one data channel is stalled, the fetch agent does not pass data
> toward upper layer ( in this case upper layer is CBT).
> 2) thus the fetch agent stops consuming data from a linked list of ORBs.
> 3) By the way an application would append new ORB which requests
> status reply as the application need to solve the problem. (may be
> new ORB uses other logical channel. But the logical channel number
> is enclosed in data buffer associated with this ORB)
> 4) The fetch agent does not read this new data buffer, because he is
>     busy. And he does not have any internal FIFO space to read new data.
> 5) Finally the fetch agent does not pass new request to CBT. He will
> know that new ORB should be delivered to other logical channel, thus
> he could do that, but he didn't.... It is too late.
> 
> We can provide ORB pre-fetch queue as the front end process, before
> the fetch agent really consumes data stored in data buffer. And I believe 
> that ORBs shall *not* be executed in order. And I prefer to choose
> one login for one transport. Thus I want to say "A linked list of ORBs may
> contain many requests to various logical channels".


[Shue, Greg]
As I understand it, ORB "pre-fetching" is a desirable (required?)
characteristic of out-of-order processing and out-of-order
completion.  Either there is one login for one transport, and no
multiplexing needs to be done at the SBP-2 level, or there is one
login for multiple transports, so routing information is required
in the ORB CDB (yuck!  :-).  The whole purpose of CBT is to
provide multiplexing and data pacing such that whatever data
packets are sent already have the memory space reserved at the
other end, so all packet transfers can be completed immediately.


[Shue, Greg]
I think we need to choose whether multiple transports are
supported for one login or not.  (Haven't we already decided no?)
If one transport per login, and one login per transport, then
routing is not an issue.




> "One login for one logical channel" solves this problem. However multiple
> login supportive SBP-2 target is very expensive.


[Shue, Greg]
What leads you to think that a fetch agent is expensive?  Is it
any more expensive than the CBT agent managing credit for a given
CBT channel?  My guess is that the SBP-2 fetch agent is actually
cheaper, especially since all the code to run the fetch agent
could probably be reused across all instances.  But, I may be
missing some complexity behind an SBP-2 fetch agent.


> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp





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


From ewa at apple.com  Mon Jan 12 14:25:33 1998
From: ewa at apple.com (Eric W. Anderson)
Date: Wed May  6 14:00:46 2009
Subject: P1394> NT5: Automatic SBP-2 login?
Message-ID: <B0DFB574-41073@17.219.105.142>

Fumio Nagasaka writes:
>But as you know, Windows NT5.0 SBP-2 initiator invokes one log-in
>to the target device when PC boots up. And the initiator never log-out
>until an user shut down his PC. I am afraid of that log-in function of
>SBP-2 is not exported to other software, in Windows NT5.0 environment.


Can we confirm this behavior?  I think this would make it impossible
to use two Windows NT5 computers on the same FireWire bus with any
SBP-2 device (printer, disk drive, etc).  After the first computer
boots and makes logins, the second computer will be unable to access
any SBP-2 device.  Is that correct?


Certainly we plan to be more flexible in Mac OS.  In general, no
automatic logins will be performed - logins will happen on a device-
by-device basis, depending on user requirements/actions.  For example,
a Mac would only perform a login to a printer when the user actually
tries to print a document, or check printer configuration.  Then the
Mac would log out when the work was completed.


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------

From fumiona at venus.dtinet.or.jp  Mon Jan 12 16:43:24 1998
From: fumiona at venus.dtinet.or.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:46 2009
Subject: P1394> NT5: Automatic SBP-2 login?
Message-ID: <B0DFB574-41073@17.219.105.142>

Hi,
I must apologize that I am not suitable person to discuss specification of a
consumer PC OS. Some consumer PC operating system under development
would often have temporary specification. As we can adopt many PCs and
peripherals utilizing 1394 bus, and some of them could be SBP-2 devices.
I am afraid of one thing involved with inter-connectivity.


However any PC operating system would be improved everyday, thus I would
not talk about this issue through the mailing list. It is too risky.
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


-----Original Message-----
From:	Eric W. Anderson [SMTP:ewa@apple.com]
Sent:	Tuesday, January 13, 1998 4:26 AM
To:	Fumio Nagasaka; 'Greg Shue'; p1394@pwg.org
Subject:	P1394> NT5: Automatic SBP-2 login?


Fumio Nagasaka writes:
>But as you know, Windows NT5.0 SBP-2 initiator invokes one log-in
>to the target device when PC boots up. And the initiator never log-out
>until an user shut down his PC. I am afraid of that log-in function of
>SBP-2 is not exported to other software, in Windows NT5.0 environment.


Can we confirm this behavior?  I think this would make it impossible
to use two Windows NT5 computers on the same FireWire bus with any
SBP-2 device (printer, disk drive, etc).  After the first computer
boots and makes logins, the second computer will be unable to access
any SBP-2 device.  Is that correct?


Certainly we plan to be more flexible in Mac OS.  In general, no
automatic logins will be performed - logins will happen on a device-
by-device basis, depending on user requirements/actions.  For example,
a Mac would only perform a login to a printer when the user actually
tries to print a document, or check printer configuration.  Then the
Mac would log out when the work was completed.


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------

From don at lexmark.com  Wed Jan 14 17:14:49 1998
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:46 2009
Subject: P1394> PWG Meeting Agenda - Final
Message-ID: <199801150126.AA09514@interlock2.lexmark.com>

Here's the final meeting agenda for Jan 26-30.  Details on the individual
groups will be provided by the appropriate chairs.  Status presentations
and subsequent discussion will be STRICTLY limited to 10 minutes.  If a
chair
is not going to be present, please post your status to the mailing list and
send it to me at least 1 week before the meeting.


Monday, Jan 26
     8:30 - 5:30    1394 Printing


Tuesday, Jan 27
     8:30 - 5:30    1394 Printing


Wednesday, Jan 28
     8:30      PWG General Meeting
          8:30 Next Meetings
          8:45 Print MIB Status
          8:55 Job MIB Status
          9:05 Finisher MIB Status
          9:15 Sense Status
          9:25 IPP Status
          9:35 1394 Printing Status
          9:45 Open PWG Issues
                    - Job MIB traps
                    - others
     10:30          IPP
                    - XML
                    - other open issues


Thursday, Jan 29
     8:30 - 5:30    IPP
                    - overflow from Wednesday
                    - Prototyping


Friday, Jan 30
     8:30 - 5:30    Finisher MIB




**********************************************
* Don Wright                 don@lexmark.com *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

From brianb at vcd.hp.com  Thu Jan 15 18:33:12 1998
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:46 2009
Subject: P1394> 1394 PWG Meeting - Extra Day
Message-ID: <3.0.2.32.19980115153312.00839940@popmail1.vcd.hp.com>

1394 folks,


During several recent meetings we have "discovered" reasons to meet for an
extra day or part of an extra day after the scheduled two-day meeting.
Because of that, I have extended my trip for an extra day to allow for such
an impromptu meeting.  I wanted to announce this ahead of time because
others might also wish to extend their trips.


Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227

From gregs at sdd.hp.com  Thu Jan 15 19:33:52 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:46 2009
Subject: P1394> 1394 PWG Meeting - Extra Day (fwd)
Message-ID: <199801160033.QAA22766@hpsdlgj1.sdd.hp.com>

Forwarded message:
> From p1394-owner@pwg.org Thu Jan 15 15:23:45 PST 1998
> Message-Id: <3.0.2.32.19980115153312.00839940@popmail1.vcd.hp.com>
> X-Sender: brianb@popmail1.vcd.hp.com
> X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
> Date: Thu, 15 Jan 1998 15:33:12 -0800
> To: 1394 PWG <p1394@pwg.org>
> From: Brian Batchelder <brianb@vcd.hp.com>
> Subject: P1394> 1394 PWG Meeting - Extra Day
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> Sender: p1394-owner@pwg.org
> 
> 1394 folks,
> 
> During several recent meetings we have "discovered" reasons to meet for an
> extra day or part of an extra day after the scheduled two-day meeting.
> Because of that, I have extended my trip for an extra day to allow for such
> an impromptu meeting.  I wanted to announce this ahead of time because
> others might also wish to extend their trips.


I'll extend my trip too.


> Brian
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
> Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
> DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227
> 
> 





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


From fumiona at venus.dtinet.or.jp  Fri Jan 16 17:20:07 1998
From: fumiona at venus.dtinet.or.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Tel-conf at 1/12
Message-ID: <199801160033.QAA22766@hpsdlgj1.sdd.hp.com>

Fumio Wrote:
<<
1)	if one data channel is stalled, the fetch agent does not pass data toward 
upper layer ( in this case upper layer is CBT).
2)	thus the fetch agent stops consuming data from a linked list of ORBs.
3)	By the way an application would append new ORB which requests status 
reply as the application need to solve the problem. (may be new ORB uses 
other logical channel. But the logical channel number is enclosed in data 
buffer associated with this ORB)
4)	The fetch agent does not read this new data buffer, because he is busy. 
And he does not have any internal FIFO space to read new data.
5)	Finally the fetch agent does not pass new request to CBT. He will know 
that new ORB should be delivered to other logical channel, thus he could do 
that, but he didn't.... It is too late.
>>


Through the tel-conference held at January 12, Greg Shue's opinion
makes me recognize my points shown above had misunderstanding.
PWG-profile defines SBP-2 as CBT driven data-link layer. So when
an initiator starts transaction, the target peer gives credits for each
logical channels. If the initiator appends out-ORB up to given credits,
all these requests will be stored into target peer's FIFO without over-
flow. Thus we don't need to assume that a target agent will be stalled.


On the other hand, when the target peer starts transaction, the initiator
peer gives credits for each logical channels. In this case the initiator
needs to append an in-ORB at each time. Because if the initiator
appends N+k in-ORBs in a list, and the target has only N requests,
then k in-ORBs will not be consumed. From this point of view, I think
each in-ORB shall be set a notify bit one, when PWG-profile applied.
The initiator may be notified when provided in-ORB is consumed by
the target peer. Then the initiator may append one more in-ORB on
the inked list.


As conclusion, I think we don't need to fill CDB with any socket 
information
nor control information,... Greg, do you have any points?
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


-----Original Message-----
From:	Fumio Nagasaka [SMTP:fumiona@venus.dtinet.or.jp]
Sent:	Saturday, January 10, 1998 9:48 AM
To:	'Greg Shue'; Nagasaka Fumio
Cc:	ALAN_BERKEMA@hp-roseville-om2.om.hp.com; p1394@pwg.org
Subject:	RE: P1394> RE: [PP1394:00137]


Hi,
Fumio wrote:
> At LA meeting, we agreed to remove PSID and SSID from CDB of normal
> command block ORB. However, now I would like to suggest to enclose
> 1284.4 supportive flag and 6 bytes 1284.4 packet header in CDB.
>
> The reason is outlined below.
> 1)	IEEE 1284.4 is providing "out-of-band packet control flag" in the
> header
> for 1284.4 packets.
> 2)	However if we does not enclose any 1284.4 information in normal
> command
> block ORB. Fetch Agent needs to examine buffered data that wad
> fetched
> after the fetch agent processed the ORB.
> 3)	Basically, out-of-band packet shall be extracted as soon as
> possible.
> 4)	Thus we would like to make short cut to detect out-of-band requests
> without
> reading buffer space associated with each ORB.


>[Shue,Greg] These comments lead me to think there is some
>confusion about what does "out-of-band" mean.  As I was told at
>one of the PWG meetings, it means information which is
>_synchronous_ to a specific point in the data stream, but is not
>to be interpreted as normal data.  As such, the phrase "shall be
>extracted as soon as possible" doesn't make sense to me.  Can
>this be explained further?


My colleague pointed out same thing. I misunderstood usage of
"out-of-band". But still I would like to enclose some control information
in CDB. Because current specification has problem shown below,...
1) if one data channel is stalled, the fetch agent does not pass data
toward upper layer ( in this case upper layer is CBT).
2) thus the fetch agent stops consuming data from a linked list of ORBs.
3) By the way an application would append new ORB which requests
status reply as the application need to solve the problem. (may be
new ORB uses other logical channel. But the logical channel number
is enclosed in data buffer associated with this ORB)
4) The fetch agent does not read this new data buffer, because he is
    busy. And he does not have any internal FIFO space to read new data.
5) Finally the fetch agent does not pass new request to CBT. He will
know that new ORB should be delivered to other logical channel, thus
he could do that, but he didn't.... It is too late.


We can provide ORB pre-fetch queue as the front end process, before
the fetch agent really consumes data stored in data buffer. And I believe
that ORBs shall *not* be executed in order. And I prefer to choose
one login for one transport. Thus I want to say "A linked list of ORBs may
contain many requests to various logical channels".


"One login for one logical channel" solves this problem. However multiple
login supportive SBP-2 target is very expensive.


--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp

From lstein at fapo.com  Fri Jan 16 21:44:22 1998
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:47 2009
Subject: P1394> January Meeting List
Message-ID: <Version.32.19980116183517.00ffe2e0@pop3.fapo.com>

--=====================_885033862==_
Content-Type: text/plain; charset="us-ascii"


Hello,


I've attached an Excel spreadsheet of the people who have responded to the
meeting for January.  Please check to make sure I got your reservation
correct.


Your checkin date says "in".  A "1" is in the column for the meeting you
will be attending.  If you are leaving the same day as attending a meeting
then there is no "out" for your checkout.  If you are leaving some other
day then I listed it as "out".


Also, if you are planning on attending the Whale watching cruise on Monday
night I listed you under "Whale".  If you still want to go but are not on
the list please let me know.


I don't know the meeting charges yet.  It should be around $30 per day.


Thanks,
Larry


--=====================_885033862==_
Content-Type: application/octet-stream; name="Janmtg.xls";
 x-mac-type="584C5334"; x-mac-creator="5843454C"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Janmtg.xls"


[encoded data, 40117 characters]
--=====================_885033862==_
Content-Type: text/plain; charset="us-ascii"




**********************************************************
Larry A. Stein		Ph. 619-292-2742
Warp Nine Engineering	Fax 619-292-8020
lstein@fapo.com		http://www.fapo.com
**********************************************************
--=====================_885033862==_--

From gregs at sdd.hp.com  Mon Jan 19 13:10:22 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Tel-conf at 1/12
Message-ID: <199801191810.KAA01547@hpsdlgj1.sdd.hp.com>

> Fumio Wrote:
...
> flow. Thus we don't need to assume that a target agent will be stalled.


I think that's correct.


> On the other hand, when the target peer starts transaction, the initiator
> peer gives credits for each logical channels. In this case the initiator
> needs to append an in-ORB at each time. Because if the initiator
> appends N+k in-ORBs in a list, and the target has only N requests,
> then k in-ORBs will not be consumed. From this point of view, I think
> each in-ORB shall be set a notify bit one, when PWG-profile applied.
> The initiator may be notified when provided in-ORB is consumed by
> the target peer. Then the initiator may append one more in-ORB on
> the inked list.
> 
> As conclusion, I think we don't need to fill CDB with any socket 
> information
> nor control information,... Greg, do you have any points?


I agree with your conclusion.


The only additional point that comes to mind is the dependence
upon out-of-order execution, completion, and dequeuing of
requests (ORBs).  I'm uncomfortable with this because the SBP-2
spec doesn't describe out-of-order completion of requests or
removal of completed requests from within an active request list.




> --------------------------------------------
> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp



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


From gleclair at agentz.com  Tue Jan 20 01:59:24 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:47 2009
Subject: P1394> EMAIL I mentioned in 1/12 telecon
Message-ID: <199801191810.KAA01547@hpsdlgj1.sdd.hp.com>

This is the email I referred to during the telecon.


For those on 1394 PWG reflector who haven't seen this yet.....


Should 1394 PWG profile require/recommend the feature set of 1394a?


Comments?


------------------
Greg LeClair




-----Original Message-----
From:	Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com]
Sent:	Thursday, January 08, 1998 8:53 PM
To:	stds-1394@ieee.org; 1394-architecture@1394TA.org; 1394ohci-l@austin.ibm.com
Cc:	federico@unibrain.com; paull@otenet.gr; met@unibrain.com; zach@unibrain.com
Subject:	Re: Clarifications & Suggestions


Dimitris,


Thank you for your time in submitting these issues for discussion.  
I've embedded some personal comments below.  As an unsolicited piece 
of advice, I'd suggest that you may see better results from 
categorizing your issues into related standards activities (OHCI vs 
P1394a vs Bridging, etc.) and then posting just the pertinent 
questions to the appropriate working reflector.  Also, please be aware 
the P1394a is making every effort to wrap things up and, as such, is 
unlikely to consider any new proposal at this date.  My intention is 
not to discourage you ... I just simply wanted to set appropriate 
expectations.  Some of these ideas may be well suited for follow-on 
1394 TA white papers, best known methods, etc.


Again, see some my two comments below.


Regards,


Jerry Hauck
Intel Corp.
(408) 765-5528
jerry_hauck@ccm.sc.intel.com


> Hello Everybody,
> 
> I am working as a 1394 device driver developer at Unibrain 
> (www.unibrain.com). Over the
> course of my work I have come up with a few questions and a few proposals 
> for 1394, and
> I guess that this list is the proper place to lay them down.
> 
> Here is a quick summary of the topics that I will discuss below:
> (1) CLARIFICATION: One or multiple talkers allowed on an isochronous 
> channel?
>     1394-1995 and P1394a Draft 1.13 include contradicting references on this
> issue.
> (2) PROPOSAL: Broadcast Bus ID.
> (3) PROPOSAL: GUID to Physical ID map registers. 
> (4) PROPOSAL: 2-Writes-Make-A-Read transaction. 
> (5) PROPOSAL: OHCI Physical Lower Bound Register.
> 
> ---------------------------------------------------------------------------- 
> ------------
> (1) CLARIFICATION: One or multiple talkers allowed on an isochronous 
> channel?
> 
>   Can more than one nodes transmit on an isochronous channel (during
> different
>   isochronous cycles)? If you read the references that I include below you
> will
>   realise that you cannot be 100% certain (page numbers are as they appear 
>   on the printed documents):
> 
>   P1394a13, page 12:
>     2.2.13 channel: A relationship between a group of nodes, *talkers* and
> listeners.
>     The group is identified by a number between zero and 63. Channel numbers
> are
>     allocated co-operatively through isochronous resource management
> facilities.
> 
>   COMMENT: Notice the plural for *talkers*.
> 
> 
>   P1394a13, page 101:
>     For a given channel number, no more than one talker may transmit an
> isochronous
>     stream packet with that channel number each isochronous period.
> 
>   COMMENT: Clearly such a statement would not be necessary if there is only
> one talker
>            allowed for each channel.
> 
> 
>   P1394a13, page 101:
>     Multiple nodes may transmit asynchronous stream packets with the same
> channel
>     number or the same node may transmit multiple asynchronous stream
> packets with
>     the same channel number as often as desired, subject to arbitration
> fairness.
> 
>   COMMENT: Multiple talkers are permitted for asynchronous streams.
> 
> 
>   P1394a13, page 112:
>     DUPLICATE CHANNEL DETECTED (Optional). A stream packet was received with
> a channel
>     number equal to one of the node's active, transmit isochronous channels.
> 
>   COMMENT: Does 'active' mean active during the current isochornous cycle or
> more
>            generally configured for isochronous transmission?
> 
> 
>   1394-1995 (Draft 8.0v3), page 238, 8.4.2.4:
>     If an isochronous resourse, either channel or bandwidth, cannot be
> reallocated,
>     the Serial Bus node that owned the resources prior to the bus reset
> shall cause
>     the corresponding isochronous talker to cease broadcast of isochronous
> packets.
> 
>   COMMENT: Now here we see a statement about a channel and its corresponding
> talker,
>            not talkers. This statement clearly supposes that there is only
> one talker
>            that should be instructed to cease its transmissions.
> 
> 
>   1394-1995 (Draft 8.0v3), page 240, 8.4.3:
>     Owners of isochronous resources, either bandwidth or channel
> assignments, gain
>     ownership of these resources through the procedures described in clauses
> 8.4.3.1
>     and 8.4.3.2. Note that the owner of an isochronous resource need be
> neither
>     *the* talker nor *a* listener for the channel in question.
> 
>   COMMENT: Note that it speaks about THE talker (clearly implies only one)
>            and A listener (obviously implies many).
> 
> 
>   OHCI Draft 1.0, Annex D.4 Isochronous Transmit, page 155:
>     A bus reset does not affect the transmission of isochronous packets,
> which continue
>     being transmitted for their assigned channels. It is software's
> responsibility to
>     perform the necessary isochronous resource re-allocation and make any
> communication
>     to the talker's and/or receivers' control registers.
> 
>   COMMENT: This also clearly implies one talker and multiple listeners.
> 
> 
>   If you ask my opinion I would say that it sounds wiser and more reasonable
> to allow
> only one talker per isochronous channel. Here are some of the consequences 
> of allowing
> multiple talkers:
> 
> (*) The chip must monitor the cable for the channel numbers that have 
> transmitted
>     during the current isochronous cycle and avoid transmitting data for
> these channels
>     during this cycle (the transmission would cause a DUPLICATE CHANNEL
> DETECTED error).
>     This does not sound to my ears like being trivial (especially if there
> are DMA
>     contexts configured for multiple channel transmissions).
> 
> (*) It is not easy to share the bandwidth of a channel between many nodes.
>     Indeed, a node might not get the chance to transmit at all if some node
> closer
>     to the cycle master continuously transmits on the channel!!! That node
> would
>     always win isochronous arbitration first.
>     So there must be application logic involved in the whole story, for
> example a
>     logical token passed around the talkers so that each can speak in turn.
> This
>     involves extra programming complications (what will happen if the bus is
> split,
>     or if the token gets corrupted) in order to save bandwidth (for example
> 5 instances
>     of an application running on different nodes, that need to transmit at
> 10Mbps in
>     turn one after the other, can use only 10Mbps instead of allocating a
> total of
>     50Mbps and utilizing only 10 at a time).
> 
> 
>   Based on the contradicting references that I include above, I think that
> the issue
> deserves a clarification. Maybe it could be discussed at the P1394a working 
> group
> meeting.


[Jerry Hauck]  I actually do not find the references contradictory.  When 
referring to _isochronous_ streams, I belive all of the references cited above 
are consistent.  Only one isochronous talker per isochronous channel.  P1394a 
introduced the concept of _asynchronous_ streams.  These streams allow multiple 
talkers per channel.  Hardware is not at all impacted.  During the isochornous 
period, links transmit the isochronous stream packets as normal.  Higher layers 
ensure that the channel numbers are unique and the DUPLICATE_CHANNEL detection 
function can reveal if this is violated.  During the asynchronous interval, 
links can broadcast asynch stream packets which will have been assigned one or 
more channel numbers all of which are distinct from the isoch channel numbers.  
Multiple talkers are allowed on this distinct set of channels.




> 
> ---------------------------------------------------------------------------- 
> ------------
> (2) PROPOSAL: Broadcast Bus ID.
> 
>   I think that it would be a good idea if apart from 0x3FF (the local bus
> ID) another
>   bus ID is reserved for broadcasts that are intended not only for the local
> network,
>   but for all 1394 networks attached through 1394 bridges. These broadcasts
> would cross
>   1394 bridges and reach all nodes whatsoever.
> 
>   The reason why this would be a good idea is that this way a node can very
> easily
>   notify the whole 1394 world of significant events (the addition of a new
> printer, a
>   change in address -see also below-). Instead of having all nodes
> continuously poll
>   and cause significant traffic, the node in question can inform the world
> in one
>   transmission.
> 
> ---------------------------------------------------------------------------- 
> ------------
> (3) PROPOSAL: GUID to Physical ID map registers.
> 
>   The first activity that software will initiate after a bus reset is the
> discovery of
>   the new physical IDs that nodes have acquired. A driver that presents a
> handle based
>   API to an application will usually maintain some form of GUID-to-PhyID
> map. The
>   handle is opened based on the GUID, but the actual transmissions are made
> with the PhyID.
>   After a bus reset the driver will clear its GUID-to-PhyID map and try to
> reestablish
>   the mappings by reading the Bus_Info_Block of the nodes present on the
> bus.
>   This will cause significant traffic which can be avoided if we introduce
> the notion
>   of GUID-to-PhyID map registers.
> 
>   This will be a reserved area in the 1394 address space, of size 1023*63*64
> bits.
>   There will be one entry corresponding to each possible NodeID, for a total
> of
>   1023*63 entries. Each entry will be storing the EUI-64 of the node that
> currently
>   holds the specific NodeID.
>   This register map will be maintained at *all* nodes and can be possibly
> considered
>   write-only (although this only makes little difference).
>   After a bus reset each node clears its own register map, and broadcasts a
> write with
>   its EUI-64 to the entry corresponding to its new Physical ID. This way on
> a bus with
>   20 nodes there will be 20 broadcast writes and everybody's mappings would
> be updated.
> 
>   Using the current non-solution each node would have to read the other 19
> nodes' GUIDs
>   for a total of 19*19=361 reads and another 361 read responses, which is
> significantly
>   more than the 20 64-bit broadcast writes.
> 
>   Moreover, if a node is communicating with some node on a remote 1394
> network (the
>   driver would be obviously aware of that), it can broadcast the write using
> the
>   broadcast bus ID mentioned above, so that the other node(s) are
> immediately informed
>   of the address change without lost packets and timeouts.
>   A node on a remote network cannot be informed of the bus reset on the
> local network.
>   So apart from sending packets to a non-existent node, it could possibly
> send a few
>   transactions to another node before realising that it is talking to
> another node,
>   if at all! Things would be greatly simplified if the node would receive a
> packet
>   implying the new GUID-to-PhyID mapping.
> 
> 
> ---------------------------------------------------------------------------- 
> ------------
> (4) PROPOSAL: 2-Writes-Make-A-Read transaction.
> 
>   I recently read on an IEEE journal about the 2-Writes-Make-A-Read model
> for bus reads.
>   The author was saying the bus reads are a slow operation and could be
> replaced by two
>   writes as follows: the requester writes to some control registers the
> offset and amount
>   of data that it wants to read, and also a response buffer address. When
> the data is
>   ready the responder performs a write operation to the buffer address
> provided by the
>   requestor.
> 
>   Based on that we could introduce a similar transaction for asynchronous
> reads on the
>   1394 bus. The read is a packet containing source 1394 address, amount of
> data to read,
>   and destination 1394 address. The data will be returned as a normal write
> transaction
>   to this address.
> 
>   This could have great benefits, especially if coupled with the OHCI
> standard that
>   specifies that transactions in the low 4GB can be performed directly. The
> reader sets
>   up the response buffer at some available address in the low 4GB, and when
> the response
>   arrives (as a write transaction) it is directly written at the destination
> buffer
>   without any need for response mappings and buffer availability checks,
> ready
>   to provide to the application without redundant data copies from a random
> response
>   buffer to the application buffer (now the application buffer is set up as
> *the* response
>   buffer).


[Jerry Hauck] I think OHCI already supports this (more or less).  Most 
usage models for OHCI I envision don't have the host using many (if 
any) read requests.  Instead, peripheral devices (or other OHCI's) are 
programmed to push data into the Physical region of the local OHCI.  I 
think we can accomplish the efficiency and performance of your 
suggestion by ensuring that SBP-2, IP over 1394, etc. all use the 
concept of "bus-mastering" into OHCI.  As such, the Asynch Rx Response 
Queue will get very little usage in OHCI.


> 
>   But generally I think that such a model of operation would simplify the
> workings of
>   1394 at all levels, since there would only be one kind of transaction to
> deal with
>   (writes, either simple or locked).
> ---------------------------------------------------------------------------- 
> ------------
> (5) PROPOSAL: OHCI Physical Lower Bound Register.
> 
>   Mapping the low 4GB of a node's 1394 address space to the host's low 4GB
> of physical
>   memory is obviously a good idea but I think that it should be more
> strictly controlled,
>   apart from a simple filter that permits or prohibits a node from direct
> physical access.
> 
>   Even if the node is a fully trusted node, access to all of the host
> physical memory can
>   pause a serious security and stability threat.
> 
>   I would propose that the host controller can specify both the start and
> the end of the
>   address range where direct physical access is allowed, instead of having
> the lower bound
>   fixed at 48'h0 and only the upper bound specified in an optional register. 
>   This way the device driver running on a personal computer operating system
> can possibly
>   reserve a physical address range as needed by the applications and only
> allow access
>   to this range.
> 
>   Personally I would opt for several pairs of such registers to allow for
> maximum driver
>   flexibility but I can live with one :-)
> 
> ---------------------------------------------------------------------------- 
> ------------
> 
>   Well this is what I have to propose for discussion. May be these proposals
> should be
>   made directly to a working group meeting, but I think it's better to
> discuss them
>   here for a while first.
> 
>   I am looking forward to your responses.
> 
>   Sincerely Yours,
> 
> ============================================================================ 
> ============
> Dimitris Staikos
> dstaikos@unibrain.com (Business mail only please), 
> dstaikos@softlab.ntua.gr (Personal mail), ICQ UIN 169876 Top Jimmy 
> Software Systems & Applications Chief Engineer, UniBrain, 
> http://www.unibrain.com
> Diploma. El. & Computer Eng. National Technical University of Athens (NTUA)
> 
> http://www.ntua.gr
> ============================================================================ 
> ============
> After all is said and done, there is usually more said than done.
> Some make it happen, some watch it happen, and some say, "what happened?" 
> Each man with a new idea is a crank until the idea succeeds.
> Once the game is over, the king and the pawn go back into the same box.
> How a man plays a game shows something of his character, how he loses shows 
> all of it.
> ============================================================================ 
> ============

From ewa at apple.com  Tue Jan 20 12:53:31 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:47 2009
Subject: P1394> EMAIL I mentioned in 1/12 telecon
In-Reply-To: <P1394> EMAIL I mentioned in 1/12 telecon>
Message-ID: <B0EA249D-1D83D@17.216.20.63>

On Mon, Jan 19, 1998 10:59 PM, Greg Leclair wrote:


> For those on 1394 PWG reflector who haven't seen this yet.....
> 
> Should 1394 PWG profile require/recommend the feature set of 1394a?
> 
> Comments?


If you can find specific 1394a features that are absent in 1394-1995
that yield a meaningful cost reduction for devices using that profile,
then you could consider it.  Otherwise, I would avoid taking a stand.
1394-1995 and 1394a are supposed to be largely interoperable, so there's
no value to throwing that interoperability away for no reason.


Eric Anderson
Apple Computer, Inc.
ewa@apple.com

From lstein at fapo.com  Wed Jan 21 17:58:10 1998
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Meeting Charges
Message-ID: <Version.32.19980121145810.0101eca0@pop3.fapo.com>

Aloha All,


The meeting charge for the January PWG meetings will be $36.00 per person
per meeting day.  This includes the room rental, AV equipment, power
strips, food and beverage.


Hopefully, to make things easier, Warp Nine will process all the meeting
charges through our card service.  This way we don't have to have the hotel
involved at all.  Yes Don, we will provide receipts if requested.


Please print out this email, fill in the questions and bring it to the
meeting.  Checks made out to Warp Nine or cash made out to Larry is fine also.


Thanks,
Larry


________________________________________________________________


January PWG Meeting Charges


# of Meetings	Charge
1 day			$36
2 days			$72
3 days			$108
4 days			$144
5 days			$180


Name:


Company:


Phone Number:


Card Type:		Visa	MasterCard		American Express


Card number:


Expiration date:


Total Meeting Days: 


Total Meeting Charge:


Name on Card (if different):


Street address or PO box no. credit card is billed to:


Zip code credit card is billed to:


Receipt requested? 		Yes		No


Fax number for receipt:


Signature:
***************************************************************
Larry A. Stein			Phone: 	(619)292-2742
Warp Nine Engineering		Fax:	(619)292-8020
				Web: 	http://www.fapo.com
***************************************************************

From ohnishi at cbm.canon.co.jp  Thu Jan 22 03:52:14 1998
From: ohnishi at cbm.canon.co.jp (Ohnishi, Nobuhiro)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Posting announce: DPP 0.71
Message-ID: <199801220852.RAA25410@leo.cbm.canon.co.jp>

Dear PWG(p1394) members,


DPP 0.71 (Direct Print Protocol proposal) was updated to ver. 0.71 and was
approved at today's PWG-C SC meeting. (It will be introduced in PWG-Hawaii
meeting.)
You can get it by accessing the following URL.
ftp://ftp.tokyoweb.or.jp/pwgc1394/pub/proposals/sub-wg/DPPSpec071.PDF


Also, FDS 0.7 (which has been already approved in PWG-C)  is in the same
directory.
ftp://ftp.tokyoweb.or.jp/pwgc1394/pub/proposals/sub-wg/FDSprop07.pdf


Regards,
Nobuhiro Ohnishi
Canon Inc. (PWG-C web site administrator)

From fumiona at venus.dtinet.or.jp  Thu Jan 22 11:39:29 1998
From: fumiona at venus.dtinet.or.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:47 2009
Subject: P1394> 1394 PWG technical repot
Message-ID: <199801220852.RAA25410@leo.cbm.canon.co.jp>

------ =_NextPart_000_01BD279F.E0EC2E60
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit


Hi,


Please find an attached document which I summarized my points 
suggested through the telephone conference held in January 12.
My document is describing why we may use in order execution with
C.B.T. Actually I changed my opinion after the telephone conference.
Now I agree that we shall not enclose any 1284.4 header information
in CDB of a normal command block ORB. Also I would like to
suggest how a PWG profile supportive initiator manage in-ORBs, 
when reverse directional transaction is required.
Thank you,


 




--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


------ =_NextPart_000_01BD279F.E0EC2E60
Content-Type: application/pdf; name="PWG.98.1.26.a.PDF"
Content-Transfer-Encoding: base64


[encoded data, 26642 characters]
CiUlRU9GDQo=


------ =_NextPart_000_01BD279F.E0EC2E60--

From ewa at apple.com  Fri Jan 23 03:18:13 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Re: 1394 PWG Profile rev 0.1c
In-Reply-To: <1394 PWG Profile rev 0.1c>
Message-ID: <B0ED9248-20C846@17.219.104.32>

>      Here is the latest revision of the profile that we began
>      reviewing in LA.


I think I can clear up part of this issue:


> 11.1 Issues
> Microsoft has implemented their SBP-2 driver to do a login on
> powerup and not logout until the PC is shut down. Though this is
> provided for within the SBP-2 specification, it requires devices
> which may be shared among multiple PCs to support multiple logins
> to a single service, even if the service cannot be simultaneously
> used by the different PCs.
>
> Can imaging devices (which want to take advantage of the shared
> nature of 1394) tolerate the resource requirements to operate on
> a multiple Microsoft O/S host configuration?


I spoke with Microsoft about this.  The explanation is that their
SBP-2 driver at present only works with disk drives.  (More
precisely, it is only designed to support disk drives)  Windows
is not designed to share disk drives on 1394, so the login is
automatic.  This will make life difficult for users with multiple
Windows machines and at least one disk on their 1394 bus.


I guess if you hot-plug a disk drive and the "wrong" Windows
machine logs in to it first, you can just unplug the disk, wait
2 seconds for a login timeout, and then try again.  That should
be lots of fun.


But, Microsoft says that their treatment of printers will be
different.  They will only login to printers and other shared
devices when they actually want to use the printer.  So a printer
with only one login could be shared by several Windows systems.
Apple plans to do the same thing for printers using SBP-2.


It is unfortunate that nobody from Microsoft seems to want to
participate in this discussion.  You can write to them at
1394@microsoft.com if you have questions.


Eric Anderson
FireWire Software
Apple Computer, Inc.
ewa@apple.com
408-974-8187

From gleclair at agentz.com  Sat Jan 24 15:04:54 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Will not make the meeting
Message-ID: <B0ED9248-20C846@17.219.104.32>

Don't expect me in Maui tonight. I've called and cancelled my reservations. I got 
pretty sick last night and doctor's advice is to stay put.


Following was my idea for the meeting agenda. Other topics or presentations, 
please forward to the list.


Mon. 1/26
	- 1394 PWG 1 Year Review
	- PWG-C Status
	- Direct Print Protocol Presentation - Nob Shinoda
	- 1212r FDS Discussion / Q&A as applied to DPP / and 1394 PWG - Ats Nakamura
	- Imaging Profile Spec read-through - Alan Berkema
	
Tues. 1/27
	- Imaging Profile Spec Discussion - Alan Berkema & Greg Shue
	- Other Topics
	- 1394 PWG Plan


Wed. 1/28
	- Status report to PWG


FYI - Attendees who wanted to attend 1394 TA requested time on Monday for 
        presenting DPP. I've asked Ats to do a summary of 1212r - FDS.

From brianb at vcd.hp.com  Fri Jan 23 11:51:06 1998
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:47 2009
Subject: P1394> EMAIL I mentioned in 1/12 telecon
In-Reply-To: <B0EA249D-1D83D@17.216.20.63>
Message-ID: <3.0.3.32.19980123085106.00953220@popmail1.vcd.hp.com>

>On Mon, Jan 19, 1998 10:59 PM, Greg Leclair wrote:
>
>> For those on 1394 PWG reflector who haven't seen this yet.....
>> 
>> Should 1394 PWG profile require/recommend the feature set of 1394a?
>> 
>> Comments?


At 09:53 AM 1/20/98 -0800, Eric Anderson wrote:
>If you can find specific 1394a features that are absent in 1394-1995
>that yield a meaningful cost reduction for devices using that profile,
>then you could consider it.  Otherwise, I would avoid taking a stand.
>1394-1995 and 1394a are supposed to be largely interoperable, so there's
>no value to throwing that interoperability away for no reason.


I agree with Eric, but for a slightly different reason.  Companies may wish
to implement 1394PWG-compliant devices before 1394a silicon becomes
available.  So, unless there is some really compelling feature in 1394a, I
suggest we allow 1394-1995, 1394a and 1394b implementations to be compliant.


Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227

From brianb at vcd.hp.com  Fri Jan 23 12:12:11 1998
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Re: 1394 PWG Profile rev 0.1c & SBP-2 Logins
In-Reply-To: <B0ED9248-20C846@17.219.104.32>
Message-ID: <3.0.3.32.19980123091211.00920720@popmail1.vcd.hp.com>

At 12:18 AM 1/23/98 -0800, Eric Anderson wrote:
>>      Here is the latest revision of the profile that we began
>>      reviewing in LA.
>
>I think I can clear up part of this issue:
>
>> 11.1 Issues
>> Microsoft has implemented their SBP-2 driver to do a login on
>> powerup and not logout until the PC is shut down. Though this is
>> provided for within the SBP-2 specification, it requires devices
>> which may be shared among multiple PCs to support multiple logins
>> to a single service, even if the service cannot be simultaneously
>> used by the different PCs.
>>
>> Can imaging devices (which want to take advantage of the shared
>> nature of 1394) tolerate the resource requirements to operate on
>> a multiple Microsoft O/S host configuration?
>
>I spoke with Microsoft about this.  The explanation is that their
>SBP-2 driver at present only works with disk drives.  (More
>precisely, it is only designed to support disk drives)  Windows
>is not designed to share disk drives on 1394, so the login is
>automatic.  This will make life difficult for users with multiple
>Windows machines and at least one disk on their 1394 bus.


Do disk drives support multiple logins?  Even if they do, there would
certainly be some sort of limit which would eventually be hit.


>I guess if you hot-plug a disk drive and the "wrong" Windows
>machine logs in to it first, you can just unplug the disk, wait
>2 seconds for a login timeout, and then try again.  That should
>be lots of fun.


Yup.  I think a lot of us have convinced ourselves that "networking" would
be quite prevalent on 1394 busses, as 1394 will be "free" on new PCs and
TCP/IP will be available in the O/S.  However, if you can't boot up more
than one PC per bus, you'll have a pretty boring network!


>But, Microsoft says that their treatment of printers will be
>different.  They will only login to printers and other shared
>devices when they actually want to use the printer.  So a printer
>with only one login could be shared by several Windows systems.
>Apple plans to do the same thing for printers using SBP-2.


Will they logout after printing?  I think printer manufacturers will have
to assume that not all devices will logout, meaning that printers targeted
at anything other than a point-to-point environment will have to support
more than one login.  I don't understand the resources required for each
login.  We need to do that analysis before deciding upon a multi-login
model for printing.


>It is unfortunate that nobody from Microsoft seems to want to
>participate in this discussion.  You can write to them at
>1394@microsoft.com if you have questions.
>
>Eric Anderson
>FireWire Software
>Apple Computer, Inc.
>ewa@apple.com
>408-974-8187
>
>
>
>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227

From carterk at us.ibm.com  Mon Feb  2 12:37:18 1998
From: carterk at us.ibm.com (Keith Carter)
Date: Wed May  6 14:00:47 2009
Subject: P1394> PWG meeting in Austin on 3/2-6
Message-ID: <3.0.3.32.19980123091211.00920720@popmail1.vcd.hp.com>

Print gurus,


I'll be the host for the PWG meeting in Austin, Texas on 3/2-6.  Here's the
scoop and a request for your "ping" to me by 3:00PM CST on Tuesday, 2/10.


HOTEL INFORMATION


Hyatt Regency Austin (located on Town Lake in downtown Austin).
Phone: 512-477-1234
$101 per night (single occupancy).
Meeting room charge will be based on meeting attendance per day (see PING
INFORMATION)
Cab fare from airport is $12-14.
Cab fare to the Sixth Street entertainment area is $4-5 (or a hike of 9-10
blocks for the athletically inclined).
Restaurants within 1 block of the hotel include: Threadgills (famous for their
home style cookin'), Jalisco's (Tex Mex), Hooters (burgers and more...), Al
Capone's (Italian), Bennigan's (bar and grill) and Aussie's (bar and grill).
The Hyatt also has a very good restaurant.  Chuy's (Tex Mex and cool t-shirts)
and other restaurants are within a short drive of the hotel.
For you olympians, there is a public jogging trail that goes by the hotel and
around the lake.


PWG MEETING AGENDA


Here is the agenda proposed by Don Wright:


Monday (3/2), Tuesday (3/3):
  -- 1394 Printing
Wednesday (3/4) AM:
  -- PWG overview session
  -- Discussion on NC Printing
Wednesday (3/4) PM:
  -- IPP
Thursday (3/5):
  -- IPP
Friday (3/6):
  -- Finisher
  -- Job MIB Traps


Please address any questions on the PWG agenda to Don Wright.  Please address
any questions on a working group agenda to the working group chair.


PING INFORMATION


Please send pings to me by 3:00PM CST on Tuesday, 2/10 with the following
information:


1)  What meeting dates will you attend?
2)  Will you stay at the Hyatt hotel?
3)  If you are staying at the Hyatt, what are your arrival and departure dates?


On 2/11, I'll provide the information to the hotel, distribute a list of
attendees to the PWG distribution lists, and provide you with the meeting room
costs per day.  On 2/12 you may start making your reservations at the Hyatt
hotel under the name "Printer Working Group".


Have a super day,


Keith Carter
Senior Software Engineer
IBM Network Computing Software Division in Austin, Texas
internet email: carterk@us.ibm.com
Notes email: Keith Carter/Austin/IBM@IBMUS
phone: 512-838-2155
tie-line: 678-2155
fax: 512-838-0169

From mark at mtesoft.com  Tue Feb  3 00:08:59 1998
From: mark at mtesoft.com (Mark T. Edmead)
Date: Wed May  6 14:00:47 2009
Subject: P1394> RE: PWG> PWG meeting in Austin on 3/2-6
Message-ID: <3.0.3.32.19980123091211.00920720@popmail1.vcd.hp.com>

Keith:


I will be attending.


1)  What meeting dates will you attend?


3-2 and 3-3


2)  Will you stay at the Hyatt hotel?


Yes


3)  If you are staying at the Hyatt, what are your arrival and departure dates?


Probably arrive the day before and leave the day after.


Regards,


Mark Edmead




****************************************************************
Mark T. Edmead
MTE Software, Inc.
Microsoft Windows Systems Design and Engineering Consultants
Microsoft Certified Solution Providers
3645 Ruffin Road, Suite 350
San Diego, CA 92123
(619) 292-2050
(619) 292-5977 FAX
http://www.mtesoft.com
e-mail: mark@mtesoft.com   
*********************************************************
            _\^|^/_
             (o  o)
 --o0O0----(_)----0O0o--






On Monday, February 02, 1998 9:37 AM, Keith Carter [SMTP:carterk@us.ibm.com] wrote:
> Print gurus,
> 
> I'll be the host for the PWG meeting in Austin, Texas on 3/2-6.  Here's the
> scoop and a request for your "ping" to me by 3:00PM CST on Tuesday, 2/10.
> 
> HOTEL INFORMATION
> 
> Hyatt Regency Austin (located on Town Lake in downtown Austin).
> Phone: 512-477-1234
> $101 per night (single occupancy).
> Meeting room charge will be based on meeting attendance per day (see PING
> INFORMATION)
> Cab fare from airport is $12-14.
> Cab fare to the Sixth Street entertainment area is $4-5 (or a hike of 9-10
> blocks for the athletically inclined).
> Restaurants within 1 block of the hotel include: Threadgills (famous for their
> home style cookin'), Jalisco's (Tex Mex), Hooters (burgers and more...), Al
> Capone's (Italian), Bennigan's (bar and grill) and Aussie's (bar and grill).
> The Hyatt also has a very good restaurant.  Chuy's (Tex Mex and cool t-shirts)
> and other restaurants are within a short drive of the hotel.
> For you olympians, there is a public jogging trail that goes by the hotel and
> around the lake.
> 
> PWG MEETING AGENDA
> 
> Here is the agenda proposed by Don Wright:
> 
> Monday (3/2), Tuesday (3/3):
>   -- 1394 Printing
> Wednesday (3/4) AM:
>   -- PWG overview session
>   -- Discussion on NC Printing
> Wednesday (3/4) PM:
>   -- IPP
> Thursday (3/5):
>   -- IPP
> Friday (3/6):
>   -- Finisher
>   -- Job MIB Traps
> 
> Please address any questions on the PWG agenda to Don Wright.  Please address
> any questions on a working group agenda to the working group chair.
> 
> PING INFORMATION
> 
> Please send pings to me by 3:00PM CST on Tuesday, 2/10 with the following
> information:
> 
> 1)  What meeting dates will you attend?
> 2)  Will you stay at the Hyatt hotel?
> 3)  If you are staying at the Hyatt, what are your arrival and departure dates?
> 
> On 2/11, I'll provide the information to the hotel, distribute a list of
> attendees to the PWG distribution lists, and provide you with the meeting room
> costs per day.  On 2/12 you may start making your reservations at the Hyatt
> hotel under the name "Printer Working Group".
> 
> Have a super day,
> 
> Keith Carter
> Senior Software Engineer
> IBM Network Computing Software Division in Austin, Texas
> internet email: carterk@us.ibm.com
> Notes email: Keith Carter/Austin/IBM@IBMUS
> phone: 512-838-2155
> tie-line: 678-2155
> fax: 512-838-0169

From lstein at fapo.com  Tue Feb  3 18:17:00 1998
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Maui Meeting Charges
Message-ID: <Version.32.19980203150950.0102f2c0@pop3.fapo.com>

Aloha Howlies,


I hope that everyone had a productive meeting last week.  I am in the
process of getting all the charges completed.  


Due to some no shows, some mis-understandings on attendance, and extra
charges, the per day meeting charge will be $38.00.  In addition, the
1393PWG meetings had extra meal and group charges.  These will all be
stated on the receipts.  If you requested a faxed receipt to an
international number, there will be a $2.00 charge.


Sorry for being picky about this but when you multiply the little things by
40 or so, they start to add up.


We should have all the receipts done by the end of the week.


Mahalo,


Larry 
***************************************************************
Larry A. Stein			Phone: 	(619)292-2742
Warp Nine Engineering		Fax:	(619)292-8020
				Web: 	http://www.fapo.com
***************************************************************

From gregs at sdd.hp.com  Fri Feb  6 17:04:06 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <199802062204.OAA12531@hpsdlgj1.sdd.hp.com>

Hi all,


At the January 98 PWG 1394 meeting, I mentioned that Technology
Rendezvous Inc.  was prototyping the IP1394 solution, and had
already developed SBP-2 target and initiator modules.  (FYI, I've
appended the announcement that I was forwarded to the bottom of
this message.)


I approached them about sharing some rough estimates of code size
for the IP1394 glue, SBP-2 target and initiator, and 1394 bus
manager modules to get a feel for how "heavy" the protocol
implementations really are.  They graciously shared the flowing
estimates with us, and certainly deserve our thanks.  Since the
technology is still being developed, these implementations are
certainly going to be tuned and the numbers will change a little
bit.


  Component                Rough ROM size (KBytes)
  ---------                -----------------------
  SBP-2 initiator core     15 +/- 5
  SBP-2 target core        15 +/- 5  (incl. Mgmt+Fetch agent, no exec agent)
  IP1394 glue layer        15 +/- 5  (curr proto impl., not quite fully func)
  OS supplied TCP/IP stack 50 -> 100 (depends on other stack components incl.)


  Serial Bus Mgr           12 -> 15


  Tailgate core            12 +/- 3


  Link Ctlr driver cores   12 -> 18






>Hi,
>
>Technology Rendezvous Inc. would like to join the interoperability
>test event.
>TRI has IP1394 implementations and will be interested in
>interoperability testing with other vendors. Our focus has been
>embedded peripheral systems.
>
>TRI has IP1394 implementation running under VxWorks and PSOS
>TCP/IP stacks with following features:
>  - NETWORK_CHANNELS register implementation
>  - IP unicast
>  - ARP
>  - Fragmentation and Reassembly
>  - IP broadcast with the following exceptions
>    Since, we have this implementation on 1394-1995 chipsets
>    the IP1394 implementation supports broadcast using
>    IEEE 1394-1995 broadcast mechanism OR  using redirect
>    mechanism ( Where all nodes send the broadcast packets to the
>    active NPM which redirects these packet on ISOCHRONOUS channel )
>    as posted by TRI (Srinivasa Addepalli) on IP1394 WG a while ago.
>    Also the broadcast machinist is configurable.
>
>If future we will support implementation for the following:
>   - IP multicast
>   - Isochronous IP unicast
>
>The above implementations and NPM mechanism are currently being
>tested.
>
>/*** About TRI ***/
>Technology Rendezvous Inc. is a leading supplier of embedded
>system solutions. TRI provides a well layered and portable
>IEEE-1394 software for peripheral and embedded systems. The
>software stack supports both Isochronous & Asynchronous data
>transfers and various protocols including SBP-2 target, SBP-2
>initiator, SBP-2 with MSP, SBP-2 with printer profile and
>IP over 1394. The software stack has been designed to work with
>or without an operating system and hence it is very suitable for
>deeply embedded systems. The stack supports TI and IBM link
>Controllers and the Hardware adaptation layer (HAL) of the stack
>can be changed to support other 1394 Link Controllers.
>TRI also provides IEEE-1394 link layer core and FPGA based test
>and development environment as a complete system solution.
>Please visit TRI website at http://www.trinc.com or call me
>at 408-566-0280 x:201 for more information.
>
>-Sathyan
>
>
>/*****************************************************************
>One-Stop Solution house for your PCMCIA, FLASH, 1394 needs **/
>Technology Rendezvous Inc.             Ph  : 408-566-0280 Ext:201
>3160, De La Cruz Blvd.                 Fax : 408-566-0284
>Suite #101, Santa Clara                e-mail:  sathyan@trinc.com
>CA - 95054,  USA                       http://www.trinc.com
>*****************************************************************/





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


From carterk at us.ibm.com  Mon Feb  9 09:27:25 1998
From: carterk at us.ibm.com (Keith Carter)
Date: Wed May  6 14:00:47 2009
Subject: P1394> A friendly reminder to "ping" for the PWG meeting in Austin
Message-ID: <199802062204.OAA12531@hpsdlgj1.sdd.hp.com>

Here's a friendly reminder.  Please send me a "ping" by 3:00PM CST on Tuesday,
2/10 for the PWG meeting in Austin, Texas on 3/2-6.  Attached is my original
note with the information and request.  To date, only 10 people have sent me a
"ping".


Thanks,


Keith Carter
Senior Software Engineer
IBM Network Computing Software Division in Austin, Texas
internet email: carterk@us.ibm.com
Notes email: Keith Carter/Austin/IBM@IBMUS
phone: 512-838-2155
tie-line: 678-2155
fax: 512-838-0169


---------------------- Forwarded by Keith Carter/Austin/IBM on 02-09-98 08:23 AM
 ---------------------------




Keith Carter
02-02-98 11:29 AM


To: ipp@pwg.org@internet, jmp@pwg.org@internet, fin@pwg.org@internet,
pwg@pwg.org@internet, p1394@pwg.org@internet
cc:
From: Keith Carter/Austin/IBM @ IBMUS
Subject: PWG meeting in Austin on 3/2-6


Print gurus,


I'll be the host for the PWG meeting in Austin, Texas on 3/2-6.  Here's the
scoop and a request for your "ping" to me by 3:00PM CST on Tuesday, 2/10.


HOTEL INFORMATION


Hyatt Regency Austin (located on Town Lake in downtown Austin).
Phone: 512-477-1234
$101 per night (single occupancy).
Meeting room charge will be based on meeting attendance per day (see PING
INFORMATION)
Cab fare from airport is $12-14.
Cab fare to the Sixth Street entertainment area is $4-5 (or a hike of 9-10
blocks for the athletically inclined).
Restaurants within 1 block of the hotel include: Threadgills (famous for their
home style cookin'), Jalisco's (Tex Mex), Hooters (burgers and more...), Al
Capone's (Italian), Bennigan's (bar and grill) and Aussie's (bar and grill).
The Hyatt also has a very good restaurant.  Chuy's (Tex Mex and cool t-shirts)
and other restaurants are within a short drive of the hotel.
For you olympians, there is a public jogging trail that goes by the hotel and
around the lake.


PWG MEETING AGENDA


Here is the agenda proposed by Don Wright:


Monday (3/2), Tuesday (3/3):
  -- 1394 Printing
Wednesday (3/4) AM:
  -- PWG overview session
  -- Discussion on NC Printing
Wednesday (3/4) PM:
  -- IPP
Thursday (3/5):
  -- IPP
Friday (3/6):
  -- Finisher
  -- Job MIB Traps


Please address any questions on the PWG agenda to Don Wright.  Please address
any questions on a working group agenda to the working group chair.


PING INFORMATION


Please send pings to me by 3:00PM CST on Tuesday, 2/10 with the following
information:


1)  What meeting dates will you attend?
2)  Will you stay at the Hyatt hotel?
3)  If you are staying at the Hyatt, what are your arrival and departure dates?


On 2/11, I'll provide the information to the hotel, distribute a list of
attendees to the PWG distribution lists, and provide you with the meeting room
costs per day.  On 2/12 you may start making your reservations at the Hyatt
hotel under the name "Printer Working Group".


Have a super day,


Keith Carter
Senior Software Engineer
IBM Network Computing Software Division in Austin, Texas
internet email: carterk@us.ibm.com
Notes email: Keith Carter/Austin/IBM@IBMUS
phone: 512-838-2155
tie-line: 678-2155
fax: 512-838-0169

From lstein at fapo.com  Mon Feb  9 11:26:13 1998
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:47 2009
Subject: P1394> County Line
Message-ID: <199802091629.IAA22712@barley.adnc.com>

Austin meeting, County Line BBQ, Monday night.


How many?


-Larry
***************************************************************
Larry A. Stein			Phone: 	(619)292-2742
Warp Nine Engineering		Fax:	(619)292-8020
				Web: 	http://www.fapo.com
***************************************************************

From lstein at fapo.com  Mon Feb  9 11:25:11 1998
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:47 2009
Subject: P1394> 1284.4 over SBP-2
Message-ID: <199802091629.IAA22710@barley.adnc.com>

Hello Everyone,


I'm sending this message to see if we can stimulate some discussion on this
subject prior to the 1394PWG meeting in Austin next month.


For the past year we have been meeting to develop a standard to provide the
high functionality transport method for printing over the IEEE 1394
interface.  This is 'high functionality' , or 'thick' transport, as opposed
to the 'thin' transport that is being developed by the PWG-C.  The
direction that our group has taken has involved reviewing FCP, DFA, SBP-2,
and others, as the lower transport and datalink interface, with something
else as the transport interface.  This something else has focused on 1284.4
or on a native 'glue' layer to the underlying datalink.


At this point in time we have apparently narrowed our potential solutions
to the following:


A- 1284.4 with SBP-2
B-  New SBP-2 command set with SBP-2


As many of you are aware, I'm primarily in support of option A as the
preferred solution.  I'd like to take this opportunity to provide some of
my reasoning and get feedback from you.


My support for this solution is not necessarily a technical reason, but a
market reason.  As Greg Shue et al pointed out at the Maui meeting, it is
possible to provide the required functionality by defining a new Command
Set for SBP-2.  This would provide a transport solution for 1394 that is
based solely on the SBP-2 protocol.  Technically, this is probably a better
solution than option A.


My question is "Is this really the best solution for the market today?".
Many of us have expended great effort in developing the IEEE P1284.4
standard.  One of the purposes and goals of  the development was to create
a datalink independent transport standard that could be used over the
parallel port and other physical interfaces.


The intent here was to create a standard that would allow a peripheral to
operate over various interfaces without requiring major architectural
changes to the product.  In other words, a modular approach to the
peripheral design.  A printer or MFP device could be developed to work with
1284.4 over parallel today, and 'easily' adapted to work over 1394
tomorrow.  The host application interface may not even know the difference.


I think that this is the primary reasons for choosing option A.  It sends a
clear statement to peripheral and OS vendors that 1284.4 is the preferred
transport interface for printer and MFP peripherals.  We back this up by
providing solutions for parallel (1284.3) and for 1394.  This is not a
stagnant industry and certainly new interfaces will appear in the future.
I think it would be a great service that we provide a clear migration path
between interfaces that do not require redesign of the entire system.


Providing both options may be the result of this effort.  I think that
option A should be the preferred one.


I await your responses.


Thanks,
Larry




***************************************************************
Larry A. Stein			Phone: 	(619)292-2742
Warp Nine Engineering		Fax:	(619)292-8020
				Web: 	http://www.fapo.com
***************************************************************

From carterk at us.ibm.com  Mon Feb  9 14:06:24 1998
From: carterk at us.ibm.com (Keith Carter)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Getting the $101 rate at the Hyatt hotel for the PWG meeting
Message-ID: <199802091629.IAA22710@barley.adnc.com>

Per my original note, you may make reservations under "PWG" at the Hyatt hotel
for the rate of $101/night starting on Thursday 2/12.  The Hyatt hotel won't
lock in the rate until I give them a list of people with arrival and departure
dates.  Thus, my request of everyone to "ping" me by 3:00PM CST on 2/10 so I
can send this information to the Hyatt on 2/11.  The hotel will then open
reservations under "PWG" at $101/night on 2/12.  Anyone who makes reservations
at a higher rate before 2/12 should notify me because the Hyatt will lower
their rate to $101 if I inform them to do so on 2/11.  The Hyatt hotel is
holding 25 rooms per night for the PWG through 2/11 but they require names to
reserve these rooms so please ping soon!  To date, I have received 14 pings.


Have a super day,


Keith Carter
Senior Software Engineer
IBM Network Computing Software Division in Austin, Texas
internet email: carterk@us.ibm.com
Notes email: Keith Carter/Austin/IBM@IBMUS
phone: 512-838-2155
tie-line: 678-2155
fax: 512-838-0169

From brianb at vcd.hp.com  Mon Feb  9 12:36:52 1998
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
In-Reply-To: <199802062204.OAA12531@hpsdlgj1.sdd.hp.com>
Message-ID: <3.0.3.32.19980209093652.00920670@popmail1.vcd.hp.com>

At 02:04 PM 2/6/98 -0800, Greg Shue wrote:


[snip]


>I approached them about sharing some rough estimates of code size
>for the IP1394 glue, SBP-2 target and initiator, and 1394 bus
>manager modules to get a feel for how "heavy" the protocol
>implementations really are.  They graciously shared the flowing
>estimates with us, and certainly deserve our thanks.  Since the
>technology is still being developed, these implementations are
>certainly going to be tuned and the numbers will change a little
>bit.
>
>  Component                Rough ROM size (KBytes)
>  ---------                -----------------------
>  SBP-2 initiator core     15 +/- 5
>  SBP-2 target core        15 +/- 5  (incl. Mgmt+Fetch agent, no exec agent)


Any idea how big a combined SBP-2 target/initiator would be?  15-30K? ;-)


[snip]


Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227

From mark at mtesoft.com  Mon Feb  9 14:43:14 1998
From: mark at mtesoft.com (Mark T. Edmead)
Date: Wed May  6 14:00:47 2009
Subject: P1394> RE: PWG> Getting the $101 rate at the Hyatt hotel for the PWG meeting
Message-ID: <3.0.3.32.19980209093652.00920670@popmail1.vcd.hp.com>

Keith:


Yes, I already made reservervations for myself and Larry Stein at the 
higher rate. If you could inform Hyatt when you call them that would be 
great.  Like I said earlier, I will be out of the country for a while, this 
is why I made the reservations so early.


Thanks!


Mark


-----Original Message-----
From:	Keith Carter [SMTP:carterk@us.ibm.com]
Sent:	Monday, February 09, 1998 11:06 AM
To:	p1394@pwg.org; pwg@pwg.org; fin@pwg.org; jmp@pwg.org; ipp@pwg.org
Subject:	PWG> Getting the $101 rate at the Hyatt hotel for the PWG meeting


Per my original note, you may make reservations under "PWG" at the Hyatt 
hotel
for the rate of $101/night starting on Thursday 2/12.  The Hyatt hotel 
won't
lock in the rate until I give them a list of people with arrival and 
departure
dates.  Thus, my request of everyone to "ping" me by 3:00PM CST on 2/10 so 
I
can send this information to the Hyatt on 2/11.  The hotel will then open
reservations under "PWG" at $101/night on 2/12.  Anyone who makes 
reservations
at a higher rate before 2/12 should notify me because the Hyatt will lower
their rate to $101 if I inform them to do so on 2/11.  The Hyatt hotel is
holding 25 rooms per night for the PWG through 2/11 but they require names 
to
reserve these rooms so please ping soon!  To date, I have received 14 
pings.


Have a super day,


Keith Carter
Senior Software Engineer
IBM Network Computing Software Division in Austin, Texas
internet email: carterk@us.ibm.com
Notes email: Keith Carter/Austin/IBM@IBMUS
phone: 512-838-2155
tie-line: 678-2155
fax: 512-838-0169

From rturner at sharplabs.com  Mon Feb  9 15:02:43 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <3.0.3.32.19980209093652.00920670@popmail1.vcd.hp.com>

I am very interested in the combined target/initiator footprint as well.


Thx


Randy




	-----Original Message-----
	From:	Brian Batchelder [SMTP:brianb@vcd.hp.com]
	Sent:	Monday, February 09, 1998 9:37 AM
	To:	p1394@pwg.org
	Subject:	Re: P1394> Rough SBP-2 & IP1394 core component
ROM sizes


	At 02:04 PM 2/6/98 -0800, Greg Shue wrote:


	[snip]


	>I approached them about sharing some rough estimates of code
size
	>for the IP1394 glue, SBP-2 target and initiator, and 1394 bus
	>manager modules to get a feel for how "heavy" the protocol
	>implementations really are.  They graciously shared the flowing
	>estimates with us, and certainly deserve our thanks.  Since the
	>technology is still being developed, these implementations are
	>certainly going to be tuned and the numbers will change a
little
	>bit.
	>
	>  Component                Rough ROM size (KBytes)
	>  ---------                -----------------------
	>  SBP-2 initiator core     15 +/- 5
	>  SBP-2 target core        15 +/- 5  (incl. Mgmt+Fetch agent,
no exec agent)


	Any idea how big a combined SBP-2 target/initiator would be?
15-30K? ;-)


	[snip]


	Brian


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	Brian Batchelder      | Hewlett-Packard      |
mailto:brianb@vcd.hp.com  
	Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360)
212-4107  
	DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360)
212-4227

From brianb at vcd.hp.com  Mon Feb  9 17:25:52 1998
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Announcement of Off-Cycle AV WG meeting in March
Message-ID: <3.0.3.32.19980209142552.00884a50@popmail1.vcd.hp.com>

--=====================_887091952==_
Content-Type: text/plain; charset="us-ascii"


Is anyone going to this?  It would be nice to have participation in the
AV/C printing discussion from the 1394PWG.


Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


>Date: Thu, 05 Feb 1998 19:52:30 +0900
>To: 1394-av@1394TA.org, 1394-dsi@1394TA.org
>From: Harumi Kawamura <harumi@arch.sony.co.jp>
>Subject: Announcement of Off-Cycle AV WG meeting in March
>Cc: lammers@fb.sony.de
>Sender: <1394-DSI@1394TA.org>
>Precedence: Bulk
>
>Hi People
>
>I would like to give notice of the off-cycle AV WG meeting on March 16-18.
>
>The tentative agenda:
>1) Tuner (updates of the document, profiles discussion, etc.)
>2) Resource sharing (RESERVE command, stream locking, bandwidth management,
>etc.)
>3) Disc (updates of the document) and Changer
>4) Human I/F command (on screen display, remote control command, etc.)
>5) AV/C printing (the general asynchronous data transfer using AV/C)
>
>We will discuss 5) as a joint meeting with PWG-C SWG2.
>
>We hope many people join this meeting. Please note that each attendee must
>send the registration form to Nathalie Lammers AND the hotel by February 10.
>
>See you in Stuttgart!
>
>Harumi
>
>> X-UIDL: 886381283.012
>> Subject: Announcement of Off-Cycle AV WG meeting in March
>> Date: Fri, 30 Jan 98 22:13:33 -0800
>> X-Sender: aaronl@newt.lsi.sel.sony.com
>> X-Mailer: Claris Emailer 2.0v2, June 6, 1997
>> From: Aaron Ludtke <aaronl@lsi.sel.sony.com>
>> To: "1394 AV group" <1394-av@1394TA.org>
>> Sender: <1394-AV@1394TA.org>
>> 
>> Hi People,
>> 
>> As announced at the January 1998 AV Working Group meeting, we will hold 
>> an off-cycle AV WG meeting in March immediately before Cebit. The 
>> information is as follows:
>> 
>> What: Off-cycle AV WG meeting to discuss the AV/C Disc model & command 
>> set, the AV/C Tuner model and command set (updates of the document, 
>> remaining issues such as resource management and profile definitions, 
>> etc.), and possibly other very important topics.
>> 
>> When: March 16-18, 1998
>> 
>> Where: Stuttgart, Germany
>> 
>> Details:
>> 
>> We have a block reservation of 25 rooms, for
>> 
>> Check IN:  15 March
>> Check out: 19 March
>> 
>> Room rate: 199,- DM; breakfast: DM 28.-
>> 
>> Each attendee  is requested to make his own arrangement at the Hotel
>> Copthorne Stuttgart International  by indicating the Code Word:
>> "SONY/1394 TA AV Meeting" by  
>> 
>> 10 FEBRUARY 1998 at the latest!
>> 
>> Tel: + 49 711 721 1050
>> Fax: + 49 711 721 2931
>> 
>> Please note that you have to mention your credit card 
>> number when reserving the hotel room in order to guarantee late 
>> arrival.
>> 
>> Attached to this message is a special sheet which MUST be filled out and 
>> sent to the 
>> hotel with a copy to the person who is making the arrangements for us 
>> (Nathalie Lammers of Sony)
>> 
>> (Fax: + 49 711 5858-199, E-Mail: lammers@fb.sony.de)
>> 
>> The sheet is a PDF file, uuencoded.
>> 
>> PLEASE NOTE THE FOLLOWING FEES FOR THE MEETING:
>> The conference fee for every participant (even when he intends to attend
>> only one day) will be:
>> 
>> DM 240 
>> 
>> The only accepted currency will be German marks due to administrative
>> reasons. The fee includes food, meeting room rental, etc.
>> 
>> 
>> Those participants who are planning to visit CeBIT Fair
>> in Hannover, please consider the following flight schedule:
>> 
>> 19. March:
>> 
>> 1) STR - HAN: 06.35 - 07.35 LH 115
>> 2) STR - HAN: 10.00 - 11.15 EW 730
>> 3) STR - HAN: 10.50 - 11.50 LH 1057
>> 
>> 18. March:
>> 
>> 1.) STR - HAN: 18.10 - 19.10 LH 1059
>> 2.) STR - HAN: 18.35 - 19.35 LH 1129
>> 
>> Currently, availability is good and there are still
>> enough seats!
>> 
>> There is also a very good train connection from
>> Stuttgart to Hanover by the ICE train. The train stops in front
>> of the CeBIT entrance and takes about 3.5 hours. 
>> 
>> 19 March
>> Stuttgart station to Hanover Laatzen(CeBIT) : 
>> 1) 06.51 - 10.36 by ICE 
>> 2) 07.27- 10.36 by ICE
>> 
>> Price of a one way ticket: DM 271,-
>> 
>> 
>> If you intend to participate in the off-cycle WG meeting, please make 
>> sure to meet the February 10 deadline for hotel reservation. Remember, 
>> Cebit causes logisitical problems in a very large geographic area, so 
>> time is important!
>> 
>> 
>> Thanks very much,
>> 
>> Aaron Ludtke
>> AV WG secretary
>> $BWl%&$5$l$?E:IU%U%!%$%k!'(J"c:\program
files\eudora\attach\Mar98Invite1.pdf"
>
>
>
--=====================_887091952==_
Content-Type: application/pdf; name="Mar98Inv.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Mar98Inv.pdf"


[encoded data, 65669 characters]
--=====================_887091952==_--

From gregs at sdd.hp.com  Mon Feb  9 17:56:17 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
In-Reply-To: <D10983CAC30DD111B41400805FA6A1C12722EE@admsrvnt02.enet.sharplabs.com>
Message-ID: <199802092256.OAA18947@hpsdlgj1.sdd.hp.com>

My guess is that the combined footprint would be exactly the sum
of the SBP-2 initiator and SBP-2 target footprints.  I can't figure
out any parts which would be shared, since the Bus Mgr and Link controller
code have already been extracted and would be common.


Greg Shue


> 
> 
> I am very interested in the combined target/initiator footprint as well.
> 
> Thx
> 
> Randy
> 
> 
> 	-----Original Message-----
> 	From:	Brian Batchelder [SMTP:brianb@vcd.hp.com]
> 	Sent:	Monday, February 09, 1998 9:37 AM
> 	To:	p1394@pwg.org
> 	Subject:	Re: P1394> Rough SBP-2 & IP1394 core component
> ROM sizes
> 
> 	At 02:04 PM 2/6/98 -0800, Greg Shue wrote:
> 
> 	[snip]
> 
> 	>I approached them about sharing some rough estimates of code
> size
> 	>for the IP1394 glue, SBP-2 target and initiator, and 1394 bus
> 	>manager modules to get a feel for how "heavy" the protocol
> 	>implementations really are.  They graciously shared the flowing
> 	>estimates with us, and certainly deserve our thanks.  Since the
> 	>technology is still being developed, these implementations are
> 	>certainly going to be tuned and the numbers will change a
> little
> 	>bit.
> 	>
> 	>  Component                Rough ROM size (KBytes)
> 	>  ---------                -----------------------
> 	>  SBP-2 initiator core     15 +/- 5
> 	>  SBP-2 target core        15 +/- 5  (incl. Mgmt+Fetch agent,
> no exec agent)
> 
> 	Any idea how big a combined SBP-2 target/initiator would be?
> 15-30K? ;-)
> 
> 	[snip]
> 
> 	Brian
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 	Brian Batchelder      | Hewlett-Packard      |
> mailto:brianb@vcd.hp.com  
> 	Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360)
> 212-4107  
> 	DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360)
> 212-4227
> 





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


From ewa at apple.com  Tue Feb 10 01:33:35 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:47 2009
Subject: P1394> 1284.4 over SBP-2
In-Reply-To: <P1394> 1284.4 over SBP-2>
Message-ID: <B1053A76-86066@17.128.200.23>

Hi Larry,


Since you asked, I'll try to politely explain my preference for
solution B: New SBP-2 command set with SBP-2.  I regret that I
can't make a strong argument, because I haven't had the time to
track closely your progress with solution A.  Still, I think
there are compelling reasons to consider solution B.


Recently, the 1394 community had the opportunity to define a
storage protocol for 1394.  The first solution, Tailgate, gave
us essentially an ATA interface bridged over 1394.  Both the
target and the initiator had to operate as if traditional ATA
was the interconnect.  Sure, SBP-2 was present, but only as a
transport, and much of it's potential was wasted.  Tailgate
was supposed to be quick an easy and lead to rapid market
adoption.  What actually happened was quite different.


Microsoft and others realized that adopting this model would
"lock in" ATA for a long time, including long after ATA itself
was dead.  Emulating a dead technology with new technology may
yield short-term savings in implementation, but at the expense of
long-term losses in performance.  Amazingly, reason prevailed,
and Tailgate was abandoned in favor of a pure SBP-2 protocol
for disk drives.  As it turned out, Tailgate vendors quickly
switched to Native Bridge, which still allowed today's drives
to act like 1394 drives, by making them look (from a 1394
point of view) like fully native devices.  As far as I can tell
this switch was not too painful, and now we aren't stuck with
ATA.  Everyone won.


Now we have a similar situation with printers.  1284.4 is a
very well established technology.  Compared to 1394, I think it
would be fair to say that 1284.4 is also a very slow and clumsy
technology (nothing personal!).  Surprise, surprise - the idea
comes up to bundle 1284.4 in SBP-2 because some purported savings
can be had, in the short term.  From what I have seen of how this
works, it is quite inefficient, with lots of unsolicited status
requests and in general lots of hand-holding by the CPU on the
initiator.  This is not what SBP-2 was designed for.


As printer resolutions climb, printer bandwidth rises very
quickly.  Yes, we all still do dull black and white word
processing, but I think you printer vendors will agree that the
exciting (high-margin) areas are in con-tone large-format high-
speed printers - just the sort that need 1394.  Or sparing that,
even consumer-level inkjets now have remarkable resolutions and
consume quite a lot of bandwidth.


Used properly, SBP-2 allows huge data transfers that can proceed
at the pace of the consumer (printer), with no hand-holding by
the host (computer).  Since host systems have 32 or more megs of
RAM today, ideally, printing should proceed with at most one
interrupt per megabyte of data transferred (assuming no errors),
leaving the CPU free to do useful work (like rasterizing).  SBP-2
and OpenHCI make this possible - but only if protocols are designed
with care to avoid needless interruption of the host.


Perhaps I have misunderstood your recent work regarding 1284.4 on
1394 in SBP-2, but I believe that the present plan will have far
more overhead than what I just described.  Specifically, I believe
this overhead comes from carefully emulating 1284.4 rather than
using SBP-2 in it's most natural way.  Over the lifetime of
1394, the cost of that overhead in wasted MIPS and wasted time will
far exceed any possible savings from recycling current protocols
and software.


1394 is far more "future friendly" and scalable than other
interconnects were at their introductions.  That didn't stop
Ethernet, ATA, SCSI, Parallel Port, and the like from living as
useful technologies for one or two decades.  Our goal should be
to make 1394 last at least as long, if not longer.  Portability
of a protocol to new interconnects at the expense of efficiency
doesn't seem valuable to me in this context - in fact, it seems
counter-productive.  The more inefficient the protocol we choose,
the more demand there will be for ever-faster interconnects.  A
well-designed, efficient protocol can last a very long time, and
serve everyone's needs better during that time.


I hope I haven't gone too far overboard here or stepped too hard
on any toes.  To conclude, I want to ask a simple question:  Has
anyone run this idea past Microsoft?  Microsoft killed off
Tailgate, and my guess is that they may have similar feelings
about printing.  Market reality is that we'll all follow whatever
they decide, so it really makes sense to get them involved.


Alas, I can't join you in Austin, but I do welcome your comments
by email.  Please be patient if you ask good (ie hard) questions.


Sincerely,


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.      408-974-8187
--------------------------------------


> Hello Everyone,
> 
> I'm sending this message to see if we can stimulate some discussion on
this
> subject prior to the 1394PWG meeting in Austin next month.
> 
> For the past year we have been meeting to develop a standard to provide
the
> high functionality transport method for printing over the IEEE 1394
> interface.  This is 'high functionality' , or 'thick' transport, as
opposed
> to the 'thin' transport that is being developed by the PWG-C.  The
> direction that our group has taken has involved reviewing FCP, DFA,
SBP-2,
> and others, as the lower transport and datalink interface, with something
> else as the transport interface.  This something else has focused on
1284.4
> or on a native 'glue' layer to the underlying datalink.
> 
> At this point in time we have apparently narrowed our potential solutions
> to the following:
> 
> A- 1284.4 with SBP-2
> B-  New SBP-2 command set with SBP-2
> 
> As many of you are aware, I'm primarily in support of option A as the
> preferred solution.  I'd like to take this opportunity to provide some of
> my reasoning and get feedback from you.
> 
> My support for this solution is not necessarily a technical reason, but a
> market reason.  As Greg Shue et al pointed out at the Maui meeting, it is
> possible to provide the required functionality by defining a new Command
> Set for SBP-2.  This would provide a transport solution for 1394 that is
> based solely on the SBP-2 protocol.  Technically, this is probably a
better
> solution than option A.
> 
> My question is "Is this really the best solution for the market today?".
> Many of us have expended great effort in developing the IEEE P1284.4
> standard.  One of the purposes and goals of  the development was to
create
> a datalink independent transport standard that could be used over the
> parallel port and other physical interfaces.
> 
> The intent here was to create a standard that would allow a peripheral to
> operate over various interfaces without requiring major architectural
> changes to the product.  In other words, a modular approach to the
> peripheral design.  A printer or MFP device could be developed to work
with
> 1284.4 over parallel today, and 'easily' adapted to work over 1394
> tomorrow.  The host application interface may not even know the
difference.
> 
> I think that this is the primary reasons for choosing option A.  It sends
a
> clear statement to peripheral and OS vendors that 1284.4 is the preferred
> transport interface for printer and MFP peripherals.  We back this up by
> providing solutions for parallel (1284.3) and for 1394.  This is not a
> stagnant industry and certainly new interfaces will appear in the future.
> I think it would be a great service that we provide a clear migration
path
> between interfaces that do not require redesign of the entire system.
> 
> Providing both options may be the result of this effort.  I think that
> option A should be the preferred one.
> 
> I await your responses.
> 
> Thanks,
> Larry
> 
> 
> ***************************************************************
> Larry A. Stein			Phone: 	(619)292-2742
> Warp Nine Engineering		Fax:	(619)292-8020
> 				Web: 	http://www.fapo.com
> ***************************************************************

From ewa at apple.com  Tue Feb 10 01:33:35 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:47 2009
Subject: P1394> 1284.4 over SBP-2
In-Reply-To: <P1394> 1284.4 over SBP-2>
Message-ID: <B1053A76-86066@17.128.200.23>

Hi Larry,


Since you asked, I'll try to politely explain my preference for
solution B: New SBP-2 command set with SBP-2.  I regret that I
can't make a strong argument, because I haven't had the time to
track closely your progress with solution A.  Still, I think
there are compelling reasons to consider solution B.


Recently, the 1394 community had the opportunity to define a
storage protocol for 1394.  The first solution, Tailgate, gave
us essentially an ATA interface bridged over 1394.  Both the
target and the initiator had to operate as if traditional ATA
was the interconnect.  Sure, SBP-2 was present, but only as a
transport, and much of it's potential was wasted.  Tailgate
was supposed to be quick an easy and lead to rapid market
adoption.  What actually happened was quite different.


Microsoft and others realized that adopting this model would
"lock in" ATA for a long time, including long after ATA itself
was dead.  Emulating a dead technology with new technology may
yield short-term savings in implementation, but at the expense of
long-term losses in performance.  Amazingly, reason prevailed,
and Tailgate was abandoned in favor of a pure SBP-2 protocol
for disk drives.  As it turned out, Tailgate vendors quickly
switched to Native Bridge, which still allowed today's drives
to act like 1394 drives, by making them look (from a 1394
point of view) like fully native devices.  As far as I can tell
this switch was not too painful, and now we aren't stuck with
ATA.  Everyone won.


Now we have a similar situation with printers.  1284.4 is a
very well established technology.  Compared to 1394, I think it
would be fair to say that 1284.4 is also a very slow and clumsy
technology (nothing personal!).  Surprise, surprise - the idea
comes up to bundle 1284.4 in SBP-2 because some purported savings
can be had, in the short term.  From what I have seen of how this
works, it is quite inefficient, with lots of unsolicited status
requests and in general lots of hand-holding by the CPU on the
initiator.  This is not what SBP-2 was designed for.


As printer resolutions climb, printer bandwidth rises very
quickly.  Yes, we all still do dull black and white word
processing, but I think you printer vendors will agree that the
exciting (high-margin) areas are in con-tone large-format high-
speed printers - just the sort that need 1394.  Or sparing that,
even consumer-level inkjets now have remarkable resolutions and
consume quite a lot of bandwidth.


Used properly, SBP-2 allows huge data transfers that can proceed
at the pace of the consumer (printer), with no hand-holding by
the host (computer).  Since host systems have 32 or more megs of
RAM today, ideally, printing should proceed with at most one
interrupt per megabyte of data transferred (assuming no errors),
leaving the CPU free to do useful work (like rasterizing).  SBP-2
and OpenHCI make this possible - but only if protocols are designed
with care to avoid needless interruption of the host.


Perhaps I have misunderstood your recent work regarding 1284.4 on
1394 in SBP-2, but I believe that the present plan will have far
more overhead than what I just described.  Specifically, I believe
this overhead comes from carefully emulating 1284.4 rather than
using SBP-2 in it's most natural way.  Over the lifetime of
1394, the cost of that overhead in wasted MIPS and wasted time will
far exceed any possible savings from recycling current protocols
and software.


1394 is far more "future friendly" and scalable than other
interconnects were at their introductions.  That didn't stop
Ethernet, ATA, SCSI, Parallel Port, and the like from living as
useful technologies for one or two decades.  Our goal should be
to make 1394 last at least as long, if not longer.  Portability
of a protocol to new interconnects at the expense of efficiency
doesn't seem valuable to me in this context - in fact, it seems
counter-productive.  The more inefficient the protocol we choose,
the more demand there will be for ever-faster interconnects.  A
well-designed, efficient protocol can last a very long time, and
serve everyone's needs better during that time.


I hope I haven't gone too far overboard here or stepped too hard
on any toes.  To conclude, I want to ask a simple question:  Has
anyone run this idea past Microsoft?  Microsoft killed off
Tailgate, and my guess is that they may have similar feelings
about printing.  Market reality is that we'll all follow whatever
they decide, so it really makes sense to get them involved.


Alas, I can't join you in Austin, but I do welcome your comments
by email.  Please be patient if you ask good (ie hard) questions.


Sincerely,


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.      408-974-8187
--------------------------------------


> Hello Everyone,
> 
> I'm sending this message to see if we can stimulate some discussion on
this
> subject prior to the 1394PWG meeting in Austin next month.
> 
> For the past year we have been meeting to develop a standard to provide
the
> high functionality transport method for printing over the IEEE 1394
> interface.  This is 'high functionality' , or 'thick' transport, as
opposed
> to the 'thin' transport that is being developed by the PWG-C.  The
> direction that our group has taken has involved reviewing FCP, DFA,
SBP-2,
> and others, as the lower transport and datalink interface, with something
> else as the transport interface.  This something else has focused on
1284.4
> or on a native 'glue' layer to the underlying datalink.
> 
> At this point in time we have apparently narrowed our potential solutions
> to the following:
> 
> A- 1284.4 with SBP-2
> B-  New SBP-2 command set with SBP-2
> 
> As many of you are aware, I'm primarily in support of option A as the
> preferred solution.  I'd like to take this opportunity to provide some of
> my reasoning and get feedback from you.
> 
> My support for this solution is not necessarily a technical reason, but a
> market reason.  As Greg Shue et al pointed out at the Maui meeting, it is
> possible to provide the required functionality by defining a new Command
> Set for SBP-2.  This would provide a transport solution for 1394 that is
> based solely on the SBP-2 protocol.  Technically, this is probably a
better
> solution than option A.
> 
> My question is "Is this really the best solution for the market today?".
> Many of us have expended great effort in developing the IEEE P1284.4
> standard.  One of the purposes and goals of  the development was to
create
> a datalink independent transport standard that could be used over the
> parallel port and other physical interfaces.
> 
> The intent here was to create a standard that would allow a peripheral to
> operate over various interfaces without requiring major architectural
> changes to the product.  In other words, a modular approach to the
> peripheral design.  A printer or MFP device could be developed to work
with
> 1284.4 over parallel today, and 'easily' adapted to work over 1394
> tomorrow.  The host application interface may not even know the
difference.
> 
> I think that this is the primary reasons for choosing option A.  It sends
a
> clear statement to peripheral and OS vendors that 1284.4 is the preferred
> transport interface for printer and MFP peripherals.  We back this up by
> providing solutions for parallel (1284.3) and for 1394.  This is not a
> stagnant industry and certainly new interfaces will appear in the future.
> I think it would be a great service that we provide a clear migration
path
> between interfaces that do not require redesign of the entire system.
> 
> Providing both options may be the result of this effort.  I think that
> option A should be the preferred one.
> 
> I await your responses.
> 
> Thanks,
> Larry
> 
> 
> ***************************************************************
> Larry A. Stein			Phone: 	(619)292-2742
> Warp Nine Engineering		Fax:	(619)292-8020
> 				Web: 	http://www.fapo.com
> ***************************************************************

From lstein at fapo.com  Tue Feb 10 10:53:28 1998
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:47 2009
Subject: P1394> 1284.4 over SBP-2
In-Reply-To: <199802100712.AA25133@lexmark.lexmark.com>
Message-ID: <199802101557.HAA23068@proxyb2.san.rr.com>

Dear Eric,


Thank you for your comments.  Please see my responses.
For everyone else;  the intent of this thread is to provoke discussion
prior to our next meeting.  Please chime in.




At 2/10/98 02:12 AM, Eric Anderson wrote:
>Hi Larry,
>
>Since you asked, I'll try to politely explain my preference for
>solution B: New SBP-2 command set with SBP-2.  I regret that I
>can't make a strong argument, because I haven't had the time to
>track closely your progress with solution A.  Still, I think
>there are compelling reasons to consider solution B.

From gregs at sdd.hp.com  Tue Feb 10 22:21:19 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:47 2009
Subject: P1394> 1284.4 over SBP-2
In-Reply-To: <199802091629.IAA22710@barley.adnc.com>
Message-ID: <199802110321.TAA21652@hpsdlgj1.sdd.hp.com>

> I await your responses.


OK, here we go...




Larry Stein wrote:


> At this point in time we have apparently narrowed our potential solutions
> to the following:
> 
> A- 1284.4 with SBP-2
> B-  New SBP-2 command set with SBP-2
> 
> As many of you are aware, I'm primarily in support of option A as the
> preferred solution.  I'd like to take this opportunity to provide some of
> my reasoning and get feedback from you.
> 
> My support for this solution is not necessarily a technical reason, but a
> market reason.  As Greg Shue et al pointed out at the Maui meeting, it is
> possible to provide the required functionality by defining a new Command
> Set for SBP-2.  This would provide a transport solution for 1394 that is
> based solely on the SBP-2 protocol.  Technically, this is probably a better
> solution than option A.
> 
> My question is "Is this really the best solution for the market today?".
> Many of us have expended great effort in developing the IEEE P1284.4
> standard.  One of the purposes and goals of  the development was to create
> a datalink independent transport standard that could be used over the
> parallel port and other physical interfaces.
> 
> The intent here was to create a standard that would allow a peripheral to
> operate over various interfaces without requiring major architectural
> changes to the product.  In other words, a modular approach to the
> peripheral design.  A printer or MFP device could be developed to work with
> 1284.4 over parallel today, and 'easily' adapted to work over 1394
> tomorrow.  The host application interface may not even know the difference.
> 


As I understood it, the ability for 'a peripheral to operate over
various interfaces without requiring major architectural changes
to the product' is provided by meeting the specified transport
service requirements.  As long as the transport requirements are
met, no architectural changes are required of the product.  Thus,
the transport layers are all modular with respect to the product.
(I think this is also why the PWG has not tried to eliminate a
TCP/IP printing solution.  :-)




The main difference between options A and B is whether multiple
services are made available through a 1284.4 MUX layer, or
through a combination of Unit Directories and Logical Unit
Numbers.  The command set features needed for a combined
1284.4/SBP-2 solution are essentially identical as for an
SBP-2 only solution (as shown below).


  In order to provide a combined SBP-2/1284.4 solution, an
  SBP-2 command set must be provided which meets the Data Link
  requirements spelled out for 1284.4.  These are:


    R1) Register/Unregister transport layer with the Data Link layer
    R2) Packet Data Transfer - error free, in order, as a whole
    R3) Asynchronous Operation - no polling shall be required.


  In order to map this within SBP-2, then the command set must
  provide (at least) the following features:


    F1) Transient link interruption support
	  (to support R2 and R3)
    F2) Non-transient link loss indication  (to support F1)
    F3) Extended SBP-2 Access Control to the transport
	  interface (to support F1)


    F4) SBP-2 ORB execution model for packet transfers
	  (to support R2 and R3)
    F5) Encapsulating of 1284.4 packets into ORBs
	  (to support R2)
    F6) Policy to determine maximum DL packet size
	  (to support R2 and F1)
    F7) Policy for how 1284.4 dialogue maps into SBP-2 access
	 control (to support R2, R3, and F1)


    F8) Standard mechanism for indicating existence of 1284.4
	 peer (to support R1)


    So, any of these features which are common with an SBP-2 only
    solution are outside the scope of concern here.  (For the
    unfamiliar, they all are provided in the (very rough) SBP-2
    only proposal presented at the January PWG 1394 meeting.)


These features are also those required for an SBP-2 only solution.
Since these are in common, they _don't_ affect the choice of option A
vs. option B.




I can't give an answer to Larry's question directly, because "best"
is rather subjective.  What's "best" for a customer might not be
"best" for a developer, and that might not be "best" for a
technology, which are all indirectly related to what is "best"
for the market.  I tried to identify above what are not areas of
tradeoffs between the two options so that we can look at what are.




If "best" is thought of in terms of market, then (I suppose)
supportability and deployment of the solution(s) matter the most,
because the 'market' has almost no history.  There really is no
legacy issue which makes either choice A or choice B preferred,
even though there are "legacy" printing solutions which will need
to be supported (i.e.  AVC, IP1394).  So, each of the following
areas become signficant:




If "best" is thought of in terms of providing the transport
services outlined by the requirements, then there is no
signficant difference between the SBP-2 only solution or the
combined solution.


If "best" is thought of in terms of developers and development
effort, then there is no significant difference between providing
the SBP-2 only solution or the SBP-2 portion of a combined
solution.  There will be additional effort for a combined
solution if a 1284.4 driver needs to be developed.


If "best" is thought of in terms of (availability of) OS support,
then the SBP-2 only solution is preferred because a greater portion
of the total solution already is provided by or is committed to
by OS vendors.


If "best" is thought of in terms of product cost, then the SBP-2
only solution is preferred because it has fewer layers.


If "best" is thought of in terms of performance, then the SBP-2
only solution is preferred because it isn't limited to 64-KByte
packets.


If "best" is thought of in terms of 1394 bus usage, then the
SBP-2 only solution is preferred because it doesn't have the CBT
crediting traffic of 1284.4.


If "best" is thought of in terms of compliance testability, then
the SBP-2 only solution is preferred because it is simpler and
has fewer layers.


If "best" is thought of in terms of availability customer
solutions, then the SBP-2 only solution is preferred because of
it's smaller footprint (which makes it more attractive to
integrate into more devices) and it's spreading use for varying
types of services on 1394.




> I think that this is the primary reasons for choosing option A.  It sends a
> clear statement to peripheral and OS vendors that 1284.4 is the preferred
> transport interface for printer and MFP peripherals.  We back this up by
> providing solutions for parallel (1284.3) and for 1394.  This is not a
> stagnant industry and certainly new interfaces will appear in the future.
> I think it would be a great service that we provide a clear migration path
> between interfaces that do not require redesign of the entire system.


Unfortunately, that message of 1284.4 being "the preferred
transport interface for printers" has been lost in the shuffle.
There are (currently) four transport protocols being defined on
1394 for printing.  These are:


  + AVC (for video snapshot)
  + DPP (for non-PC device-to-device)
  + PWG 1394 solution(s) (being discussed)
  + IP1394


I also haven't seen it get embraced for standardization on USB,
where hardware limitations and lack of a multiplexing transport
protocol solution identify a hole which 1284.4 can fill.




When this is added to (Apple's) Eric Anderson's thoughts of:


  - Emulating a dead technology with new technology may yield
    short-term savings in implementation, but at the expense of
    long-term losses in performance.  (philisophical)


  - Amazingly, reason prevailed, and Tailgate was abandoned in
    favor of a pure SBP-2 protocol for disk drives. (historical)


  - From what I have seen of how this (1284.4 over SBP-2) works,
    it is quite inefficient, with lots of unsolicited status
    requests and in general lots of hand-holding by the CPU on the
    initiator.  This is not what SBP-2 was designed for.  (perceptual)


  - Used properly, SBP-2 allows huge data transfers that can proceed
    at the pace of the consumer (printer), with no hand-holding by
    the host (computer)... SBP-2 and OpenHCI make this possible - but
    only if protocols are designed with care to avoid needless
    interruption of the host.  (practical)


  - 1394 is far more "future friendly" and scalable than other
    interconnects were at their introductions...  The more inefficient
    the protocol we choose, the more demand there will be for
    ever-faster interconnects.  A well-designed, efficient protocol
    can last a very long time, and serve everyone's needs better during
    that time.  (consequential)


  - To conclude, I want to ask a simple question:  Has anyone run
    this idea past Microsoft?  Microsoft killed off Tailgate, and
    my guess is that they may have similar feelings about printing.
    Market reality is that we'll all follow whatever they decide,
    so it really makes sense to get them involved.  (REALISTIC!!)


And (from a previous posting of Eric's):


 -  Microsoft says that their treatment of printers will be
    different.  They will only login to printers and other shared
    devices when they actually want to use the printer.  So a printer
    with only one login could be shared by several Windows systems.
    Apple plans to do the same thing for printers using SBP-2.


And the most quotable quote from the January 98 PWG 1394 meeting:


  "Every protocol looks light until it's implemented."




Given all of this, I am compelled to support option B.





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


From ewa at apple.com  Tue Feb 10 22:06:26 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:47 2009
Subject: P1394> 1284.4 over SBP-2
In-Reply-To: <P1394> 1284.4 over SBP-2>
Message-ID: <B1066275-62B20@17.128.201.215>

> Dear Eric,
> 
> Thank you for your comments.  Please see my responses.
> For everyone else;  the intent of this thread is to provoke discussion
> prior to our next meeting.  Please chime in.
> 
> 
> At 2/10/98 02:12 AM, Eric Anderson wrote:
> >Hi Larry,
> >
> >Since you asked, I'll try to politely explain my preference for
> >solution B: New SBP-2 command set with SBP-2.  I regret that I
> >can't make a strong argument, because I haven't had the time to
> >track closely your progress with solution A.  Still, I think
> >there are compelling reasons to consider solution B.


Hi Larry,


I never received anything more than what is shown above.  If you
sent comments, please send me another copy.  Thanks!


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.      408-974-8187
--------------------------------------

From stephen at hpb16977.boi.hp.com  Wed Feb 11 11:29:55 1998
From: stephen at hpb16977.boi.hp.com (Stephen Holmstead)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <B1066275-62B20@17.128.201.215>

My experiences in the past is that combining target AND initiator
functions into a single device is VERY difficult.  The complexity of the
state tables and ambiguities that can arise make it very difficult.
Also, I don't believe any of the chip manufacturers support SBP-2 for
both target and initiator.  In my opinion, it's NOT just a matter of
adding the 15K for the target and 15K for the initiator.  The target and
initiator have vastly different functions.   Designing a model that did
both (well) would be a challenge.  It was problems like this that fueled
many of the AEN (asynchronous event notification) debates.


Stephen


> -----Original Message-----
> From:	Turner, Randy [SMTP:rturner@sharplabs.com]
> Sent:	Monday, February 09, 1998 1:03 PM
> To:	'Brian Batchelder'; p1394@pwg.org
> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> 
> 
> I am very interested in the combined target/initiator footprint as
> well.
> 
> Thx
> 
> Randy
> 
> 
> 	-----Original Message-----
> 	From:	Brian Batchelder [SMTP:brianb@vcd.hp.com]
> 	Sent:	Monday, February 09, 1998 9:37 AM
> 	To:	p1394@pwg.org
> 	Subject:	Re: P1394> Rough SBP-2 & IP1394 core component
> ROM sizes
> 
> 	At 02:04 PM 2/6/98 -0800, Greg Shue wrote:
> 
> 	[snip]
> 
> 	>I approached them about sharing some rough estimates of code
> size
> 	>for the IP1394 glue, SBP-2 target and initiator, and 1394 bus
> 	>manager modules to get a feel for how "heavy" the protocol
> 	>implementations really are.  They graciously shared the flowing
> 	>estimates with us, and certainly deserve our thanks.  Since the
> 	>technology is still being developed, these implementations are
> 	>certainly going to be tuned and the numbers will change a
> little
> 	>bit.
> 	>
> 	>  Component                Rough ROM size (KBytes)
> 	>  ---------                -----------------------
> 	>  SBP-2 initiator core     15 +/- 5
> 	>  SBP-2 target core        15 +/- 5  (incl. Mgmt+Fetch agent,
> no exec agent)
> 
> 	Any idea how big a combined SBP-2 target/initiator would be?
> 15-30K? ;-)
> 
> 	[snip]
> 
> 	Brian
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~
> 	Brian Batchelder      | Hewlett-Packard      |
> mailto:brianb@vcd.hp.com  
> 	Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360)
> 212-4107  
> 	DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360)
> 212-4227

From rturner at sharplabs.com  Wed Feb 11 11:35:10 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <B1066275-62B20@17.128.201.215>

I didn't know chip sets offered "explicit" support for SBP-2. OHCI
maybe, but I hadn't seen the chip set feature in the brochure for
"chip-level SBP-2 support".


Also, since 1394 is a peer-to-peer interface, anyone developing a
peer-to-peer device (like the majority of the Japanese electronics
industry), would have to essentially duplicate the functionality of
SBP-2 initiator and target, whether they actually use SBP-2 to do this,
or some other (potentially proprietary) method for implementing
peer-to-peer functionality.


Randy






	-----Original Message-----
	From:	Stephen Holmstead [SMTP:stephen@hpb16977.boi.hp.com]
	Sent:	Wednesday, February 11, 1998 8:30 AM
	To:	'Turner, Randy'; 'Brian Batchelder'; p1394@pwg.org
	Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes


	My experiences in the past is that combining target AND
initiator
	functions into a single device is VERY difficult.  The
complexity of the
	state tables and ambiguities that can arise make it very
difficult.
	Also, I don't believe any of the chip manufacturers support
SBP-2 for
	both target and initiator.  In my opinion, it's NOT just a
matter of
	adding the 15K for the target and 15K for the initiator.  The
target and
	initiator have vastly different functions.   Designing a model
that did
	both (well) would be a challenge.  It was problems like this
that fueled
	many of the AEN (asynchronous event notification) debates.


	Stephen


	> -----Original Message-----
	> From:	Turner, Randy [SMTP:rturner@sharplabs.com]
	> Sent:	Monday, February 09, 1998 1:03 PM
	> To:	'Brian Batchelder'; p1394@pwg.org
	> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes
	> 
	> 
	> I am very interested in the combined target/initiator
footprint as
	> well.
	> 
	> Thx
	> 
	> Randy
	> 
	> 
	> 	-----Original Message-----
	> 	From:	Brian Batchelder [SMTP:brianb@vcd.hp.com]
	> 	Sent:	Monday, February 09, 1998 9:37 AM
	> 	To:	p1394@pwg.org
	> 	Subject:	Re: P1394> Rough SBP-2 & IP1394 core
component
	> ROM sizes
	> 
	> 	At 02:04 PM 2/6/98 -0800, Greg Shue wrote:
	> 
	> 	[snip]
	> 
	> 	>I approached them about sharing some rough estimates of
code
	> size
	> 	>for the IP1394 glue, SBP-2 target and initiator, and
1394 bus
	> 	>manager modules to get a feel for how "heavy" the
protocol
	> 	>implementations really are.  They graciously shared the
flowing
	> 	>estimates with us, and certainly deserve our thanks.
Since the
	> 	>technology is still being developed, these
implementations are
	> 	>certainly going to be tuned and the numbers will change
a
	> little
	> 	>bit.
	> 	>
	> 	>  Component                Rough ROM size (KBytes)
	> 	>  ---------                -----------------------
	> 	>  SBP-2 initiator core     15 +/- 5
	> 	>  SBP-2 target core        15 +/- 5  (incl. Mgmt+Fetch
agent,
	> no exec agent)
	> 
	> 	Any idea how big a combined SBP-2 target/initiator would
be?
	> 15-30K? ;-)
	> 
	> 	[snip]
	> 
	> 	Brian
	> 
	>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	> ~
	> 	Brian Batchelder      | Hewlett-Packard      |
	> mailto:brianb@vcd.hp.com  
	> 	Connectivity Futurist | 1115 SE 164th Ave.   | Phone:
(360)
	> 212-4107  
	> 	DeskJet Printers      | Vancouver, WA  98684 | Fax:
(360)
	> 212-4227

From gregs at sdd.hp.com  Wed Feb 11 11:59:39 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:47 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
In-Reply-To: <D10983CAC30DD111B41400805FA6A1C1272305@admsrvnt02.enet.sharplabs.com>
Message-ID: <199802111659.IAA23603@hpsdlgj1.sdd.hp.com>

Some chipsets offer HW assist for portions of the SBP-2 target
protocol.  Others offer HW support for DMA to map device memory
to Serial Bus memory, which significantly improves SBP-2 intiator
performance (e.g.  OHCI).  This does _not_ mean that the chips
are protocol-specific.


I definitely agree that initiator and target functionality are
vastly different.  In my mind, the represent opposite ends of a
client-server model.  I think it would be extremely difficult to
write a single application that could, in a single instance (or
through a single interface) be both a controller and a controlled
function.  (Note, I did not call this a Module, a Node, or a
device.  :-) I could very easily see a protocol stack for a node
having both target and initiator support.  Any server-type
services would use the target support.  Any client-type
applications would use the initiator support.  Because there is
so little that is shared, I see the size of the stacks as being
(roughly) the sum of the individual solutions, no matter how many
applications or services my node has.


Am I missing something here?


Greg Shue


> 
> 
> 
> I didn't know chip sets offered "explicit" support for SBP-2. OHCI
> maybe, but I hadn't seen the chip set feature in the brochure for
> "chip-level SBP-2 support".
> 
> Also, since 1394 is a peer-to-peer interface, anyone developing a
> peer-to-peer device (like the majority of the Japanese electronics
> industry), would have to essentially duplicate the functionality of
> SBP-2 initiator and target, whether they actually use SBP-2 to do this,
> or some other (potentially proprietary) method for implementing
> peer-to-peer functionality.
> 
> Randy
> 
> 
> 
> 	-----Original Message-----
> 	From:	Stephen Holmstead [SMTP:stephen@hpb16977.boi.hp.com]
> 	Sent:	Wednesday, February 11, 1998 8:30 AM
> 	To:	'Turner, Randy'; 'Brian Batchelder'; p1394@pwg.org
> 	Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> ROM sizes
> 
> 	My experiences in the past is that combining target AND
> initiator
> 	functions into a single device is VERY difficult.  The
> complexity of the
> 	state tables and ambiguities that can arise make it very
> difficult.
> 	Also, I don't believe any of the chip manufacturers support
> SBP-2 for
> 	both target and initiator.  In my opinion, it's NOT just a
> matter of
> 	adding the 15K for the target and 15K for the initiator.  The
> target and
> 	initiator have vastly different functions.   Designing a model
> that did
> 	both (well) would be a challenge.  It was problems like this
> that fueled
> 	many of the AEN (asynchronous event notification) debates.
> 
> 	Stephen
> 
> 	> -----Original Message-----
> 	> From:	Turner, Randy [SMTP:rturner@sharplabs.com]
> 	> Sent:	Monday, February 09, 1998 1:03 PM
> 	> To:	'Brian Batchelder'; p1394@pwg.org
> 	> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> ROM sizes
> 	> 
> 	> 
> 	> I am very interested in the combined target/initiator
> footprint as
> 	> well.
> 	> 
> 	> Thx
> 	> 
> 	> Randy
> 	> 
> 	> 
> 	> 	-----Original Message-----
> 	> 	From:	Brian Batchelder [SMTP:brianb@vcd.hp.com]
> 	> 	Sent:	Monday, February 09, 1998 9:37 AM
> 	> 	To:	p1394@pwg.org
> 	> 	Subject:	Re: P1394> Rough SBP-2 & IP1394 core
> component
> 	> ROM sizes
> 	> 
> 	> 	At 02:04 PM 2/6/98 -0800, Greg Shue wrote:
> 	> 
> 	> 	[snip]
> 	> 
> 	> 	>I approached them about sharing some rough estimates of
> code
> 	> size
> 	> 	>for the IP1394 glue, SBP-2 target and initiator, and
> 1394 bus
> 	> 	>manager modules to get a feel for how "heavy" the
> protocol
> 	> 	>implementations really are.  They graciously shared the
> flowing
> 	> 	>estimates with us, and certainly deserve our thanks.
> Since the
> 	> 	>technology is still being developed, these
> implementations are
> 	> 	>certainly going to be tuned and the numbers will change
> a
> 	> little
> 	> 	>bit.
> 	> 	>
> 	> 	>  Component                Rough ROM size (KBytes)
> 	> 	>  ---------                -----------------------
> 	> 	>  SBP-2 initiator core     15 +/- 5
> 	> 	>  SBP-2 target core        15 +/- 5  (incl. Mgmt+Fetch
> agent,
> 	> no exec agent)
> 	> 
> 	> 	Any idea how big a combined SBP-2 target/initiator would
> be?
> 	> 15-30K? ;-)
> 	> 
> 	> 	[snip]
> 	> 
> 	> 	Brian
> 	> 
> 	>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 	> ~
> 	> 	Brian Batchelder      | Hewlett-Packard      |
> 	> mailto:brianb@vcd.hp.com  
> 	> 	Connectivity Futurist | 1115 SE 164th Ave.   | Phone:
> (360)
> 	> 212-4107  
> 	> 	DeskJet Printers      | Vancouver, WA  98684 | Fax:
> (360)
> 	> 212-4227
> 

From carterk at us.ibm.com  Wed Feb 11 17:35:45 1998
From: carterk at us.ibm.com (Keith Carter)
Date: Wed May  6 14:00:47 2009
Subject: P1394> PWG meeting in Austin on 3/2-6
Message-ID: <199802111659.IAA23603@hpsdlgj1.sdd.hp.com>

Print gurus,


Thanks to everyone who "pinged" for the PWG meetings in Austin on 3/2-6.  I've
sent the information to the Hyatt hotel.  You may start making your hotel
reservations under "Printer Working Group" on Thursday, 2/12.  The phone number
for the Hyatt hotel is 512-477-1234.  Reservations at the IBM rate of
$101/night rate will be accepted through Tuesday, 2/17.  If you make your
reservation on Wednesday 2/18 or later, you may not get the IBM rate - so don't
procrastinate.  If you have already made your reservation, please contact the
hotel on 2/12 and inform them you are with the "Printer Working Group" to get
the IBM rate (several of you informed me that you already made your
reservations so I forwarded this information to the hotel but please check with
the hotel on 2/12 to ensure you get the IBM rate).


I'm awaiting the meeting room charges from the hotel.  For those who are
staying at the Hyatt hotel, you may sign a form at the meetings to charge your
room.  For everyone else, you may write a check to the "Hyatt" at the
meetings.  I'll recruit a "collector" for each meeting.


I confirmed we have the meeting room for the UPD discussion on the evening of
Tuesday 3/3 at no extra charge so all of you UPD'ers should be happy.  Just ask
for the meeting room for the Printer Working Group.


For your information, I have appended the "ping" list after this note.  Please
notify me directly of  any mistakes.


Ok, back to my real job...


Keith Carter
Senior Software Engineer
IBM Network Computing Software Division in Austin, Texas
internet email: carterk@us.ibm.com
Notes email: Keith Carter/Austin/IBM@IBMUS
phone: 512-838-2155
tie-line: 678-2155
fax: 512-838-0169


PING LIST FOR PWG MEETING IN AUSTIN, TEXAS ON MARCH 2-6, 1998


Name                 Company      PWG   Hyatt?  Arrive  Depart


Chuck Adams          Tektronix    3/4-6   Y     3/3     3/6
Ron Bergman          Dataproducts 3/4-6   Y     3/3     3/6
Brian Batchelder     HP           3/2-3   Y     3/1     3/4
Alan Berkema         HP           3/2-3   N     - -     - -
Keith Carter         IBM          3/4-5   N     - -     - -
Roger deBry          IBM          3/4-5   Y     3/3     3/5
Mabry Dozier         QMS Inc.     3/4-6   Y     3/3     3/6
Mark Edmead          MTE Software 3/2-3   Y     3/1     3/4
Lee Farrell          Canon        3/2-6   Y     3/1     3/6
Richard Hart         Digital      3/4-6   Y     3/3     3/6
Tom Hastings         XEROX        3/4-6   Y     3/3     3/6
Bob Herriot          SUN          3/4-5   Y     3/3     3/6
Osamu Hirata         Canon        3/2-3   Y     3/1     3/4
Henrik Holst         i-data Int'l 3/2-5   Y     3/1     3/5
Scott Isaacson       Novell       3/4-5   Y     3/3     3/5
David Kellerman      Northlake SW 3/4-6   Y     3/3     3/6
Greg LeClair         EPSON        3/2-4   Y     3/1     3/4
Harry Lewis          IBM          3/4-6   Y     3/3     3/6
Carl-Uno Manros      XEROX        3/4-5   Y     3/3     3/5
Jay Martin           Underscore   3/4-5   Y     3/3     3/6
Yoshinori Murakami   EPSON        3/2-3   Y     3/1     3/4
Fumio Nagasaka       EPSON        3/2-4   Y     3/1     3/5
Bob Pentecost        HP           3/4-6   Y     3/3     3/6
Akihiro Shimura      Canon        3/2-3   Y     3/1     3/5
Greg Shue            HP           3/2-3   Y     3/1     3/3
Larry Stein          Warp Nine    3/2-3   Y     3/1     3/4
Philip Thambidurai   Okidata     3/3-5   Y     3/2     3/6
? Thrasher           Lexmark      3/2-3   Y     3/1     3/4
Randy Turner         Sharp Labs   3/2-5   Y     3/1     3/6
Bill Wagner          OSICOM/DPI   3/2-6   Y     3/2     3/6
Jim Walker           DAZEL        3/4-6   N     - -     - -
Don Wright           Lexmark      3/2-6   Y     3/1     3/6
Lloyd Young          Lexmark      3/4-6   Y     3/3     3/6
Peter Zehler         XEROX        3/4-5   Y     3/3     3/6




PWG Meeting Attendance by Date


3/2    3/3   3/4   3/5   3/6
16     17    25    23    13

From lstein at fapo.com  Wed Feb 11 23:41:05 1998
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:47 2009
Subject: P1394> 1284.4 over SBP-2
In-Reply-To: <199802110321.TAA21652@hpsdlgj1.sdd.hp.com>
Message-ID: <199802120444.UAA07738@cello.qnet.com>

Greg,


Thanks for your comments.  The purpose of starting this thread was to get
some of these issues and questions discussed before the next meeting.  I
think it's working.


Thanks,
Larry


At 2/10/98 07:21 PM, Greg Shue wrote:
>
>> I await your responses.
>
>OK, here we go...
>
>
>Larry Stein wrote:
>
>> At this point in time we have apparently narrowed our potential solutions
>> to the following:
>> 
>> A- 1284.4 with SBP-2
>> B-  New SBP-2 command set with SBP-2
>> 
>> As many of you are aware, I'm primarily in support of option A as the
>> preferred solution.  I'd like to take this opportunity to provide some of
>> my reasoning and get feedback from you.
>> 
>> My support for this solution is not necessarily a technical reason, but a
>> market reason.  As Greg Shue et al pointed out at the Maui meeting, it is
>> possible to provide the required functionality by defining a new Command
>> Set for SBP-2.  This would provide a transport solution for 1394 that is
>> based solely on the SBP-2 protocol.  Technically, this is probably a better
>> solution than option A.
>> 
>> My question is "Is this really the best solution for the market today?".
>> Many of us have expended great effort in developing the IEEE P1284.4
>> standard.  One of the purposes and goals of  the development was to create
>> a datalink independent transport standard that could be used over the
>> parallel port and other physical interfaces.
>> 
>> The intent here was to create a standard that would allow a peripheral to
>> operate over various interfaces without requiring major architectural
>> changes to the product.  In other words, a modular approach to the
>> peripheral design.  A printer or MFP device could be developed to work with
>> 1284.4 over parallel today, and 'easily' adapted to work over 1394
>> tomorrow.  The host application interface may not even know the difference.
>> 
>
>As I understood it, the ability for 'a peripheral to operate over
>various interfaces without requiring major architectural changes
>to the product' is provided by meeting the specified transport
>service requirements.  As long as the transport requirements are
>met, no architectural changes are required of the product.  Thus,
>the transport layers are all modular with respect to the product.
>(I think this is also why the PWG has not tried to eliminate a
>TCP/IP printing solution.  :-)
>
>
>The main difference between options A and B is whether multiple
>services are made available through a 1284.4 MUX layer, or
>through a combination of Unit Directories and Logical Unit
>Numbers.  The command set features needed for a combined
>1284.4/SBP-2 solution are essentially identical as for an
>SBP-2 only solution (as shown below).
>
>  In order to provide a combined SBP-2/1284.4 solution, an
>  SBP-2 command set must be provided which meets the Data Link
>  requirements spelled out for 1284.4.  These are:
>
>    R1) Register/Unregister transport layer with the Data Link layer
>    R2) Packet Data Transfer - error free, in order, as a whole
>    R3) Asynchronous Operation - no polling shall be required.
>
>  In order to map this within SBP-2, then the command set must
>  provide (at least) the following features:
>
>    F1) Transient link interruption support
>	  (to support R2 and R3)


>    F2) Non-transient link loss indication  (to support F1)
>    F3) Extended SBP-2 Access Control to the transport
>	  interface (to support F1)
>
>    F4) SBP-2 ORB execution model for packet transfers
>	  (to support R2 and R3)
>    F5) Encapsulating of 1284.4 packets into ORBs
>	  (to support R2)
>    F6) Policy to determine maximum DL packet size
>	  (to support R2 and F1)
>    F7) Policy for how 1284.4 dialogue maps into SBP-2 access
>	control (to support R2, R3, and F1)
>
>    F8) Standard mechanism for indicating existence of 1284.4
>	peer (to support R1)
>
>    So, any of these features which are common with an SBP-2 only
>    solution are outside the scope of concern here.  (For the
>    unfamiliar, they all are provided in the (very rough) SBP-2
>    only proposal presented at the January PWG 1394 meeting.)
>
>These features are also those required for an SBP-2 only solution.
>Since these are in common, they _don't_ affect the choice of option A
>vs. option B.
>
>
>I can't give an answer to Larry's question directly, because "best"
>is rather subjective.  What's "best" for a customer might not be
>"best" for a developer, and that might not be "best" for a
>technology, which are all indirectly related to what is "best"
>for the market.  I tried to identify above what are not areas of
>tradeoffs between the two options so that we can look at what are.
>
>
>If "best" is thought of in terms of market, then (I suppose)
>supportability and deployment of the solution(s) matter the most,
>because the 'market' has almost no history.  There really is no
>legacy issue which makes either choice A or choice B preferred,
>even though there are "legacy" printing solutions which will need
>to be supported (i.e.  AVC, IP1394).  So, each of the following
>areas become signficant:
>
>
>If "best" is thought of in terms of providing the transport
>services outlined by the requirements, then there is no
>signficant difference between the SBP-2 only solution or the
>combined solution.
>
>If "best" is thought of in terms of developers and development
>effort, then there is no significant difference between providing
>the SBP-2 only solution or the SBP-2 portion of a combined
>solution.  There will be additional effort for a combined
>solution if a 1284.4 driver needs to be developed.
>
>If "best" is thought of in terms of (availability of) OS support,
>then the SBP-2 only solution is preferred because a greater portion
>of the total solution already is provided by or is committed to
>by OS vendors.
>
>If "best" is thought of in terms of product cost, then the SBP-2
>only solution is preferred because it has fewer layers.
>
>If "best" is thought of in terms of performance, then the SBP-2
>only solution is preferred because it isn't limited to 64-KByte
>packets.
>
>If "best" is thought of in terms of 1394 bus usage, then the
>SBP-2 only solution is preferred because it doesn't have the CBT
>crediting traffic of 1284.4.
>
>If "best" is thought of in terms of compliance testability, then
>the SBP-2 only solution is preferred because it is simpler and
>has fewer layers.


>
>If "best" is thought of in terms of availability customer
>solutions, then the SBP-2 only solution is preferred because of
>it's smaller footprint (which makes it more attractive to
>integrate into more devices) and it's spreading use for varying
>types of services on 1394.
>
>
>> I think that this is the primary reasons for choosing option A.  It sends a
>> clear statement to peripheral and OS vendors that 1284.4 is the preferred
>> transport interface for printer and MFP peripherals.  We back this up by
>> providing solutions for parallel (1284.3) and for 1394.  This is not a
>> stagnant industry and certainly new interfaces will appear in the future.
>> I think it would be a great service that we provide a clear migration path
>> between interfaces that do not require redesign of the entire system.
>
>Unfortunately, that message of 1284.4 being "the preferred
>transport interface for printers" has been lost in the shuffle.
>There are (currently) four transport protocols being defined on
>1394 for printing.  These are:
>
>  + AVC (for video snapshot)
>  + DPP (for non-PC device-to-device)
>  + PWG 1394 solution(s) (being discussed)
>  + IP1394
>
>I also haven't seen it get embraced for standardization on USB,
>where hardware limitations and lack of a multiplexing transport
>protocol solution identify a hole which 1284.4 can fill.
>
>
>When this is added to (Apple's) Eric Anderson's thoughts of:
>
>  - Emulating a dead technology with new technology may yield
>    short-term savings in implementation, but at the expense of
>    long-term losses in performance.  (philisophical)
>
>  - Amazingly, reason prevailed, and Tailgate was abandoned in
>    favor of a pure SBP-2 protocol for disk drives. (historical)
>
>  - From what I have seen of how this (1284.4 over SBP-2) works,
>    it is quite inefficient, with lots of unsolicited status
>    requests and in general lots of hand-holding by the CPU on the
>    initiator.  This is not what SBP-2 was designed for.  (perceptual)
>
>  - Used properly, SBP-2 allows huge data transfers that can proceed
>    at the pace of the consumer (printer), with no hand-holding by
>    the host (computer)... SBP-2 and OpenHCI make this possible - but
>    only if protocols are designed with care to avoid needless
>    interruption of the host.  (practical)
>
>  - 1394 is far more "future friendly" and scalable than other
>    interconnects were at their introductions...  The more inefficient
>    the protocol we choose, the more demand there will be for
>    ever-faster interconnects.  A well-designed, efficient protocol
>    can last a very long time, and serve everyone's needs better during
>    that time.  (consequential)
>
>  - To conclude, I want to ask a simple question:  Has anyone run
>    this idea past Microsoft?  Microsoft killed off Tailgate, and
>    my guess is that they may have similar feelings about printing.
>    Market reality is that we'll all follow whatever they decide,
>    so it really makes sense to get them involved.  (REALISTIC!!)
>
>And (from a previous posting of Eric's):
>


> -  Microsoft says that their treatment of printers will be
>    different.  They will only login to printers and other shared
>    devices when they actually want to use the printer.  So a printer
>    with only one login could be shared by several Windows systems.
>    Apple plans to do the same thing for printers using SBP-2.
>
>And the most quotable quote from the January 98 PWG 1394 meeting:
>
>  "Every protocol looks light until it's implemented."
>
>
>Given all of this, I am compelled to support option B.
>
>
>-- 
>Greg Shue
>Hewlett-Packard Company
>Office Products Division			gregs@sdd.hp.com
>----------------------------------------------------------------
> 
**********************************************************
Larry A. Stein		Ph. 619-292-2742
Warp Nine Engineering	Fax 619-292-8020
lstein@fapo.com		http://www.fapo.com
**********************************************************

From Nagasaka.Fumio at exc.epson.co.jp  Wed Feb 11 21:49:55 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:47 2009
Subject: P1394> 1284.4 over SBP-2
Message-ID: <199802120444.UAA07738@cello.qnet.com>

Hi Larry,


I am waiting for meeting minutes of PWG/PWG-C Hawaii meeting.
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


		-----Original Message-----
		From:	Larry Stein [SMTP:lstein@fapo.com]
		Sent:	Wednesday, February 11, 1998 12:53 AM
		To:	p1284_3@lexmark.com; Multiple recipients of list
		Cc:	p1394@pwg.org
		Subject:	Re: P1394> 1284.4 over SBP-2


		Dear Eric,


		Thank you for your comments.  Please see my responses.
		For everyone else;  the intent of this thread is to
provoke discussion
		prior to our next meeting.  Please chime in.




		At 2/10/98 02:12 AM, Eric Anderson wrote:
		>Hi Larry,
		>
		>Since you asked, I'll try to politely explain my
preference for
		>solution B: New SBP-2 command set with SBP-2.  I regret
that I
		>can't make a strong argument, because I haven't had the
time to
		>track closely your progress with solution A.  Still, I
think
		>there are compelling reasons to consider solution B.

From Nagasaka.Fumio at exc.epson.co.jp  Thu Feb 12 01:59:31 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:48 2009
Subject: P1394> 1284.4 over SBP-2
Message-ID: <199802120444.UAA07738@cello.qnet.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_000_01BD3784.4C5B70D6
Content-Type: text/plain


Dear Eric,
Dear Larry,


Please find an attached document which shows issue Eric and myself
had discussed at December 3, 1997.
 <<Generation.PDF>> 
I am writing printer drivers that covers first generation of 1394
printing.
These printer drivers are supporting option A.
<<
A-	1284.4 with SBP-2
B-	New SBP-2 command set with SBP-2
>>
I also prefer to choose option A at least in these couple of years. One
of my reason is market reason same as Larry. Another my reason is
technical reason. As I mentioned before, a target peer which supports
CBT allows initiator peers to send ORBs safely. Any data link layer
which services only one data path has difficulties to support multiple
logical channels. Because, if once one of logical channels had been
stalled, other requests that goes same data path will be stalled.
The CBT set the data link layer free from these difficulties.


However CBT provided by IEEE 1284.4 dose not clear 100 % of
problems. Please show a figure below.
 <<InOrbStalled.PDF>> 
The fourth ORB in this figure will be stalled when ch. #1 of the
target peer does not have any packet to reply. Thus <I> feel
necessity to develop second generation transport layer to 
support SBP-2 printing or completely new idea. However
efforts for standardization will easily take ten to twelve months
if we start to discuss every things from scratch.
I think 1394 PWG shall make first generation protocol with
option A at first.
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


		-----Original Message-----
		From:	Larry Stein [SMTP:lstein@fapo.com]
		Sent:	Wednesday, February 11, 1998 12:53 AM
		To:	p1284_3@lexmark.com; Multiple recipients of list
		Cc:	p1394@pwg.org
		Subject:	Re: P1394> 1284.4 over SBP-2


		Dear Eric,


		Thank you for your comments.  Please see my responses.
		For everyone else;  the intent of this thread is to
provoke discussion
		prior to our next meeting.  Please chime in.




		At 2/10/98 02:12 AM, Eric Anderson wrote:
		>Hi Larry,
		>
		>Since you asked, I'll try to politely explain my
preference for
		>solution B: New SBP-2 command set with SBP-2.  I regret
that I
		>can't make a strong argument, because I haven't had the
time to
		>track closely your progress with solution A.  Still, I
think
		>there are compelling reasons to consider solution B.


------ =_NextPart_000_01BD3784.4C5B70D6
Content-Type: application/octet-stream;
	name="Generation.PDF"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="Generation.PDF"


[encoded data, 7007 characters]
dGFydHhyZWYNCjQ3NjUNCiUlRU9GDQo=


------ =_NextPart_000_01BD3784.4C5B70D6
Content-Type: application/octet-stream;
	name="InOrbStalled.PDF"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="InOrbStalled.PDF"


[encoded data, 25179 characters]
YmU5MGQ1ZD5dDQo+Pg0Kc3RhcnR4cmVmDQoxNzczMw0KJSVFT0YNCg==


------ =_NextPart_000_01BD3784.4C5B70D6--

From carterk at us.ibm.com  Thu Feb 12 08:58:04 1998
From: carterk at us.ibm.com (Keith Carter)
Date: Wed May  6 14:00:48 2009
Subject: P1394> RESEND: PWG meeting in Austin on 3/2-6
Message-ID: <199802120444.UAA07738@cello.qnet.com>

---------------------- Forwarded by Keith Carter/Austin/IBM on 02-12-98 07:59 AM
 ---------------------------




Keith Carter
02-11-98 04:24 PM


To: ipp@pwg.org@internet, jmp@pwg.org@internet, fin@pwg.org@internet,
pwg@pwg.org@internet, p1394@pwg.org@internet
cc:
From: Keith Carter/Austin/IBM @ IBMUS
Subject: PWG meeting in Austin on 3/2-6


Print gurus,


Thanks to everyone who "pinged" for the PWG meetings in Austin on 3/2-6.  I've
sent the information to the Hyatt hotel.  You may start making your hotel
reservations under "Printer Working Group" on Thursday, 2/12.  The phone number
for the Hyatt hotel is 512-477-1234.  Reservations at the IBM rate of
$101/night rate will be accepted through Tuesday, 2/17.  If you make your
reservation on Wednesday 2/18 or later, you may not get the IBM rate - so don't
procrastinate.  If you have already made your reservation, please contact the
hotel on 2/12 and inform them you are with the "Printer Working Group" to get
the IBM rate (several of you informed me that you already made your
reservations so I forwarded this information to the hotel but please check with
the hotel on 2/12 to ensure you get the IBM rate).


I'm awaiting the meeting room charges from the hotel.  For those who are
staying at the Hyatt hotel, you may sign a form at the meetings to charge your
room.  For everyone else, you may write a check to the "Hyatt" at the
meetings.  I'll recruit a "collector" for each meeting.


I confirmed we have the meeting room for the UPD discussion on the evening of
Tuesday 3/3 at no extra charge so all of you UPD'ers should be happy.  Just ask
for the meeting room for the Printer Working Group.


For your information, I have appended the "ping" list after this note.  Please
notify me directly of  any mistakes.


Ok, back to my real job...


Keith Carter
Senior Software Engineer
IBM Network Computing Software Division in Austin, Texas
internet email: carterk@us.ibm.com
Notes email: Keith Carter/Austin/IBM@IBMUS
phone: 512-838-2155
tie-line: 678-2155
fax: 512-838-0169


PING LIST FOR PWG MEETING IN AUSTIN, TEXAS ON MARCH 2-6, 1998


Name                 Company      PWG   Hyatt?  Arrive  Depart


Chuck Adams          Tektronix    3/4-6   Y     3/3     3/6
Ron Bergman          Dataproducts 3/4-6   Y     3/3     3/6
Brian Batchelder     HP           3/2-3   Y     3/1     3/4
Alan Berkema         HP           3/2-3   N     - -     - -
Keith Carter         IBM          3/4-5   N     - -     - -
Roger deBry          IBM          3/4-5   Y     3/3     3/5
Mabry Dozier         QMS Inc.     3/4-6   Y     3/3     3/6
Mark Edmead          MTE Software 3/2-3   Y     3/1     3/4
Lee Farrell          Canon        3/2-6   Y     3/1     3/6
Richard Hart         Digital      3/4-6   Y     3/3     3/6
Tom Hastings         XEROX        3/4-6   Y     3/3     3/6
Bob Herriot          SUN          3/4-5   Y     3/3     3/6
Osamu Hirata         Canon        3/2-3   Y     3/1     3/4
Henrik Holst         i-data Int'l 3/2-5   Y     3/1     3/5
Scott Isaacson       Novell       3/4-5   Y     3/3     3/5
David Kellerman      Northlake SW 3/4-6   Y     3/3     3/6
Greg LeClair         EPSON        3/2-4   Y     3/1     3/4
Harry Lewis          IBM          3/4-6   Y     3/3     3/6
Carl-Uno Manros      XEROX        3/4-5   Y     3/3     3/5
Jay Martin           Underscore   3/4-5   Y     3/3     3/6
Yoshinori Murakami   EPSON        3/2-3   Y     3/1     3/4
Fumio Nagasaka       EPSON        3/2-4   Y     3/1     3/5
Bob Pentecost        HP           3/4-6   Y     3/3     3/6
Akihiro Shimura      Canon        3/2-3   Y     3/1     3/5
Greg Shue            HP           3/2-3   Y     3/1     3/3
Larry Stein          Warp Nine    3/2-3   Y     3/1     3/4
Philip Thambidurai   Okidata     3/3-5   Y     3/2     3/6
? Thrasher           Lexmark      3/2-3   Y     3/1     3/4
Randy Turner         Sharp Labs   3/2-5   Y     3/1     3/6
Bill Wagner          OSICOM/DPI   3/2-6   Y     3/2     3/6
Jim Walker           DAZEL        3/4-6   N     - -     - -
Don Wright           Lexmark      3/2-6   Y     3/1     3/6
Lloyd Young          Lexmark      3/4-6   Y     3/3     3/6
Peter Zehler         XEROX        3/4-5   Y     3/3     3/6




PWG Meeting Attendance by Date


3/2    3/3   3/4   3/5   3/6
16     17    25    23    13

From shimura at pure.cpdc.canon.co.jp  Thu Feb 12 10:05:04 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:48 2009
Subject: P1394> 1284.4 over SBP-2
In-Reply-To: <199802110321.TAA21652@hpsdlgj1.sdd.hp.com>
Message-ID: <199802121505.AAA10011@slant1.pure.cpdc.canon.co.jp>

On Tue, 10 Feb 1998 19:21:19 -0800 (PST)
Greg Shue <gregs@sdd.hp.com> wrote:


> > I await your responses.
> 
> OK, here we go...


OK, I'll follow...


> Larry Stein wrote:
> 
> > At this point in time we have apparently narrowed our potential solutions
> > to the following:
> > 
> > A- 1284.4 with SBP-2
> > B-  New SBP-2 command set with SBP-2


(snip)


> As I understood it, the ability for 'a peripheral to operate over
> various interfaces without requiring major architectural changes
> to the product' is provided by meeting the specified transport
> service requirements.  As long as the transport requirements are
> met, no architectural changes are required of the product.  Thus,
> the transport layers are all modular with respect to the product.


I agree. This was original intent of the HPT which Ueda-san and I
introduced from last June meeting.


(snip)


> Given all of this, I am compelled to support option B.


Basically, I also support to consider option B, but it is still not
clear for me how the data transfer of each direction is done
independently within single login in SBP-2 only solution.


If target request data transfer by "Data Available" flag in certain
status block, initiator will subsequently append "SND data-in" ORB in
the current task list. It will be possible for the target to check if
there is a "SND data-in" ORB in the task list BEFORE the initiator
appends the "SND data-in" ORB. After finding there is no "SND data-in"
ORB, the target may issue another unsolicited status which indicates
"Data Available". By this status, the initiator may append one more
(total two) "SND data-in" ORB in the task list. After that, the
target will need to abort the excessive ORB.
Is this a way the SBP-2 only solution works?


I think that aborting tasks implies subsequent task retries, and may
not be efficient.
It seems natural to make two independent logins for each direction,
one for down-link and another for up-link by using the idea to map
them into logical units. Furthermore, by extending this to allow to
allocate up-link in reverse fashion (i.e., the target of down-link
makes a login to the initiator of down-link), the link between two
devices will become symmetric if both ends have both initiator and
target functionality.


Any suggestions?



--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.


From lstein at fapo.com  Thu Feb 12 10:00:14 1998
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Delay in Minutes
In-Reply-To: <01376112D7AFD011911E0020AF70BEC5075AA8@CPUEX1>
Message-ID: <Version.32.19980212065820.01006c40@pop3.fapo.com>

Sorry the minutes will be late.  I'm at a show in New Orleans until Monday.
 I'll try to get them out next week.


Thanks,
Larry


At 2/12/98 11:49 AM, Nagasaka Fumio wrote:
>Hi Larry,
>
>I am waiting for meeting minutes of PWG/PWG-C Hawaii meeting.
>--------------------------------------------
>-------------------------------
>Fumio Nagasaka


**********************************************************
Larry A. Stein		Ph. 619-292-2742
Warp Nine Engineering	Fax 619-292-8020
lstein@fapo.com		http://www.fapo.com
**********************************************************

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Thu Feb 12 11:56:43 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:48 2009
Subject: P1394> 1284.4 over SBP-2
In-Reply-To: <199802121505.AAA10011@slant1.pure.cpdc.canon.co.jp>
Message-ID: <H0000d930ed29cf0@MHS>

--openmail-part-11792923-00000001
Content-Type: application/octet-stream; name="1.txt"
Content-Disposition: attachment; filename="1.txt"
Content-Transfer-Encoding: base64


UmVjZWl2ZWQ6IGZyb20gcGFscmVsMS5ocC5jb20gKHBhbHJlbDEuaHAuY29tIFsxNS44MS4x
NjguMTBdKSBieSB2ZW51cy5yb3NlLmhwLmNvbSB3aXRoIEVTTVRQICg4LjcuMS84LjcuMyBU
SVMgNS4wIE9wZW5tYWlsKSBpZCBIQUEyNjg0NiBmb3IgPGFsYW5fYmVya2VtYUBocC1yb3Nl
dmlsbGUtb20yLm9tLmhwLmNvbT47IFRodSwgMTIgRmViIDE5OTggMDc6MDc6NDIgLTA4MDAg
KFBTVCkKUmVjZWl2ZWQ6IGZyb20gbGlzdHMudW5kZXJzY29yZS5jb20gKHVzY29yZS0xLm12
LmNvbSBbMTk5LjEyNS44NS4zMF0pCglieSBwYWxyZWwxLmhwLmNvbSAoOC44LjYvOC44LjV0
aXMpIHdpdGggRVNNVFAgaWQgSEFBMTU0NDA7CglUaHUsIDEyIEZlYiAxOTk4IDA3OjA3OjMy
IC0wODAwIChQU1QpClJlY2VpdmVkOiBmcm9tIGxvY2FsaG9zdCAoZGFlbW9uQGxvY2FsaG9z
dCkgYnkgbGlzdHMudW5kZXJzY29yZS5jb20gKDguNy41LzguNy4zKSB3aXRoIFNNVFAgaWQg
S0FBMDIzNjA7IFRodSwgMTIgRmViIDE5OTggMTA6MDc6MjggLTA1MDAgKEVTVCkKUmVjZWl2
ZWQ6IGJ5IHB3Zy5vcmcgKGJ1bGtfbWFpbGVyIHYxLjUpOyBUaHUsIDEyIEZlYiAxOTk4IDEw
OjA2OjA5IC0wNTAwClJlY2VpdmVkOiAoZnJvbSBkYWVtb25AbG9jYWxob3N0KSBieSBsaXN0
cy51bmRlcnNjb3JlLmNvbSAoOC43LjUvOC43LjMpIGlkIEtBQTAyMjEyIGZvciBwMTM5NC1v
dXRnb2luZzsgVGh1LCAxMiBGZWIgMTk5OCAxMDowNjowMCAtMDUwMCAoRVNUKQpEYXRlOiBG
cmksIDEzIEZlYiAxOTk4IDAwOjA1OjA0ICswOTAwIChKU1QpCk1lc3NhZ2UtSWQ6IDwxOTk4
MDIxMjE1MDUuQUFBMTAwMTFAc2xhbnQxLnB1cmUuY3BkYy5jYW5vbi5jby5qcD4KRnJvbTog
QWtpaGlybyBTaGltdXJhIDxzaGltdXJhQHB1cmUuY3BkYy5jYW5vbi5jby5qcD4KVG86IEdy
ZWcgU2h1ZSA8Z3JlZ3NAc2RkLmhwLmNvbT4KQ2M6IHAxMzk0QHB3Zy5vcmcsIFAxMjg0XzNA
bGV4bWFyay5jb20sIExhcnJ5IFN0ZWluIDxsc3RlaW5AZmFwby5jb20+ClN1YmplY3Q6IFJl
OiBQMTM5ND4gMTI4NC40IG92ZXIgU0JQLTIKSW4tUmVwbHktVG86IDwxOTk4MDIxMTAzMjEu
VEFBMjE2NTJAaHBzZGxnajEuc2RkLmhwLmNvbT4KUmVmZXJlbmNlczogPDE5OTgwMjA5MTYy
OS5JQUEyMjcxMEBiYXJsZXkuYWRuYy5jb20+IDwxOTk4MDIxMTAzMjEuVEFBMjE2NTJAaHBz
ZGxnajEuc2RkLmhwLmNvbT4KTWltZS1WZXJzaW9uOiAxLjAKQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluOyBjaGFyc2V0PVVTLUFTQ0lJCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdi
aXQKWC1NYWlsZXI6IEJlY2t5ISB2ZXIgMS4yMwpTZW5kZXI6IHAxMzk0LW93bmVyQHB3Zy5v
cmcK


--openmail-part-11792923-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline; filename="Re:"
Content-Transfer-Encoding: 7bit


     I tend to favor option B as well.
     
     I think Shimura san has some good points at the end of his message 
     that goes to the heart of what is still not clear with the option B 
     proposal. I think we need to work up some example scenarios and 
     explore exactly how this will work. Greg Shue got any ideas here.
     
     regards,
     Alan




______________________________ Reply Separator _________________________________
Subject: Re: P1394> 1284.4 over SBP-2
Author:  Non-HP-shimura (shimura@pure.cpdc.canon.co.jp) at HP-Roseville,mimegw3
Date:    2/12/98 7:05 AM




On Tue, 10 Feb 1998 19:21:19 -0800 (PST) 
Greg Shue <gregs@sdd.hp.com> wrote:
     
> > I await your responses.
> 
> OK, here we go...
     
OK, I'll follow...
     
> Larry Stein wrote:
> 
> > At this point in time we have apparently narrowed our potential solutions 
> > to the following:
> > 
> > A- 1284.4 with SBP-2
> > B-  New SBP-2 command set with SBP-2
     
(snip)
     
> As I understood it, the ability for 'a peripheral to operate over 
> various interfaces without requiring major architectural changes 
> to the product' is provided by meeting the specified transport
> service requirements.  As long as the transport requirements are 
> met, no architectural changes are required of the product.  Thus, 
> the transport layers are all modular with respect to the product.
     
I agree. This was original intent of the HPT which Ueda-san and I 
introduced from last June meeting.
     
(snip)
     
> Given all of this, I am compelled to support option B.
     
Basically, I also support to consider option B, but it is still not 
clear for me how the data transfer of each direction is done 
independently within single login in SBP-2 only solution.
     
If target request data transfer by "Data Available" flag in certain 
status block, initiator will subsequently append "SND data-in" ORB in 
the current task list. It will be possible for the target to check if 
there is a "SND data-in" ORB in the task list BEFORE the initiator 
appends the "SND data-in" ORB. After finding there is no "SND data-in" 
ORB, the target may issue another unsolicited status which indicates 
"Data Available". By this status, the initiator may append one more 
(total two) "SND data-in" ORB in the task list. After that, the
target will need to abort the excessive ORB. 
Is this a way the SBP-2 only solution works?
     
I think that aborting tasks implies subsequent task retries, and may 
not be efficient.
It seems natural to make two independent logins for each direction, 
one for down-link and another for up-link by using the idea to map 
them into logical units. Furthermore, by extending this to allow to 
allocate up-link in reverse fashion (i.e., the target of down-link 
makes a login to the initiator of down-link), the link between two 
devices will become symmetric if both ends have both initiator and 
target functionality.
     
Any suggestions?
     

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp) 
 Office Imaging Products Development Center 3 
 CANON INC.


--openmail-part-11792923-00000001--


From gregs at sdd.hp.com  Thu Feb 12 13:24:21 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:48 2009
Subject: P1394> 1284.4 over SBP-2
In-Reply-To: <199802121505.AAA10011@slant1.pure.cpdc.canon.co.jp>
Message-ID: <199802121824.KAA26099@hpsdlgj1.sdd.hp.com>

Akihiro Shimura writes:
> Basically, I also support to consider option B, but it is still not
> clear for me how the data transfer of each direction is done
> independently within single login in SBP-2 only solution.
> 
> If target request data transfer by "Data Available" flag in certain
> status block, initiator will subsequently append "SND data-in" ORB in
> the current task list. It will be possible for the target to check if
> there is a "SND data-in" ORB in the task list BEFORE the initiator
> appends the "SND data-in" ORB. After finding there is no "SND data-in"
> ORB, the target may issue another unsolicited status which indicates
> "Data Available". By this status, the initiator may append one more
> (total two) "SND data-in" ORB in the task list. After that, the
> target will need to abort the excessive ORB.
> Is this a way the SBP-2 only solution works?


It's not the way I intended it to work.  Let me work through
the model I've had in mind.


It is a status signal that data is available for the initiator.  It is
not an event requesting a new task be placed on the task list.


The status is updated at exactly two points in time:  on the
completion of a task; and on a spontaneous change from No Data
Available to Data Available when there are to active tasks on the
task list.  It is up to the initiator to determine whether a new
task needs to be enqueued on the task list or not.  The task
enqueuing algorithm for the initiator would basically be:


  for (;;)
  {
      while target has unexpected data available
	  get target data one request at a time


      enqueue one request for an expected data transfer
  }


When the target has data available, and at least one request
exists on the active task list, the data available indication is
given on the completion status of the first ORB.  The initiator
will enqueue a new ORB for receiving target data if, and only if,
no request for target data has already been enqueued on the task
list.  This ORB would be associated with the "hanging read"
already required for independent communication in each direction.


The target would continue to process the ORB list until one of
the following states is reached:


  S1) the ORB list will be empty  (no active task set)


  S2) the ORB list processing stalls at a data transfer to the target,
      and the target has no data for the initiator.
      (no more target buffer space, and no reason to abort the task set)


  S3) the ORB list processing stalls at a data transfer to the initiator
      (initiator expects data from the target, but none is currently
       available)


When data becomes available, the following transitions take place:


  From S1
    the target signals Data Available via unsolicited status;
    the initiator enqueues one ORB to receive the data;
    the target resumes processing the ORB;
    on completion of the request, the target indicates whether
      or not more data is available.


  From S2
    the target aborts all the requests on the task list and indicates
      that data is available for the initiator on each request;
    the initiator enqueues one ORB to receive the data;
    the target resumes processing the ORB;
    on completion of the request, the target indicates whether
      or not more data is available.


    When the target has no more data available, the initiator
      requeues the aborted requests.


  From S3
    the target continues processing the task set


The only ineffeciency occurs when the target doesn't behave the way
the initiator expects.


  If we are doing unidirectional printing, then there is no data
  for the initiator, and the task set is never aborted.


  If we are interacting with the device, and it behaves as expected,
  then there is no unexpected data for the initiator, so the task
  set is never aborted.  (For interactive Postscript, scanning models,
  and request/reply paradigms like SNMP)


  If the target doesn't behave as expected and has lots of unsolicited
  data for the initiator, the target aborts the current task set and
  the initiator pauses sending data to the target until the target has
  no more data for the initiator.


The worst-case scenario occurs if the target keeps generating bursts
of unexpected data for the initiator and the task sets are perpetually
aborted.  The net effect of this is minimized simply by minimizing
the length of the active task set!  Having 2-4 data transfer requests
queued  (e.g. double-buffering) may be sufficient (for most applications)
to keep the task list running and the target busy.




> I think that aborting tasks implies subsequent task retries, and may
> not be efficient.


Yes, aborting tasks implies subsequent task retries.
The overhead is in the target (pre) fetching the ORBs
in order to abort them, and in requeuing the task set
when the data available indication disappears.


But don't forget that the maximum data transfer size is known,
so the target doesn't need to fetch any real data until it knows
that it can complete the request!


> It seems natural to make two independent logins for each direction,
> one for down-link and another for up-link by using the idea to map
> them into logical units. Furthermore, by extending this to allow to
> allocate up-link in reverse fashion (i.e., the target of down-link
> makes a login to the initiator of down-link), the link between two
> devices will become symmetric if both ends have both initiator and
> target functionality.
> 
> Any suggestions?


Haven't we been down this road before?  (Yes, and rejected it.)




> --
>  Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
>  Office Imaging Products Development Center 3
>  CANON INC.
> 





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


From carterk at us.ibm.com  Thu Feb 12 18:25:18 1998
From: carterk at us.ibm.com (Keith Carter)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Hotel reservations for the Hyatt
Message-ID: <199802121824.KAA26099@hpsdlgj1.sdd.hp.com>

Earlier today (Thursday, 2/12), the Hyatt hotel mistakenly told some people I
was holding a block of rooms that I would reserve on everyone's behalf.  This
misunderstanding has been corrected.  Everyone who was so informed, should make
their own reservation with the hotel under "Printer Working Group" per our
original plan.  The hotel phone number is 512-477-1234.  Also, please continue
to send me pings on your attendance at the meetings so we have the most
accurate headcount possible for the meetings.


Thanks...


Keith Carter
Senior Software Engineer
IBM Network Computing Software Division in Austin, Texas
internet email: carterk@us.ibm.com
Notes email: Keith Carter/Austin/IBM@IBMUS
phone: 512-838-2155
tie-line: 678-2155
fax: 512-838-0169

From Nagasaka.Fumio at exc.epson.co.jp  Fri Feb 13 05:54:02 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:48 2009
Subject: [PP1394:00147] Re: P1394> 1284.4 over SBP-2
In-Reply-To: <[PP1394:00147] Re: P1394> 1284.4 over SBP-2>
Message-ID: <199802121824.KAA26099@hpsdlgj1.sdd.hp.com>

Greg Shue wrote:
>To highlight the issue:
>   Exactly how does an initiator peer which supports CBT receive a 
>   Credit packet from the target at any indeterminate time?
>This is not provided directly by 1284.4.  How are you planning on 
>solving it for your implementation of option A?


1)	The initiator place $B!H(JCreditRequest$B!I(J packet in an out-ORB.(J
2)	If the target find an in-ORB in the linked list of ORBs, target
fill out
	the buffer associated this ORB with $B!H(JCreditRequestReply$B!I(J
packet.
3)	If the target could not find any in-ORB in the linked list of
ORB,
then the target send unsolicited status which requests the initiator
to provide an in-ORB in the list. Then go to step #2. 


Am I missing any steps?
I think step #3 becomes overhead. So CBT supportive SBP-2 profile
does not mark higher speed than pure SBP-2 transaction.


--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


		-----Original Message-----
		From:	Greg Shue [SMTP:gregs@sdd.hp.com]
		Sent:	Friday, February 13, 1998 4:58 AM
		To:	pp1394 ML
		Subject:	[PP1394:00147] Re: P1394> 1284.4 over
SBP-2


		> 
		> 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_000_01BD3784.4C5B70D6
		> Content-Type: text/plain
		> 
		> Dear Eric,
		> Dear Larry,
		> 
		> Please find an attached document which shows issue
Eric and myself
		> had discussed at December 3, 1997.
		>  <<Generation.PDF>> 
		> I am writing printer drivers that covers first
generation of 1394
		> printing.
		> These printer drivers are supporting option A.
		> <<
		> A-	1284.4 with SBP-2
		> B-	New SBP-2 command set with SBP-2
		> >>
		> I also prefer to choose option A at least in these
couple of years. One
		> of my reason is market reason same as Larry. Another
my reason is
		> technical reason. As I mentioned before, a target peer
which supports
		> CBT allows initiator peers to send ORBs safely. Any
data link layer
		> which services only one data path has difficulties to
support multiple
		> logical channels. Because, if once one of logical
channels had been
		> stalled, other requests that goes same data path will
be stalled.
		> The CBT set the data link layer free from these
difficulties.


		Yes, any link which supports only one data path has
difficulties
		to support multiple logical channels.


		This is exactly why I identified the major issue between
option A
		and option B as whether multiple functions within a
device are
		provided via:


		  MUX layer for multiple functions access presented as
one Unit (option A)
		vs.
		  separate units for each function  (option B)


		This is really the choice between the two options.






		The other topic of discussion under this thread deals
with how to
		use SBP-2 to provide independent, opposing,
unidirectional data
		streams over the same login.  Whether option A or option
B is
		chosen, the issue of providing the specified
bidirectional
		service to the layer above SBP-2 still exists.  And, I
think it's
		exactly the same issue.


		To highlight the issue:


		  Exactly how does an initiator peer which supports CBT
receive
		  a Credit packet from the target at any indeterminate
time?


		This is not provided directly by 1284.4.  How are you
planning on
		solving it for your implementation of option A?




		> -------------------------------
		> Fumio Nagasaka
		> Epson Software Development Laboratory Inc.
		> Tel +81 268 25 4111,  Fax +81 268 25 4627
		> E-mail to nagasaka.fumio@exc.epson.co.jp




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

From Nagasaka.Fumio at exc.epson.co.jp  Fri Feb 13 05:27:28 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <199802121824.KAA26099@hpsdlgj1.sdd.hp.com>

I agree with Stephen,
> Also, I don$B!G(Jt believe any of the chip manufacturers support SBP-2 for(J
both target and initiator.


Do we need to develop a firmware which supports two LINK ICs
one for initiator and one for target? 
I think $B!H(Jyes$B!I(J. Because typical LINK IC has only one input FIFO in(J
each chip. And it is very difficult to implement two different software
stack utilizing one i/o channel.
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


		-----Original Message-----
		From:	Stephen Holmstead [SMTP:stephen@hpb16977.boi.hp.
com]
		Sent:	Thursday, February 12, 1998 1:30 AM
		To:	'Turner, Randy'; 'Brian Batchelder';
p1394@pwg.org
		Subject:	RE: P1394> Rough SBP-2 & IP1394 core
component ROM sizes


		My experiences in the past is that combining target AND
initiator
		functions into a single device is VERY difficult.  The
complexity of the
		state tables and ambiguities that can arise make it very
difficult.
		Also, I don't believe any of the chip manufacturers
support SBP-2 for
		both target and initiator.  In my opinion, it's NOT just
a matter of
		adding the 15K for the target and 15K for the initiator.
The target and
		initiator have vastly different functions.   Designing a
model that did
		both (well) would be a challenge.  It was problems like
this that fueled
		many of the AEN (asynchronous event notification)
debates.


		Stephen


		> -----Original Message-----
		> From:	Turner, Randy [SMTP:rturner@sharplabs.com]
		> Sent:	Monday, February 09, 1998 1:03 PM
		> To:	'Brian Batchelder'; p1394@pwg.org
		> Subject:	RE: P1394> Rough SBP-2 & IP1394 core
component ROM sizes
		> 
		> 
		> I am very interested in the combined target/initiator
footprint as
		> well.
		> 
		> Thx
		> 
		> Randy
		> 
		> 
		> 	-----Original Message-----
		> 	From:	Brian Batchelder
[SMTP:brianb@vcd.hp.com]
		> 	Sent:	Monday, February 09, 1998 9:37 AM
		> 	To:	p1394@pwg.org
		> 	Subject:	Re: P1394> Rough SBP-2 & IP1394
core component
		> ROM sizes
		> 
		> 	At 02:04 PM 2/6/98 -0800, Greg Shue wrote:
		> 
		> 	[snip]
		> 
		> 	>I approached them about sharing some rough
estimates of code
		> size
		> 	>for the IP1394 glue, SBP-2 target and
initiator, and 1394 bus
		> 	>manager modules to get a feel for how "heavy"
the protocol
		> 	>implementations really are.  They graciously
shared the flowing
		> 	>estimates with us, and certainly deserve our
thanks.  Since the
		> 	>technology is still being developed, these
implementations are
		> 	>certainly going to be tuned and the numbers
will change a
		> little
		> 	>bit.
		> 	>
		> 	>  Component                Rough ROM size
(KBytes)
		> 	>  ---------
-----------------------
		> 	>  SBP-2 initiator core     15 +/- 5
		> 	>  SBP-2 target core        15 +/- 5  (incl.
Mgmt+Fetch agent,
		> no exec agent)
		> 
		> 	Any idea how big a combined SBP-2
target/initiator would be?
		> 15-30K? ;-)
		> 
		> 	[snip]
		> 
		> 	Brian
		> 
		>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
		> ~
		> 	Brian Batchelder      | Hewlett-Packard      |
		> mailto:brianb@vcd.hp.com  
		> 	Connectivity Futurist | 1115 SE 164th Ave.   |
Phone: (360)
		> 212-4107  
		> 	DeskJet Printers      | Vancouver, WA  98684 |
Fax:   (360)
		> 212-4227

From Nagasaka.Fumio at exc.epson.co.jp  Fri Feb 13 06:35:11 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:48 2009
Subject: P1394> 1284.4 over SBP-2
Message-ID: <199802121824.KAA26099@hpsdlgj1.sdd.hp.com>

Hi,


Alan wrote:
<<
     I think Shimura san has some good points at the end of his message 
     that goes to the heart of what is still not clear with the option B


     proposal. I think we need to work up some example scenarios and 
     explore exactly how this will work. Greg Shue got any ideas here.
>>    
Alan, I think Shimura san has pointed out one important thing here,$B!D(J


Akihiro Shimura wrote:
<<
		If target request data transfer by "Data Available" flag
in certain
		status block, initiator will subsequently append "SND
data-in" ORB in
		the current task list. It will be possible for the
target to check if
		there is a "SND data-in" ORB in the task list BEFORE the
initiator
		appends the "SND data-in" ORB. After finding there is no
"SND data-in"
		ORB, the target may issue another unsolicited status
which indicates
		"Data Available". By this status, the initiator may
append one more
		(total two) "SND data-in" ORB in the task list. After
that, the
		target will need to abort the excessive ORB.
Is this a way the SBP-2 only solution works?
>>


I would like to introduce these rules shown below,
1)	The initiator clear Unsolicited_Status_Enable register to forbid
the target
	to issue unsolicited status which says "Data Available", while
the initiator
	is appending new ORBs in the list.
2)	The target shall observe Unsolicited_Status_Enable register,
whether or not it is
	set to one, before it scans linked list of ORBs.
3)	When the target found Unsolicited_Status_Enable register is set
to one,
and there is no in-ORB in the list, then the target may send unsolicited
status.


Then the initiator will not generate too many in-ORBs in the list.


Akihiro Shimura wrote:
<<
		It seems natural to make two independent logins for each
direction,
		one for down-link and another for up-link by using the
idea to map
		them into logical units. Furthermore, by extending this
to allow to
		allocate up-link in reverse fashion (i.e., the target of
down-link
		makes a login to the initiator of down-link), the link
between two
		devices will become symmetric if both ends have both
initiator and
target functionality.
>>
It is interesting. I had same idea to use two logins in last summer. But
my reason was different.
If we use one up-link and one down-ink, can we use multiple logical
channels in each direction? Then how can we prevent *one simple
uni-directional data path* to be stalled?
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


		-----Original Message-----
		From:	Akihiro Shimura
[SMTP:shimura@pure.cpdc.canon.co.jp]
		Sent:	Friday, February 13, 1998 12:05 AM
		To:	Greg Shue
		Cc:	p1394@pwg.org; P1284_3@lexmark.com; Larry Stein
		Subject:	Re: P1394> 1284.4 over SBP-2


		On Tue, 10 Feb 1998 19:21:19 -0800 (PST)
		Greg Shue <gregs@sdd.hp.com> wrote:


		> > I await your responses.
		> 
		> OK, here we go...


		OK, I'll follow...


		> Larry Stein wrote:
		> 
		> > At this point in time we have apparently narrowed
our potential solutions
		> > to the following:
		> > 
		> > A- 1284.4 with SBP-2
		> > B-  New SBP-2 command set with SBP-2


		(snip)


		> As I understood it, the ability for 'a peripheral to
operate over
		> various interfaces without requiring major
architectural changes
		> to the product' is provided by meeting the specified
transport
		> service requirements.  As long as the transport
requirements are
		> met, no architectural changes are required of the
product.  Thus,
		> the transport layers are all modular with respect to
the product.


		I agree. This was original intent of the HPT which
Ueda-san and I
		introduced from last June meeting.


		(snip)


		> Given all of this, I am compelled to support option B.


		Basically, I also support to consider option B, but it
is still not
		clear for me how the data transfer of each direction is
done
		independently within single login in SBP-2 only
solution.


		If target request data transfer by "Data Available" flag
in certain
		status block, initiator will subsequently append "SND
data-in" ORB in
		the current task list. It will be possible for the
target to check if
		there is a "SND data-in" ORB in the task list BEFORE the
initiator
		appends the "SND data-in" ORB. After finding there is no
"SND data-in"
		ORB, the target may issue another unsolicited status
which indicates
		"Data Available". By this status, the initiator may
append one more
		(total two) "SND data-in" ORB in the task list. After
that, the
		target will need to abort the excessive ORB.
		Is this a way the SBP-2 only solution works?


		I think that aborting tasks implies subsequent task
retries, and may
		not be efficient.
		It seems natural to make two independent logins for each
direction,
		one for down-link and another for up-link by using the
idea to map
		them into logical units. Furthermore, by extending this
to allow to
		allocate up-link in reverse fashion (i.e., the target of
down-link
		makes a login to the initiator of down-link), the link
between two
		devices will become symmetric if both ends have both
initiator and
		target functionality.


		Any suggestions?


		--
		 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
		 Office Imaging Products Development Center 3
		 CANON INC.

From ueda at slab.tnr.sharp.co.jp  Fri Feb 13 21:44:35 1998
From: ueda at slab.tnr.sharp.co.jp (Toru Ueda)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
In-Reply-To: <D10983CAC30DD111B41400805FA6A1C1272305@admsrvnt02.enet.sharplabs.com>
Message-ID: <9802131244.AA15847@slab.slab.tnr.sharp.co.jp>

I don't want to make any confusion about PC printing protocol. This is
only for your information.


>From consumer device point of view, "symmetrical" is the essential
feature of the protocol.
For example, a digital still camera wants to send its image data to
printers.  Also the same camera wants to receive image data from the 
other still cameras. We want to use the same protocol for both use.


These are three essential features for consumer device.


1) Bi-directional
  Each side can send and receive data.
  SBP2 supports bi-directional feature.
  
2) "True" bi-directional
  Each side can send and receive data at any time.
  Alan's architecture supports "true" bi-directional feature by using
  transmit buffer, receive buffer and unsolicited status.
  
3) Symmetrical
  Each side has the same architecture.
  This is completely different from bi-directional issue.
  
Consumer device needs these three features and the protocol must be
simple.


If SBP2 implementation needs 30K for initiator and target, it might be
difficult to use it for consumer device.


Toru Ueda
Software labs.
Sharp Corp.


On Wed, 11 Feb 1998 08:35:10 -0800
"Turner, Randy" <rturner@sharplabs.com> wrote:


> 
> 
> I didn't know chip sets offered "explicit" support for SBP-2. OHCI
> maybe, but I hadn't seen the chip set feature in the brochure for
> "chip-level SBP-2 support".
> 
> Also, since 1394 is a peer-to-peer interface, anyone developing a
> peer-to-peer device (like the majority of the Japanese electronics
> industry), would have to essentially duplicate the functionality of
> SBP-2 initiator and target, whether they actually use SBP-2 to do this,
> or some other (potentially proprietary) method for implementing
> peer-to-peer functionality.
> 
> Randy
> 
> 
> 
> 	-----Original Message-----
> 	From:	Stephen Homestead [SMTP:stephen@hpb16977.boi.hp.com]
> 	Sent:	Wednesday, February 11, 1998 8:30 AM
> 	To:	'Turner, Randy'; 'Brian Batchelder'; p1394@pwg.org
> 	Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> ROM sizes
> 
> 	My experiences in the past is that combining target AND
> initiator
> 	functions into a single device is VERY difficult.  The
> complexity of the
> 	state tables and ambiguities that can arise make it very
> difficult.
> 	Also, I don't believe any of the chip manufacturers support
> SBP-2 for
> 	both target and initiator.  In my opinion, it's NOT just a
> matter of
> 	adding the 15K for the target and 15K for the initiator.  The
> target and
> 	initiator have vastly different functions.   Designing a model
> that did
> 	both (well) would be a challenge.  It was problems like this
> that fueled
> 	many of the AEN (asynchronous event notification) debates.
> 
> 	Stephen
> 
> 	> -----Original Message-----
> 	> From:	Turner, Randy [SMTP:rturner@sharplabs.com]
> 	> Sent:	Monday, February 09, 1998 1:03 PM
> 	> To:	'Brian Batchelder'; p1394@pwg.org
> 	> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> ROM sizes
> 	> 
> 	> 
> 	> I am very interested in the combined target/initiator
> footprint as
> 	> well.
> 	> 
> 	> Thx
> 	> 
> 	> Randy
> 	> 
> 	> 
> 	> 	-----Original Message-----
> 	> 	From:	Brian Batchelder [SMTP:brianb@vcd.hp.com]
> 	> 	Sent:	Monday, February 09, 1998 9:37 AM
> 	> 	To:	p1394@pwg.org
> 	> 	Subject:	Re: P1394> Rough SBP-2 & IP1394 core
> component
> 	> ROM sizes
> 	> 
> 	> 	At 02:04 PM 2/6/98 -0800, Greg Shue wrote:
> 	> 
> 	> 	[snip]
> 	> 
> 	> 	>I approached them about sharing some rough estimates of
> code
> 	> size
> 	> 	>for the IP1394 glue, SBP-2 target and initiator, and
> 1394 bus
> 	> 	>manager modules to get a feel for how "heavy" the
> protocol
> 	> 	>implementations really are.  They graciously shared the
> flowing
> 	> 	>estimates with us, and certainly deserve our thanks.
> Since the
> 	> 	>technology is still being developed, these
> implementations are
> 	> 	>certainly going to be tuned and the numbers will change
> a
> 	> little
> 	> 	>bit.
> 	> 	>
> 	> 	>  Component                Rough ROM size (KBytes)
> 	> 	>  ---------                -----------------------
> 	> 	>  SBP-2 initiator core     15 +/- 5
> 	> 	>  SBP-2 target core        15 +/- 5  (incl. Mgmt+Fetch
> agent,
> 	> no exec agent)
> 	> 
> 	> 	Any idea how big a combined SBP-2 target/initiator would
> be?
> 	> 15-30K? ;-)
> 	> 
> 	> 	[snip]
> 	> 
> 	> 	Brian
> 	> 
> 	>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 	> ~
> 	> 	Brian Batchelder      | Hewlett-Packard      |
> 	> mailto:brianb@vcd.hp.com  
> 	> 	Connectivity Futurist | 1115 SE 164th Ave.   | Phone:
> (360)
> 	> 212-4107  
> 	> 	DeskJet Printers      | Vancouver, WA  98684 | Fax:
> (360)
> 	> 212-4227
> 

From Nagasaka.Fumio at exc.epson.co.jp  Fri Feb 13 07:47:08 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:48 2009
Subject: P1394> 1284.4 over SBP-2
Message-ID: <9802131244.AA15847@slab.slab.tnr.sharp.co.jp>

Hi Greg,


Your opinion persuade me 95%,$B!D(J I like your opinion.(J
However I could not agree these points.


Greg Shue wrote:
<<
If $B!H(Jbest$B!I(J is thought of in terms of developers and development effort,(J
then there is no significant difference between providing the SBP-2 only
solution or the SBP-2 portion of a combined solution.  There will be
additional effort for a combined solution if a 1284.4 driver needs to be
developed.
If $B!H(Jbest$B!I(J is thought of in terms of (availability of) OS support,(J
then the SBP-2 only solution is preferred because a greater portion
of the total solution already is provided by or is committed to
by OS vendors.
>>


If we choose 1284.4 as transport layer in PC printing architecture,
we can use same transport layer to cover USB, 1394 and conventional
parallel port. And if we adopt socket API on 1284.4 service, then we
can use same interface for any local devices and for any network
devices.


This feature greatly decrease development efforts to make protocol
stack in PC printing area. And it would provide better usability even
for end users.


If we choose new transport for SBP-2/1394 stack, then we need to
develop different middle device driver to cover rest of other I/O(s). 


How do you think this point?
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


		-----Original Message-----
		From:	Greg Shue [SMTP:gregs@sdd.hp.com]
		Sent:	Wednesday, February 11, 1998 12:21 PM
		To:	Larry Stein
		Cc:	p1394@pwg.org; P1284_3@lexmark.com
		Subject:	Re: P1394> 1284.4 over SBP-2




		> I await your responses.


		OK, here we go...




		Larry Stein wrote:


		> At this point in time we have apparently narrowed our
potential solutions
		> to the following:
		> 
		> A- 1284.4 with SBP-2
		> B-  New SBP-2 command set with SBP-2
		> 
		> As many of you are aware, I'm primarily in support of
option A as the
		> preferred solution.  I'd like to take this opportunity
to provide some of
		> my reasoning and get feedback from you.
		> 
		> My support for this solution is not necessarily a
technical reason, but a
		> market reason.  As Greg Shue et al pointed out at the
Maui meeting, it is
		> possible to provide the required functionality by
defining a new Command
		> Set for SBP-2.  This would provide a transport
solution for 1394 that is
		> based solely on the SBP-2 protocol.  Technically, this
is probably a better
		> solution than option A.
		> 
		> My question is "Is this really the best solution for
the market today?".
		> Many of us have expended great effort in developing
the IEEE P1284.4
		> standard.  One of the purposes and goals of  the
development was to create
		> a datalink independent transport standard that could
be used over the
		> parallel port and other physical interfaces.
		> 
		> The intent here was to create a standard that would
allow a peripheral to
		> operate over various interfaces without requiring
major architectural
		> changes to the product.  In other words, a modular
approach to the
		> peripheral design.  A printer or MFP device could be
developed to work with
		> 1284.4 over parallel today, and 'easily' adapted to
work over 1394
		> tomorrow.  The host application interface may not even
know the difference.
		> 


		As I understood it, the ability for 'a peripheral to
operate over
		various interfaces without requiring major architectural
changes
		to the product' is provided by meeting the specified
transport
		service requirements.  As long as the transport
requirements are
		met, no architectural changes are required of the
product.  Thus,
		the transport layers are all modular with respect to the
product.
		(I think this is also why the PWG has not tried to
eliminate a
		TCP/IP printing solution.  :-)




		The main difference between options A and B is whether
multiple
		services are made available through a 1284.4 MUX layer,
or
		through a combination of Unit Directories and Logical
Unit
		Numbers.  The command set features needed for a combined
		1284.4/SBP-2 solution are essentially identical as for
an
		SBP-2 only solution (as shown below).


		  In order to provide a combined SBP-2/1284.4 solution,
an
		  SBP-2 command set must be provided which meets the
Data Link
		  requirements spelled out for 1284.4.  These are:


		    R1) Register/Unregister transport layer with the
Data Link layer
		    R2) Packet Data Transfer - error free, in order, as
a whole
		    R3) Asynchronous Operation - no polling shall be
required.


		  In order to map this within SBP-2, then the command
set must
		  provide (at least) the following features:


		    F1) Transient link interruption support
			  (to support R2 and R3)
		    F2) Non-transient link loss indication  (to support
F1)
		    F3) Extended SBP-2 Access Control to the transport
			  interface (to support F1)


		    F4) SBP-2 ORB execution model for packet transfers
			  (to support R2 and R3)
		    F5) Encapsulating of 1284.4 packets into ORBs
			  (to support R2)
		    F6) Policy to determine maximum DL packet size
			  (to support R2 and F1)
		    F7) Policy for how 1284.4 dialogue maps into SBP-2
access
			 control (to support R2, R3, and F1)


		    F8) Standard mechanism for indicating existence of
1284.4
			 peer (to support R1)


		    So, any of these features which are common with an
SBP-2 only
		    solution are outside the scope of concern here.
(For the
		    unfamiliar, they all are provided in the (very
rough) SBP-2
		    only proposal presented at the January PWG 1394
meeting.)


		These features are also those required for an SBP-2 only
solution.
		Since these are in common, they _don't_ affect the
choice of option A
		vs. option B.




		I can't give an answer to Larry's question directly,
because "best"
		is rather subjective.  What's "best" for a customer
might not be
		"best" for a developer, and that might not be "best" for
a
		technology, which are all indirectly related to what is
"best"
		for the market.  I tried to identify above what are not
areas of
		tradeoffs between the two options so that we can look at
what are.




		If "best" is thought of in terms of market, then (I
suppose)
		supportability and deployment of the solution(s) matter
the most,
		because the 'market' has almost no history.  There
really is no
		legacy issue which makes either choice A or choice B
preferred,
		even though there are "legacy" printing solutions which
will need
		to be supported (i.e.  AVC, IP1394).  So, each of the
following
		areas become signficant:




		If "best" is thought of in terms of providing the
transport
		services outlined by the requirements, then there is no
		signficant difference between the SBP-2 only solution or
the
		combined solution.


		If "best" is thought of in terms of developers and
development
		effort, then there is no significant difference between
providing
		the SBP-2 only solution or the SBP-2 portion of a
combined
		solution.  There will be additional effort for a
combined
		solution if a 1284.4 driver needs to be developed.


		If "best" is thought of in terms of (availability of) OS
support,
		then the SBP-2 only solution is preferred because a
greater portion
		of the total solution already is provided by or is
committed to
		by OS vendors.


		If "best" is thought of in terms of product cost, then
the SBP-2
		only solution is preferred because it has fewer layers.


		If "best" is thought of in terms of performance, then
the SBP-2
		only solution is preferred because it isn't limited to
64-KByte
		packets.


		If "best" is thought of in terms of 1394 bus usage, then
the
		SBP-2 only solution is preferred because it doesn't have
the CBT
		crediting traffic of 1284.4.


		If "best" is thought of in terms of compliance
testability, then
		the SBP-2 only solution is preferred because it is
simpler and
		has fewer layers.


		If "best" is thought of in terms of availability
customer
		solutions, then the SBP-2 only solution is preferred
because of
		it's smaller footprint (which makes it more attractive
to
		integrate into more devices) and it's spreading use for
varying
		types of services on 1394.




		> I think that this is the primary reasons for choosing
option A.  It sends a
		> clear statement to peripheral and OS vendors that
1284.4 is the preferred
		> transport interface for printer and MFP peripherals.
We back this up by
		> providing solutions for parallel (1284.3) and for
1394.  This is not a
		> stagnant industry and certainly new interfaces will
appear in the future.
		> I think it would be a great service that we provide a
clear migration path
		> between interfaces that do not require redesign of the
entire system.


		Unfortunately, that message of 1284.4 being "the
preferred
		transport interface for printers" has been lost in the
shuffle.
		There are (currently) four transport protocols being
defined on
		1394 for printing.  These are:


		  + AVC (for video snapshot)
		  + DPP (for non-PC device-to-device)
		  + PWG 1394 solution(s) (being discussed)
		  + IP1394


		I also haven't seen it get embraced for standardization
on USB,
		where hardware limitations and lack of a multiplexing
transport
		protocol solution identify a hole which 1284.4 can fill.




		When this is added to (Apple's) Eric Anderson's thoughts
of:


		  - Emulating a dead technology with new technology may
yield
		    short-term savings in implementation, but at the
expense of
		    long-term losses in performance.  (philisophical)


		  - Amazingly, reason prevailed, and Tailgate was
abandoned in
		    favor of a pure SBP-2 protocol for disk drives.
(historical)


		  - From what I have seen of how this (1284.4 over
SBP-2) works,
		    it is quite inefficient, with lots of unsolicited
status
		    requests and in general lots of hand-holding by the
CPU on the
		    initiator.  This is not what SBP-2 was designed for.
(perceptual)


		  - Used properly, SBP-2 allows huge data transfers that
can proceed
		    at the pace of the consumer (printer), with no
hand-holding by
		    the host (computer)... SBP-2 and OpenHCI make this
possible - but
		    only if protocols are designed with care to avoid
needless
		    interruption of the host.  (practical)


		  - 1394 is far more "future friendly" and scalable than
other
		    interconnects were at their introductions...  The
more inefficient
		    the protocol we choose, the more demand there will
be for
		    ever-faster interconnects.  A well-designed,
efficient protocol
		    can last a very long time, and serve everyone's
needs better during
		    that time.  (consequential)


		  - To conclude, I want to ask a simple question:  Has
anyone run
		    this idea past Microsoft?  Microsoft killed off
Tailgate, and
		    my guess is that they may have similar feelings
about printing.
		    Market reality is that we'll all follow whatever
they decide,
		    so it really makes sense to get them involved.
(REALISTIC!!)


		And (from a previous posting of Eric's):


		 -  Microsoft says that their treatment of printers will
be
		    different.  They will only login to printers and
other shared
		    devices when they actually want to use the printer.
So a printer
		    with only one login could be shared by several
Windows systems.
		    Apple plans to do the same thing for printers using
SBP-2.


		And the most quotable quote from the January 98 PWG 1394
meeting:


		  "Every protocol looks light until it's implemented."




		Given all of this, I am compelled to support option B.




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

From rturner at sharplabs.com  Fri Feb 13 09:08:57 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:48 2009
Subject: P1394> 1284.4 over SBP-2
Message-ID: <9802131244.AA15847@slab.slab.tnr.sharp.co.jp>

If we want to keep the application programming interface consistent
across all different kind of link types, then I think a socket interface
is the best way to do this. Note that this application interface only
provides access to a "transport" stack. The actual application protocol
used (DPP, IPP, 1284.1, etc.) would still be done by the application.


And if we want to use a socket interface as the common transport
interface for applications, this socket interface would support all of
the layering models that have been proposed thus far, including, but not
limited to:
				1284.4 over SBP-2
				SBP-2 over transaction layer (OHCI,
etc.)
				1284.4 over 1284.3
				TCP/IP over ethernet
				TCP/IP over 1394


Note that the SBP-2 over transaction layer option would also support DPP
over socket interface as well.


My point from all of this is that for the layering models discussed so
far, we don't have to worry about providing a common API for
applications. So we can keep our discussion focused on relevant
technical transport issues.




Randy




	-----Original Message-----
	From:	Nagasaka Fumio [SMTP:Nagasaka.Fumio@exc.epson.co.jp]
	Sent:	Friday, February 13, 1998 4:47 AM
	To:	Greg Shue; Larry Stein
	Cc:	p1394@pwg.org; P1284_3@lexmark.com; PWG-C mailing
	Subject:	RE: P1394> 1284.4 over SBP-2


	Hi Greg,


	Your opinion persuade me 95%,? I like your opinion.
	However I could not agree these points.


	Greg Shue wrote:
	<<
	If ?best? is thought of in terms of developers and development
effort,
	then there is no significant difference between providing the
SBP-2 only
	solution or the SBP-2 portion of a combined solution.  There
will be
	additional effort for a combined solution if a 1284.4 driver
needs to be
	developed.
	If ?best? is thought of in terms of (availability of) OS
support,
	then the SBP-2 only solution is preferred because a greater
portion
	of the total solution already is provided by or is committed to
	by OS vendors.
	>>


	If we choose 1284.4 as transport layer in PC printing
architecture,
	we can use same transport layer to cover USB, 1394 and
conventional
	parallel port. And if we adopt socket API on 1284.4 service,
then we
	can use same interface for any local devices and for any network
	devices.


	This feature greatly decrease development efforts to make
protocol
	stack in PC printing area. And it would provide better usability
even
	for end users.


	If we choose new transport for SBP-2/1394 stack, then we need to
	develop different middle device driver to cover rest of other
I/O(s). 


	How do you think this point?
	--------------------------------------------
	-------------------------------
	Fumio Nagasaka
	Epson Software Development Laboratory Inc.
	Tel +81 268 25 4111,  Fax +81 268 25 4627
	E-mail to nagasaka.fumio@exc.epson.co.jp


			-----Original Message-----
			From:	Greg Shue [SMTP:gregs@sdd.hp.com]
			Sent:	Wednesday, February 11, 1998 12:21 PM
			To:	Larry Stein
			Cc:	p1394@pwg.org; P1284_3@lexmark.com
			Subject:	Re: P1394> 1284.4 over SBP-2




			> I await your responses.


			OK, here we go...




			Larry Stein wrote:


			> At this point in time we have apparently
narrowed our
	potential solutions
			> to the following:
			> 
			> A- 1284.4 with SBP-2
			> B-  New SBP-2 command set with SBP-2
			> 
			> As many of you are aware, I'm primarily in
support of
	option A as the
			> preferred solution.  I'd like to take this
opportunity
	to provide some of
			> my reasoning and get feedback from you.
			> 
			> My support for this solution is not
necessarily a
	technical reason, but a
			> market reason.  As Greg Shue et al pointed out
at the
	Maui meeting, it is
			> possible to provide the required functionality
by
	defining a new Command
			> Set for SBP-2.  This would provide a transport
	solution for 1394 that is
			> based solely on the SBP-2 protocol.
Technically, this
	is probably a better
			> solution than option A.
			> 
			> My question is "Is this really the best
solution for
	the market today?".
			> Many of us have expended great effort in
developing
	the IEEE P1284.4
			> standard.  One of the purposes and goals of
the
	development was to create
			> a datalink independent transport standard that
could
	be used over the
			> parallel port and other physical interfaces.
			> 
			> The intent here was to create a standard that
would
	allow a peripheral to
			> operate over various interfaces without
requiring
	major architectural
			> changes to the product.  In other words, a
modular
	approach to the
			> peripheral design.  A printer or MFP device
could be
	developed to work with
			> 1284.4 over parallel today, and 'easily'
adapted to
	work over 1394
			> tomorrow.  The host application interface may
not even
	know the difference.
			> 


			As I understood it, the ability for 'a
peripheral to
	operate over
			various interfaces without requiring major
architectural
	changes
			to the product' is provided by meeting the
specified
	transport
			service requirements.  As long as the transport
	requirements are
			met, no architectural changes are required of
the
	product.  Thus,
			the transport layers are all modular with
respect to the
	product.
			(I think this is also why the PWG has not tried
to
	eliminate a
			TCP/IP printing solution.  :-)




			The main difference between options A and B is
whether
	multiple
			services are made available through a 1284.4 MUX
layer,
	or
			through a combination of Unit Directories and
Logical
	Unit
			Numbers.  The command set features needed for a
combined
			1284.4/SBP-2 solution are essentially identical
as for
	an
			SBP-2 only solution (as shown below).


			  In order to provide a combined SBP-2/1284.4
solution,
	an
			  SBP-2 command set must be provided which meets
the
	Data Link
			  requirements spelled out for 1284.4.  These
are:


			    R1) Register/Unregister transport layer with
the
	Data Link layer
			    R2) Packet Data Transfer - error free, in
order, as
	a whole
			    R3) Asynchronous Operation - no polling
shall be
	required.


			  In order to map this within SBP-2, then the
command
	set must
			  provide (at least) the following features:


			    F1) Transient link interruption support
				  (to support R2 and R3)
			    F2) Non-transient link loss indication  (to
support
	F1)
			    F3) Extended SBP-2 Access Control to the
transport
				  interface (to support F1)


			    F4) SBP-2 ORB execution model for packet
transfers
				  (to support R2 and R3)
			    F5) Encapsulating of 1284.4 packets into
ORBs
				  (to support R2)
			    F6) Policy to determine maximum DL packet
size
				  (to support R2 and F1)
			    F7) Policy for how 1284.4 dialogue maps into
SBP-2
	access
				 control (to support R2, R3, and F1)


			    F8) Standard mechanism for indicating
existence of
	1284.4
				 peer (to support R1)


			    So, any of these features which are common
with an
	SBP-2 only
			    solution are outside the scope of concern
here.
	(For the
			    unfamiliar, they all are provided in the
(very
	rough) SBP-2
			    only proposal presented at the January PWG
1394
	meeting.)


			These features are also those required for an
SBP-2 only
	solution.
			Since these are in common, they _don't_ affect
the
	choice of option A
			vs. option B.




			I can't give an answer to Larry's question
directly,
	because "best"
			is rather subjective.  What's "best" for a
customer
	might not be
			"best" for a developer, and that might not be
"best" for
	a
			technology, which are all indirectly related to
what is
	"best"
			for the market.  I tried to identify above what
are not
	areas of
			tradeoffs between the two options so that we can
look at
	what are.




			If "best" is thought of in terms of market, then
(I
	suppose)
			supportability and deployment of the solution(s)
matter
	the most,
			because the 'market' has almost no history.
There
	really is no
			legacy issue which makes either choice A or
choice B
	preferred,
			even though there are "legacy" printing
solutions which
	will need
			to be supported (i.e.  AVC, IP1394).  So, each
of the
	following
			areas become signficant:




			If "best" is thought of in terms of providing
the
	transport
			services outlined by the requirements, then
there is no
			signficant difference between the SBP-2 only
solution or
	the
			combined solution.


			If "best" is thought of in terms of developers
and
	development
			effort, then there is no significant difference
between
	providing
			the SBP-2 only solution or the SBP-2 portion of
a
	combined
			solution.  There will be additional effort for a
	combined
			solution if a 1284.4 driver needs to be
developed.


			If "best" is thought of in terms of
(availability of) OS
	support,
			then the SBP-2 only solution is preferred
because a
	greater portion
			of the total solution already is provided by or
is
	committed to
			by OS vendors.


			If "best" is thought of in terms of product
cost, then
	the SBP-2
			only solution is preferred because it has fewer
layers.


			If "best" is thought of in terms of performance,
then
	the SBP-2
			only solution is preferred because it isn't
limited to
	64-KByte
			packets.


			If "best" is thought of in terms of 1394 bus
usage, then
	the
			SBP-2 only solution is preferred because it
doesn't have
	the CBT
			crediting traffic of 1284.4.


			If "best" is thought of in terms of compliance
	testability, then
			the SBP-2 only solution is preferred because it
is
	simpler and
			has fewer layers.


			If "best" is thought of in terms of availability
	customer
			solutions, then the SBP-2 only solution is
preferred
	because of
			it's smaller footprint (which makes it more
attractive
	to
			integrate into more devices) and it's spreading
use for
	varying
			types of services on 1394.




			> I think that this is the primary reasons for
choosing
	option A.  It sends a
			> clear statement to peripheral and OS vendors
that
	1284.4 is the preferred
			> transport interface for printer and MFP
peripherals.
	We back this up by
			> providing solutions for parallel (1284.3) and
for
	1394.  This is not a
			> stagnant industry and certainly new interfaces
will
	appear in the future.
			> I think it would be a great service that we
provide a
	clear migration path
			> between interfaces that do not require
redesign of the
	entire system.


			Unfortunately, that message of 1284.4 being "the
	preferred
			transport interface for printers" has been lost
in the
	shuffle.
			There are (currently) four transport protocols
being
	defined on
			1394 for printing.  These are:


			  + AVC (for video snapshot)
			  + DPP (for non-PC device-to-device)
			  + PWG 1394 solution(s) (being discussed)
			  + IP1394


			I also haven't seen it get embraced for
standardization
	on USB,
			where hardware limitations and lack of a
multiplexing
	transport
			protocol solution identify a hole which 1284.4
can fill.




			When this is added to (Apple's) Eric Anderson's
thoughts
	of:


			  - Emulating a dead technology with new
technology may
	yield
			    short-term savings in implementation, but at
the
	expense of
			    long-term losses in performance.
(philisophical)


			  - Amazingly, reason prevailed, and Tailgate
was
	abandoned in
			    favor of a pure SBP-2 protocol for disk
drives.
	(historical)


			  - From what I have seen of how this (1284.4
over
	SBP-2) works,
			    it is quite inefficient, with lots of
unsolicited
	status
			    requests and in general lots of hand-holding
by the
	CPU on the
			    initiator.  This is not what SBP-2 was
designed for.
	(perceptual)


			  - Used properly, SBP-2 allows huge data
transfers that
	can proceed
			    at the pace of the consumer (printer), with
no
	hand-holding by
			    the host (computer)... SBP-2 and OpenHCI
make this
	possible - but
			    only if protocols are designed with care to
avoid
	needless
			    interruption of the host.  (practical)


			  - 1394 is far more "future friendly" and
scalable than
	other
			    interconnects were at their introductions...
The
	more inefficient
			    the protocol we choose, the more demand
there will
	be for
			    ever-faster interconnects.  A well-designed,
	efficient protocol
			    can last a very long time, and serve
everyone's
	needs better during
			    that time.  (consequential)


			  - To conclude, I want to ask a simple
question:  Has
	anyone run
			    this idea past Microsoft?  Microsoft killed
off
	Tailgate, and
			    my guess is that they may have similar
feelings
	about printing.
			    Market reality is that we'll all follow
whatever
	they decide,
			    so it really makes sense to get them
involved.
	(REALISTIC!!)


			And (from a previous posting of Eric's):


			 -  Microsoft says that their treatment of
printers will
	be
			    different.  They will only login to printers
and
	other shared
			    devices when they actually want to use the
printer.
	So a printer
			    with only one login could be shared by
several
	Windows systems.
			    Apple plans to do the same thing for
printers using
	SBP-2.


			And the most quotable quote from the January 98
PWG 1394
	meeting:


			  "Every protocol looks light until it's
implemented."




			Given all of this, I am compelled to support
option B.




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

From bogus@does.not.exist.com  Fri Feb 13 12:07:52 1998
From: bogus@does.not.exist.com ()
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
In-Reply-To: <rturner@sharplabs.com>
Message-ID: <v04003a03b10a27e5dbea@[192.168.1.25]>

Regarding the note from Nagasaka Fumio:
>I agree with Stephen,
>> Also, I don$B!G(Jt believe any of the chip manufacturers support SBP-2
>>for(J
>both target and initiator.
>
>Do we need to develop a firmware which supports two LINK ICs
>one for initiator and one for target?
>I think $B!H(Jyes$B!I(J. Because typical LINK IC has only one input
>FIFO in(J
>each chip. And it is very difficult to implement two different software
>stack utilizing one i/o channel.


1) All of the Pele-based designs (OpenHCI, among others) do an excellent
job as both initiator and target ... indeed, they can support an almost
unlimited number of simultaneous initiator and target contexts
simultaneously. They are, however, PCI bus master designs ... so unless you
are building a relatively high-end printer, they may not be in your price
range (but check with IC suppliers like Sony, Symbios, and FFM for Pele,
and virtually everyone about OpenHCI).


2) Sony has a fine SBP-2 target part that is also useful for initiator use,
but requires more software and external DMA interaction.


3) The number of input FIFOs is not too important, except as an
optimization, particularly when inbound bus bridging is provided (useful
for CPU-type initiators). The key is to have good receive DMA into the
controller memory.


4) 1394 is quite different from traditional "I/O channels" ... mainly
because it's really a memory bus. If you treat it correctly (as a memory
bus), then it is quite simple to implement multiple stacks using the same
hardware. Indeed, our own proto systems implement as many as 4 protocol
stacks using relatively primative hardware.


===========================================================================
Michael D. Johas Teener, Chief Technical Officer & Chairman of the Board
Zayante, Inc., 269 Mt. Hermon Rd. #111, Scotts Valley, CA 95066-4000, USA
email: mike@zayante.com    voice: +1-408-461-4901   fax: +1-408-461-1394
======================== http://www.zayante.com ===========================

From carterk at us.ibm.com  Fri Feb 13 15:37:57 1998
From: carterk at us.ibm.com (Keith Carter)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Re: Hotel reservations for the Hyatt
In-Reply-To: <Hotel reservations for the Hyatt>
Message-ID: <v04003a03b10a27e5dbea@[192.168.1.25]>

Mabry wrote today (2/13):


>Keith,
>
>How do you like your new job as travel agent?  ;)
>
>Our travel dept tried to book me a room we have been told that the rate was "no
>longer available", and mentioned something about all the rooms at that rate
have
>been "used up".  This was tried yesterday.  I just got off the phone myself,
and
>was told the same....
>
>Any ideas what they are talking about?
>
>The rate I am being quoted is $165.00/night.


Mabry,


This job as travel agent is looking less appealing by the minute.  I called the
meeting coordinator at the Hyatt hotel who assured me they will fix this
problem immediately.  There are rooms available at the IBM rate.  Please try
again to make your reservation.


Everyone,


Anyone else who has encountered this problem, please try again to make your
reservation.


Sincerely, your travel agent,


Keith Carter
Senior Software Engineer
IBM Network Computing Software Division in Austin, Texas
internet email: carterk@us.ibm.com
Notes email: Keith Carter/Austin/IBM@IBMUS
phone: 512-838-2155
tie-line: 678-2155
fax: 512-838-0169

From fumiona at venus.dti.ne.jp  Fri Feb 13 20:14:04 1998
From: fumiona at venus.dti.ne.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <v04003a03b10a27e5dbea@[192.168.1.25]>

Dear Mike,
Thanks for your productive information.


May I think your information results that the combined footprint
would be smaller than the sum of the SBP-2 initiator and SBP-2
target footprints?


Also I think SBP-2 is really well designed to support memory-
bus architecture provided by IEEE 1394. So if we adopt socket
stream API on SBP-2, I am afraid of that we might bring some
drawbacks from conventional I/O channel like architecture.
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


-----Original Message-----
From:	Michael D. Johas Teener - CTO & CoB, Zayante, Inc [SMTP:mike@zayante.com]
Sent:	Saturday, February 14, 1998 2:08 AM
To:	Nagasaka Fumio
Cc:	Stephen Holmstead; 'Turner, Randy'; 'Brian Batchelder'; p1394@pwg.org; pp1394 ML
Subject:	RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes


Regarding the note from Nagasaka Fumio:
>I agree with Stephen,
>> Also, I don$B!G(Jt believe any of the chip manufacturers support SBP-2(J
>>for
>both target and initiator.
>
>Do we need to develop a firmware which supports two LINK ICs
>one for initiator and one for target?
>I think $B!H(Jyes$B!I(J. Because typical LINK IC has only one input(J
>FIFO in
>each chip. And it is very difficult to implement two different software
>stack utilizing one i/o channel.


1) All of the Pele-based designs (OpenHCI, among others) do an excellent
job as both initiator and target ... indeed, they can support an almost
unlimited number of simultaneous initiator and target contexts
simultaneously. They are, however, PCI bus master designs ... so unless you
are building a relatively high-end printer, they may not be in your price
range (but check with IC suppliers like Sony, Symbios, and FFM for Pele,
and virtually everyone about OpenHCI).


2) Sony has a fine SBP-2 target part that is also useful for initiator use,
but requires more software and external DMA interaction.


3) The number of input FIFOs is not too important, except as an
optimization, particularly when inbound bus bridging is provided (useful
for CPU-type initiators). The key is to have good receive DMA into the
controller memory.


4) 1394 is quite different from traditional "I/O channels" ... mainly
because it's really a memory bus. If you treat it correctly (as a memory
bus), then it is quite simple to implement multiple stacks using the same
hardware. Indeed, our own proto systems implement as many as 4 protocol
stacks using relatively primative hardware.


===========================================================================
Michael D. Johas Teener, Chief Technical Officer & Chairman of the Board
Zayante, Inc., 269 Mt. Hermon Rd. #111, Scotts Valley, CA 95066-4000, USA
email: mike@zayante.com    voice: +1-408-461-4901   fax: +1-408-461-1394
======================== http://www.zayante.com ===========================

From atsnaka at bsd.canon.co.jp  Fri Feb 13 20:40:40 1998
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:48 2009
Subject: P1394> 1284.4 over SBP-2
In-Reply-To: <B1053A76-86066@17.128.200.23>
Message-ID: <199802140140.KAA16985@bsdmail.bsd.canon.co.jp>

To All,






>At this point in time we have apparently narrowed our potential solutions


>to the following:






>A- 1284.4 with SBP-2


>B-  New SBP-2 command set with SBP-2








chosen to be THE transport for PC printing, and we will work the "glue"


for it. Has it ?  


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  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






At 22:33 98/02/09 -0800, Eric Anderson wrote:


> 


> Recently, the 1394 community had the opportunity to define a


> storage protocol for 1394.  The first solution, Tailgate, gave


> us essentially an ATA interface bridged over 1394.  Both the


> target and the initiator had to operate as if traditional ATA


> was the interconnect.  Sure, SBP-2 was present, but only as a


> transport, and much of it's potential was wasted.  Tailgate


> was supposed to be quick an easy and lead to rapid market


> adoption.  What actually happened was quite different.


> 


> Microsoft and others realized that adopting this model would


> "lock in" ATA for a long time, including long after ATA itself


> was dead.  Emulating a dead technology with new technology may


> yield short-term savings in implementation, but at the expense of


> long-term losses in performance.  Amazingly, reason prevailed,


> and Tailgate was abandoned in favor of a pure SBP-2 protocol


> for disk drives.  As it turned out, Tailgate vendors quickly


> switched to Native Bridge, which still allowed today's drives


> to act like 1394 drives, by making them look (from a 1394


> point of view) like fully native devices.  As far as I can tell


> this switch was not too painful, and now we aren't stuck with


> ATA.  Everyone won.


> 


> Now we have a similar situation with printers.  1284.4 is a


> very well established technology.  Compared to 1394, I think it


> would be fair to say that 1284.4 is also a very slow and clumsy


> technology (nothing personal!).  Surprise, surprise - the idea


> comes up to bundle 1284.4 in SBP-2 because some purported savings


> can be had, in the short term.  From what I have seen of how this


> works, it is quite inefficient, with lots of unsolicited status


> requests and in general lots of hand-holding by the CPU on the


> initiator.  This is not what SBP-2 was designed for.


> 








-----------------------------------------


<bigger>Atsushi Nakamura


</bigger>-----------------------------------------




BJ Technology Develpoment 22,


Canon Inc.




53 Imai Kami-cho


Nakahara-Ku, Kawasaki-shi


postal no. 211




tel:+81-3-44-733-6111(ext.5593)


    +81-3-44-739-6634(direct)


fax:+81-3-44-739-6756


email(1):Atsushi_Nakamura@cbj.canon.co.jp


email(2):atsnaka@bsd.canon.co.jp


-----------------------------------------

From shimura at pure.cpdc.canon.co.jp  Fri Feb 13 21:44:00 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:48 2009
Subject: P1394> 1284.4 over SBP-2
In-Reply-To: <01376112D7AFD011911E0020AF70BEC5075AFA@CPUEX1>
Message-ID: <199802140244.LAA13654@slant1.pure.cpdc.canon.co.jp>

On Fri, 13 Feb 1998 20:35:11 +0900
Nagasaka Fumio <Nagasaka.Fumio@exc.epson.co.jp> wrote:
(snip)
> Akihiro Shimura wrote:
> <<
> 	If target request data transfer by "Data Available" flag in certain
> 	status block, initiator will subsequently append "SND data-in" ORB in
> 	the current task list. It will be possible for the target to check if
> 	there is a "SND data-in" ORB in the task list BEFORE the initiator
> 	appends the "SND data-in" ORB. After finding there is no "SND Data-in"
> 	ORB, the target may issue another unsolicited status which indicates
> 	"Data Available". By this status, the initiator may append one more
> 	(total two) "SND data-in" ORB in the task list. After that, the
> 	target will need to abort the excessive ORB.
> 	Is this a way the SBP-2 only solution works?
> >>


As far as I understand, the "another unsolicited status" will not
happen in this scenario by the definition given by Greg because the
target is already in "Data Available" state. (Greg, thank you for the
clarification.)


> I would like to introduce these rules shown below,
(snip)
> Then the initiator will not generate too many in-ORBs in the list.
> 
> Akihiro Shimura wrote:
> <<
> 	It seems natural to make two independent logins for each direction,
> 	one for down-link and another for up-link by using the idea to map
> 	them into logical units. Furthermore, by extending this to allow to
> 	allocate up-link in reverse fashion (i.e., the target of down-link
> 	makes a login to the initiator of down-link), the link between two
> 	devices will become symmetric if both ends have both initiator and
> 	target functionality.
> >>
> It is interesting. I had same idea to use two logins in last summer. But
> my reason was different.
> If we use one up-link and one down-ink, can we use multiple logical
> channels in each direction? Then how can we prevent *one simple
> uni-directional data path* to be stalled?


I'm not sure if I understand your question, but the functionality
equivalent to multiple logical channel is already done in the SBP-2
only solution (option B) via unit architecture. If the target does NOT
behave as expected by the initiator, like asynchronous notification,
"aborting task"(which implies subsequent retry) will be necessary to
keep each direction independent.  To avoid the use of "aborting task"
while keeping each direction independent, I thought it may be natural
to allocate two independent links(logical units) for down-link and
up-link instead of using "aborting task".


On Thu, 12 Feb 1998 10:24:21 -0800 (PST)
Greg Shue <gregs@sdd.hp.com> wrote:
> Haven't we been down this road before?  (Yes, and rejected it.)


I don't remember if this(one initiator makes two logins for each
transfer direction without using 1284.4) is addressed already or not.
Is this addressed in last August (Redmond) meeting?

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.


From stephen at hpb16977.boi.hp.com  Fri Feb 13 22:58:39 1998
From: stephen at hpb16977.boi.hp.com (Stephen Holmstead)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <199802140244.LAA13654@slant1.pure.cpdc.canon.co.jp>

I agree with Toru that we NEED a symmetrical transport.  I really don't
care which option (A or B) is used, as long as we can provide a
symmetrical connection.  In fact, that was one of the PWG transport
requirements from that start, but it just seems that we have accepted a
transport (SBP-2) that isn't symmetrical and we are calling it good.
The PWG-C also needs a symmetrical transport.  I would love to have the
same transport for the PWG and PWG-C (since they both have the same
requirements).  I would HATE to have to make a printer that implemented
two different transports for PWG and PWG-C printing.  I think most
printer manufacturers would agree.


Greg Shue said that he made a proposal to the January PWG that would
extend SBP-2 so that it was symmetrical (at least that is what I
understand--I may be way off here).  If so, that would be great.  I have
not been able to find any minutes from the PWG since Dec 97 (anyone got
some?).


1394 could really use a commonly accepted symmetrical transport layer.
If that's 1284.4, great.  If that's a modified SBP-2, great.  If that's
TCP/IP, great.  If that's DPP's Thin Protocol, great.


Personally, I am biased towards IP or 1284.4 (if you couldn't tell).


Stephen Holmstead


> -----Original Message-----
> From:	Toru Ueda [SMTP:ueda@slab.tnr.sharp.co.jp]
> Sent:	Friday, February 13, 1998 5:45 AM
> To:	Turner, Randy
> Cc:	'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
> Subject:	Re[2]: P1394> Rough SBP-2 & IP1394 core component ROM
> sizes
> 
> 
> I don't want to make any confusion about PC printing protocol. This is
> only for your information.
> 
> >From consumer device point of view, "symmetrical" is the essential
> feature of the protocol.
> For example, a digital still camera wants to send its image data to
> printers.  Also the same camera wants to receive image data from the 
> other still cameras. We want to use the same protocol for both use.
> 
> These are three essential features for consumer device.
> 
> 1) Bi-directional
>   Each side can send and receive data.
>   SBP2 supports bi-directional feature.
>   
> 2) "True" bi-directional
>   Each side can send and receive data at any time.
>   Alan's architecture supports "true" bi-directional feature by using
>   transmit buffer, receive buffer and unsolicited status.
>   
> 3) Symmetrical
>   Each side has the same architecture.
>   This is completely different from bi-directional issue.
>   
> Consumer device needs these three features and the protocol must be
> simple.
> 
> If SBP2 implementation needs 30K for initiator and target, it might be
> difficult to use it for consumer device.
> 
> Toru Ueda
> Software labs.
> Sharp Corp.
> 
> On Wed, 11 Feb 1998 08:35:10 -0800
> "Turner, Randy" <rturner@sharplabs.com> wrote:
> 
> > 
> > 
> > I didn't know chip sets offered "explicit" support for SBP-2. OHCI
> > maybe, but I hadn't seen the chip set feature in the brochure for
> > "chip-level SBP-2 support".
> > 
> > Also, since 1394 is a peer-to-peer interface, anyone developing a
> > peer-to-peer device (like the majority of the Japanese electronics
> > industry), would have to essentially duplicate the functionality of
> > SBP-2 initiator and target, whether they actually use SBP-2 to do
> this,
> > or some other (potentially proprietary) method for implementing
> > peer-to-peer functionality.
> > 
> > Randy
> > 
> > 
> > 
> > 	-----Original Message-----
> > 	From:	Stephen Homestead [SMTP:stephen@hpb16977.boi.hp.com]
> > 	Sent:	Wednesday, February 11, 1998 8:30 AM
> > 	To:	'Turner, Randy'; 'Brian Batchelder'; p1394@pwg.org
> > 	Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> > ROM sizes
> > 
> > 	My experiences in the past is that combining target AND
> > initiator
> > 	functions into a single device is VERY difficult.  The
> > complexity of the
> > 	state tables and ambiguities that can arise make it very
> > difficult.
> > 	Also, I don't believe any of the chip manufacturers support
> > SBP-2 for
> > 	both target and initiator.  In my opinion, it's NOT just a
> > matter of
> > 	adding the 15K for the target and 15K for the initiator.  The
> > target and
> > 	initiator have vastly different functions.   Designing a model
> > that did
> > 	both (well) would be a challenge.  It was problems like this
> > that fueled
> > 	many of the AEN (asynchronous event notification) debates.
> > 
> > 	Stephen
> > 
> > 	> -----Original Message-----
> > 	> From:	Turner, Randy [SMTP:rturner@sharplabs.com]
> > 	> Sent:	Monday, February 09, 1998 1:03 PM
> > 	> To:	'Brian Batchelder'; p1394@pwg.org
> > 	> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> > ROM sizes
> > 	> 
> > 	> 
> > 	> I am very interested in the combined target/initiator
> > footprint as
> > 	> well.
> > 	> 
> > 	> Thx
> > 	> 
> > 	> Randy
> > 	> 
> > 	> 
> > 	> 	-----Original Message-----
> > 	> 	From:	Brian Batchelder [SMTP:brianb@vcd.hp.com]
> > 	> 	Sent:	Monday, February 09, 1998 9:37 AM
> > 	> 	To:	p1394@pwg.org
> > 	> 	Subject:	Re: P1394> Rough SBP-2 & IP1394 core
> > component
> > 	> ROM sizes
> > 	> 
> > 	> 	At 02:04 PM 2/6/98 -0800, Greg Shue wrote:
> > 	> 
> > 	> 	[snip]
> > 	> 
> > 	> 	>I approached them about sharing some rough estimates of
> > code
> > 	> size
> > 	> 	>for the IP1394 glue, SBP-2 target and initiator, and
> > 1394 bus
> > 	> 	>manager modules to get a feel for how "heavy" the
> > protocol
> > 	> 	>implementations really are.  They graciously shared the
> > flowing
> > 	> 	>estimates with us, and certainly deserve our thanks.
> > Since the
> > 	> 	>technology is still being developed, these
> > implementations are
> > 	> 	>certainly going to be tuned and the numbers will change
> > a
> > 	> little
> > 	> 	>bit.
> > 	> 	>
> > 	> 	>  Component                Rough ROM size (KBytes)
> > 	> 	>  ---------                -----------------------
> > 	> 	>  SBP-2 initiator core     15 +/- 5
> > 	> 	>  SBP-2 target core        15 +/- 5  (incl. Mgmt+Fetch
> > agent,
> > 	> no exec agent)
> > 	> 
> > 	> 	Any idea how big a combined SBP-2 target/initiator would
> > be?
> > 	> 15-30K? ;-)
> > 	> 
> > 	> 	[snip]
> > 	> 
> > 	> 	Brian
> > 	> 
> > 	>
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 	> ~
> > 	> 	Brian Batchelder      | Hewlett-Packard      |
> > 	> mailto:brianb@vcd.hp.com  
> > 	> 	Connectivity Futurist | 1115 SE 164th Ave.   | Phone:
> > (360)
> > 	> 212-4107  
> > 	> 	DeskJet Printers      | Vancouver, WA  98684 | Fax:
> > (360)
> > 	> 212-4227
> > 

From fumiona at venus.dti.ne.jp  Sat Feb 14 23:21:45 1998
From: fumiona at venus.dti.ne.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <199802140244.LAA13654@slant1.pure.cpdc.canon.co.jp>

Dear Toru san,


One point.
I think 30k is good size even for cheap consumer devices.
This size is smaller than typical VxWorks implementation, and it
may be smaller than JetSend.


So please give us information how big your DPP ROM size is expected to.


--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


-----Original Message-----
From:	Toru Ueda [SMTP:ueda@slab.tnr.sharp.co.jp]
Sent:	Saturday, February 14, 1998 6:45 AM
To:	Turner, Randy
Cc:	'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
Subject:	Re[2]: P1394> Rough SBP-2 & IP1394 core component ROM sizes




I don't want to make any confusion about PC printing protocol. This is
only for your information.


>From consumer device point of view, "symmetrical" is the essential
feature of the protocol.
For example, a digital still camera wants to send its image data to
printers.  Also the same camera wants to receive image data from the 
other still cameras. We want to use the same protocol for both use.


These are three essential features for consumer device.


1) Bi-directional
  Each side can send and receive data.
  SBP2 supports bi-directional feature.
  
2) "True" bi-directional
  Each side can send and receive data at any time.
  Alan's architecture supports "true" bi-directional feature by using
  transmit buffer, receive buffer and unsolicited status.
  
3) Symmetrical
  Each side has the same architecture.
  This is completely different from bi-directional issue.
  
Consumer device needs these three features and the protocol must be
simple.


If SBP2 implementation needs 30K for initiator and target, it might be
difficult to use it for consumer device.


Toru Ueda
Software labs.
Sharp Corp.


On Wed, 11 Feb 1998 08:35:10 -0800
"Turner, Randy" <rturner@sharplabs.com> wrote:


> 
> 
> I didn't know chip sets offered "explicit" support for SBP-2. OHCI
> maybe, but I hadn't seen the chip set feature in the brochure for
> "chip-level SBP-2 support".
> 
> Also, since 1394 is a peer-to-peer interface, anyone developing a
> peer-to-peer device (like the majority of the Japanese electronics
> industry), would have to essentially duplicate the functionality of
> SBP-2 initiator and target, whether they actually use SBP-2 to do this,
> or some other (potentially proprietary) method for implementing
> peer-to-peer functionality.
> 
> Randy
> 
> 
> 
> 	-----Original Message-----
> 	From:	Stephen Homestead [SMTP:stephen@hpb16977.boi.hp.com]
> 	Sent:	Wednesday, February 11, 1998 8:30 AM
> 	To:	'Turner, Randy'; 'Brian Batchelder'; p1394@pwg.org
> 	Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> ROM sizes
> 
> 	My experiences in the past is that combining target AND
> initiator
> 	functions into a single device is VERY difficult.  The
> complexity of the
> 	state tables and ambiguities that can arise make it very
> difficult.
> 	Also, I don't believe any of the chip manufacturers support
> SBP-2 for
> 	both target and initiator.  In my opinion, it's NOT just a
> matter of
> 	adding the 15K for the target and 15K for the initiator.  The
> target and
> 	initiator have vastly different functions.   Designing a model
> that did
> 	both (well) would be a challenge.  It was problems like this
> that fueled
> 	many of the AEN (asynchronous event notification) debates.
> 
> 	Stephen
> 
> 	> -----Original Message-----
> 	> From:	Turner, Randy [SMTP:rturner@sharplabs.com]
> 	> Sent:	Monday, February 09, 1998 1:03 PM
> 	> To:	'Brian Batchelder'; p1394@pwg.org
> 	> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> ROM sizes
> 	> 
> 	> 
> 	> I am very interested in the combined target/initiator
> footprint as
> 	> well.
> 	> 
> 	> Thx
> 	> 
> 	> Randy
> 	> 
> 	> 
> 	> 	-----Original Message-----
> 	> 	From:	Brian Batchelder [SMTP:brianb@vcd.hp.com]
> 	> 	Sent:	Monday, February 09, 1998 9:37 AM
> 	> 	To:	p1394@pwg.org
> 	> 	Subject:	Re: P1394> Rough SBP-2 & IP1394 core
> component
> 	> ROM sizes
> 	> 
> 	> 	At 02:04 PM 2/6/98 -0800, Greg Shue wrote:
> 	> 
> 	> 	[snip]
> 	> 
> 	> 	>I approached them about sharing some rough estimates of
> code
> 	> size
> 	> 	>for the IP1394 glue, SBP-2 target and initiator, and
> 1394 bus
> 	> 	>manager modules to get a feel for how "heavy" the
> protocol
> 	> 	>implementations really are.  They graciously shared the
> flowing
> 	> 	>estimates with us, and certainly deserve our thanks.
> Since the
> 	> 	>technology is still being developed, these
> implementations are
> 	> 	>certainly going to be tuned and the numbers will change
> a
> 	> little
> 	> 	>bit.
> 	> 	>
> 	> 	>  Component                Rough ROM size (KBytes)
> 	> 	>  ---------                -----------------------
> 	> 	>  SBP-2 initiator core     15 +/- 5
> 	> 	>  SBP-2 target core        15 +/- 5  (incl. Mgmt+Fetch
> agent,
> 	> no exec agent)
> 	> 
> 	> 	Any idea how big a combined SBP-2 target/initiator would
> be?
> 	> 15-30K? ;-)
> 	> 
> 	> 	[snip]
> 	> 
> 	> 	Brian
> 	> 
> 	>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 	> ~
> 	> 	Brian Batchelder      | Hewlett-Packard      |
> 	> mailto:brianb@vcd.hp.com  
> 	> 	Connectivity Futurist | 1115 SE 164th Ave.   | Phone:
> (360)
> 	> 212-4107  
> 	> 	DeskJet Printers      | Vancouver, WA  98684 | Fax:
> (360)
> 	> 212-4227
> 

From atsnaka at mxa.mesh.ne.jp  Sun Feb 15 10:24:13 1998
From: atsnaka at mxa.mesh.ne.jp (Atsushi Nakamura)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <199802140244.LAA13654@slant1.pure.cpdc.canon.co.jp>

>The PWG-C also needs a symmetrical transport.  I would love to have the
>same transport for the PWG and PWG-C (since they both have the same
>requirements).  I would HATE to have to make a printer that implemented
>two different transports for PWG and PWG-C printing.  I think most
>printer manufacturers would agree.


I think everyone would agree to this as an "ideal" solution.
Unfortunately. the reality (at least now) is that the PWG and PWG-C
have requirements that are "similar", but not the "same".
The difference may be small, but seem to be crutial to both sides.
It may be the "level",or depth of each requirement items, or
priority of requirement items (for example, "light", symmetrical VS,
existing
protocol use, OS support)


If we can come up with a PWG solutionthat can cover the difference, that
would be great. On the other hand, if the DPP thin transport can be used fro
PWG printing, that would be good too, and will be the ideal solution.


>, but it just seems that we have accepted a
>transport (SBP-2) that isn't symmetrical and we are calling it good.


I think so too. It's one of the reasons why I asked the whether we
ever officially decide to go with SBP-2...


There was still discussion  in Maui whether symmetrical (and/or
bi-directional)
was necessary or not for PWG printing. (must or want ?)
This is one of the questions we need to get consensus first , as well as
prioritizing the requirements. For example, if existing protocol use is much
more important for PWG printing than symmetric, SBP-2 may be good
after all.


-----Original Message-----
�·�o�l : Stephen Holmstead <stephen@hpb16977.boi.hp.com>
ˆ¶�æ : 'Toru Ueda' <ueda@slab.tnr.sharp.co.jp>; Turner, Randy
<rturner@sharplabs.com>
CC : 'Stephen Holmstead' <stephen@hpb16977.boi.hp.com>; 'Brian Batchelder'
<brianb@vcd.hp.com>; p1394@pwg.org <p1394@pwg.org>
“úŽž : 1998”N2ŒŽ14“ú 13:00
Œ�–¼ : RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes




>I agree with Toru that we NEED a symmetrical transport.  I really don't
>care which option (A or B) is used, as long as we can provide a
>symmetrical connection.  In fact, that was one of the PWG transport
>requirements from that start, but it just seems that we have accepted a
>transport (SBP-2) that isn't symmetrical and we are calling it good.
>The PWG-C also needs a symmetrical transport.  I would love to have the
>same transport for the PWG and PWG-C (since they both have the same
>requirements).  I would HATE to have to make a printer that implemented
>two different transports for PWG and PWG-C printing.  I think most
>printer manufacturers would agree.
>
>Greg Shue said that he made a proposal to the January PWG that would
>extend SBP-2 so that it was symmetrical (at least that is what I
>understand--I may be way off here).  If so, that would be great.  I have
>not been able to find any minutes from the PWG since Dec 97 (anyone got
>some?).
>
>1394 could really use a commonly accepted symmetrical transport layer.
>If that's 1284.4, great.  If that's a modified SBP-2, great.  If that's
>TCP/IP, great.  If that's DPP's Thin Protocol, great.
>
>Personally, I am biased towards IP or 1284.4 (if you couldn't tell).
>
>Stephen Holmstead
>
>> -----Original Message-----
>> From: Toru Ueda [SMTP:ueda@slab.tnr.sharp.co.jp]
>> Sent: Friday, February 13, 1998 5:45 AM
>> To: Turner, Randy
>> Cc: 'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
>> Subject: Re[2]: P1394> Rough SBP-2 & IP1394 core component ROM
>> sizes
>>
>>
>> I don't want to make any confusion about PC printing protocol. This is
>> only for your information.
>>
>> >From consumer device point of view, "symmetrical" is the essential
>> feature of the protocol.
>> For example, a digital still camera wants to send its image data to
>> printers.  Also the same camera wants to receive image data from the
>> other still cameras. We want to use the same protocol for both use.
>>
>> These are three essential features for consumer device.
>>
>> 1) Bi-directional
>>   Each side can send and receive data.
>>   SBP2 supports bi-directional feature.
>>
>> 2) "True" bi-directional
>>   Each side can send and receive data at any time.
>>   Alan's architecture supports "true" bi-directional feature by using
>>   transmit buffer, receive buffer and unsolicited status.
>>
>> 3) Symmetrical
>>   Each side has the same architecture.
>>   This is completely different from bi-directional issue.
>>
>> Consumer device needs these three features and the protocol must be
>> simple.
>>
>> If SBP2 implementation needs 30K for initiator and target, it might be
>> difficult to use it for consumer device.
>>
>> Toru Ueda
>> Software labs.
>> Sharp Corp.
>>
>> On Wed, 11 Feb 1998 08:35:10 -0800
>> "Turner, Randy" <rturner@sharplabs.com> wrote:
>>
>> >
>> >
>> > I didn't know chip sets offered "explicit" support for SBP-2. OHCI
>> > maybe, but I hadn't seen the chip set feature in the brochure for
>> > "chip-level SBP-2 support".
>> >
>> > Also, since 1394 is a peer-to-peer interface, anyone developing a
>> > peer-to-peer device (like the majority of the Japanese electronics
>> > industry), would have to essentially duplicate the functionality of
>> > SBP-2 initiator and target, whether they actually use SBP-2 to do
>> this,
>> > or some other (potentially proprietary) method for implementing
>> > peer-to-peer functionality.
>> >
>> > Randy
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Stephen Homestead [SMTP:stephen@hpb16977.boi.hp.com]
>> > Sent: Wednesday, February 11, 1998 8:30 AM
>> > To: 'Turner, Randy'; 'Brian Batchelder'; p1394@pwg.org
>> > Subject: RE: P1394> Rough SBP-2 & IP1394 core component
>> > ROM sizes
>> >
>> > My experiences in the past is that combining target AND
>> > initiator
>> > functions into a single device is VERY difficult.  The
>> > complexity of the
>> > state tables and ambiguities that can arise make it very
>> > difficult.
>> > Also, I don't believe any of the chip manufacturers support
>> > SBP-2 for
>> > both target and initiator.  In my opinion, it's NOT just a
>> > matter of
>> > adding the 15K for the target and 15K for the initiator.  The
>> > target and
>> > initiator have vastly different functions.   Designing a model
>> > that did
>> > both (well) would be a challenge.  It was problems like this
>> > that fueled
>> > many of the AEN (asynchronous event notification) debates.
>> >
>> > Stephen
>> >
>> > > -----Original Message-----
>> > > From: Turner, Randy [SMTP:rturner@sharplabs.com]
>> > > Sent: Monday, February 09, 1998 1:03 PM
>> > > To: 'Brian Batchelder'; p1394@pwg.org
>> > > Subject: RE: P1394> Rough SBP-2 & IP1394 core component
>> > ROM sizes
>> > >
>> > >
>> > > I am very interested in the combined target/initiator
>> > footprint as
>> > > well.
>> > >
>> > > Thx
>> > >
>> > > Randy
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: Brian Batchelder [SMTP:brianb@vcd.hp.com]
>> > > Sent: Monday, February 09, 1998 9:37 AM
>> > > To: p1394@pwg.org
>> > > Subject: Re: P1394> Rough SBP-2 & IP1394 core
>> > component
>> > > ROM sizes
>> > >
>> > > At 02:04 PM 2/6/98 -0800, Greg Shue wrote:
>> > >
>> > > [snip]
>> > >
>> > > >I approached them about sharing some rough estimates of
>> > code
>> > > size
>> > > >for the IP1394 glue, SBP-2 target and initiator, and
>> > 1394 bus
>> > > >manager modules to get a feel for how "heavy" the
>> > protocol
>> > > >implementations really are.  They graciously shared the
>> > flowing
>> > > >estimates with us, and certainly deserve our thanks.
>> > Since the
>> > > >technology is still being developed, these
>> > implementations are
>> > > >certainly going to be tuned and the numbers will change
>> > a
>> > > little
>> > > >bit.
>> > > >
>> > > >  Component                Rough ROM size (KBytes)
>> > > >  ---------                -----------------------
>> > > >  SBP-2 initiator core     15 +/- 5
>> > > >  SBP-2 target core        15 +/- 5  (incl. Mgmt+Fetch
>> > agent,
>> > > no exec agent)
>> > >
>> > > Any idea how big a combined SBP-2 target/initiator would
>> > be?
>> > > 15-30K? ;-)
>> > >
>> > > [snip]
>> > >
>> > > Brian
>> > >
>> > >
>> >
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> > > ~
>> > > Brian Batchelder      | Hewlett-Packard      |
>> > > mailto:brianb@vcd.hp.com
>> > > Connectivity Futurist | 1115 SE 164th Ave.   | Phone:
>> > (360)
>> > > 212-4107
>> > > DeskJet Printers      | Vancouver, WA  98684 | Fax:
>> > (360)
>> > > 212-4227
>> >
>

From hitoshis at MICROSOFT.com  Sun Feb 15 17:17:50 1998
From: hitoshis at MICROSOFT.com (Hitoshi Sekine)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <199802140244.LAA13654@slant1.pure.cpdc.canon.co.jp>

I love a symmetrical transport also. PC Printing has supported 1284, USB and
1394 soon. If you considers a symmetrical transport for 1284, USB and 1394
(and IP), it will be great for us. To redesign PC software only for a new
1394 print transport will be tough. I don't mean to recommend different
solutions between PWG-C and PWG. We need to get our priorities right. Not to
confuse PC software industry is my first priority.


I personally understand that 1284.4 may be a bridge over those local
interfaces and familiar with an IP printer.


Hitoshi Sekine




> -----Original Message-----
> From:	Fumio Nagasaka [SMTP:fumiona@venus.dti.ne.jp]
> Sent:	Saturday, February 14, 1998 9:04 PM
> To:	'Stephen Holmstead'; 'Toru Ueda'; Turner, Randy
> Cc:	'Brian Batchelder'; p1394@pwg.org; 'PWG-C mailing';
> 'p1284_3@lexmark.com'; Hitoshi Sekine
> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> 
> Dear Stephen,
> 
> Your opinion bring us back to December 1996. Actually we started from
> this point. 
> 
> I would like to list up existing standards and some proposals here.
> 
> Transaction architecture:
> --------------------------------------------------------------------------
> ----------------
> IEEE 1394     |   Memory Bus
> --------------------------------------------------------------------------
> ----------------
> SBP-2         |   Memory Bus
> DPP           |   Stream       (PWG-C / Toru Ueda)
> TCP           |   Stream
> DFA           |   Stream       (PWG / Alan C. Berkema)
> 1284.4         |   no definition
> --------------------------------------------------------------------------
> ----------------
> 
> Transaction style:
> --------------------------------------------------------------------------
> ----------------
> IEEE 1394     |   push and pull,  symmetrical
> --------------------------------------------------------------------------
> ----------------
> SBP-2         |   pull
> DPP           |   push,  symmetrical
> TCP           |   push,  symmetrical (may implement passive open)
> DFA           |   push,  symmetrical
> 1284.4         |   push control, symmetrical
> --------------------------------------------------------------------------
> ----------------
> 
> Please correct if I had overlooked something or I am missing some points.
> 
> Stephen wrote:
> <<
> requirements).  I would HATE to have to make a printer that implemented
> two different transports for PWG and PWG-C printing.  I think most
> printer manufacturers would agree.
> >>
> 
> No.
> Due to some market reasons, printer manufactures are required
> to support USB, conventional parallel port, 1394 and Macintosh serial
> interface. However Digital Camera (one of typical consumer imaging
> device) does not support parallel port. Thus for some consumer
> device manufactures, it is meaning less to have a solution which
> provide common protocol stack to cover various existing interface.
> 
> If PWG and PWG-C shall have same solution, I think we shall
> have only one "Printer Working Group". However many Japanese
> companies could not agree with this plan. They might have their own
> reasons. And I think we ought to pay consideration for them.
> --------------------------------------------
> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
> 
> -----Original Message-----
> From:	Stephen Holmstead [SMTP:stephen@hpb16977.boi.hp.com]
> Sent:	Saturday, February 14, 1998 12:59 PM
> To:	'Toru Ueda'; Turner, Randy
> Cc:	'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> 
> I agree with Toru that we NEED a symmetrical transport.  I really don't
> care which option (A or B) is used, as long as we can provide a
> symmetrical connection.  In fact, that was one of the PWG transport
> requirements from that start, but it just seems that we have accepted a
> transport (SBP-2) that isn't symmetrical and we are calling it good.
> The PWG-C also needs a symmetrical transport.  I would love to have the
> same transport for the PWG and PWG-C (since they both have the same
> requirements).  I would HATE to have to make a printer that implemented
> two different transports for PWG and PWG-C printing.  I think most
> printer manufacturers would agree.
> 
> Greg Shue said that he made a proposal to the January PWG that would
> extend SBP-2 so that it was symmetrical (at least that is what I
> understand--I may be way off here).  If so, that would be great.  I have
> not been able to find any minutes from the PWG since Dec 97 (anyone got
> some?).
> 
> 1394 could really use a commonly accepted symmetrical transport layer.
> If that's 1284.4, great.  If that's a modified SBP-2, great.  If that's
> TCP/IP, great.  If that's DPP's Thin Protocol, great.
> 
> Personally, I am biased towards IP or 1284.4 (if you couldn't tell).
> 
> Stephen Holmstead
> 
> > -----Original Message-----
> > From:	Toru Ueda [SMTP:ueda@slab.tnr.sharp.co.jp]
> > Sent:	Friday, February 13, 1998 5:45 AM
> > To:	Turner, Randy
> > Cc:	'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
> > Subject:	Re[2]: P1394> Rough SBP-2 & IP1394 core component ROM
> > sizes
> > 
> > 
> > I don't want to make any confusion about PC printing protocol. This is
> > only for your information.
> > 
> > >From consumer device point of view, "symmetrical" is the essential
> > feature of the protocol.
> > For example, a digital still camera wants to send its image data to
> > printers.  Also the same camera wants to receive image data from the 
> > other still cameras. We want to use the same protocol for both use.
> > 
> > These are three essential features for consumer device.
> > 
> > 1) Bi-directional
> >   Each side can send and receive data.
> >   SBP2 supports bi-directional feature.
> >   
> > 2) "True" bi-directional
> >   Each side can send and receive data at any time.
> >   Alan's architecture supports "true" bi-directional feature by using
> >   transmit buffer, receive buffer and unsolicited status.
> >   
> > 3) Symmetrical
> >   Each side has the same architecture.
> >   This is completely different from bi-directional issue.
> >   
> > Consumer device needs these three features and the protocol must be
> > simple.
> > 
> > If SBP2 implementation needs 30K for initiator and target, it might be
> > difficult to use it for consumer device.
> > 
> > Toru Ueda
> > Software labs.
> > Sharp Corp.
> > 
> > On Wed, 11 Feb 1998 08:35:10 -0800
> > "Turner, Randy" <rturner@sharplabs.com> wrote:
> > 
> > > 
> > > 
> > > I didn't know chip sets offered "explicit" support for SBP-2. OHCI
> > > maybe, but I hadn't seen the chip set feature in the brochure for
> > > "chip-level SBP-2 support".
> > > 
> > > Also, since 1394 is a peer-to-peer interface, anyone developing a
> > > peer-to-peer device (like the majority of the Japanese electronics
> > > industry), would have to essentially duplicate the functionality of
> > > SBP-2 initiator and target, whether they actually use SBP-2 to do
> > this,
> > > or some other (potentially proprietary) method for implementing
> > > peer-to-peer functionality.
> > > 
> > > Randy
> > > 
> > > 
> > > 
> > > 	-----Original Message-----
> > > 	From:	Stephen Homestead [SMTP:stephen@hpb16977.boi.hp.com]
> > > 	Sent:	Wednesday, February 11, 1998 8:30 AM
> > > 	To:	'Turner, Randy'; 'Brian Batchelder'; p1394@pwg.org
> > > 	Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> > > ROM sizes
> > > 
> > > 	My experiences in the past is that combining target AND
> > > initiator
> > > 	functions into a single device is VERY difficult.  The
> > > complexity of the
> > > 	state tables and ambiguities that can arise make it very
> > > difficult.
> > > 	Also, I don't believe any of the chip manufacturers support
> > > SBP-2 for
> > > 	both target and initiator.  In my opinion, it's NOT just a
> > > matter of
> > > 	adding the 15K for the target and 15K for the initiator.  The
> > > target and
> > > 	initiator have vastly different functions.   Designing a model
> > > that did
> > > 	both (well) would be a challenge.  It was problems like this
> > > that fueled
> > > 	many of the AEN (asynchronous event notification) debates.
> > > 
> > > 	Stephen
> > > 
> > > 	> -----Original Message-----
> > > 	> From:	Turner, Randy [SMTP:rturner@sharplabs.com]
> > > 	> Sent:	Monday, February 09, 1998 1:03 PM
> > > 	> To:	'Brian Batchelder'; p1394@pwg.org
> > > 	> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> > > ROM sizes
> > > 	> 
> > > 	> 
> > > 	> I am very interested in the combined target/initiator
> > > footprint as
> > > 	> well.
> > > 	> 
> > > 	> Thx
> > > 	> 
> > > 	> Randy
> > > 	> 
> > > 	> 
> > > 	> 	-----Original Message-----
> > > 	> 	From:	Brian Batchelder [SMTP:brianb@vcd.hp.com]
> > > 	> 	Sent:	Monday, February 09, 1998 9:37 AM
> > > 	> 	To:	p1394@pwg.org
> > > 	> 	Subject:	Re: P1394> Rough SBP-2 & IP1394 core
> > > component
> > > 	> ROM sizes
> > > 	> 
> > > 	> 	At 02:04 PM 2/6/98 -0800, Greg Shue wrote:
> > > 	> 
> > > 	> 	[snip]
> > > 	> 
> > > 	> 	>I approached them about sharing some rough estimates of
> > > code
> > > 	> size
> > > 	> 	>for the IP1394 glue, SBP-2 target and initiator, and
> > > 1394 bus
> > > 	> 	>manager modules to get a feel for how "heavy" the
> > > protocol
> > > 	> 	>implementations really are.  They graciously shared the
> > > flowing
> > > 	> 	>estimates with us, and certainly deserve our thanks.
> > > Since the
> > > 	> 	>technology is still being developed, these
> > > implementations are
> > > 	> 	>certainly going to be tuned and the numbers will change
> > > a
> > > 	> little
> > > 	> 	>bit.
> > > 	> 	>
> > > 	> 	>  Component                Rough ROM size (KBytes)
> > > 	> 	>  ---------                -----------------------
> > > 	> 	>  SBP-2 initiator core     15 +/- 5
> > > 	> 	>  SBP-2 target core        15 +/- 5  (incl. Mgmt+Fetch
> > > agent,
> > > 	> no exec agent)
> > > 	> 
> > > 	> 	Any idea how big a combined SBP-2 target/initiator would
> > > be?
> > > 	> 15-30K? ;-)
> > > 	> 
> > > 	> 	[snip]
> > > 	> 
> > > 	> 	Brian
> > > 	> 
> > > 	>
> > >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > 	> ~
> > > 	> 	Brian Batchelder      | Hewlett-Packard      |
> > > 	> mailto:brianb@vcd.hp.com  
> > > 	> 	Connectivity Futurist | 1115 SE 164th Ave.   | Phone:
> > > (360)
> > > 	> 212-4107  
> > > 	> 	DeskJet Printers      | Vancouver, WA  98684 | Fax:
> > > (360)
> > > 	> 212-4227
> > > 

From fumiona at venus.dti.ne.jp  Sun Feb 15 18:41:32 1998
From: fumiona at venus.dti.ne.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:48 2009
Subject: P1394> 1284.4 over SBP-2
Message-ID: <199802140244.LAA13654@slant1.pure.cpdc.canon.co.jp>

Hi Greg,


S2 state will not happen, when your model uses "Credit Base Transport".
The initiator will not send more packets than given credits by the target.
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


-----Original Message-----
From:	Greg Shue [SMTP:gregs@sdd.hp.com]
Sent:	Friday, February 13, 1998 3:24 AM
To:	Akihiro Shimura
Cc:	p1394@pwg.org; P1284_3@lexmark.com
Subject:	Re: P1394> 1284.4 over SBP-2


Akihiro Shimura writes:
> Basically, I also support to consider option B, but it is still not
> clear for me how the data transfer of each direction is done
> independently within single login in SBP-2 only solution.
> 
> If target request data transfer by "Data Available" flag in certain
> status block, initiator will subsequently append "SND data-in" ORB in
> the current task list. It will be possible for the target to check if
> there is a "SND data-in" ORB in the task list BEFORE the initiator
> appends the "SND data-in" ORB. After finding there is no "SND data-in"
> ORB, the target may issue another unsolicited status which indicates
> "Data Available". By this status, the initiator may append one more
> (total two) "SND data-in" ORB in the task list. After that, the
> target will need to abort the excessive ORB.
> Is this a way the SBP-2 only solution works?


It's not the way I intended it to work.  Let me work through
the model I've had in mind.


It is a status signal that data is available for the initiator.  It is
not an event requesting a new task be placed on the task list.


The status is updated at exactly two points in time:  on the
completion of a task; and on a spontaneous change from No Data
Available to Data Available when there are to active tasks on the
task list.  It is up to the initiator to determine whether a new
task needs to be enqueued on the task list or not.  The task
enqueuing algorithm for the initiator would basically be:


  for (;;)
  {
      while target has unexpected data available
	  get target data one request at a time


      enqueue one request for an expected data transfer
  }


When the target has data available, and at least one request
exists on the active task list, the data available indication is
given on the completion status of the first ORB.  The initiator
will enqueue a new ORB for receiving target data if, and only if,
no request for target data has already been enqueued on the task
list.  This ORB would be associated with the "hanging read"
already required for independent communication in each direction.


The target would continue to process the ORB list until one of
the following states is reached:


  S1) the ORB list will be empty  (no active task set)


  S2) the ORB list processing stalls at a data transfer to the target,
      and the target has no data for the initiator.
      (no more target buffer space, and no reason to abort the task set)


  S3) the ORB list processing stalls at a data transfer to the initiator
      (initiator expects data from the target, but none is currently
       available)


When data becomes available, the following transitions take place:


  From S1
    the target signals Data Available via unsolicited status;
    the initiator enqueues one ORB to receive the data;
    the target resumes processing the ORB;
    on completion of the request, the target indicates whether
      or not more data is available.


  From S2
    the target aborts all the requests on the task list and indicates
      that data is available for the initiator on each request;
    the initiator enqueues one ORB to receive the data;
    the target resumes processing the ORB;
    on completion of the request, the target indicates whether
      or not more data is available.


    When the target has no more data available, the initiator
      requeues the aborted requests.


  From S3
    the target continues processing the task set


The only ineffeciency occurs when the target doesn't behave the way
the initiator expects.


  If we are doing unidirectional printing, then there is no data
  for the initiator, and the task set is never aborted.


  If we are interacting with the device, and it behaves as expected,
  then there is no unexpected data for the initiator, so the task
  set is never aborted.  (For interactive Postscript, scanning models,
  and request/reply paradigms like SNMP)


  If the target doesn't behave as expected and has lots of unsolicited
  data for the initiator, the target aborts the current task set and
  the initiator pauses sending data to the target until the target has
  no more data for the initiator.


The worst-case scenario occurs if the target keeps generating bursts
of unexpected data for the initiator and the task sets are perpetually
aborted.  The net effect of this is minimized simply by minimizing
the length of the active task set!  Having 2-4 data transfer requests
queued  (e.g. double-buffering) may be sufficient (for most applications)
to keep the task list running and the target busy.




> I think that aborting tasks implies subsequent task retries, and may
> not be efficient.


Yes, aborting tasks implies subsequent task retries.
The overhead is in the target (pre) fetching the ORBs
in order to abort them, and in requeuing the task set
when the data available indication disappears.


But don't forget that the maximum data transfer size is known,
so the target doesn't need to fetch any real data until it knows
that it can complete the request!


> It seems natural to make two independent logins for each direction,
> one for down-link and another for up-link by using the idea to map
> them into logical units. Furthermore, by extending this to allow to
> allocate up-link in reverse fashion (i.e., the target of down-link
> makes a login to the initiator of down-link), the link between two
> devices will become symmetric if both ends have both initiator and
> target functionality.
> 
> Any suggestions?


Haven't we been down this road before?  (Yes, and rejected it.)




> --
>  Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
>  Office Imaging Products Development Center 3
>  CANON INC.
> 





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


From atsnaka at mxa.mesh.ne.jp  Sun Feb 15 22:34:52 1998
From: atsnaka at mxa.mesh.ne.jp (Atsushi Nakamura)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <199802140244.LAA13654@slant1.pure.cpdc.canon.co.jp>

For PWG printing,
We will have to decide whether not we use 1284.4 or not,
but in any case, it is inefficient to stack overlapping
functionality.
My choices would be either :


1) 1284.4 - "glue"- 1394
2) "glue"or cmd set - SBP-2- 1394
3) "glue"or cmd set - other transport(thin?)-1394


I am yet uncertain which is the best( maybe 2) or 3) ),
but I DO have a opinion that in any case :
1284.4 over SBP-2
is not my choice, because in this case;


>Sure, SBP-2 was present, but only as a
>transport, and much of it's potential was wasted.


would happen. (same for 1284.4)
Is using 1284.4 our first priority, or is using SBP-2 our
first priority ? (or something else? )(or using both !?)


P.S I would like to refer to Eric's comment about the 1394 disks
      again.
>Recently, the 1394 community had the opportunity to define a
>storage protocol for 1394.  The first solution, Tailgate, gave
>us essentially an ATA interface bridged over 1394.  Both the
>target and the initiator had to operate as if traditional ATA
>was the interconnect.  Sure, SBP-2 was present, but only as a
>transport, and much of it's potential was wasted.  Tailgate
>was supposed to be quick an easy and lead to rapid market
>adoption.  What actually happened was quite different.


I think this is the same situation with 1284.4 (as ATA) and
SBP-2 (or IP,Thin.... )


>Microsoft and others realized that adopting this model would
>"lock in" ATA for a long time, including long after ATA itself
>was dead.  Emulating a dead technology with new technology may
>yield short-term savings in implementation, but at the expense of
>long-term losses in performance.  Amazingly, reason prevailed,
>and Tailgate was abandoned in favor of a pure SBP-2 protocol
>for disk drives.  As it turned out, Tailgate vendors quickly
>switched to Native Bridge, which still allowed today's drives
>to act like 1394 drives, by making them look (from a 1394
>point of view) like fully native devices.  As far as I can tell
>this switch was not too painful, and now we aren't stuck with
>ATA.  Everyone won.


Let's not repeat history....




-------------------------------------------------
Atsushi Nakamura
BJ Printing Technology 22
Canon Inc.
-------------------------------------------------


-----Original Message-----
$B:9=P?M(B : Hitoshi Sekine <hitoshis@microsoft.com>
$B08@h(B : 'Fumio Nagasaka' <fumiona@venus.dti.ne.jp>; 'Stephen Holmstead'
<stephen@hpb16977.boi.hp.com>; 'Toru Ueda' <ueda@slab.tnr.sharp.co.jp>;
Turner, Randy <rturner@sharplabs.com>
CC : 'Brian Batchelder' <brianb@vcd.hp.com>; p1394@pwg.org <p1394@pwg.org>;
'PWG-C mailing' <pp1394@cpdc.canon.co.jp>; 'p1284_3@lexmark.com'
<p1284_3@lexmark.com>
$BF|;~(B : 1998$BG/(B2$B7n(B16$BF|(B 7:21
$B7oL>(B : RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes




>
>I love a symmetrical transport also. PC Printing has supported 1284, USB
and
>1394 soon. If you considers a symmetrical transport for 1284, USB and 1394
>(and IP), it will be great for us. To redesign PC software only for a new
>1394 print transport will be tough. I don't mean to recommend different
>solutions between PWG-C and PWG. We need to get our priorities right. Not
to
>confuse PC software industry is my first priority.
>
>I personally understand that 1284.4 may be a bridge over those local
>interfaces and familiar with an IP printer.
>
>Hitoshi Sekine
>
>
>> -----Original Message-----
>> From: Fumio Nagasaka [SMTP:fumiona@venus.dti.ne.jp]
>> Sent: Saturday, February 14, 1998 9:04 PM
>> To: 'Stephen Holmstead'; 'Toru Ueda'; Turner, Randy
>> Cc: 'Brian Batchelder'; p1394@pwg.org; 'PWG-C mailing';
>> 'p1284_3@lexmark.com'; Hitoshi Sekine
>> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
>>
>> Dear Stephen,
>>
>> Your opinion bring us back to December 1996. Actually we started from
>> this point.
>>
>> I would like to list up existing standards and some proposals here.
>>
>> Transaction architecture:
>> -------------------------------------------------------------------------
-
>> ----------------
>> IEEE 1394     |   Memory Bus
>> -------------------------------------------------------------------------
-
>> ----------------
>> SBP-2         |   Memory Bus
>> DPP           |   Stream       (PWG-C / Toru Ueda)
>> TCP           |   Stream
>> DFA           |   Stream       (PWG / Alan C. Berkema)
>> 1284.4         |   no definition
>> -------------------------------------------------------------------------
-
>> ----------------
>>
>> Transaction style:
>> -------------------------------------------------------------------------
-
>> ----------------
>> IEEE 1394     |   push and pull,  symmetrical
>> -------------------------------------------------------------------------
-
>> ----------------
>> SBP-2         |   pull
>> DPP           |   push,  symmetrical
>> TCP           |   push,  symmetrical (may implement passive open)
>> DFA           |   push,  symmetrical
>> 1284.4         |   push control, symmetrical
>> -------------------------------------------------------------------------
-
>> ----------------
>>
>> Please correct if I had overlooked something or I am missing some points.
>>
>> Stephen wrote:
>> <<
>> requirements).  I would HATE to have to make a printer that implemented
>> two different transports for PWG and PWG-C printing.  I think most
>> printer manufacturers would agree.
>> >>
>>
>> No.
>> Due to some market reasons, printer manufactures are required
>> to support USB, conventional parallel port, 1394 and Macintosh serial
>> interface. However Digital Camera (one of typical consumer imaging
>> device) does not support parallel port. Thus for some consumer
>> device manufactures, it is meaning less to have a solution which
>> provide common protocol stack to cover various existing interface.
>>
>> If PWG and PWG-C shall have same solution, I think we shall
>> have only one "Printer Working Group". However many Japanese
>> companies could not agree with this plan. They might have their own
>> reasons. And I think we ought to pay consideration for them.
>> --------------------------------------------
>> -------------------------------
>> Fumio Nagasaka
>> Epson Software Development Laboratory Inc.
>> Tel +81 268 25 4111,  Fax +81 268 25 4627
>> E-mail to nagasaka.fumio@exc.epson.co.jp
>>
>> -----Original Message-----
>> From: Stephen Holmstead [SMTP:stephen@hpb16977.boi.hp.com]
>> Sent: Saturday, February 14, 1998 12:59 PM
>> To: 'Toru Ueda'; Turner, Randy
>> Cc: 'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
>> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
>>
>> I agree with Toru that we NEED a symmetrical transport.  I really don't
>> care which option (A or B) is used, as long as we can provide a
>> symmetrical connection.  In fact, that was one of the PWG transport
>> requirements from that start, but it just seems that we have accepted a
>> transport (SBP-2) that isn't symmetrical and we are calling it good.
>> The PWG-C also needs a symmetrical transport.  I would love to have the
>> same transport for the PWG and PWG-C (since they both have the same
>> requirements).  I would HATE to have to make a printer that implemented
>> two different transports for PWG and PWG-C printing.  I think most
>> printer manufacturers would agree.
>>
>> Greg Shue said that he made a proposal to the January PWG that would
>> extend SBP-2 so that it was symmetrical (at least that is what I
>> understand--I may be way off here).  If so, that would be great.  I have
>> not been able to find any minutes from the PWG since Dec 97 (anyone got
>> some?).
>>
>> 1394 could really use a commonly accepted symmetrical transport layer.
>> If that's 1284.4, great.  If that's a modified SBP-2, great.  If that's
>> TCP/IP, great.  If that's DPP's Thin Protocol, great.
>>
>> Personally, I am biased towards IP or 1284.4 (if you couldn't tell).
>>
>> Stephen Holmstead
>>

From hitoshis at MICROSOFT.com  Mon Feb 16 00:59:36 1998
From: hitoshis at MICROSOFT.com (Hitoshi Sekine)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <199802140244.LAA13654@slant1.pure.cpdc.canon.co.jp>

Nakamura-san,


I still like to provide a same transport for PC software over the other
printer interfaces. Printer manufactures have supported USB, 1284 and .4 for
printers. I believe that no one like to develop software running only with
PWG specific 1394 printer protocol. We need consistency over any printing
devices.


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.




By the way, who is Eric? Whom did he contact with in MS? Though I don't own
a storage, I would like to hear the story from him. If someone in MS had
miscommunication with him, I can forward it to proprietary in MS.


Thanks,
Hitoshi


> -----Original Message-----
> From:	Atsushi Nakamura [SMTP:atsnaka@mxa.mesh.ne.jp]
> Sent:	Sunday, February 15, 1998 7:35 PM
> To:	Hitoshi Sekine
> Cc:	'PWG-C mailing'; p1284_3@lexmark.com; p1394@pwg.org
> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> 
> For PWG printing,
> We will have to decide whether not we use 1284.4 or not,
> but in any case, it is inefficient to stack overlapping
> functionality.
> My choices would be either :
> 
> 1) 1284.4 - "glue"- 1394
> 2) "glue"or cmd set - SBP-2- 1394
> 3) "glue"or cmd set - other transport(thin?)-1394
> 
> I am yet uncertain which is the best( maybe 2) or 3) ),
> but I DO have a opinion that in any case :
> 1284.4 over SBP-2
> is not my choice, because in this case;
> 
> >Sure, SBP-2 was present, but only as a
> >transport, and much of it's potential was wasted.
> 
> would happen. (same for 1284.4)
> Is using 1284.4 our first priority, or is using SBP-2 our
> first priority ? (or something else? )(or using both !?)
> 
> P.S I would like to refer to Eric's comment about the 1394 disks
>       again.
> >Recently, the 1394 community had the opportunity to define a
> >storage protocol for 1394.  The first solution, Tailgate, gave
> >us essentially an ATA interface bridged over 1394.  Both the
> >target and the initiator had to operate as if traditional ATA
> >was the interconnect.  Sure, SBP-2 was present, but only as a
> >transport, and much of it's potential was wasted.  Tailgate
> >was supposed to be quick an easy and lead to rapid market
> >adoption.  What actually happened was quite different.
> 
> I think this is the same situation with 1284.4 (as ATA) and
> SBP-2 (or IP,Thin.... )
> 
> >Microsoft and others realized that adopting this model would
> >"lock in" ATA for a long time, including long after ATA itself
> >was dead.  Emulating a dead technology with new technology may
> >yield short-term savings in implementation, but at the expense of
> >long-term losses in performance.  Amazingly, reason prevailed,
> >and Tailgate was abandoned in favor of a pure SBP-2 protocol
> >for disk drives.  As it turned out, Tailgate vendors quickly
> >switched to Native Bridge, which still allowed today's drives
> >to act like 1394 drives, by making them look (from a 1394
> >point of view) like fully native devices.  As far as I can tell
> >this switch was not too painful, and now we aren't stuck with
> >ATA.  Everyone won.
> 
> Let's not repeat history....
> 
> 
> -------------------------------------------------
> Atsushi Nakamura
> BJ Printing Technology 22
> Canon Inc.
> -------------------------------------------------
> 
> -----Original Message-----
> ??? : Hitoshi Sekine <hitoshis@microsoft.com>
> ?? : 'Fumio Nagasaka' <fumiona@venus.dti.ne.jp>; 'Stephen Holmstead'
> <stephen@hpb16977.boi.hp.com>; 'Toru Ueda' <ueda@slab.tnr.sharp.co.jp>;
> Turner, Randy <rturner@sharplabs.com>
> CC : 'Brian Batchelder' <brianb@vcd.hp.com>; p1394@pwg.org
> <p1394@pwg.org>;
> 'PWG-C mailing' <pp1394@cpdc.canon.co.jp>; 'p1284_3@lexmark.com'
> <p1284_3@lexmark.com>
> ?? : 1998?2?16? 7:21
> ?? : RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> 
> 
> >
> >I love a symmetrical transport also. PC Printing has supported 1284, USB
> and
> >1394 soon. If you considers a symmetrical transport for 1284, USB and
> 1394
> >(and IP), it will be great for us. To redesign PC software only for a new
> >1394 print transport will be tough. I don't mean to recommend different
> >solutions between PWG-C and PWG. We need to get our priorities right. Not
> to
> >confuse PC software industry is my first priority.
> >
> >I personally understand that 1284.4 may be a bridge over those local
> >interfaces and familiar with an IP printer.
> >
> >Hitoshi Sekine
> >
> >
> >> -----Original Message-----
> >> From: Fumio Nagasaka [SMTP:fumiona@venus.dti.ne.jp]
> >> Sent: Saturday, February 14, 1998 9:04 PM
> >> To: 'Stephen Holmstead'; 'Toru Ueda'; Turner, Randy
> >> Cc: 'Brian Batchelder'; p1394@pwg.org; 'PWG-C mailing';
> >> 'p1284_3@lexmark.com'; Hitoshi Sekine
> >> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> >>
> >> Dear Stephen,
> >>
> >> Your opinion bring us back to December 1996. Actually we started from
> >> this point.
> >>
> >> I would like to list up existing standards and some proposals here.
> >>
> >> Transaction architecture:
> >>
> -------------------------------------------------------------------------
> -
> >> ----------------
> >> IEEE 1394     |   Memory Bus
> >>
> -------------------------------------------------------------------------
> -
> >> ----------------
> >> SBP-2         |   Memory Bus
> >> DPP           |   Stream       (PWG-C / Toru Ueda)
> >> TCP           |   Stream
> >> DFA           |   Stream       (PWG / Alan C. Berkema)
> >> 1284.4         |   no definition
> >>
> -------------------------------------------------------------------------
> -
> >> ----------------
> >>
> >> Transaction style:
> >>
> -------------------------------------------------------------------------
> -
> >> ----------------
> >> IEEE 1394     |   push and pull,  symmetrical
> >>
> -------------------------------------------------------------------------
> -
> >> ----------------
> >> SBP-2         |   pull
> >> DPP           |   push,  symmetrical
> >> TCP           |   push,  symmetrical (may implement passive open)
> >> DFA           |   push,  symmetrical
> >> 1284.4         |   push control, symmetrical
> >>
> -------------------------------------------------------------------------
> -
> >> ----------------
> >>
> >> Please correct if I had overlooked something or I am missing some
> points.
> >>
> >> Stephen wrote:
> >> <<
> >> requirements).  I would HATE to have to make a printer that implemented
> >> two different transports for PWG and PWG-C printing.  I think most
> >> printer manufacturers would agree.
> >> >>
> >>
> >> No.
> >> Due to some market reasons, printer manufactures are required
> >> to support USB, conventional parallel port, 1394 and Macintosh serial
> >> interface. However Digital Camera (one of typical consumer imaging
> >> device) does not support parallel port. Thus for some consumer
> >> device manufactures, it is meaning less to have a solution which
> >> provide common protocol stack to cover various existing interface.
> >>
> >> If PWG and PWG-C shall have same solution, I think we shall
> >> have only one "Printer Working Group". However many Japanese
> >> companies could not agree with this plan. They might have their own
> >> reasons. And I think we ought to pay consideration for them.
> >> --------------------------------------------
> >> -------------------------------
> >> Fumio Nagasaka
> >> Epson Software Development Laboratory Inc.
> >> Tel +81 268 25 4111,  Fax +81 268 25 4627
> >> E-mail to nagasaka.fumio@exc.epson.co.jp
> >>
> >> -----Original Message-----
> >> From: Stephen Holmstead [SMTP:stephen@hpb16977.boi.hp.com]
> >> Sent: Saturday, February 14, 1998 12:59 PM
> >> To: 'Toru Ueda'; Turner, Randy
> >> Cc: 'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
> >> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> >>
> >> I agree with Toru that we NEED a symmetrical transport.  I really don't
> >> care which option (A or B) is used, as long as we can provide a
> >> symmetrical connection.  In fact, that was one of the PWG transport
> >> requirements from that start, but it just seems that we have accepted a
> >> transport (SBP-2) that isn't symmetrical and we are calling it good.
> >> The PWG-C also needs a symmetrical transport.  I would love to have the
> >> same transport for the PWG and PWG-C (since they both have the same
> >> requirements).  I would HATE to have to make a printer that implemented
> >> two different transports for PWG and PWG-C printing.  I think most
> >> printer manufacturers would agree.
> >>
> >> Greg Shue said that he made a proposal to the January PWG that would
> >> extend SBP-2 so that it was symmetrical (at least that is what I
> >> understand--I may be way off here).  If so, that would be great.  I
> have
> >> not been able to find any minutes from the PWG since Dec 97 (anyone got
> >> some?).
> >>
> >> 1394 could really use a commonly accepted symmetrical transport layer.
> >> If that's 1284.4, great.  If that's a modified SBP-2, great.  If that's
> >> TCP/IP, great.  If that's DPP's Thin Protocol, great.
> >>
> >> Personally, I am biased towards IP or 1284.4 (if you couldn't tell).
> >>
> >> Stephen Holmstead
> >>
> 
> 

From rturner at sharplabs.com  Mon Feb 16 01:29:27 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <199802140244.LAA13654@slant1.pure.cpdc.canon.co.jp>

I would like very much to be able to write 1394 multifunction apps
according to the Winsock 2 specification. I am coming to the conclusion
that I would like to see one of the following two architectures to be
used:
		
		1. Application over SBP-2  over 1394 transaction layer
(OHCI, etc.)
		2. Application over 1284.4 over 1394 transaction layer
(OHCI, etc.)


In my opinion we should have a goal of maintaining a single link layer
protocol for both THIN and THICK solutions (if there is a THICK
solution). This means that for DPP solutions I would like to see us use
SBP-2, both initiator and target. If the PWG-C designs a lighter weight
link layer protocol (lighter than SBP-2), then I think we should attempt
to standardize this protocol and use it.


You will notice that I have left out the option of 1284.4 over SBP-2
because I agree with the overall sentiment that there is significant
overlap between what the two protocols offer. If there is a desire to
use 1284.4, then mapping 1284.4 directly over the 1394 transaction layer
is a natural fit. If we want to use SBP-2, then there is really no need
to use 1284.4 and we can still provide the same API to application
software.


In my opinion, a target-only or initiator-only implementation of SBP-2
is not very interesting given the peer-to-peer capabilities of the 1394
interface. Which means that if I need true peer-to-peer functionality,
then I will have to create yet again another new link layer protocol,
and I would rather solve the link layer protocol problem once. I have
not seen a technical reason so far on the DL that would adequately
explain why we cannot settle on a single, peer-to-peer link layer
protocol for 1394.


As far as the "application" specified in options 1 and 2 above, I'm
assuming this would either be DPP, 1284.1, or some other application
layer protocol. 


Randy




	-----Original Message-----
	From:	Hitoshi Sekine [SMTP:hitoshis@MICROSOFT.com]
	Sent:	Sunday, February 15, 1998 10:00 PM
	To:	'atsnaka@mxa.mesh.ne.jp'
	Cc:	'p1284_3@lexmark.com'; 'p1394@pwg.org';
'pp1394@cpdc.canon.co.jp'
	Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes


	Nakamura-san,


	I still like to provide a same transport for PC software over
the other
	printer interfaces. Printer manufactures have supported USB,
1284 and .4 for
	printers. I believe that no one like to develop software running
only with
	PWG specific 1394 printer protocol. We need consistency over any
printing
	devices.


	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.




	By the way, who is Eric? Whom did he contact with in MS? Though
I don't own
	a storage, I would like to hear the story from him. If someone
in MS had
	miscommunication with him, I can forward it to proprietary in
MS.


	Thanks,
	Hitoshi


	> -----Original Message-----
	> From:	Atsushi Nakamura [SMTP:atsnaka@mxa.mesh.ne.jp]
	> Sent:	Sunday, February 15, 1998 7:35 PM
	> To:	Hitoshi Sekine
	> Cc:	'PWG-C mailing'; p1284_3@lexmark.com; p1394@pwg.org
	> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes
	> 
	> For PWG printing,
	> We will have to decide whether not we use 1284.4 or not,
	> but in any case, it is inefficient to stack overlapping
	> functionality.
	> My choices would be either :
	> 
	> 1) 1284.4 - "glue"- 1394
	> 2) "glue"or cmd set - SBP-2- 1394
	> 3) "glue"or cmd set - other transport(thin?)-1394
	> 
	> I am yet uncertain which is the best( maybe 2) or 3) ),
	> but I DO have a opinion that in any case :
	> 1284.4 over SBP-2
	> is not my choice, because in this case;
	> 
	> >Sure, SBP-2 was present, but only as a
	> >transport, and much of it's potential was wasted.
	> 
	> would happen. (same for 1284.4)
	> Is using 1284.4 our first priority, or is using SBP-2 our
	> first priority ? (or something else? )(or using both !?)
	> 
	> P.S I would like to refer to Eric's comment about the 1394
disks
	>       again.
	> >Recently, the 1394 community had the opportunity to define a
	> >storage protocol for 1394.  The first solution, Tailgate,
gave
	> >us essentially an ATA interface bridged over 1394.  Both the
	> >target and the initiator had to operate as if traditional ATA
	> >was the interconnect.  Sure, SBP-2 was present, but only as a
	> >transport, and much of it's potential was wasted.  Tailgate
	> >was supposed to be quick an easy and lead to rapid market
	> >adoption.  What actually happened was quite different.
	> 
	> I think this is the same situation with 1284.4 (as ATA) and
	> SBP-2 (or IP,Thin.... )
	> 
	> >Microsoft and others realized that adopting this model would
	> >"lock in" ATA for a long time, including long after ATA
itself
	> >was dead.  Emulating a dead technology with new technology
may
	> >yield short-term savings in implementation, but at the
expense of
	> >long-term losses in performance.  Amazingly, reason
prevailed,
	> >and Tailgate was abandoned in favor of a pure SBP-2 protocol
	> >for disk drives.  As it turned out, Tailgate vendors quickly
	> >switched to Native Bridge, which still allowed today's drives
	> >to act like 1394 drives, by making them look (from a 1394
	> >point of view) like fully native devices.  As far as I can
tell
	> >this switch was not too painful, and now we aren't stuck with
	> >ATA.  Everyone won.
	> 
	> Let's not repeat history....
	> 
	> 
	> -------------------------------------------------
	> Atsushi Nakamura
	> BJ Printing Technology 22
	> Canon Inc.
	> -------------------------------------------------
	> 
	> -----Original Message-----
	> ??? : Hitoshi Sekine <hitoshis@microsoft.com>
	> ?? : 'Fumio Nagasaka' <fumiona@venus.dti.ne.jp>; 'Stephen
Holmstead'
	> <stephen@hpb16977.boi.hp.com>; 'Toru Ueda'
<ueda@slab.tnr.sharp.co.jp>;
	> Turner, Randy <rturner@sharplabs.com>
	> CC : 'Brian Batchelder' <brianb@vcd.hp.com>; p1394@pwg.org
	> <p1394@pwg.org>;
	> 'PWG-C mailing' <pp1394@cpdc.canon.co.jp>;
'p1284_3@lexmark.com'
	> <p1284_3@lexmark.com>
	> ?? : 1998?2?16? 7:21
	> ?? : RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
	> 
	> 
	> >
	> >I love a symmetrical transport also. PC Printing has
supported 1284, USB
	> and
	> >1394 soon. If you considers a symmetrical transport for 1284,
USB and
	> 1394
	> >(and IP), it will be great for us. To redesign PC software
only for a new
	> >1394 print transport will be tough. I don't mean to recommend
different
	> >solutions between PWG-C and PWG. We need to get our
priorities right. Not
	> to
	> >confuse PC software industry is my first priority.
	> >
	> >I personally understand that 1284.4 may be a bridge over
those local
	> >interfaces and familiar with an IP printer.
	> >
	> >Hitoshi Sekine
	> >
	> >
	> >> -----Original Message-----
	> >> From: Fumio Nagasaka [SMTP:fumiona@venus.dti.ne.jp]
	> >> Sent: Saturday, February 14, 1998 9:04 PM
	> >> To: 'Stephen Holmstead'; 'Toru Ueda'; Turner, Randy
	> >> Cc: 'Brian Batchelder'; p1394@pwg.org; 'PWG-C mailing';
	> >> 'p1284_3@lexmark.com'; Hitoshi Sekine
	> >> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM
sizes
	> >>
	> >> Dear Stephen,
	> >>
	> >> Your opinion bring us back to December 1996. Actually we
started from
	> >> this point.
	> >>
	> >> I would like to list up existing standards and some
proposals here.
	> >>
	> >> Transaction architecture:
	> >>
	>
------------------------------------------------------------------------
-
	> -
	> >> ----------------
	> >> IEEE 1394     |   Memory Bus
	> >>
	>
------------------------------------------------------------------------
-
	> -
	> >> ----------------
	> >> SBP-2         |   Memory Bus
	> >> DPP           |   Stream       (PWG-C / Toru Ueda)
	> >> TCP           |   Stream
	> >> DFA           |   Stream       (PWG / Alan C. Berkema)
	> >> 1284.4         |   no definition
	> >>
	>
------------------------------------------------------------------------
-
	> -
	> >> ----------------
	> >>
	> >> Transaction style:
	> >>
	>
------------------------------------------------------------------------
-
	> -
	> >> ----------------
	> >> IEEE 1394     |   push and pull,  symmetrical
	> >>
	>
------------------------------------------------------------------------
-
	> -
	> >> ----------------
	> >> SBP-2         |   pull
	> >> DPP           |   push,  symmetrical
	> >> TCP           |   push,  symmetrical (may implement passive
open)
	> >> DFA           |   push,  symmetrical
	> >> 1284.4         |   push control, symmetrical
	> >>
	>
------------------------------------------------------------------------
-
	> -
	> >> ----------------
	> >>
	> >> Please correct if I had overlooked something or I am
missing some
	> points.
	> >>
	> >> Stephen wrote:
	> >> <<
	> >> requirements).  I would HATE to have to make a printer that
implemented
	> >> two different transports for PWG and PWG-C printing.  I
think most
	> >> printer manufacturers would agree.
	> >> >>
	> >>
	> >> No.
	> >> Due to some market reasons, printer manufactures are
required
	> >> to support USB, conventional parallel port, 1394 and
Macintosh serial
	> >> interface. However Digital Camera (one of typical consumer
imaging
	> >> device) does not support parallel port. Thus for some
consumer
	> >> device manufactures, it is meaning less to have a solution
which
	> >> provide common protocol stack to cover various existing
interface.
	> >>
	> >> If PWG and PWG-C shall have same solution, I think we shall
	> >> have only one "Printer Working Group". However many
Japanese
	> >> companies could not agree with this plan. They might have
their own
	> >> reasons. And I think we ought to pay consideration for
them.
	> >> --------------------------------------------
	> >> -------------------------------
	> >> Fumio Nagasaka
	> >> Epson Software Development Laboratory Inc.
	> >> Tel +81 268 25 4111,  Fax +81 268 25 4627
	> >> E-mail to nagasaka.fumio@exc.epson.co.jp
	> >>
	> >> -----Original Message-----
	> >> From: Stephen Holmstead [SMTP:stephen@hpb16977.boi.hp.com]
	> >> Sent: Saturday, February 14, 1998 12:59 PM
	> >> To: 'Toru Ueda'; Turner, Randy
	> >> Cc: 'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
	> >> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM
sizes
	> >>
	> >> I agree with Toru that we NEED a symmetrical transport.  I
really don't
	> >> care which option (A or B) is used, as long as we can
provide a
	> >> symmetrical connection.  In fact, that was one of the PWG
transport
	> >> requirements from that start, but it just seems that we
have accepted a
	> >> transport (SBP-2) that isn't symmetrical and we are calling
it good.
	> >> The PWG-C also needs a symmetrical transport.  I would love
to have the
	> >> same transport for the PWG and PWG-C (since they both have
the same
	> >> requirements).  I would HATE to have to make a printer that
implemented
	> >> two different transports for PWG and PWG-C printing.  I
think most
	> >> printer manufacturers would agree.
	> >>
	> >> Greg Shue said that he made a proposal to the January PWG
that would
	> >> extend SBP-2 so that it was symmetrical (at least that is
what I
	> >> understand--I may be way off here).  If so, that would be
great.  I
	> have
	> >> not been able to find any minutes from the PWG since Dec 97
(anyone got
	> >> some?).
	> >>
	> >> 1394 could really use a commonly accepted symmetrical
transport layer.
	> >> If that's 1284.4, great.  If that's a modified SBP-2,
great.  If that's
	> >> TCP/IP, great.  If that's DPP's Thin Protocol, great.
	> >>
	> >> Personally, I am biased towards IP or 1284.4 (if you
couldn't tell).
	> >>
	> >> Stephen Holmstead
	> >>
	> 
	> 

From ueda at slab.tnr.sharp.co.jp  Mon Feb 16 15:26:15 1998
From: ueda at slab.tnr.sharp.co.jp (Toru Ueda)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
In-Reply-To: <01BD3A1C.360A9380@p18-dn02ueda.nagano.ocn.ne.jp>
Message-ID: <9802160626.AA03178@slab.slab.tnr.sharp.co.jp>

Hi Nagasaka-san,


Actually a Digital Cam corder is around $2000 list price. It's not CHEAP
though :-).


We are still working to finalize the protocol and estimate the ROM size.
I only can say is that our target ROM size for Thin protocol of DPP is
less than 10KB. This includes sender and receiver function.


If your node doesn't have to implement all functionality, it will be
smaller. This is the case that the node must receive the connection
request but doesn't need to send the request of connection.


We also want to emphasize that DPP has simple scheme. 
 1) send "connect request"
 2) send "data"
 3) receive "acknowledge"
 4) do 2) and 3)
 5) send "disconnect request"


The other side can also do 2),3),4),5).
This is very straightforward.


Again I don't want to make any confusion in PC printing discussion. 
I just want to tell DPP to PWG correctly.


Toru Ueda
Sharp Corp.
Software Labs.


On Sun, 15 Feb 1998 13:21:45 +0900
Fumio Nagasaka <fumiona@venus.dti.ne.jp> wrote:


> Dear Toru san,
> 
> One point.
> I think 30k is good size even for cheap consumer devices.
> This size is smaller than typical VxWorks implementation, and it
> may be smaller than JetSend.
> 
> So please give us information how big your DPP ROM size is expected to.
> 
> --------------------------------------------
> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
> 
> -----Original Message-----
> From:	Toru Ueda [SMTP:ueda@slab.tnr.sharp.co.jp]
> Sent:	Saturday, February 14, 1998 6:45 AM
> To:	Turner, Randy
> Cc:	'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
> Subject:	Re[2]: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> 
> 
> I don't want to make any confusion about PC printing protocol. This is
> only for your information.
> 
> >From consumer device point of view, "symmetrical" is the essential
> feature of the protocol.
> For example, a digital still camera wants to send its image data to
> printers.  Also the same camera wants to receive image data from the 
> other still cameras. We want to use the same protocol for both use.
> 
> These are three essential features for consumer device.
> 
> 1) Bi-directional
>   Each side can send and receive data.
>   SBP2 supports bi-directional feature.
>   
> 2) "True" bi-directional
>   Each side can send and receive data at any time.
>   Alan's architecture supports "true" bi-directional feature by using
>   transmit buffer, receive buffer and unsolicited status.
>   
> 3) Symmetrical
>   Each side has the same architecture.
>   This is completely different from bi-directional issue.
>   
> Consumer device needs these three features and the protocol must be
> simple.
> 
> If SBP2 implementation needs 30K for initiator and target, it might be
> difficult to use it for consumer device.
> 
> Toru Ueda
> Software labs.
> Sharp Corp.
> 
> On Wed, 11 Feb 1998 08:35:10 -0800
> "Turner, Randy" <rturner@sharplabs.com> wrote:
> 
> > 
> > 
> > I didn't know chip sets offered "explicit" support for SBP-2. OHCI
> > maybe, but I hadn't seen the chip set feature in the brochure for
> > "chip-level SBP-2 support".
> > 
> > Also, since 1394 is a peer-to-peer interface, anyone developing a
> > peer-to-peer device (like the majority of the Japanese electronics
> > industry), would have to essentially duplicate the functionality of
> > SBP-2 initiator and target, whether they actually use SBP-2 to do this,
> > or some other (potentially proprietary) method for implementing
> > peer-to-peer functionality.
> > 
> > Randy
> > 
> > 
> > 
> > 	-----Original Message-----
> > 	From:	Stephen Homestead [SMTP:stephen@hpb16977.boi.hp.com]
> > 	Sent:	Wednesday, February 11, 1998 8:30 AM
> > 	To:	'Turner, Randy'; 'Brian Batchelder'; p1394@pwg.org
> > 	Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> > ROM sizes
> > 
> > 	My experiences in the past is that combining target AND
> > initiator
> > 	functions into a single device is VERY difficult.  The
> > complexity of the
> > 	state tables and ambiguities that can arise make it very
> > difficult.
> > 	Also, I don't believe any of the chip manufacturers support
> > SBP-2 for
> > 	both target and initiator.  In my opinion, it's NOT just a
> > matter of
> > 	adding the 15K for the target and 15K for the initiator.  The
> > target and
> > 	initiator have vastly different functions.   Designing a model
> > that did
> > 	both (well) would be a challenge.  It was problems like this
> > that fueled
> > 	many of the AEN (asynchronous event notification) debates.
> > 
> > 	Stephen
> > 
> > 	> -----Original Message-----
> > 	> From:	Turner, Randy [SMTP:rturner@sharplabs.com]
> > 	> Sent:	Monday, February 09, 1998 1:03 PM
> > 	> To:	'Brian Batchelder'; p1394@pwg.org
> > 	> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> > ROM sizes
> > 	> 
> > 	> 
> > 	> I am very interested in the combined target/initiator
> > footprint as
> > 	> well.
> > 	> 
> > 	> Thx
> > 	> 
> > 	> Randy
> > 	> 
> > 	> 
> > 	> 	-----Original Message-----
> > 	> 	From:	Brian Batchelder [SMTP:brianb@vcd.hp.com]
> > 	> 	Sent:	Monday, February 09, 1998 9:37 AM
> > 	> 	To:	p1394@pwg.org
> > 	> 	Subject:	Re: P1394> Rough SBP-2 & IP1394 core
> > component
> > 	> ROM sizes
> > 	> 
> > 	> 	At 02:04 PM 2/6/98 -0800, Greg Shue wrote:
> > 	> 
> > 	> 	[snip]
> > 	> 
> > 	> 	>I approached them about sharing some rough estimates of
> > code
> > 	> size
> > 	> 	>for the IP1394 glue, SBP-2 target and initiator, and
> > 1394 bus
> > 	> 	>manager modules to get a feel for how "heavy" the
> > protocol
> > 	> 	>implementations really are.  They graciously shared the
> > flowing
> > 	> 	>estimates with us, and certainly deserve our thanks.
> > Since the
> > 	> 	>technology is still being developed, these
> > implementations are
> > 	> 	>certainly going to be tuned and the numbers will change
> > a
> > 	> little
> > 	> 	>bit.
> > 	> 	>
> > 	> 	>  Component                Rough ROM size (KBytes)
> > 	> 	>  ---------                -----------------------
> > 	> 	>  SBP-2 initiator core     15 +/- 5
> > 	> 	>  SBP-2 target core        15 +/- 5  (incl. Mgmt+Fetch
> > agent,
> > 	> no exec agent)
> > 	> 
> > 	> 	Any idea how big a combined SBP-2 target/initiator would
> > be?
> > 	> 15-30K? ;-)
> > 	> 
> > 	> 	[snip]
> > 	> 
> > 	> 	Brian
> > 	> 
> > 	>
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 	> ~
> > 	> 	Brian Batchelder      | Hewlett-Packard      |
> > 	> mailto:brianb@vcd.hp.com  
> > 	> 	Connectivity Futurist | 1115 SE 164th Ave.   | Phone:
> > (360)
> > 	> 212-4107  
> > 	> 	DeskJet Printers      | Vancouver, WA  98684 | Fax:
> > (360)
> > 	> 212-4227
> > 
> 
> 
> 

From shinoda at bsd.canon.co.jp  Mon Feb 16 01:00:19 1998
From: shinoda at bsd.canon.co.jp (Nobuhiko Shinoda)
Date: Wed May  6 14:00:48 2009
Subject: [PP1394:00156] RE: Re[2]: P1394> Rough SBP-2 & IP1394 core
In-Reply-To: <[PP1394:00156] RE: Re[2]: P1394> Rough SBP-2 & IP1394 core>
Message-ID: <199802160603.PAA05277@bsdmail.bsd.canon.co.jp>

Nagasaka-san:


Seeing the previous mail of Ueda-san, the ROM size isuue is not the discussing
point.  And I hardly understand your comparison of the code size to VxWorks or
Jet Send.


The value of 30k itself has not determined well enough.  Even if it is true,
does 30k cover real symmetric structure for the equipment and  some upper layer
i/f capability which Thin Protocol might cover to put on DPP command/data set
?


I am slightly sensitive to talk about just ROM size based on someone's
imagination or illusion which has not well identfied the functionality.  


Jet Send's code size is not worth for comparing or discussing transport layer.
"Consumer" product is very sensitive to cost of code size, but it also depends
on the benefit of "consumer".  In my experience, the first EOS system had 64kB
total ROM 10 years ago, but it was successful in the market for the reason of
integration of automatic and manual tuning capability with simple user
interface.  JetSend might lead successful product in consumer market regardless
of its code size.  But this is not the discussiong point in PWG-C.


I may be wrong, or misunderstood your point due to my lack of knowledge, but
the questioning the ROM size to Ueda-san sounds very strange after checking the
back log you attatched.








At 14:11 98/02/15 +0900, you wrote:
> Dear Toru san,
> 
> One point.
> I think 30k is good size even for cheap consumer devices.
> This size is smaller than typical VxWorks implementation, and it
> may be smaller than JetSend.
> 
> So please give us information how big your DPP ROM size is expected to.
> 


$B<DED!!?.Hf8E(J
$B#N#o#b#u#h#i#k#o!!#S#h#i#n#o#d#a(J
B$B%7%9%F%`3+H/ItItD9(J
General$B!!(JManager
BJ Printing System Development Division
B$B5!4o5;=Q3+H/%;%s%?!<I{=jD9(J
Assistant Senior General Manager
BJ Printing System Technology$B!!(JDevelopment Center
$B#C#a#n#o#n!!#I#n#c!%(J

From Nagasaka.Fumio at exc.epson.co.jp  Mon Feb 16 02:43:16 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:48 2009
Subject: [PP1394:00162] Re: Re[2]: P1394> Rough SBP-2 & IP1394 corecom
In-Reply-To: <[PP1394:00162] Re: Re[2]: P1394> Rough SBP-2 & IP1394 corecom>
Message-ID: <199802160603.PAA05277@bsdmail.bsd.canon.co.jp>

Nobuhiko wrote:
<<
I may be wrong, or misunderstood your point due to my lack of knowledge,
but the questioning the ROM size to Ueda-san sounds very strange after
checking the back log you attatched.
>>


I don$B!G(Jt$B!G(J think so.(J
The $B!H(Jsubject$B!I(J of these mail is $B!H(JRough SBP-2 & IP1394 corecomponent(J
ROM sizes$B!I(J,(J
and Greg gave us how big ROM size would be if we use SBP-2 target and
initiator.


Toru said,
<<
If SBP2 implementation needs 30K for initiator and target, it might be
difficult to use it for consumer device.
>>


I would like to know what is acceptable size of ROM for consumer device.
May be various types of devices have their own implementation. However 
I guess Toru knows DPP very well. So I think his information is
important.
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


		-----Original Message-----
		From:	Nobuhiko Shinoda [SMTP:shinoda@bsd.canon.co.jp]
		Sent:	Monday, February 16, 1998 3:03 PM
		To:	pp1394 ML
		Cc:	Fumio Nagasaka; 'Toru Ueda'; Turner, Randy;
'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
		Subject:	[PP1394:00162] Re: Re[2]: P1394> Rough
SBP-2 & IP1394 corecomponent ROM sizes




		Nagasaka-san:


		Seeing the previous mail of Ueda-san, the ROM size isuue
is not the discussing
		point.  And I hardly understand your comparison of the
code size to VxWorks or
		Jet Send.


		The value of 30k itself has not determined well enough.
Even if it is true,
		does 30k cover real symmetric structure for the
equipment and  some upper layer
		i/f capability which Thin Protocol might cover to put on
DPP command/data set
		?


		I am slightly sensitive to talk about just ROM size
based on someone's
		imagination or illusion which has not well identfied the
functionality.  


		Jet Send's code size is not worth for comparing or
discussing transport layer.
		"Consumer" product is very sensitive to cost of code
size, but it also depends
		on the benefit of "consumer".  In my experience, the
first EOS system had 64kB
		total ROM 10 years ago, but it was successful in the
market for the reason of
		integration of automatic and manual tuning capability
with simple user
		interface.  JetSend might lead successful product in
consumer market regardless
		of its code size.  But this is not the discussiong point
in PWG-C.


		I may be wrong, or misunderstood your point due to my
lack of knowledge, but
		the questioning the ROM size to Ueda-san sounds very
strange after checking the
		back log you attatched.








		At 14:11 98/02/15 +0900, you wrote:
		> Dear Toru san,
		> 
		> One point.
		> I think 30k is good size even for cheap consumer
devices.
		> This size is smaller than typical VxWorks
implementation, and it
		> may be smaller than JetSend.
		> 
		> So please give us information how big your DPP ROM
size is expected to.
		> 


		$B<DED!!?.Hf8E(J
		$B#N#o#b#u#h#i#k#o!!#S#h#i#n#o#d#a(J
		B$B%7%9%F%`3+H/ItItD9(J
		General$B!!(JManager(J
		BJ Printing System Development Division
		B$B5!4o5;=Q3+H/%;%s%?!<I{=jD9(J
		Assistant Senior General Manager
		BJ Printing System Technology$B!!(JDevelopment Center(J
		$B#C#a#n#o#n!!#I#n#c!%(J

From Nagasaka.Fumio at exc.epson.co.jp  Mon Feb 16 06:57:32 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM
Message-ID: <199802160603.PAA05277@bsdmail.bsd.canon.co.jp>

Dear Toru,


Thanks for your productive information.
My colleague has written a SBP-2 target software for our printer
optional board fitted with H8 CPU. The ROM size was 18k B.
Those source code was developed by C and assembler. Thus
we confirm Greg$B!G(Js estimation for SBP-2 ROM size is correct.(J
And I also think this size of ROM or CPU would not be acceptable for
some consumer devices. For these devices, DPP could be a
desirable solution.


So please continue to explain your idea about 1394 printing.
Does your DPP seem to be stream style protocol? Or are you
going to have any plan to provide memory bus style protocol?
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


		-----Original Message-----
		From:	Toru Ueda [SMTP:ueda@slab.tnr.sharp.co.jp]
		Sent:	Tuesday, February 17, 1998 12:26 AM
		To:	Fumio Nagasaka
		Cc:	'Stephen Holmstead'; 'Brian Batchelder';
p1394@pwg.org; 'PWG-C mailing'; Turner, Randy
		Subject:	Re[2]: Re[2]: P1394> Rough SBP-2 &
IP1394 core component ROM sizes


		Hi Nagasaka-san,


		Actually a Digital Cam corder is around $2000 list
price. It's not CHEAP
		though :-).


		We are still working to finalize the protocol and
estimate the ROM size.
		I only can say is that our target ROM size for Thin
protocol of DPP is
		less than 10KB. This includes sender and receiver
function.


		If your node doesn't have to implement all
functionality, it will be
		smaller. This is the case that the node must receive the
connection
		request but doesn't need to send the request of
connection.


		We also want to emphasize that DPP has simple scheme. 
		 1) send "connect request"
		 2) send "data"
		 3) receive "acknowledge"
		 4) do 2) and 3)
		 5) send "disconnect request"


		The other side can also do 2),3),4),5).
		This is very straightforward.


		Again I don't want to make any confusion in PC printing
discussion. 
		I just want to tell DPP to PWG correctly.


		Toru Ueda
		Sharp Corp.
		Software Labs.


		On Sun, 15 Feb 1998 13:21:45 +0900
		Fumio Nagasaka <fumiona@venus.dti.ne.jp> wrote:


		> Dear Toru san,
		> 
		> One point.
		> I think 30k is good size even for cheap consumer
devices.
		> This size is smaller than typical VxWorks
implementation, and it
		> may be smaller than JetSend.
		> 
		> So please give us information how big your DPP ROM
size is expected to.
		> 
		> --------------------------------------------
		> -------------------------------
		> Fumio Nagasaka
		> Epson Software Development Laboratory Inc.
		> Tel +81 268 25 4111,  Fax +81 268 25 4627
		> E-mail to nagasaka.fumio@exc.epson.co.jp
		> 
		> -----Original Message-----
		> From:	Toru Ueda [SMTP:ueda@slab.tnr.sharp.co.jp]
		> Sent:	Saturday, February 14, 1998 6:45 AM
		> To:	Turner, Randy
		> Cc:	'Stephen Holmstead'; 'Brian Batchelder';
p1394@pwg.org
		> Subject:	Re[2]: P1394> Rough SBP-2 & IP1394 core
component ROM sizes
		> 
		> 
		> I don't want to make any confusion about PC printing
protocol. This is
		> only for your information.
		> 
		> >From consumer device point of view, "symmetrical" is
the essential
		> feature of the protocol.
		> For example, a digital still camera wants to send its
image data to
		> printers.  Also the same camera wants to receive image
data from the 
		> other still cameras. We want to use the same protocol
for both use.
		> 
		> These are three essential features for consumer
device.
		> 
		> 1) Bi-directional
		>   Each side can send and receive data.
		>   SBP2 supports bi-directional feature.
		>   
		> 2) "True" bi-directional
		>   Each side can send and receive data at any time.
		>   Alan's architecture supports "true" bi-directional
feature by using
		>   transmit buffer, receive buffer and unsolicited
status.
		>   
		> 3) Symmetrical
		>   Each side has the same architecture.
		>   This is completely different from bi-directional
issue.
		>   
		> Consumer device needs these three features and the
protocol must be
		> simple.
		> 
		> If SBP2 implementation needs 30K for initiator and
target, it might be
		> difficult to use it for consumer device.
		> 
		> Toru Ueda
		> Software labs.
		> Sharp Corp.
		> 
		> On Wed, 11 Feb 1998 08:35:10 -0800
		> "Turner, Randy" <rturner@sharplabs.com> wrote:
		> 
		> > 
		> > 
		> > I didn't know chip sets offered "explicit" support
for SBP-2. OHCI
		> > maybe, but I hadn't seen the chip set feature in the
brochure for
		> > "chip-level SBP-2 support".
		> > 
		> > Also, since 1394 is a peer-to-peer interface, anyone
developing a
		> > peer-to-peer device (like the majority of the
Japanese electronics
		> > industry), would have to essentially duplicate the
functionality of
		> > SBP-2 initiator and target, whether they actually
use SBP-2 to do this,
		> > or some other (potentially proprietary) method for
implementing
		> > peer-to-peer functionality.
		> > 
		> > Randy
		> > 
		> > 
		> > 
		> > 	-----Original Message-----
		> > 	From:	Stephen Homestead
[SMTP:stephen@hpb16977.boi.hp.com]
		> > 	Sent:	Wednesday, February 11, 1998 8:30 AM
		> > 	To:	'Turner, Randy'; 'Brian Batchelder';
p1394@pwg.org
		> > 	Subject:	RE: P1394> Rough SBP-2 & IP1394
core component
		> > ROM sizes
		> > 
		> > 	My experiences in the past is that combining
target AND
		> > initiator
		> > 	functions into a single device is VERY
difficult.  The
		> > complexity of the
		> > 	state tables and ambiguities that can arise make
it very
		> > difficult.
		> > 	Also, I don't believe any of the chip
manufacturers support
		> > SBP-2 for
		> > 	both target and initiator.  In my opinion, it's
NOT just a
		> > matter of
		> > 	adding the 15K for the target and 15K for the
initiator.  The
		> > target and
		> > 	initiator have vastly different functions.
Designing a model
		> > that did
		> > 	both (well) would be a challenge.  It was
problems like this
		> > that fueled
		> > 	many of the AEN (asynchronous event
notification) debates.
		> > 
		> > 	Stephen
		> > 
		> > 	> -----Original Message-----
		> > 	> From:	Turner, Randy
[SMTP:rturner@sharplabs.com]
		> > 	> Sent:	Monday, February 09, 1998 1:03 PM
		> > 	> To:	'Brian Batchelder'; p1394@pwg.org
		> > 	> Subject:	RE: P1394> Rough SBP-2 & IP1394
core component
		> > ROM sizes
		> > 	> 
		> > 	> 
		> > 	> I am very interested in the combined
target/initiator
		> > footprint as
		> > 	> well.
		> > 	> 
		> > 	> Thx
		> > 	> 
		> > 	> Randy
		> > 	> 
		> > 	> 
		> > 	> 	-----Original Message-----
		> > 	> 	From:	Brian Batchelder
[SMTP:brianb@vcd.hp.com]
		> > 	> 	Sent:	Monday, February 09, 1998 9:37
AM
		> > 	> 	To:	p1394@pwg.org
		> > 	> 	Subject:	Re: P1394> Rough SBP-2 &
IP1394 core
		> > component
		> > 	> ROM sizes
		> > 	> 
		> > 	> 	At 02:04 PM 2/6/98 -0800, Greg Shue
wrote:
		> > 	> 
		> > 	> 	[snip]
		> > 	> 
		> > 	> 	>I approached them about sharing some
rough estimates of
		> > code
		> > 	> size
		> > 	> 	>for the IP1394 glue, SBP-2 target and
initiator, and
		> > 1394 bus
		> > 	> 	>manager modules to get a feel for how
"heavy" the
		> > protocol
		> > 	> 	>implementations really are.  They
graciously shared the
		> > flowing
		> > 	> 	>estimates with us, and certainly
deserve our thanks.
		> > Since the
		> > 	> 	>technology is still being developed,
these
		> > implementations are
		> > 	> 	>certainly going to be tuned and the
numbers will change
		> > a
		> > 	> little
		> > 	> 	>bit.
		> > 	> 	>
		> > 	> 	>  Component                Rough ROM
size (KBytes)
		> > 	> 	>  ---------
-----------------------
		> > 	> 	>  SBP-2 initiator core     15 +/- 5
		> > 	> 	>  SBP-2 target core        15 +/- 5
(incl. Mgmt+Fetch
		> > agent,
		> > 	> no exec agent)
		> > 	> 
		> > 	> 	Any idea how big a combined SBP-2
target/initiator would
		> > be?
		> > 	> 15-30K? ;-)
		> > 	> 
		> > 	> 	[snip]
		> > 	> 
		> > 	> 	Brian
		> > 	> 
		> > 	>
		> >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
		> > 	> ~
		> > 	> 	Brian Batchelder      | Hewlett-Packard
|
		> > 	> mailto:brianb@vcd.hp.com  
		> > 	> 	Connectivity Futurist | 1115 SE 164th
Ave.   | Phone:
		> > (360)
		> > 	> 212-4107  
		> > 	> 	DeskJet Printers      | Vancouver, WA
98684 | Fax:
		> > (360)
		> > 	> 212-4227
		> > 
		> 
		> 
		> 
		

From hirata at vip.iwa.fujixerox.co.jp  Mon Feb 16 07:17:04 1998
From: hirata at vip.iwa.fujixerox.co.jp (Kazuhiro HiRATA)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Re: Rough SBP-2 & IP1394 core component ROM sizes
In-Reply-To: <Rough SBP-2 & IP1394 core component ROM sizes>
Message-ID: <199802161216.VAA29359@goudy.vip.iwa.fujixerox.co.jp>

Hi, all.


My rough estimation of ROM code size of thin transport (transaction and 
session) of DPP is less than 8KB with 16bit-CISC based CPU.


However, I do NOT think that focusing to only ROM size to compare 
transport cost is productive discussion.  The CPU power requirement that 
handles the transport is also important factor to compare.  The other 
effective resource sizes rather than ROM should be compared to estimate 
the cost.


Also, the cost requirement of consumer product is only one example of 
thousand variety.  Everyone could say only smaller and cheaper is better.


Estimation is not more than estimation.


We should consider which we wish either backward compatibility or future 
possibility first.  It must effect the cost also.


Anyway, I don't think it is better solution to use 1284.4 over SBP-2 for 
PC printing.  If everyone recommend to use 1284.4 for PC printing, we 
should make a profile with 1284.4 over 1394 at first.


Alan or Greg, why did you choose SBP-2 based profile rather than 1284.4 
at Jan. PWG?


//HiRATA@Feb.16'98 JST

From shimura at pure.cpdc.canon.co.jp  Mon Feb 16 08:03:16 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:48 2009
Subject: How the solution B works? (Re: P1394> 1284.4 over SBP-2)
In-Reply-To: <199802121824.KAA26099@hpsdlgj1.sdd.hp.com>
Message-ID: <199802161303.WAA18137@origin.pure.cpdc.canon.co.jp>

On Thu, 12 Feb 1998 10:24:21 -0800 (PST)
Greg Shue <gregs@sdd.hp.com> wrote:
>   If the target doesn't behave as expected and has lots of unsolicited
>   data for the initiator, the target aborts the current task set and
>   the initiator pauses sending data to the target until the target has
>   no more data for the initiator.


The flow control part of "target-to-initiator" data transfer seems to
be missing here.


I suppose that the condition follows to "until" in the above sentence
would be "until the target has no more data for the initiator OR the
initiator does not have resources to receive more data from the target."
Is this what you intended or am I still missing something?


>   If we are doing unidirectional printing, then there is no data
>   for the initiator, and the task set is never aborted.
> 
>   If we are interacting with the device, and it behaves as expected,
>   then there is no unexpected data for the initiator, so the task
>   set is never aborted.  (For interactive Postscript, scanning models,
>   and request/reply paradigms like SNMP)


This sounds like expectation (or requirement) for client applications
to be master/slave.
It seems that "request/reply" is expected to be done indivisibly and
sequencially. Does the solution well cover the case "requests/replies"
are done in parallel (more than one request are outstanding) as well?




Akihiro Shimura


On Thu, 12 Feb 1998 10:24:21 -0800 (PST)
Greg Shue <gregs@sdd.hp.com> wrote:


> Akihiro Shimura writes:
> > Basically, I also support to consider option B, but it is still not
> > clear for me how the data transfer of each direction is done
> > independently within single login in SBP-2 only solution.
> > 
> > If target request data transfer by "Data Available" flag in certain
> > status block, initiator will subsequently append "SND data-in" ORB in
> > the current task list. It will be possible for the target to check if
> > there is a "SND data-in" ORB in the task list BEFORE the initiator
> > appends the "SND data-in" ORB. After finding there is no "SND data-in"
> > ORB, the target may issue another unsolicited status which indicates
> > "Data Available". By this status, the initiator may append one more
> > (total two) "SND data-in" ORB in the task list. After that, the
> > target will need to abort the excessive ORB.
> > Is this a way the SBP-2 only solution works?
> 
> It's not the way I intended it to work.  Let me work through
> the model I've had in mind.
> 
> It is a status signal that data is available for the initiator.  It is
> not an event requesting a new task be placed on the task list.
> 
> The status is updated at exactly two points in time:  on the
> completion of a task; and on a spontaneous change from No Data
> Available to Data Available when there are to active tasks on the
> task list.  It is up to the initiator to determine whether a new
> task needs to be enqueued on the task list or not.  The task
> enqueuing algorithm for the initiator would basically be:
> 
>   for (;;)
>   {
>       while target has unexpected data available
> 	  get target data one request at a time
> 
>       enqueue one request for an expected data transfer
>   }
> 
> When the target has data available, and at least one request
> exists on the active task list, the data available indication is
> given on the completion status of the first ORB.  The initiator
> will enqueue a new ORB for receiving target data if, and only if,
> no request for target data has already been enqueued on the task
> list.  This ORB would be associated with the "hanging read"
> already required for independent communication in each direction.
> 
> The target would continue to process the ORB list until one of
> the following states is reached:
> 
>   S1) the ORB list will be empty  (no active task set)
> 
>   S2) the ORB list processing stalls at a data transfer to the target,
>       and the target has no data for the initiator.
>       (no more target buffer space, and no reason to abort the task set)
> 
>   S3) the ORB list processing stalls at a data transfer to the initiator
>       (initiator expects data from the target, but none is currently
>        available)
> 
> When data becomes available, the following transitions take place:
> 
>   From S1
>     the target signals Data Available via unsolicited status;
>     the initiator enqueues one ORB to receive the data;
>     the target resumes processing the ORB;
>     on completion of the request, the target indicates whether
>       or not more data is available.
> 
>   From S2
>     the target aborts all the requests on the task list and indicates
>       that data is available for the initiator on each request;
>     the initiator enqueues one ORB to receive the data;
>     the target resumes processing the ORB;
>     on completion of the request, the target indicates whether
>       or not more data is available.
> 
>     When the target has no more data available, the initiator
>       requeues the aborted requests.
> 
>   From S3
>     the target continues processing the task set
> 
> The only ineffeciency occurs when the target doesn't behave the way
> the initiator expects.
> 
>   If we are doing unidirectional printing, then there is no data
>   for the initiator, and the task set is never aborted.
> 
>   If we are interacting with the device, and it behaves as expected,
>   then there is no unexpected data for the initiator, so the task
>   set is never aborted.  (For interactive Postscript, scanning models,
>   and request/reply paradigms like SNMP)
> 
>   If the target doesn't behave as expected and has lots of unsolicited
>   data for the initiator, the target aborts the current task set and
>   the initiator pauses sending data to the target until the target has
>   no more data for the initiator.
> 
> The worst-case scenario occurs if the target keeps generating bursts
> of unexpected data for the initiator and the task sets are perpetually
> aborted.  The net effect of this is minimized simply by minimizing
> the length of the active task set!  Having 2-4 data transfer requests
> queued  (e.g. double-buffering) may be sufficient (for most applications)
> to keep the task list running and the target busy.
> 
> 
> > I think that aborting tasks implies subsequent task retries, and may
> > not be efficient.
> 
> Yes, aborting tasks implies subsequent task retries.
> The overhead is in the target (pre) fetching the ORBs
> in order to abort them, and in requeuing the task set
> when the data available indication disappears.
> 
> But don't forget that the maximum data transfer size is known,
> so the target doesn't need to fetch any real data until it knows
> that it can complete the request!
> 
> > It seems natural to make two independent logins for each direction,
> > one for down-link and another for up-link by using the idea to map
> > them into logical units. Furthermore, by extending this to allow to
> > allocate up-link in reverse fashion (i.e., the target of down-link
> > makes a login to the initiator of down-link), the link between two
> > devices will become symmetric if both ends have both initiator and
> > target functionality.
> > 
> > Any suggestions?
> 
> Haven't we been down this road before?  (Yes, and rejected it.)
> 
> 
> > --
> >  Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
> >  Office Imaging Products Development Center 3
> >  CANON INC.
> > 
> 
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> Office Products Division			gregs@sdd.hp.com
> ----------------------------------------------------------------
> 



--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.


From stephen at hpb16977.boi.hp.com  Mon Feb 16 12:43:17 1998
From: stephen at hpb16977.boi.hp.com (Stephen Holmstead)
Date: Wed May  6 14:00:48 2009
Subject: [PP1394:00156] RE: Re[2]: P1394> Rough SBP-2 & IP1394 core co
Message-ID: <199802161303.WAA18137@origin.pure.cpdc.canon.co.jp>

Shinoda-san wrote:


>Jet Send's code size is not worth for comparing or discussing transport
layer.
>"Consumer" product is very sensitive to cost of code size, but it also
depends
>on the benefit of "consumer".  In my experience, the first EOS system
had 64kB
>total ROM 10 years ago, but it was successful in the market for the
reason of
>integration of automatic and manual tuning capability with simple user
>interface.  JetSend might lead successful product in consumer market
regardless
>of its code size.  But this is not the discussiong point in PWG-C.


I think I need to clarify the position of JetSend.  JetSend is NOT a
transport layer protocol (in the OSI model).  JetSend fits ABOVE the
transport layer and provides the session, presentation, and part of the
application layers.  JetSend is transport independent, but it does need
a transport layer to sit on.  JetSend doesn't care what transport layer
that is (e.g. 1284.4, DPP's Thin Protocol, IP/1394, etc.), but it does
need a transport layer that is symmetrical (just like DPP).  That's why
I (as one of the JetSend architects) am so interested in this current
discussion.


It sounds like there is some support to work with PWG-C to define a
standard transport layer for 1394.  I think this is excellent.  I would
strongly support and help such an effort.


Stephen Holmstead
Hewlett Packard Information Appliance Operation

From bogus@does.not.exist.com  Mon Feb 16 12:14:09 1998
From: bogus@does.not.exist.com ()
Date: Wed May  6 14:00:48 2009
Subject: 1394 higher layer protocols. Was: RE: P1394> Rough SBP-2 & IP1394
In-Reply-To: <616C9498C73ED111857F0060B06ACD59132721@hpb26851.boi.hp.com>
Message-ID: <v04003a00b10e1d2be3dc@[192.168.1.25]>

At 7:58 PM -0800 2/13/98, Stephen Holmstead wrote:
>1394 could really use a commonly accepted symmetrical transport layer.
>If that's 1284.4, great.  If that's a modified SBP-2, great.  If that's
>TCP/IP, great.  If that's DPP's Thin Protocol, great.
>
>Personally, I am biased towards IP or 1284.4 (if you couldn't tell).


I would also like to see a commonly accepted symmetrical transport layer
... but I have problems with what are currently called "IP" and "1284.4" ...


1) (the simpler one) 1284.4 was designed, if I understand correctly, as a
transport that would run across a variety of links, some with rather
restrictive natures (i.e., 1284 parallel port, minimal options) ... so
1284.4 on top of 1394 is a little bit like running the rts-cts serial port
protocol on top of IP (and I've see *that* done, too).


2) IP is a fine, well tested, and (in the form of v6) fairly simple network
protocol ... it is *not*, however, a transport protocol ... you still need
TCP on top of IP to get reliable two way communication. So you really need
TCP/IP ... and then you need to learn the IP addresses, so you need the
full IP address locating protocols of interest (DNS, maybe DHCP ....).
Which is fine if you already have it, but ....


1394 already has all the infrastructure in the local environment that is
needed. All that is needed is the transport itself. A paired SBP-2
initiator/target may provide this function, as may the "thin" transport
proposed by the PWG-C, as may a version of the transport being proposed by
IP1394. Before you get too excited about using 1284.4, or even pure IP,
take a look at the conversations in the IP1394 group. I suspect that you
will find it enlightening, if a bit frustrating.


The key is looking to *throw away* a protocol or layer ... don't add a new one.




===========================================================================
Michael D. Johas Teener, Chief Technical Officer & Chairman of the Board
Zayante, Inc., 269 Mt. Hermon Rd. #111, Scotts Valley, CA 95066-4000, USA
email: mike@zayante.com    voice: +1-408-461-4901   fax: +1-408-461-1394
======================== http://www.zayante.com ===========================

From ewa at apple.com  Mon Feb 16 05:45:28 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <B10DCA1B-53884@17.219.104.63>

Hello Sekine-san,


I am "Eric".  I am the FireWire Software lead at Apple Computer.


You wrote:
  "I love a symmetrical transport also. PC Printing has supported
   1284, USB and 1394 soon. If you considers a symmetrical transport
   for 1284, USB and 1394 (and IP), it will be great for us. To
   redesign PC software only for a new 1394 print transport will be
   tough."


Do you speak officially for Microsoft in Redmond?  Is this a policy
statement that Microsoft will support 1284.4 over 1394 instead of
a pure SBP-2 native printer protocol?  This would be very different
from Microsoft's position about Tailgate.  The 1394 team in Redmond
has been quiet on this subject, so an official response would help.


Since you did not recognize my name, perhaps you did not see my
original message.  A copy is attached below.


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.      408-974-8187
--------------------------------------


============
== This letter was sent to p1394@pwg.org and P1284_3@lexmark.com
== by Eric Anderson (ewa@apple.com) on 98.02.09:


Hi Larry,


Since you asked, I'll try to politely explain my preference for
solution B: New SBP-2 command set with SBP-2.  I regret that I
can't make a strong argument, because I haven't had the time to
track closely your progress with solution A.  Still, I think
there are compelling reasons to consider solution B.


Recently, the 1394 community had the opportunity to define a
storage protocol for 1394.  The first solution, Tailgate, gave
us essentially an ATA interface bridged over 1394.  Both the
target and the initiator had to operate as if traditional ATA
was the interconnect.  Sure, SBP-2 was present, but only as a
transport, and much of it's potential was wasted.  Tailgate
was supposed to be quick an easy and lead to rapid market
adoption.  What actually happened was quite different.


Microsoft and others realized that adopting this model would
"lock in" ATA for a long time, including long after ATA itself
was dead.  Emulating a dead technology with new technology may
yield short-term savings in implementation, but at the expense of
long-term losses in performance.  Amazingly, reason prevailed,
and Tailgate was abandoned in favor of a pure SBP-2 protocol
for disk drives.  As it turned out, Tailgate vendors quickly
switched to Native Bridge, which still allowed today's drives
to act like 1394 drives, by making them look (from a 1394
point of view) like fully native devices.  As far as I can tell
this switch was not too painful, and now we aren't stuck with
ATA.  Everyone won.


Now we have a similar situation with printers.  1284.4 is a
very well established technology.  Compared to 1394, I think it
would be fair to say that 1284.4 is also a very slow and clumsy
technology (nothing personal!).  Surprise, surprise - the idea
comes up to bundle 1284.4 in SBP-2 because some purported savings
can be had, in the short term.  From what I have seen of how this
works, it is quite inefficient, with lots of unsolicited status
requests and in general lots of hand-holding by the CPU on the
initiator.  This is not what SBP-2 was designed for.


As printer resolutions climb, printer bandwidth rises very
quickly.  Yes, we all still do dull black and white word
processing, but I think you printer vendors will agree that the
exciting (high-margin) areas are in con-tone large-format high-
speed printers - just the sort that need 1394.  Or sparing that,
even consumer-level inkjets now have remarkable resolutions and
consume quite a lot of bandwidth.


Used properly, SBP-2 allows huge data transfers that can proceed
at the pace of the consumer (printer), with no hand-holding by
the host (computer).  Since host systems have 32 or more megs of
RAM today, ideally, printing should proceed with at most one
interrupt per megabyte of data transferred (assuming no errors),
leaving the CPU free to do useful work (like rasterizing).  SBP-2
and OpenHCI make this possible - but only if protocols are designed
with care to avoid needless interruption of the host.


Perhaps I have misunderstood your recent work regarding 1284.4 on
1394 in SBP-2, but I believe that the present plan will have far
more overhead than what I just described.  Specifically, I believe
this overhead comes from carefully emulating 1284.4 rather than
using SBP-2 in it's most natural way.  Over the lifetime of
1394, the cost of that overhead in wasted MIPS and wasted time will
far exceed any possible savings from recycling current protocols
and software.


1394 is far more "future friendly" and scalable than other
interconnects were at their introductions.  That didn't stop
Ethernet, ATA, SCSI, Parallel Port, and the like from living as
useful technologies for one or two decades.  Our goal should be
to make 1394 last at least as long, if not longer.  Portability
of a protocol to new interconnects at the expense of efficiency
doesn't seem valuable to me in this context - in fact, it seems
counter-productive.  The more inefficient the protocol we choose,
the more demand there will be for ever-faster interconnects.  A
well-designed, efficient protocol can last a very long time, and
serve everyone's needs better during that time.


I hope I haven't gone too far overboard here or stepped too hard
on any toes.  To conclude, I want to ask a simple question:  Has
anyone run this idea past Microsoft?  Microsoft killed off
Tailgate, and my guess is that they may have similar feelings
about printing.  Market reality is that we'll all follow whatever
they decide, so it really makes sense to get them involved.


Alas, I can't join you in Austin, but I do welcome your comments
by email.  Please be patient if you ask good (ie hard) questions.
============
> Nakamura-san,
> 
> I still like to provide a same transport for PC software over the other
> printer interfaces. Printer manufactures have supported USB, 1284 and .4
for
> printers. I believe that no one like to develop software running only
with
> PWG specific 1394 printer protocol. We need consistency over any printing
> devices.
> 
> 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.
> 
> 
> By the way, who is Eric? Whom did he contact with in MS? Though I don't
own
> a storage, I would like to hear the story from him. If someone in MS had
> miscommunication with him, I can forward it to proprietary in MS.
> 
> Thanks,
> Hitoshi
> 
> > -----Original Message-----
> > From:	Atsushi Nakamura [SMTP:atsnaka@mxa.mesh.ne.jp]
> > Sent:	Sunday, February 15, 1998 7:35 PM
> > To:	Hitoshi Sekine
> > Cc:	'PWG-C mailing'; p1284_3@lexmark.com; p1394@pwg.org
> > Subject:	RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> > 
> > For PWG printing,
> > We will have to decide whether not we use 1284.4 or not,
> > but in any case, it is inefficient to stack overlapping
> > functionality.
> > My choices would be either :
> > 
> > 1) 1284.4 - "glue"- 1394
> > 2) "glue"or cmd set - SBP-2- 1394
> > 3) "glue"or cmd set - other transport(thin?)-1394
> > 
> > I am yet uncertain which is the best( maybe 2) or 3) ),
> > but I DO have a opinion that in any case :
> > 1284.4 over SBP-2
> > is not my choice, because in this case;
> > 
> > >Sure, SBP-2 was present, but only as a
> > >transport, and much of it's potential was wasted.
> > 
> > would happen. (same for 1284.4)
> > Is using 1284.4 our first priority, or is using SBP-2 our
> > first priority ? (or something else? )(or using both !?)
> > 
> > P.S I would like to refer to Eric's comment about the 1394 disks
> >       again.
> > >Recently, the 1394 community had the opportunity to define a
> > >storage protocol for 1394.  The first solution, Tailgate, gave
> > >us essentially an ATA interface bridged over 1394.  Both the
> > >target and the initiator had to operate as if traditional ATA
> > >was the interconnect.  Sure, SBP-2 was present, but only as a
> > >transport, and much of it's potential was wasted.  Tailgate
> > >was supposed to be quick an easy and lead to rapid market
> > >adoption.  What actually happened was quite different.
> > 
> > I think this is the same situation with 1284.4 (as ATA) and
> > SBP-2 (or IP,Thin.... )
> > 
> > >Microsoft and others realized that adopting this model would
> > >"lock in" ATA for a long time, including long after ATA itself
> > >was dead.  Emulating a dead technology with new technology may
> > >yield short-term savings in implementation, but at the expense of
> > >long-term losses in performance.  Amazingly, reason prevailed,
> > >and Tailgate was abandoned in favor of a pure SBP-2 protocol
> > >for disk drives.  As it turned out, Tailgate vendors quickly
> > >switched to Native Bridge, which still allowed today's drives
> > >to act like 1394 drives, by making them look (from a 1394
> > >point of view) like fully native devices.  As far as I can tell
> > >this switch was not too painful, and now we aren't stuck with
> > >ATA.  Everyone won.
> > 
> > Let's not repeat history....
> > 
> > 
> > -------------------------------------------------
> > Atsushi Nakamura
> > BJ Printing Technology 22
> > Canon Inc.
> > -------------------------------------------------
> > 
> > -----Original Message-----
> > ??? : Hitoshi Sekine <hitoshis@microsoft.com>
> > ?? : 'Fumio Nagasaka' <fumiona@venus.dti.ne.jp>; 'Stephen Holmstead'
> > <stephen@hpb16977.boi.hp.com>; 'Toru Ueda' <ueda@slab.tnr.sharp.co.jp>;
> > Turner, Randy <rturner@sharplabs.com>
> > CC : 'Brian Batchelder' <brianb@vcd.hp.com>; p1394@pwg.org
> > <p1394@pwg.org>;
> > 'PWG-C mailing' <pp1394@cpdc.canon.co.jp>; 'p1284_3@lexmark.com'
> > <p1284_3@lexmark.com>
> > ?? : 1998?2?16? 7:21
> > ?? : RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> > 
> > 
> > >
> > >I love a symmetrical transport also. PC Printing has supported 1284,
USB
> > and
> > >1394 soon. If you considers a symmetrical transport for 1284, USB and
> > 1394
> > >(and IP), it will be great for us. To redesign PC software only for a
new
> > >1394 print transport will be tough. I don't mean to recommend
different
> > >solutions between PWG-C and PWG. We need to get our priorities right.
Not
> > to
> > >confuse PC software industry is my first priority.
> > >
> > >I personally understand that 1284.4 may be a bridge over those local
> > >interfaces and familiar with an IP printer.
> > >
> > >Hitoshi Sekine
> > >
> > >
> > >> -----Original Message-----
> > >> From: Fumio Nagasaka [SMTP:fumiona@venus.dti.ne.jp]
> > >> Sent: Saturday, February 14, 1998 9:04 PM
> > >> To: 'Stephen Holmstead'; 'Toru Ueda'; Turner, Randy
> > >> Cc: 'Brian Batchelder'; p1394@pwg.org; 'PWG-C mailing';
> > >> 'p1284_3@lexmark.com'; Hitoshi Sekine
> > >> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> > >>
> > >> Dear Stephen,
> > >>
> > >> Your opinion bring us back to December 1996. Actually we started
from
> > >> this point.
> > >>
> > >> I would like to list up existing standards and some proposals here.
> > >>
> > >> Transaction architecture:
> > >>
> >
-------------------------------------------------------------------------
> > -
> > >> ----------------
> > >> IEEE 1394     |   Memory Bus
> > >>
> >
-------------------------------------------------------------------------
> > -
> > >> ----------------
> > >> SBP-2         |   Memory Bus
> > >> DPP           |   Stream       (PWG-C / Toru Ueda)
> > >> TCP           |   Stream
> > >> DFA           |   Stream       (PWG / Alan C. Berkema)
> > >> 1284.4         |   no definition
> > >>
> >
-------------------------------------------------------------------------
> > -
> > >> ----------------
> > >>
> > >> Transaction style:
> > >>
> >
-------------------------------------------------------------------------
> > -
> > >> ----------------
> > >> IEEE 1394     |   push and pull,  symmetrical
> > >>
> >
-------------------------------------------------------------------------
> > -
> > >> ----------------
> > >> SBP-2         |   pull
> > >> DPP           |   push,  symmetrical
> > >> TCP           |   push,  symmetrical (may implement passive open)
> > >> DFA           |   push,  symmetrical
> > >> 1284.4         |   push control, symmetrical
> > >>
> >
-------------------------------------------------------------------------
> > -
> > >> ----------------
> > >>
> > >> Please correct if I had overlooked something or I am missing some
> > points.
> > >>
> > >> Stephen wrote:
> > >> <<
> > >> requirements).  I would HATE to have to make a printer that
implemented
> > >> two different transports for PWG and PWG-C printing.  I think most
> > >> printer manufacturers would agree.
> > >> >>
> > >>
> > >> No.
> > >> Due to some market reasons, printer manufactures are required
> > >> to support USB, conventional parallel port, 1394 and Macintosh
serial
> > >> interface. However Digital Camera (one of typical consumer imaging
> > >> device) does not support parallel port. Thus for some consumer
> > >> device manufactures, it is meaning less to have a solution which
> > >> provide common protocol stack to cover various existing interface.
> > >>
> > >> If PWG and PWG-C shall have same solution, I think we shall
> > >> have only one "Printer Working Group". However many Japanese
> > >> companies could not agree with this plan. They might have their own
> > >> reasons. And I think we ought to pay consideration for them.
> > >> --------------------------------------------
> > >> -------------------------------
> > >> Fumio Nagasaka
> > >> Epson Software Development Laboratory Inc.
> > >> Tel +81 268 25 4111,  Fax +81 268 25 4627
> > >> E-mail to nagasaka.fumio@exc.epson.co.jp
> > >>
> > >> -----Original Message-----
> > >> From: Stephen Holmstead [SMTP:stephen@hpb16977.boi.hp.com]
> > >> Sent: Saturday, February 14, 1998 12:59 PM
> > >> To: 'Toru Ueda'; Turner, Randy
> > >> Cc: 'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
> > >> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> > >>
> > >> I agree with Toru that we NEED a symmetrical transport.  I really
don't
> > >> care which option (A or B) is used, as long as we can provide a
> > >> symmetrical connection.  In fact, that was one of the PWG transport
> > >> requirements from that start, but it just seems that we have
accepted a
> > >> transport (SBP-2) that isn't symmetrical and we are calling it good.
> > >> The PWG-C also needs a symmetrical transport.  I would love to have
the
> > >> same transport for the PWG and PWG-C (since they both have the same
> > >> requirements).  I would HATE to have to make a printer that
implemented
> > >> two different transports for PWG and PWG-C printing.  I think most
> > >> printer manufacturers would agree.
> > >>
> > >> Greg Shue said that he made a proposal to the January PWG that would
> > >> extend SBP-2 so that it was symmetrical (at least that is what I
> > >> understand--I may be way off here).  If so, that would be great.  I
> > have
> > >> not been able to find any minutes from the PWG since Dec 97 (anyone
got
> > >> some?).
> > >>
> > >> 1394 could really use a commonly accepted symmetrical transport
layer.
> > >> If that's 1284.4, great.  If that's a modified SBP-2, great.  If
that's
> > >> TCP/IP, great.  If that's DPP's Thin Protocol, great.
> > >>
> > >> Personally, I am biased towards IP or 1284.4 (if you couldn't tell).
> > >>
> > >> Stephen Holmstead
> > >>
> > 
> > 
> 

From hitoshis at MICROSOFT.com  Mon Feb 16 21:07:52 1998
From: hitoshis at MICROSOFT.com (Hitoshi Sekine)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <B10DCA1B-53884@17.219.104.63>

Thank you, George.


Eric, Thank you for forwarding your mail. It is what I needed to know.
Though I don't think we can throw an official comment to this public mail
alias, we can do our best to work with the industry together.


Using Sbp-2 is fine with us. I can easily implement printing stack at the
top of SBP-2. It is also reasonable with Printers. It seems that many people
in PWG can agree it.
I haven't personally decided which "option" is better since I haven't done
any technical investigation of 1284.4 over SBP-2. But the reason why I like
it is that we can provide same interfaces to any printing interfaces such as
1284, USB and 1394. Some people (Randy and ...) mentioned to define Socket
interface at the top of the layer. If it can be implemented over any
printing interfaces, it may be enough. I am particular about "SBP-2" but not
so particular about "1284.4 over SBP-2".


Thanks,
Hitoshi


> -----Original Message-----
> From:	George Chrysanthakopoulos 
> Sent:	Monday, February 16, 1998 5:39 PM
> To:	Hitoshi Sekine; 'Eric Anderson'
> Cc:	John Nels Fuller
> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> 
> Hi i am very familiar with the hole tailgate deal since i made my best to
> get rid of it. Our intentions for printing are the same as for storage.
> Use a protocol/command set that makes sense over 1394.  Sbp2 is used for
> both, same driver same stack...
> 
> For storage we are using MMC2/RBC.
> For printing i had no intention to support 1284.4 by making any special
> adjustments to the 1394/sbp2 stack. If somebody managed to attach 1284.4
> on top then thats fine ( although i agree its not the preferred method)
> 
> The current plan is to use the scsi command set over sbp2, to talk to
> scanners/printers. If the scsi command set is not adequete( or too
> bloated), then we neeed to go towards that direction(just like RBC). Right
> now however using SCSI will make existing scanner technology and hopefully
> printers come faster in the market using the sbp/1394.
> 
> i have made our intentions clear to the printing/scanner vendors i have
> been in touch so far..
> 
> thanx
> g
> 
> -----Original Message-----
> From:	Hitoshi Sekine 
> Sent:	Monday, February 16, 1998 5:29 PM
> To:	John Nels Fuller; George Chrysanthakopoulos
> Cc:	'Eric Anderson'
> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> 
> George and John,
> 
> Have you spoke to Eric at Apple? Are you aware of the story of Tailgate?
> 
> thanks,
> hitoshi
> 
> -----Original Message-----
> From:	Eric Anderson [SMTP:ewa@apple.com]
> Sent:	Monday, February 16, 1998 2:45 AM
> To:	Hitoshi Sekine
> Cc:	p1284_3@lexmark.com; p1394@pwg.org; pp1394@cpdc.canon.co.jp
> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> 
> Hello Sekine-san,
> 
> I am "Eric".  I am the FireWire Software lead at Apple Computer.
> 
> You wrote:
>   "I love a symmetrical transport also. PC Printing has supported
>    1284, USB and 1394 soon. If you considers a symmetrical transport
>    for 1284, USB and 1394 (and IP), it will be great for us. To
>    redesign PC software only for a new 1394 print transport will be
>    tough."
> 
> Do you speak officially for Microsoft in Redmond?  Is this a policy
> statement that Microsoft will support 1284.4 over 1394 instead of
> a pure SBP-2 native printer protocol?  This would be very different
> from Microsoft's position about Tailgate.  The 1394 team in Redmond
> has been quiet on this subject, so an official response would help.
> 
> Since you did not recognize my name, perhaps you did not see my
> original message.  A copy is attached below.
> 
> --------------------------------------
> Eric Anderson            ewa@apple.com
> Apple Computer, Inc.      408-974-8187
> --------------------------------------
> 
> ============
> == This letter was sent to p1394@pwg.org and P1284_3@lexmark.com
> == by Eric Anderson (ewa@apple.com) on 98.02.09:
> 
> Hi Larry,
> 
> Since you asked, I'll try to politely explain my preference for
> solution B: New SBP-2 command set with SBP-2.  I regret that I
> can't make a strong argument, because I haven't had the time to
> track closely your progress with solution A.  Still, I think
> there are compelling reasons to consider solution B.
> 
> Recently, the 1394 community had the opportunity to define a
> storage protocol for 1394.  The first solution, Tailgate, gave
> us essentially an ATA interface bridged over 1394.  Both the
> target and the initiator had to operate as if traditional ATA
> was the interconnect.  Sure, SBP-2 was present, but only as a
> transport, and much of it's potential was wasted.  Tailgate
> was supposed to be quick an easy and lead to rapid market
> adoption.  What actually happened was quite different.
> 
> Microsoft and others realized that adopting this model would
> "lock in" ATA for a long time, including long after ATA itself
> was dead.  Emulating a dead technology with new technology may
> yield short-term savings in implementation, but at the expense of
> long-term losses in performance.  Amazingly, reason prevailed,
> and Tailgate was abandoned in favor of a pure SBP-2 protocol
> for disk drives.  As it turned out, Tailgate vendors quickly
> switched to Native Bridge, which still allowed today's drives
> to act like 1394 drives, by making them look (from a 1394
> point of view) like fully native devices.  As far as I can tell
> this switch was not too painful, and now we aren't stuck with
> ATA.  Everyone won.
> 
> Now we have a similar situation with printers.  1284.4 is a
> very well established technology.  Compared to 1394, I think it
> would be fair to say that 1284.4 is also a very slow and clumsy
> technology (nothing personal!).  Surprise, surprise - the idea
> comes up to bundle 1284.4 in SBP-2 because some purported savings
> can be had, in the short term.  From what I have seen of how this
> works, it is quite inefficient, with lots of unsolicited status
> requests and in general lots of hand-holding by the CPU on the
> initiator.  This is not what SBP-2 was designed for.
> 
> As printer resolutions climb, printer bandwidth rises very
> quickly.  Yes, we all still do dull black and white word
> processing, but I think you printer vendors will agree that the
> exciting (high-margin) areas are in con-tone large-format high-
> speed printers - just the sort that need 1394.  Or sparing that,
> even consumer-level inkjets now have remarkable resolutions and
> consume quite a lot of bandwidth.
> 
> Used properly, SBP-2 allows huge data transfers that can proceed
> at the pace of the consumer (printer), with no hand-holding by
> the host (computer).  Since host systems have 32 or more megs of
> RAM today, ideally, printing should proceed with at most one
> interrupt per megabyte of data transferred (assuming no errors),
> leaving the CPU free to do useful work (like rasterizing).  SBP-2
> and OpenHCI make this possible - but only if protocols are designed
> with care to avoid needless interruption of the host.
> 
> Perhaps I have misunderstood your recent work regarding 1284.4 on
> 1394 in SBP-2, but I believe that the present plan will have far
> more overhead than what I just described.  Specifically, I believe
> this overhead comes from carefully emulating 1284.4 rather than
> using SBP-2 in it's most natural way.  Over the lifetime of
> 1394, the cost of that overhead in wasted MIPS and wasted time will
> far exceed any possible savings from recycling current protocols
> and software.
> 
> 1394 is far more "future friendly" and scalable than other
> interconnects were at their introductions.  That didn't stop
> Ethernet, ATA, SCSI, Parallel Port, and the like from living as
> useful technologies for one or two decades.  Our goal should be
> to make 1394 last at least as long, if not longer.  Portability
> of a protocol to new interconnects at the expense of efficiency
> doesn't seem valuable to me in this context - in fact, it seems
> counter-productive.  The more inefficient the protocol we choose,
> the more demand there will be for ever-faster interconnects.  A
> well-designed, efficient protocol can last a very long time, and
> serve everyone's needs better during that time.
> 
> I hope I haven't gone too far overboard here or stepped too hard
> on any toes.  To conclude, I want to ask a simple question:  Has
> anyone run this idea past Microsoft?  Microsoft killed off
> Tailgate, and my guess is that they may have similar feelings
> about printing.  Market reality is that we'll all follow whatever
> they decide, so it really makes sense to get them involved.
> 
> Alas, I can't join you in Austin, but I do welcome your comments
> by email.  Please be patient if you ask good (ie hard) questions.
> ============
> > Nakamura-san,
> > 
> > I still like to provide a same transport for PC software over the other
> > printer interfaces. Printer manufactures have supported USB, 1284 and .4
> for
> > printers. I believe that no one like to develop software running only
> with
> > PWG specific 1394 printer protocol. We need consistency over any
> printing
> > devices.
> > 
> > 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.
> > 
> > 
> > By the way, who is Eric? Whom did he contact with in MS? Though I don't
> own
> > a storage, I would like to hear the story from him. If someone in MS had
> > miscommunication with him, I can forward it to proprietary in MS.
> > 
> > Thanks,
> > Hitoshi
> > 
> > > -----Original Message-----
> > > From:	Atsushi Nakamura [SMTP:atsnaka@mxa.mesh.ne.jp]
> > > Sent:	Sunday, February 15, 1998 7:35 PM
> > > To:	Hitoshi Sekine
> > > Cc:	'PWG-C mailing'; p1284_3@lexmark.com; p1394@pwg.org
> > > Subject:	RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> > > 
> > > For PWG printing,
> > > We will have to decide whether not we use 1284.4 or not,
> > > but in any case, it is inefficient to stack overlapping
> > > functionality.
> > > My choices would be either :
> > > 
> > > 1) 1284.4 - "glue"- 1394
> > > 2) "glue"or cmd set - SBP-2- 1394
> > > 3) "glue"or cmd set - other transport(thin?)-1394
> > > 
> > > I am yet uncertain which is the best( maybe 2) or 3) ),
> > > but I DO have a opinion that in any case :
> > > 1284.4 over SBP-2
> > > is not my choice, because in this case;
> > > 
> > > >Sure, SBP-2 was present, but only as a
> > > >transport, and much of it's potential was wasted.
> > > 
> > > would happen. (same for 1284.4)
> > > Is using 1284.4 our first priority, or is using SBP-2 our
> > > first priority ? (or something else? )(or using both !?)
> > > 
> > > P.S I would like to refer to Eric's comment about the 1394 disks
> > >       again.
> > > >Recently, the 1394 community had the opportunity to define a
> > > >storage protocol for 1394.  The first solution, Tailgate, gave
> > > >us essentially an ATA interface bridged over 1394.  Both the
> > > >target and the initiator had to operate as if traditional ATA
> > > >was the interconnect.  Sure, SBP-2 was present, but only as a
> > > >transport, and much of it's potential was wasted.  Tailgate
> > > >was supposed to be quick an easy and lead to rapid market
> > > >adoption.  What actually happened was quite different.
> > > 
> > > I think this is the same situation with 1284.4 (as ATA) and
> > > SBP-2 (or IP,Thin.... )
> > > 
> > > >Microsoft and others realized that adopting this model would
> > > >"lock in" ATA for a long time, including long after ATA itself
> > > >was dead.  Emulating a dead technology with new technology may
> > > >yield short-term savings in implementation, but at the expense of
> > > >long-term losses in performance.  Amazingly, reason prevailed,
> > > >and Tailgate was abandoned in favor of a pure SBP-2 protocol
> > > >for disk drives.  As it turned out, Tailgate vendors quickly
> > > >switched to Native Bridge, which still allowed today's drives
> > > >to act like 1394 drives, by making them look (from a 1394
> > > >point of view) like fully native devices.  As far as I can tell
> > > >this switch was not too painful, and now we aren't stuck with
> > > >ATA.  Everyone won.
> > > 
> > > Let's not repeat history....
> > > 
> > > 
> > > -------------------------------------------------
> > > Atsushi Nakamura
> > > BJ Printing Technology 22
> > > Canon Inc.
> > > -------------------------------------------------
> > > 
> > > -----Original Message-----
> > > ??? : Hitoshi Sekine <hitoshis@microsoft.com>
> > > ?? : 'Fumio Nagasaka' <fumiona@venus.dti.ne.jp>; 'Stephen Holmstead'
> > > <stephen@hpb16977.boi.hp.com>; 'Toru Ueda'
> <ueda@slab.tnr.sharp.co.jp>;
> > > Turner, Randy <rturner@sharplabs.com>
> > > CC : 'Brian Batchelder' <brianb@vcd.hp.com>; p1394@pwg.org
> > > <p1394@pwg.org>;
> > > 'PWG-C mailing' <pp1394@cpdc.canon.co.jp>; 'p1284_3@lexmark.com'
> > > <p1284_3@lexmark.com>
> > > ?? : 1998?2?16? 7:21
> > > ?? : RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> > > 
> > > 
> > > >
> > > >I love a symmetrical transport also. PC Printing has supported 1284,
> USB
> > > and
> > > >1394 soon. If you considers a symmetrical transport for 1284, USB and
> > > 1394
> > > >(and IP), it will be great for us. To redesign PC software only for a
> new
> > > >1394 print transport will be tough. I don't mean to recommend
> different
> > > >solutions between PWG-C and PWG. We need to get our priorities right.
> Not
> > > to
> > > >confuse PC software industry is my first priority.
> > > >
> > > >I personally understand that 1284.4 may be a bridge over those local
> > > >interfaces and familiar with an IP printer.
> > > >
> > > >Hitoshi Sekine
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Fumio Nagasaka [SMTP:fumiona@venus.dti.ne.jp]
> > > >> Sent: Saturday, February 14, 1998 9:04 PM
> > > >> To: 'Stephen Holmstead'; 'Toru Ueda'; Turner, Randy
> > > >> Cc: 'Brian Batchelder'; p1394@pwg.org; 'PWG-C mailing';
> > > >> 'p1284_3@lexmark.com'; Hitoshi Sekine
> > > >> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> > > >>
> > > >> Dear Stephen,
> > > >>
> > > >> Your opinion bring us back to December 1996. Actually we started
> from
> > > >> this point.
> > > >>
> > > >> I would like to list up existing standards and some proposals here.
> > > >>
> > > >> Transaction architecture:
> > > >>
> > >
> -------------------------------------------------------------------------
> > > -
> > > >> ----------------
> > > >> IEEE 1394     |   Memory Bus
> > > >>
> > >
> -------------------------------------------------------------------------
> > > -
> > > >> ----------------
> > > >> SBP-2         |   Memory Bus
> > > >> DPP           |   Stream       (PWG-C / Toru Ueda)
> > > >> TCP           |   Stream
> > > >> DFA           |   Stream       (PWG / Alan C. Berkema)
> > > >> 1284.4         |   no definition
> > > >>
> > >
> -------------------------------------------------------------------------
> > > -
> > > >> ----------------
> > > >>
> > > >> Transaction style:
> > > >>
> > >
> -------------------------------------------------------------------------
> > > -
> > > >> ----------------
> > > >> IEEE 1394     |   push and pull,  symmetrical
> > > >>
> > >
> -------------------------------------------------------------------------
> > > -
> > > >> ----------------
> > > >> SBP-2         |   pull
> > > >> DPP           |   push,  symmetrical
> > > >> TCP           |   push,  symmetrical (may implement passive open)
> > > >> DFA           |   push,  symmetrical
> > > >> 1284.4         |   push control, symmetrical
> > > >>
> > >
> -------------------------------------------------------------------------
> > > -
> > > >> ----------------
> > > >>
> > > >> Please correct if I had overlooked something or I am missing some
> > > points.
> > > >>
> > > >> Stephen wrote:
> > > >> <<
> > > >> requirements).  I would HATE to have to make a printer that
> implemented
> > > >> two different transports for PWG and PWG-C printing.  I think most
> > > >> printer manufacturers would agree.
> > > >> >>
> > > >>
> > > >> No.
> > > >> Due to some market reasons, printer manufactures are required
> > > >> to support USB, conventional parallel port, 1394 and Macintosh
> serial
> > > >> interface. However Digital Camera (one of typical consumer imaging
> > > >> device) does not support parallel port. Thus for some consumer
> > > >> device manufactures, it is meaning less to have a solution which
> > > >> provide common protocol stack to cover various existing interface.
> > > >>
> > > >> If PWG and PWG-C shall have same solution, I think we shall
> > > >> have only one "Printer Working Group". However many Japanese
> > > >> companies could not agree with this plan. They might have their own
> > > >> reasons. And I think we ought to pay consideration for them.
> > > >> --------------------------------------------
> > > >> -------------------------------
> > > >> Fumio Nagasaka
> > > >> Epson Software Development Laboratory Inc.
> > > >> Tel +81 268 25 4111,  Fax +81 268 25 4627
> > > >> E-mail to nagasaka.fumio@exc.epson.co.jp
> > > >>
> > > >> -----Original Message-----
> > > >> From: Stephen Holmstead [SMTP:stephen@hpb16977.boi.hp.com]
> > > >> Sent: Saturday, February 14, 1998 12:59 PM
> > > >> To: 'Toru Ueda'; Turner, Randy
> > > >> Cc: 'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
> > > >> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> > > >>
> > > >> I agree with Toru that we NEED a symmetrical transport.  I really
> don't
> > > >> care which option (A or B) is used, as long as we can provide a
> > > >> symmetrical connection.  In fact, that was one of the PWG transport
> > > >> requirements from that start, but it just seems that we have
> accepted a
> > > >> transport (SBP-2) that isn't symmetrical and we are calling it
> good.
> > > >> The PWG-C also needs a symmetrical transport.  I would love to have
> the
> > > >> same transport for the PWG and PWG-C (since they both have the same
> > > >> requirements).  I would HATE to have to make a printer that
> implemented
> > > >> two different transports for PWG and PWG-C printing.  I think most
> > > >> printer manufacturers would agree.
> > > >>
> > > >> Greg Shue said that he made a proposal to the January PWG that
> would
> > > >> extend SBP-2 so that it was symmetrical (at least that is what I
> > > >> understand--I may be way off here).  If so, that would be great.  I
> > > have
> > > >> not been able to find any minutes from the PWG since Dec 97 (anyone
> got
> > > >> some?).
> > > >>
> > > >> 1394 could really use a commonly accepted symmetrical transport
> layer.
> > > >> If that's 1284.4, great.  If that's a modified SBP-2, great.  If
> that's
> > > >> TCP/IP, great.  If that's DPP's Thin Protocol, great.
> > > >>
> > > >> Personally, I am biased towards IP or 1284.4 (if you couldn't
> tell).
> > > >>
> > > >> Stephen Holmstead
> > > >>
> > > 
> > > 
> > 
> 
> 
> 
> 
> 

From rturner at sharplabs.com  Mon Feb 16 21:44:01 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <B10DCA1B-53884@17.219.104.63>

Hitoshi,


It is my impression that SBP-2, as being implemented by Microsoft, is
initiator-only. Is this still the case? Overall, I would agree with you
that SBP-2 would work fine for printing, but I would like the same
transport to be used for multifunction devices, including printing,
scanning, fax, etc. For this reason I would like our specification to
say that we can support an overall SBP-2 that contains both target and
initiator functionality. 


There has been some discussion on the list in the past that this request
is "difficult to do". To date, I haven't seen any technical rationale
for this sentiment. Rather, Michael Teener and others have stated that
it can be accomplished. One other reason that was mentioned, was that
supporting target-SBP-2 would require dynamic settings to the
configuration ROM for NT 5.0. I do not think supporting both
initiator-and-target SBP-2 would require dynamic config ROM settings.


And yes, I would also like to reiterate my desire to see access to this
transport available through a Winsock-2 address family.


Randy




	-----Original Message-----
	From:	Hitoshi Sekine [SMTP:hitoshis@MICROSOFT.com]
	Sent:	Monday, February 16, 1998 6:08 PM
	To:	George Chrysanthakopoulos; 'Eric Anderson'
	Cc:	John Nels Fuller; 'p1284_3@lexmark.com';
'p1394@pwg.org'; 'pp1394@cpdc.canon.co.jp'
	Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes


	Thank you, George.


	Eric, Thank you for forwarding your mail. It is what I needed to
know.
	Though I don't think we can throw an official comment to this
public mail
	alias, we can do our best to work with the industry together.


	Using Sbp-2 is fine with us. I can easily implement printing
stack at the
	top of SBP-2. It is also reasonable with Printers. It seems that
many people
	in PWG can agree it.
	I haven't personally decided which "option" is better since I
haven't done
	any technical investigation of 1284.4 over SBP-2. But the reason
why I like
	it is that we can provide same interfaces to any printing
interfaces such as
	1284, USB and 1394. Some people (Randy and ...) mentioned to
define Socket
	interface at the top of the layer. If it can be implemented over
any
	printing interfaces, it may be enough. I am particular about
"SBP-2" but not
	so particular about "1284.4 over SBP-2".


	Thanks,
	Hitoshi


	> -----Original Message-----
	> From:	George Chrysanthakopoulos 
	> Sent:	Monday, February 16, 1998 5:39 PM
	> To:	Hitoshi Sekine; 'Eric Anderson'
	> Cc:	John Nels Fuller
	> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes
	> 
	> Hi i am very familiar with the hole tailgate deal since i made
my best to
	> get rid of it. Our intentions for printing are the same as for
storage.
	> Use a protocol/command set that makes sense over 1394.  Sbp2
is used for
	> both, same driver same stack...
	> 
	> For storage we are using MMC2/RBC.
	> For printing i had no intention to support 1284.4 by making
any special
	> adjustments to the 1394/sbp2 stack. If somebody managed to
attach 1284.4
	> on top then thats fine ( although i agree its not the
preferred method)
	> 
	> The current plan is to use the scsi command set over sbp2, to
talk to
	> scanners/printers. If the scsi command set is not adequete( or
too
	> bloated), then we neeed to go towards that direction(just like
RBC). Right
	> now however using SCSI will make existing scanner technology
and hopefully
	> printers come faster in the market using the sbp/1394.
	> 
	> i have made our intentions clear to the printing/scanner
vendors i have
	> been in touch so far..
	> 
	> thanx
	> g
	> 
	> -----Original Message-----
	> From:	Hitoshi Sekine 
	> Sent:	Monday, February 16, 1998 5:29 PM
	> To:	John Nels Fuller; George Chrysanthakopoulos
	> Cc:	'Eric Anderson'
	> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes
	> 
	> George and John,
	> 
	> Have you spoke to Eric at Apple? Are you aware of the story of
Tailgate?
	> 
	> thanks,
	> hitoshi
	> 
	> -----Original Message-----
	> From:	Eric Anderson [SMTP:ewa@apple.com]
	> Sent:	Monday, February 16, 1998 2:45 AM
	> To:	Hitoshi Sekine
	> Cc:	p1284_3@lexmark.com; p1394@pwg.org;
pp1394@cpdc.canon.co.jp
	> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes
	> 
	> Hello Sekine-san,
	> 
	> I am "Eric".  I am the FireWire Software lead at Apple
Computer.
	> 
	> You wrote:
	>   "I love a symmetrical transport also. PC Printing has
supported
	>    1284, USB and 1394 soon. If you considers a symmetrical
transport
	>    for 1284, USB and 1394 (and IP), it will be great for us.
To
	>    redesign PC software only for a new 1394 print transport
will be
	>    tough."
	> 
	> Do you speak officially for Microsoft in Redmond?  Is this a
policy
	> statement that Microsoft will support 1284.4 over 1394 instead
of
	> a pure SBP-2 native printer protocol?  This would be very
different
	> from Microsoft's position about Tailgate.  The 1394 team in
Redmond
	> has been quiet on this subject, so an official response would
help.
	> 
	> Since you did not recognize my name, perhaps you did not see
my
	> original message.  A copy is attached below.
	> 
	> --------------------------------------
	> Eric Anderson            ewa@apple.com
	> Apple Computer, Inc.      408-974-8187
	> --------------------------------------
	> 
	> ============
	> == This letter was sent to p1394@pwg.org and
P1284_3@lexmark.com
	> == by Eric Anderson (ewa@apple.com) on 98.02.09:
	> 
	> Hi Larry,
	> 
	> Since you asked, I'll try to politely explain my preference
for
	> solution B: New SBP-2 command set with SBP-2.  I regret that I
	> can't make a strong argument, because I haven't had the time
to
	> track closely your progress with solution A.  Still, I think
	> there are compelling reasons to consider solution B.
	> 
	> Recently, the 1394 community had the opportunity to define a
	> storage protocol for 1394.  The first solution, Tailgate, gave
	> us essentially an ATA interface bridged over 1394.  Both the
	> target and the initiator had to operate as if traditional ATA
	> was the interconnect.  Sure, SBP-2 was present, but only as a
	> transport, and much of it's potential was wasted.  Tailgate
	> was supposed to be quick an easy and lead to rapid market
	> adoption.  What actually happened was quite different.
	> 
	> Microsoft and others realized that adopting this model would
	> "lock in" ATA for a long time, including long after ATA itself
	> was dead.  Emulating a dead technology with new technology may
	> yield short-term savings in implementation, but at the expense
of
	> long-term losses in performance.  Amazingly, reason prevailed,
	> and Tailgate was abandoned in favor of a pure SBP-2 protocol
	> for disk drives.  As it turned out, Tailgate vendors quickly
	> switched to Native Bridge, which still allowed today's drives
	> to act like 1394 drives, by making them look (from a 1394
	> point of view) like fully native devices.  As far as I can
tell
	> this switch was not too painful, and now we aren't stuck with
	> ATA.  Everyone won.
	> 
	> Now we have a similar situation with printers.  1284.4 is a
	> very well established technology.  Compared to 1394, I think
it
	> would be fair to say that 1284.4 is also a very slow and
clumsy
	> technology (nothing personal!).  Surprise, surprise - the idea
	> comes up to bundle 1284.4 in SBP-2 because some purported
savings
	> can be had, in the short term.  From what I have seen of how
this
	> works, it is quite inefficient, with lots of unsolicited
status
	> requests and in general lots of hand-holding by the CPU on the
	> initiator.  This is not what SBP-2 was designed for.
	> 
	> As printer resolutions climb, printer bandwidth rises very
	> quickly.  Yes, we all still do dull black and white word
	> processing, but I think you printer vendors will agree that
the
	> exciting (high-margin) areas are in con-tone large-format
high-
	> speed printers - just the sort that need 1394.  Or sparing
that,
	> even consumer-level inkjets now have remarkable resolutions
and
	> consume quite a lot of bandwidth.
	> 
	> Used properly, SBP-2 allows huge data transfers that can
proceed
	> at the pace of the consumer (printer), with no hand-holding by
	> the host (computer).  Since host systems have 32 or more megs
of
	> RAM today, ideally, printing should proceed with at most one
	> interrupt per megabyte of data transferred (assuming no
errors),
	> leaving the CPU free to do useful work (like rasterizing).
SBP-2
	> and OpenHCI make this possible - but only if protocols are
designed
	> with care to avoid needless interruption of the host.
	> 
	> Perhaps I have misunderstood your recent work regarding 1284.4
on
	> 1394 in SBP-2, but I believe that the present plan will have
far
	> more overhead than what I just described.  Specifically, I
believe
	> this overhead comes from carefully emulating 1284.4 rather
than
	> using SBP-2 in it's most natural way.  Over the lifetime of
	> 1394, the cost of that overhead in wasted MIPS and wasted time
will
	> far exceed any possible savings from recycling current
protocols
	> and software.
	> 
	> 1394 is far more "future friendly" and scalable than other
	> interconnects were at their introductions.  That didn't stop
	> Ethernet, ATA, SCSI, Parallel Port, and the like from living
as
	> useful technologies for one or two decades.  Our goal should
be
	> to make 1394 last at least as long, if not longer.
Portability
	> of a protocol to new interconnects at the expense of
efficiency
	> doesn't seem valuable to me in this context - in fact, it
seems
	> counter-productive.  The more inefficient the protocol we
choose,
	> the more demand there will be for ever-faster interconnects.
A
	> well-designed, efficient protocol can last a very long time,
and
	> serve everyone's needs better during that time.
	> 
	> I hope I haven't gone too far overboard here or stepped too
hard
	> on any toes.  To conclude, I want to ask a simple question:
Has
	> anyone run this idea past Microsoft?  Microsoft killed off
	> Tailgate, and my guess is that they may have similar feelings
	> about printing.  Market reality is that we'll all follow
whatever
	> they decide, so it really makes sense to get them involved.
	> 
	> Alas, I can't join you in Austin, but I do welcome your
comments
	> by email.  Please be patient if you ask good (ie hard)
questions.
	> ============
	> > Nakamura-san,
	> > 
	> > I still like to provide a same transport for PC software
over the other
	> > printer interfaces. Printer manufactures have supported USB,
1284 and .4
	> for
	> > printers. I believe that no one like to develop software
running only
	> with
	> > PWG specific 1394 printer protocol. We need consistency over
any
	> printing
	> > devices.
	> > 
	> > 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.
	> > 
	> > 
	> > By the way, who is Eric? Whom did he contact with in MS?
Though I don't
	> own
	> > a storage, I would like to hear the story from him. If
someone in MS had
	> > miscommunication with him, I can forward it to proprietary
in MS.
	> > 
	> > Thanks,
	> > Hitoshi
	> > 
	> > > -----Original Message-----
	> > > From:	Atsushi Nakamura [SMTP:atsnaka@mxa.mesh.ne.jp]
	> > > Sent:	Sunday, February 15, 1998 7:35 PM
	> > > To:	Hitoshi Sekine
	> > > Cc:	'PWG-C mailing'; p1284_3@lexmark.com;
p1394@pwg.org
	> > > Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes
	> > > 
	> > > For PWG printing,
	> > > We will have to decide whether not we use 1284.4 or not,
	> > > but in any case, it is inefficient to stack overlapping
	> > > functionality.
	> > > My choices would be either :
	> > > 
	> > > 1) 1284.4 - "glue"- 1394
	> > > 2) "glue"or cmd set - SBP-2- 1394
	> > > 3) "glue"or cmd set - other transport(thin?)-1394
	> > > 
	> > > I am yet uncertain which is the best( maybe 2) or 3) ),
	> > > but I DO have a opinion that in any case :
	> > > 1284.4 over SBP-2
	> > > is not my choice, because in this case;
	> > > 
	> > > >Sure, SBP-2 was present, but only as a
	> > > >transport, and much of it's potential was wasted.
	> > > 
	> > > would happen. (same for 1284.4)
	> > > Is using 1284.4 our first priority, or is using SBP-2 our
	> > > first priority ? (or something else? )(or using both !?)
	> > > 
	> > > P.S I would like to refer to Eric's comment about the 1394
disks
	> > >       again.
	> > > >Recently, the 1394 community had the opportunity to
define a
	> > > >storage protocol for 1394.  The first solution, Tailgate,
gave
	> > > >us essentially an ATA interface bridged over 1394.  Both
the
	> > > >target and the initiator had to operate as if traditional
ATA
	> > > >was the interconnect.  Sure, SBP-2 was present, but only
as a
	> > > >transport, and much of it's potential was wasted.
Tailgate
	> > > >was supposed to be quick an easy and lead to rapid market
	> > > >adoption.  What actually happened was quite different.
	> > > 
	> > > I think this is the same situation with 1284.4 (as ATA)
and
	> > > SBP-2 (or IP,Thin.... )
	> > > 
	> > > >Microsoft and others realized that adopting this model
would
	> > > >"lock in" ATA for a long time, including long after ATA
itself
	> > > >was dead.  Emulating a dead technology with new
technology may
	> > > >yield short-term savings in implementation, but at the
expense of
	> > > >long-term losses in performance.  Amazingly, reason
prevailed,
	> > > >and Tailgate was abandoned in favor of a pure SBP-2
protocol
	> > > >for disk drives.  As it turned out, Tailgate vendors
quickly
	> > > >switched to Native Bridge, which still allowed today's
drives
	> > > >to act like 1394 drives, by making them look (from a 1394
	> > > >point of view) like fully native devices.  As far as I
can tell
	> > > >this switch was not too painful, and now we aren't stuck
with
	> > > >ATA.  Everyone won.
	> > > 
	> > > Let's not repeat history....
	> > > 
	> > > 
	> > > -------------------------------------------------
	> > > Atsushi Nakamura
	> > > BJ Printing Technology 22
	> > > Canon Inc.
	> > > -------------------------------------------------
	> > > 
	> > > -----Original Message-----
	> > > ??? : Hitoshi Sekine <hitoshis@microsoft.com>
	> > > ?? : 'Fumio Nagasaka' <fumiona@venus.dti.ne.jp>; 'Stephen
Holmstead'
	> > > <stephen@hpb16977.boi.hp.com>; 'Toru Ueda'
	> <ueda@slab.tnr.sharp.co.jp>;
	> > > Turner, Randy <rturner@sharplabs.com>
	> > > CC : 'Brian Batchelder' <brianb@vcd.hp.com>; p1394@pwg.org
	> > > <p1394@pwg.org>;
	> > > 'PWG-C mailing' <pp1394@cpdc.canon.co.jp>;
'p1284_3@lexmark.com'
	> > > <p1284_3@lexmark.com>
	> > > ?? : 1998?2?16? 7:21
	> > > ?? : RE: P1394> Rough SBP-2 & IP1394 core component ROM
sizes
	> > > 
	> > > 
	> > > >
	> > > >I love a symmetrical transport also. PC Printing has
supported 1284,
	> USB
	> > > and
	> > > >1394 soon. If you considers a symmetrical transport for
1284, USB and
	> > > 1394
	> > > >(and IP), it will be great for us. To redesign PC
software only for a
	> new
	> > > >1394 print transport will be tough. I don't mean to
recommend
	> different
	> > > >solutions between PWG-C and PWG. We need to get our
priorities right.
	> Not
	> > > to
	> > > >confuse PC software industry is my first priority.
	> > > >
	> > > >I personally understand that 1284.4 may be a bridge over
those local
	> > > >interfaces and familiar with an IP printer.
	> > > >
	> > > >Hitoshi Sekine
	> > > >
	> > > >
	> > > >> -----Original Message-----
	> > > >> From: Fumio Nagasaka [SMTP:fumiona@venus.dti.ne.jp]
	> > > >> Sent: Saturday, February 14, 1998 9:04 PM
	> > > >> To: 'Stephen Holmstead'; 'Toru Ueda'; Turner, Randy
	> > > >> Cc: 'Brian Batchelder'; p1394@pwg.org; 'PWG-C mailing';
	> > > >> 'p1284_3@lexmark.com'; Hitoshi Sekine
	> > > >> Subject: RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes
	> > > >>
	> > > >> Dear Stephen,
	> > > >>
	> > > >> Your opinion bring us back to December 1996. Actually
we started
	> from
	> > > >> this point.
	> > > >>
	> > > >> I would like to list up existing standards and some
proposals here.
	> > > >>
	> > > >> Transaction architecture:
	> > > >>
	> > >
	>
------------------------------------------------------------------------
-
	> > > -
	> > > >> ----------------
	> > > >> IEEE 1394     |   Memory Bus
	> > > >>
	> > >
	>
------------------------------------------------------------------------
-
	> > > -
	> > > >> ----------------
	> > > >> SBP-2         |   Memory Bus
	> > > >> DPP           |   Stream       (PWG-C / Toru Ueda)
	> > > >> TCP           |   Stream
	> > > >> DFA           |   Stream       (PWG / Alan C. Berkema)
	> > > >> 1284.4         |   no definition
	> > > >>
	> > >
	>
------------------------------------------------------------------------
-
	> > > -
	> > > >> ----------------
	> > > >>
	> > > >> Transaction style:
	> > > >>
	> > >
	>
------------------------------------------------------------------------
-
	> > > -
	> > > >> ----------------
	> > > >> IEEE 1394     |   push and pull,  symmetrical
	> > > >>
	> > >
	>
------------------------------------------------------------------------
-
	> > > -
	> > > >> ----------------
	> > > >> SBP-2         |   pull
	> > > >> DPP           |   push,  symmetrical
	> > > >> TCP           |   push,  symmetrical (may implement
passive open)
	> > > >> DFA           |   push,  symmetrical
	> > > >> 1284.4         |   push control, symmetrical
	> > > >>
	> > >
	>
------------------------------------------------------------------------
-
	> > > -
	> > > >> ----------------
	> > > >>
	> > > >> Please correct if I had overlooked something or I am
missing some
	> > > points.
	> > > >>
	> > > >> Stephen wrote:
	> > > >> <<
	> > > >> requirements).  I would HATE to have to make a printer
that
	> implemented
	> > > >> two different transports for PWG and PWG-C printing.  I
think most
	> > > >> printer manufacturers would agree.
	> > > >> >>
	> > > >>
	> > > >> No.
	> > > >> Due to some market reasons, printer manufactures are
required
	> > > >> to support USB, conventional parallel port, 1394 and
Macintosh
	> serial
	> > > >> interface. However Digital Camera (one of typical
consumer imaging
	> > > >> device) does not support parallel port. Thus for some
consumer
	> > > >> device manufactures, it is meaning less to have a
solution which
	> > > >> provide common protocol stack to cover various existing
interface.
	> > > >>
	> > > >> If PWG and PWG-C shall have same solution, I think we
shall
	> > > >> have only one "Printer Working Group". However many
Japanese
	> > > >> companies could not agree with this plan. They might
have their own
	> > > >> reasons. And I think we ought to pay consideration for
them.
	> > > >> --------------------------------------------
	> > > >> -------------------------------
	> > > >> Fumio Nagasaka
	> > > >> Epson Software Development Laboratory Inc.
	> > > >> Tel +81 268 25 4111,  Fax +81 268 25 4627
	> > > >> E-mail to nagasaka.fumio@exc.epson.co.jp
	> > > >>
	> > > >> -----Original Message-----
	> > > >> From: Stephen Holmstead
[SMTP:stephen@hpb16977.boi.hp.com]
	> > > >> Sent: Saturday, February 14, 1998 12:59 PM
	> > > >> To: 'Toru Ueda'; Turner, Randy
	> > > >> Cc: 'Stephen Holmstead'; 'Brian Batchelder';
p1394@pwg.org
	> > > >> Subject: RE: P1394> Rough SBP-2 & IP1394 core component
ROM sizes
	> > > >>
	> > > >> I agree with Toru that we NEED a symmetrical transport.
I really
	> don't
	> > > >> care which option (A or B) is used, as long as we can
provide a
	> > > >> symmetrical connection.  In fact, that was one of the
PWG transport
	> > > >> requirements from that start, but it just seems that we
have
	> accepted a
	> > > >> transport (SBP-2) that isn't symmetrical and we are
calling it
	> good.
	> > > >> The PWG-C also needs a symmetrical transport.  I would
love to have
	> the
	> > > >> same transport for the PWG and PWG-C (since they both
have the same
	> > > >> requirements).  I would HATE to have to make a printer
that
	> implemented
	> > > >> two different transports for PWG and PWG-C printing.  I
think most
	> > > >> printer manufacturers would agree.
	> > > >>
	> > > >> Greg Shue said that he made a proposal to the January
PWG that
	> would
	> > > >> extend SBP-2 so that it was symmetrical (at least that
is what I
	> > > >> understand--I may be way off here).  If so, that would
be great.  I
	> > > have
	> > > >> not been able to find any minutes from the PWG since
Dec 97 (anyone
	> got
	> > > >> some?).
	> > > >>
	> > > >> 1394 could really use a commonly accepted symmetrical
transport
	> layer.
	> > > >> If that's 1284.4, great.  If that's a modified SBP-2,
great.  If
	> that's
	> > > >> TCP/IP, great.  If that's DPP's Thin Protocol, great.
	> > > >>
	> > > >> Personally, I am biased towards IP or 1284.4 (if you
couldn't
	> tell).
	> > > >>
	> > > >> Stephen Holmstead
	> > > >>
	> > > 
	> > > 
	> > 
	> 
	> 
	> 
	> 
	> 

From georgioc at microsoft.com  Mon Feb 16 22:09:00 1998
From: georgioc at microsoft.com (George Chrysanthakopoulos)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <B10DCA1B-53884@17.219.104.63>

Hi,
our intentions is to use the same transport over 1394. Right now we plan to
use ( and already have driver support for) scanners,printers and storage
devices under sbp2. There no need to have a target/initiator functionality
on the PC and that  is one of the reasons sbp2 was designed the way it was. 
So even if there is no need for the PC to become a target sbp2 node, even
for multilun devices, it is possible but not recommended for normal
printer/scanner applications. And yes it will require dynamic config rom
settings.


In any case, its not necessery and scanners/printers/HDD/cdroms will work
just fine with the PC being initiator. Through unsolicited status and a
proper command set the target can initiate requests, if that is your
concern.


RBC is designed exaclty for that purpose, for storage devices using sbp2.
MMC/2 i used for cdrom/dvd type of devices.
In any case the OS is going to use one single lower driver stack to
accomodate scanners, printers, storage devices etc as long as they use sbp2
as the transport on 1394. The command set can and will be slightly different
between devices but we like it to be as similar to SCSI as possible ( for
several reasons). This is the major premise RBC and MMC2 are being specified
on...


it would be great if the scanner/printing group chooses a similar method as
RBC/MMC2. This makes sbp2 devices have driver support today , reusing the
upper class drivers used for other buses (ide/scsi). 


So for example the scsi class driver used on top of a scsi scanner on SCSI,
can be re-used with absolutely NO modifications, for an 1394/SBP2 scanner,
that uses the scsi command set today.... In the 1394 scanner however, th
elower drivers will be the sbp2port driver and the 1394 lower drivers.


if you would like more details about our implementation please just let me
know ( so we dont flood the reflector with replies)


thanx


george


> -----Original Message-----
> From:	Turner, Randy [SMTP:rturner@sharplabs.com]
> Sent:	Monday, February 16, 1998 6:44 PM
> To:	Hitoshi Sekine; George Chrysanthakopoulos; 'Eric Anderson'
> Cc:	John Nels Fuller; 'p1284_3@lexmark.com'; 'p1394@pwg.org';
> 'pp1394@cpdc.canon.co.jp'
> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> 
> 
> Hitoshi,
> 
> It is my impression that SBP-2, as being implemented by Microsoft, is
> initiator-only. Is this still the case? Overall, I would agree with you
> that SBP-2 would work fine for printing, but I would like the same
> transport to be used for multifunction devices, including printing,
> scanning, fax, etc. For this reason I would like our specification to
> say that we can support an overall SBP-2 that contains both target and
> initiator functionality. 
> 
> There has been some discussion on the list in the past that this request
> is "difficult to do". To date, I haven't seen any technical rationale
> for this sentiment. Rather, Michael Teener and others have stated that
> it can be accomplished. One other reason that was mentioned, was that
> supporting target-SBP-2 would require dynamic settings to the
> configuration ROM for NT 5.0. I do not think supporting both
> initiator-and-target SBP-2 would require dynamic config ROM settings.
> 
> And yes, I would also like to reiterate my desire to see access to this
> transport available through a Winsock-2 address family.
> 
> Randy
> 
> 
> 	-----Original Message-----
> 	From:	Hitoshi Sekine [SMTP:hitoshis@MICROSOFT.com]
> 	Sent:	Monday, February 16, 1998 6:08 PM
> 	To:	George Chrysanthakopoulos; 'Eric Anderson'
> 	Cc:	John Nels Fuller; 'p1284_3@lexmark.com';
> 'p1394@pwg.org'; 'pp1394@cpdc.canon.co.jp'
> 	Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> ROM sizes
> 
> 	Thank you, George.
> 
> 	Eric, Thank you for forwarding your mail. It is what I needed to
> know.
> 	Though I don't think we can throw an official comment to this
> public mail
> 	alias, we can do our best to work with the industry together.
> 
> 	Using Sbp-2 is fine with us. I can easily implement printing
> stack at the
> 	top of SBP-2. It is also reasonable with Printers. It seems that
> many people
> 	in PWG can agree it.
> 	I haven't personally decided which "option" is better since I
> haven't done
> 	any technical investigation of 1284.4 over SBP-2. But the reason
> why I like
> 	it is that we can provide same interfaces to any printing
> interfaces such as
> 	1284, USB and 1394. Some people (Randy and ...) mentioned to
> define Socket
> 	interface at the top of the layer. If it can be implemented over
> any
> 	printing interfaces, it may be enough. I am particular about
> "SBP-2" but not
> 	so particular about "1284.4 over SBP-2".
> 
> 	Thanks,
> 	Hitoshi
> 
> 	> -----Original Message-----
> 	> From:	George Chrysanthakopoulos 
> 	> Sent:	Monday, February 16, 1998 5:39 PM
> 	> To:	Hitoshi Sekine; 'Eric Anderson'
> 	> Cc:	John Nels Fuller
> 	> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> ROM sizes
> 	> 
> 	> Hi i am very familiar with the hole tailgate deal since i made
> my best to
> 	> get rid of it. Our intentions for printing are the same as for
> storage.
> 	> Use a protocol/command set that makes sense over 1394.  Sbp2
> is used for
> 	> both, same driver same stack...
> 	> 
> 	> For storage we are using MMC2/RBC.
> 	> For printing i had no intention to support 1284.4 by making
> any special
> 	> adjustments to the 1394/sbp2 stack. If somebody managed to
> attach 1284.4
> 	> on top then thats fine ( although i agree its not the
> preferred method)
> 	> 
> 	> The current plan is to use the scsi command set over sbp2, to
> talk to
> 	> scanners/printers. If the scsi command set is not adequete( or
> too
> 	> bloated), then we neeed to go towards that direction(just like
> RBC). Right
> 	> now however using SCSI will make existing scanner technology
> and hopefully
> 	> printers come faster in the market using the sbp/1394.
> 	> 
> 	> i have made our intentions clear to the printing/scanner
> vendors i have
> 	> been in touch so far..
> 	> 
> 	> thanx
> 	> g
> 	> 
> 	> -----Original Message-----
> 	> From:	Hitoshi Sekine 
> 	> Sent:	Monday, February 16, 1998 5:29 PM
> 	> To:	John Nels Fuller; George Chrysanthakopoulos
> 	> Cc:	'Eric Anderson'
> 	> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> ROM sizes
> 	> 
> 	> George and John,
> 	> 
> 	> Have you spoke to Eric at Apple? Are you aware of the story of
> Tailgate?
> 	> 
> 	> thanks,
> 	> hitoshi
> 	> 
> 	> -----Original Message-----
> 	> From:	Eric Anderson [SMTP:ewa@apple.com]
> 	> Sent:	Monday, February 16, 1998 2:45 AM
> 	> To:	Hitoshi Sekine
> 	> Cc:	p1284_3@lexmark.com; p1394@pwg.org;
> pp1394@cpdc.canon.co.jp
> 	> Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> ROM sizes
> 	> 
> 	> Hello Sekine-san,
> 	> 
> 	> I am "Eric".  I am the FireWire Software lead at Apple
> Computer.
> 	> 
> 	> You wrote:
> 	>   "I love a symmetrical transport also. PC Printing has
> supported
> 	>    1284, USB and 1394 soon. If you considers a symmetrical
> transport
> 	>    for 1284, USB and 1394 (and IP), it will be great for us.
> To
> 	>    redesign PC software only for a new 1394 print transport
> will be
> 	>    tough."
> 	> 
> 	> Do you speak officially for Microsoft in Redmond?  Is this a
> policy
> 	> statement that Microsoft will support 1284.4 over 1394 instead
> of
> 	> a pure SBP-2 native printer protocol?  This would be very
> different
> 	> from Microsoft's position about Tailgate.  The 1394 team in
> Redmond
> 	> has been quiet on this subject, so an official response would
> help.
> 	> 
> 	> Since you did not recognize my name, perhaps you did not see
> my
> 	> original message.  A copy is attached below.
> 	> 
> 	> --------------------------------------
> 	> Eric Anderson            ewa@apple.com
> 	> Apple Computer, Inc.      408-974-8187
> 	> --------------------------------------
> 	> 
> 	> ============
> 	> == This letter was sent to p1394@pwg.org and
> P1284_3@lexmark.com
> 	> == by Eric Anderson (ewa@apple.com) on 98.02.09:
> 	> 
> 	> Hi Larry,
> 	> 
> 	> Since you asked, I'll try to politely explain my preference
> for
> 	> solution B: New SBP-2 command set with SBP-2.  I regret that I
> 	> can't make a strong argument, because I haven't had the time
> to
> 	> track closely your progress with solution A.  Still, I think
> 	> there are compelling reasons to consider solution B.
> 	> 
> 	> Recently, the 1394 community had the opportunity to define a
> 	> storage protocol for 1394.  The first solution, Tailgate, gave
> 	> us essentially an ATA interface bridged over 1394.  Both the
> 	> target and the initiator had to operate as if traditional ATA
> 	> was the interconnect.  Sure, SBP-2 was present, but only as a
> 	> transport, and much of it's potential was wasted.  Tailgate
> 	> was supposed to be quick an easy and lead to rapid market
> 	> adoption.  What actually happened was quite different.
> 	> 
> 	> Microsoft and others realized that adopting this model would
> 	> "lock in" ATA for a long time, including long after ATA itself
> 	> was dead.  Emulating a dead technology with new technology may
> 	> yield short-term savings in implementation, but at the expense
> of
> 	> long-term losses in performance.  Amazingly, reason prevailed,
> 	> and Tailgate was abandoned in favor of a pure SBP-2 protocol
> 	> for disk drives.  As it turned out, Tailgate vendors quickly
> 	> switched to Native Bridge, which still allowed today's drives
> 	> to act like 1394 drives, by making them look (from a 1394
> 	> point of view) like fully native devices.  As far as I can
> tell
> 	> this switch was not too painful, and now we aren't stuck with
> 	> ATA.  Everyone won.
> 	> 
> 	> Now we have a similar situation with printers.  1284.4 is a
> 	> very well established technology.  Compared to 1394, I think
> it
> 	> would be fair to say that 1284.4 is also a very slow and
> clumsy
> 	> technology (nothing personal!).  Surprise, surprise - the idea
> 	> comes up to bundle 1284.4 in SBP-2 because some purported
> savings
> 	> can be had, in the short term.  From what I have seen of how
> this
> 	> works, it is quite inefficient, with lots of unsolicited
> status
> 	> requests and in general lots of hand-holding by the CPU on the
> 	> initiator.  This is not what SBP-2 was designed for.
> 	> 
> 	> As printer resolutions climb, printer bandwidth rises very
> 	> quickly.  Yes, we all still do dull black and white word
> 	> processing, but I think you printer vendors will agree that
> the
> 	> exciting (high-margin) areas are in con-tone large-format
> high-
> 	> speed printers - just the sort that need 1394.  Or sparing
> that,
> 	> even consumer-level inkjets now have remarkable resolutions
> and
> 	> consume quite a lot of bandwidth.
> 	> 
> 	> Used properly, SBP-2 allows huge data transfers that can
> proceed
> 	> at the pace of the consumer (printer), with no hand-holding by
> 	> the host (computer).  Since host systems have 32 or more megs
> of
> 	> RAM today, ideally, printing should proceed with at most one
> 	> interrupt per megabyte of data transferred (assuming no
> errors),
> 	> leaving the CPU free to do useful work (like rasterizing).
> SBP-2
> 	> and OpenHCI make this possible - but only if protocols are
> designed
> 	> with care to avoid needless interruption of the host.
> 	> 
> 	> Perhaps I have misunderstood your recent work regarding 1284.4
> on
> 	> 1394 in SBP-2, but I believe that the present plan will have
> far
> 	> more overhead than what I just described.  Specifically, I
> believe
> 	> this overhead comes from carefully emulating 1284.4 rather
> than
> 	> using SBP-2 in it's most natural way.  Over the lifetime of
> 	> 1394, the cost of that overhead in wasted MIPS and wasted time
> will
> 	> far exceed any possible savings from recycling current
> protocols
> 	> and software.
> 	> 
> 	> 1394 is far more "future friendly" and scalable than other
> 	> interconnects were at their introductions.  That didn't stop
> 	> Ethernet, ATA, SCSI, Parallel Port, and the like from living
> as
> 	> useful technologies for one or two decades.  Our goal should
> be
> 	> to make 1394 last at least as long, if not longer.
> Portability
> 	> of a protocol to new interconnects at the expense of
> efficiency
> 	> doesn't seem valuable to me in this context - in fact, it
> seems
> 	> counter-productive.  The more inefficient the protocol we
> choose,
> 	> the more demand there will be for ever-faster interconnects.
> A
> 	> well-designed, efficient protocol can last a very long time,
> and
> 	> serve everyone's needs better during that time.
> 	> 
> 	> I hope I haven't gone too far overboard here or stepped too
> hard
> 	> on any toes.  To conclude, I want to ask a simple question:
> Has
> 	> anyone run this idea past Microsoft?  Microsoft killed off
> 	> Tailgate, and my guess is that they may have similar feelings
> 	> about printing.  Market reality is that we'll all follow
> whatever
> 	> they decide, so it really makes sense to get them involved.
> 	> 
> 	> Alas, I can't join you in Austin, but I do welcome your
> comments
> 	> by email.  Please be patient if you ask good (ie hard)
> questions.
> 	> ============
> 	> > Nakamura-san,
> 	> > 
> 	> > I still like to provide a same transport for PC software
> over the other
> 	> > printer interfaces. Printer manufactures have supported USB,
> 1284 and .4
> 	> for
> 	> > printers. I believe that no one like to develop software
> running only
> 	> with
> 	> > PWG specific 1394 printer protocol. We need consistency over
> any
> 	> printing
> 	> > devices.
> 	> > 
> 	> > 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.
> 	> > 
> 	> > 
> 	> > By the way, who is Eric? Whom did he contact with in MS?
> Though I don't
> 	> own
> 	> > a storage, I would like to hear the story from him. If
> someone in MS had
> 	> > miscommunication with him, I can forward it to proprietary
> in MS.
> 	> > 
> 	> > Thanks,
> 	> > Hitoshi
> 	> > 
> 	> > > -----Original Message-----
> 	> > > From:	Atsushi Nakamura [SMTP:atsnaka@mxa.mesh.ne.jp]
> 	> > > Sent:	Sunday, February 15, 1998 7:35 PM
> 	> > > To:	Hitoshi Sekine
> 	> > > Cc:	'PWG-C mailing'; p1284_3@lexmark.com;
> p1394@pwg.org
> 	> > > Subject:	RE: P1394> Rough SBP-2 & IP1394 core component
> ROM sizes
> 	> > > 
> 	> > > For PWG printing,
> 	> > > We will have to decide whether not we use 1284.4 or not,
> 	> > > but in any case, it is inefficient to stack overlapping
> 	> > > functionality.
> 	> > > My choices would be either :
> 	> > > 
> 	> > > 1) 1284.4 - "glue"- 1394
> 	> > > 2) "glue"or cmd set - SBP-2- 1394
> 	> > > 3) "glue"or cmd set - other transport(thin?)-1394
> 	> > > 
> 	> > > I am yet uncertain which is the best( maybe 2) or 3) ),
> 	> > > but I DO have a opinion that in any case :
> 	> > > 1284.4 over SBP-2
> 	> > > is not my choice, because in this case;
> 	> > > 
> 	> > > >Sure, SBP-2 was present, but only as a
> 	> > > >transport, and much of it's potential was wasted.
> 	> > > 
> 	> > > would happen. (same for 1284.4)
> 	> > > Is using 1284.4 our first priority, or is using SBP-2 our
> 	> > > first priority ? (or something else? )(or using both !?)
> 	> > > 
> 	> > > P.S I would like to refer to Eric's comment about the 1394
> disks
> 	> > >       again.
> 	> > > >Recently, the 1394 community had the opportunity to
> define a
> 	> > > >storage protocol for 1394.  The first solution, Tailgate,
> gave
> 	> > > >us essentially an ATA interface bridged over 1394.  Both
> the
> 	> > > >target and the initiator had to operate as if traditional
> ATA
> 	> > > >was the interconnect.  Sure, SBP-2 was present, but only
> as a
> 	> > > >transport, and much of it's potential was wasted.
> Tailgate
> 	> > > >was supposed to be quick an easy and lead to rapid market
> 	> > > >adoption.  What actually happened was quite different.
> 	> > > 
> 	> > > I think this is the same situation with 1284.4 (as ATA)
> and
> 	> > > SBP-2 (or IP,Thin.... )
> 	> > > 
> 	> > > >Microsoft and others realized that adopting this model
> would
> 	> > > >"lock in" ATA for a long time, including long after ATA
> itself
> 	> > > >was dead.  Emulating a dead technology with new
> technology may
> 	> > > >yield short-term savings in implementation, but at the
> expense of
> 	> > > >long-term losses in performance.  Amazingly, reason
> prevailed,
> 	> > > >and Tailgate was abandoned in favor of a pure SBP-2
> protocol
> 	> > > >for disk drives.  As it turned out, Tailgate vendors
> quickly
> 	> > > >switched to Native Bridge, which still allowed today's
> drives
> 	> > > >to act like 1394 drives, by making them look (from a 1394
> 	> > > >point of view) like fully native devices.  As far as I
> can tell
> 	> > > >this switch was not too painful, and now we aren't stuck
> with
> 	> > > >ATA.  Everyone won.
> 	> > > 
> 	> > > Let's not repeat history....
> 	> > > 
> 	> > > 
> 	> > > -------------------------------------------------
> 	> > > Atsushi Nakamura
> 	> > > BJ Printing Technology 22
> 	> > > Canon Inc.
> 	> > > -------------------------------------------------
> 	> > > 
> 	> > > -----Original Message-----
> 	> > > ??? : Hitoshi Sekine <hitoshis@microsoft.com>
> 	> > > ?? : 'Fumio Nagasaka' <fumiona@venus.dti.ne.jp>; 'Stephen
> Holmstead'
> 	> > > <stephen@hpb16977.boi.hp.com>; 'Toru Ueda'
> 	> <ueda@slab.tnr.sharp.co.jp>;
> 	> > > Turner, Randy <rturner@sharplabs.com>
> 	> > > CC : 'Brian Batchelder' <brianb@vcd.hp.com>; p1394@pwg.org
> 	> > > <p1394@pwg.org>;
> 	> > > 'PWG-C mailing' <pp1394@cpdc.canon.co.jp>;
> 'p1284_3@lexmark.com'
> 	> > > <p1284_3@lexmark.com>
> 	> > > ?? : 1998?2?16? 7:21
> 	> > > ?? : RE: P1394> Rough SBP-2 & IP1394 core component ROM
> sizes
> 	> > > 
> 	> > > 
> 	> > > >
> 	> > > >I love a symmetrical transport also. PC Printing has
> supported 1284,
> 	> USB
> 	> > > and
> 	> > > >1394 soon. If you considers a symmetrical transport for
> 1284, USB and
> 	> > > 1394
> 	> > > >(and IP), it will be great for us. To redesign PC
> software only for a
> 	> new
> 	> > > >1394 print transport will be tough. I don't mean to
> recommend
> 	> different
> 	> > > >solutions between PWG-C and PWG. We need to get our
> priorities right.
> 	> Not
> 	> > > to
> 	> > > >confuse PC software industry is my first priority.
> 	> > > >
> 	> > > >I personally understand that 1284.4 may be a bridge over
> those local
> 	> > > >interfaces and familiar with an IP printer.
> 	> > > >
> 	> > > >Hitoshi Sekine
> 	> > > >
> 	> > > >
> 	> > > >> -----Original Message-----
> 	> > > >> From: Fumio Nagasaka [SMTP:fumiona@venus.dti.ne.jp]
> 	> > > >> Sent: Saturday, February 14, 1998 9:04 PM
> 	> > > >> To: 'Stephen Holmstead'; 'Toru Ueda'; Turner, Randy
> 	> > > >> Cc: 'Brian Batchelder'; p1394@pwg.org; 'PWG-C mailing';
> 	> > > >> 'p1284_3@lexmark.com'; Hitoshi Sekine
> 	> > > >> Subject: RE: P1394> Rough SBP-2 & IP1394 core component
> ROM sizes
> 	> > > >>
> 	> > > >> Dear Stephen,
> 	> > > >>
> 	> > > >> Your opinion bring us back to December 1996. Actually
> we started
> 	> from
> 	> > > >> this point.
> 	> > > >>
> 	> > > >> I would like to list up existing standards and some
> proposals here.
> 	> > > >>
> 	> > > >> Transaction architecture:
> 	> > > >>
> 	> > >
> 	>
> ------------------------------------------------------------------------
> -
> 	> > > -
> 	> > > >> ----------------
> 	> > > >> IEEE 1394     |   Memory Bus
> 	> > > >>
> 	> > >
> 	>
> ------------------------------------------------------------------------
> -
> 	> > > -
> 	> > > >> ----------------
> 	> > > >> SBP-2         |   Memory Bus
> 	> > > >> DPP           |   Stream       (PWG-C / Toru Ueda)
> 	> > > >> TCP           |   Stream
> 	> > > >> DFA           |   Stream       (PWG / Alan C. Berkema)
> 	> > > >> 1284.4         |   no definition
> 	> > > >>
> 	> > >
> 	>
> ------------------------------------------------------------------------
> -
> 	> > > -
> 	> > > >> ----------------
> 	> > > >>
> 	> > > >> Transaction style:
> 	> > > >>
> 	> > >
> 	>
> ------------------------------------------------------------------------
> -
> 	> > > -
> 	> > > >> ----------------
> 	> > > >> IEEE 1394     |   push and pull,  symmetrical
> 	> > > >>
> 	> > >
> 	>
> ------------------------------------------------------------------------
> -
> 	> > > -
> 	> > > >> ----------------
> 	> > > >> SBP-2         |   pull
> 	> > > >> DPP           |   push,  symmetrical
> 	> > > >> TCP           |   push,  symmetrical (may implement
> passive open)
> 	> > > >> DFA           |   push,  symmetrical
> 	> > > >> 1284.4         |   push control, symmetrical
> 	> > > >>
> 	> > >
> 	>
> ------------------------------------------------------------------------
> -
> 	> > > -
> 	> > > >> ----------------
> 	> > > >>
> 	> > > >> Please correct if I had overlooked something or I am
> missing some
> 	> > > points.
> 	> > > >>
> 	> > > >> Stephen wrote:
> 	> > > >> <<
> 	> > > >> requirements).  I would HATE to have to make a printer
> that
> 	> implemented
> 	> > > >> two different transports for PWG and PWG-C printing.  I
> think most
> 	> > > >> printer manufacturers would agree.
> 	> > > >> >>
> 	> > > >>
> 	> > > >> No.
> 	> > > >> Due to some market reasons, printer manufactures are
> required
> 	> > > >> to support USB, conventional parallel port, 1394 and
> Macintosh
> 	> serial
> 	> > > >> interface. However Digital Camera (one of typical
> consumer imaging
> 	> > > >> device) does not support parallel port. Thus for some
> consumer
> 	> > > >> device manufactures, it is meaning less to have a
> solution which
> 	> > > >> provide common protocol stack to cover various existing
> interface.
> 	> > > >>
> 	> > > >> If PWG and PWG-C shall have same solution, I think we
> shall
> 	> > > >> have only one "Printer Working Group". However many
> Japanese
> 	> > > >> companies could not agree with this plan. They might
> have their own
> 	> > > >> reasons. And I think we ought to pay consideration for
> them.
> 	> > > >> --------------------------------------------
> 	> > > >> -------------------------------
> 	> > > >> Fumio Nagasaka
> 	> > > >> Epson Software Development Laboratory Inc.
> 	> > > >> Tel +81 268 25 4111,  Fax +81 268 25 4627
> 	> > > >> E-mail to nagasaka.fumio@exc.epson.co.jp
> 	> > > >>
> 	> > > >> -----Original Message-----
> 	> > > >> From: Stephen Holmstead
> [SMTP:stephen@hpb16977.boi.hp.com]
> 	> > > >> Sent: Saturday, February 14, 1998 12:59 PM
> 	> > > >> To: 'Toru Ueda'; Turner, Randy
> 	> > > >> Cc: 'Stephen Holmstead'; 'Brian Batchelder';
> p1394@pwg.org
> 	> > > >> Subject: RE: P1394> Rough SBP-2 & IP1394 core component
> ROM sizes
> 	> > > >>
> 	> > > >> I agree with Toru that we NEED a symmetrical transport.
> I really
> 	> don't
> 	> > > >> care which option (A or B) is used, as long as we can
> provide a
> 	> > > >> symmetrical connection.  In fact, that was one of the
> PWG transport
> 	> > > >> requirements from that start, but it just seems that we
> have
> 	> accepted a
> 	> > > >> transport (SBP-2) that isn't symmetrical and we are
> calling it
> 	> good.
> 	> > > >> The PWG-C also needs a symmetrical transport.  I would
> love to have
> 	> the
> 	> > > >> same transport for the PWG and PWG-C (since they both
> have the same
> 	> > > >> requirements).  I would HATE to have to make a printer
> that
> 	> implemented
> 	> > > >> two different transports for PWG and PWG-C printing.  I
> think most
> 	> > > >> printer manufacturers would agree.
> 	> > > >>
> 	> > > >> Greg Shue said that he made a proposal to the January
> PWG that
> 	> would
> 	> > > >> extend SBP-2 so that it was symmetrical (at least that
> is what I
> 	> > > >> understand--I may be way off here).  If so, that would
> be great.  I
> 	> > > have
> 	> > > >> not been able to find any minutes from the PWG since
> Dec 97 (anyone
> 	> got
> 	> > > >> some?).
> 	> > > >>
> 	> > > >> 1394 could really use a commonly accepted symmetrical
> transport
> 	> layer.
> 	> > > >> If that's 1284.4, great.  If that's a modified SBP-2,
> great.  If
> 	> that's
> 	> > > >> TCP/IP, great.  If that's DPP's Thin Protocol, great.
> 	> > > >>
> 	> > > >> Personally, I am biased towards IP or 1284.4 (if you
> couldn't
> 	> tell).
> 	> > > >>
> 	> > > >> Stephen Holmstead
> 	> > > >>
> 	> > > 
> 	> > > 
> 	> > 
> 	> 
> 	> 
> 	> 
> 	> 
> 	> 

From brianb at vcd.hp.com  Tue Feb 17 03:30:23 1998
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
In-Reply-To: <199802111659.IAA23603@hpsdlgj1.sdd.hp.com>
Message-ID: <3.0.3.32.19980217003023.0086bdf0@popmail1.vcd.hp.com>

Time to put in my $0.02-worth.  I apologize if any of this is redundant.  I
wrote it a few days ago, but only now have been able to send it.


1394 was designed for, and will be used as a symmetric, peer-to-peer bus.
The majority of devices will benefit from being able to communicate with
every other device, which includes both initiating that communication and
sending and receiving data.  Other devices that don't need peer-to-peer
functionality will also move to 1394 for other factors, e.g. throughput,
installed base, etc.


IMHO, SBP-2 was designed to provide for those non peer-to-peer devices by
emulating old master-slave busses on top of this inherently peer-to-peer
bus.  (Flame away!)  This works well for mass storage devices, for example.
 The initiator always initiates (sorry) communication.  The target never
initiates communication.  The initiator knows the sequence and quantity of
data to be transferred.  The target paces and executes the transfer of that
data.  


Unfortunately, this doesn't map well to true "peers".  As I indicated
earlier, each peer wants to initiate communication with other peers, in
addition to being the target of other peers.  You can think of this from
the application point of view.  Applications that operate as clients want
to initiate communication with applications that operate as servers.  Most
devices will have both types of applications.  Printers have print engines
(servers) and status engines (clients).  Scanners have control engines
(servers) and scan engines (clients).  Multi-function peripherals have all
of that plus maybe FAX engines, which might act as servers and clients.


In the past, we have made clients look like servers and vice-versa, because
of the limitation of our busses.  Fine.  I can see SBP-2 as a mechanism to
bring those old implementations to 1394.  We have also figured out ways to
allow clients and servers over master/slave busses by hiding the
"master/slaveness" in the transport layer (1284.4 is an example of this).
To make SBP-2 work AS IS for us, we would have to choose one of those two
paths, and we still have to add some other functionality.


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.


If, however, targiators CAN'T be supported, I believe we will have to look
elsewhere for a solution.  I like Ats' idea of 1284.4 over something else
(DFA?).  I agree that 1284.4+SBP-2 does feel quite redundant.  I know that
we chose SBP-2 largely because it was an existing standard with support
from both Microsoft and the mass-storage industry.  One thing this long
discussion has DEFINITELY taught me is that SBP-2 is not unanimously
believed to be the obvious solution.


Remember, we are specifying a protocol that we must assume will be used for
at least the next 10 years.  Can we afford to limit the functionality of
our implementations?


Brian


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227

From Ozay_Oktay at cissc.canon.com  Tue Feb 17 13:03:02 1998
From: Ozay_Oktay at cissc.canon.com (Oktay, Ozay)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Rough SBP-2 & IP1394 core component ROM sizes
Message-ID: <3.0.3.32.19980217003023.0086bdf0@popmail1.vcd.hp.com>

I have been quietly monitoring this discussion on the reflector. So far
this is the best analysis I have read.


I agree with Brian almost entirely.. When preparing a standard we must
look into the future. We could be accommodating but we should never be
constricting for the sake of backward compatibility.


Best Regards


Ozay Oktay
Canon Information Systems




	----------
	From:  Brian Batchelder [SMTP:brianb@vcd.hp.com]
	Sent:  Tuesday, February 17, 1998 12:30 AM
	To:  p1394@pwg.org
	Subject:  Re: P1394> Rough SBP-2 & IP1394 core component ROM
sizes


	Time to put in my $0.02-worth.  I apologize if any of this is
redundant.  I
	wrote it a few days ago, but only now have been able to send it.


	1394 was designed for, and will be used as a symmetric,
peer-to-peer bus.
	The majority of devices will benefit from being able to
communicate with
	every other device, which includes both initiating that
communication and
	sending and receiving data.  Other devices that don't need
peer-to-peer
	functionality will also move to 1394 for other factors, e.g.
throughput,
	installed base, etc.


	IMHO, SBP-2 was designed to provide for those non peer-to-peer
devices by
	emulating old master-slave busses on top of this inherently
peer-to-peer
	bus.  (Flame away!)  This works well for mass storage devices,
for example.
	 The initiator always initiates (sorry) communication.  The
target never
	initiates communication.  The initiator knows the sequence and
quantity of
	data to be transferred.  The target paces and executes the
transfer of that
	data.  


	Unfortunately, this doesn't map well to true "peers".  As I
indicated
	earlier, each peer wants to initiate communication with other
peers, in
	addition to being the target of other peers.  You can think of
this from
	the application point of view.  Applications that operate as
clients want
	to initiate communication with applications that operate as
servers.  Most
	devices will have both types of applications.  Printers have
print engines
	(servers) and status engines (clients).  Scanners have control
engines
	(servers) and scan engines (clients).  Multi-function
peripherals have all
	of that plus maybe FAX engines, which might act as servers and
clients.


	In the past, we have made clients look like servers and
vice-versa, because
	of the limitation of our busses.  Fine.  I can see SBP-2 as a
mechanism to
	bring those old implementations to 1394.  We have also figured
out ways to
	allow clients and servers over master/slave busses by hiding the
	"master/slaveness" in the transport layer (1284.4 is an example
of this).
	To make SBP-2 work AS IS for us, we would have to choose one of
those two
	paths, and we still have to add some other functionality.


	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.


	If, however, targiators CAN'T be supported, I believe we will
have to look
	elsewhere for a solution.  I like Ats' idea of 1284.4 over
something else
	(DFA?).  I agree that 1284.4+SBP-2 does feel quite redundant.  I
know that
	we chose SBP-2 largely because it was an existing standard with
support
	from both Microsoft and the mass-storage industry.  One thing
this long
	discussion has DEFINITELY taught me is that SBP-2 is not
unanimously
	believed to be the obvious solution.


	Remember, we are specifying a protocol that we must assume will
be used for
	at least the next 10 years.  Can we afford to limit the
functionality of
	our implementations?


	Brian




~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	Brian Batchelder      | Hewlett-Packard      |
mailto:brianb@vcd.hp.com  
	Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360)
212-4107  
	DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360)
212-4227

From gregs at sdd.hp.com  Tue Feb 17 14:06:21 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:48 2009
Subject: [PP1394:00147] Re: P1394> 1284.4 over SBP-2
In-Reply-To: <01376112D7AFD011911E0020AF70BEC5075AF3@CPUEX1>
Message-ID: <199802171906.LAA08192@hpsdlgj1.sdd.hp.com>

You are not missing any steps, BUT you are missing the point.
The issue wasn't how to deal with CreditRequest packets (which
is a transaction which follows the flow of data), but how to
deal with a _Credit_ packet (which is a transaction which runs
opposite to the flow of data for which credit is being given).


The transaction direction is completely different and so requires
a completely different mechanism.


To illustrate the difference:


  Data flows from PC to printer
  PC runs out of credit, so issues a CreditRequest to the printer.
  Printer gives the CreditRequestReply back to the PC.


     NOTE: This must be done immediately to allow the PC to
     do other command trasactions and avoid blocking the CBT
     channel.  Otherwise, additional command channel credits
     must be supported and must exist.
     
     Since this must be done immediately, it may be returned with
     zero credit.  In this case, the PC will not ask for additional
     credit because the printer remembers the request and will
     _spontaneously_ give credit when buffer space is available.
     This is done with a Credit/CreditReply transaction initiated
     by the printer, not another CreditRequest/CreditRequestReply!


  PC waits for more credit, WITHOUT polling for credit.
  Printer has buffer space available for PC, so fills out a
    Credit packet to be sent to the printer...


      How is this packet sent?


      What needs to happen is the PC needs to read the packet,
      process it, and send a CreditReply packet in response!
      The mechanisms beneath the CBT protocol need to support this,
      and so we must understand _exactly_ how this is done
      since the Credit packet from the printer could be ready
      at _any_ point in time.


  The difference between Credit and CreditRequest is similar to
  the difference between data push and data pull.


CBT & SBP-2 combined could never match SBP-2 by itself in terms of
performance.  The overhead of explicit credit management guarantees
that.


Fumio Nagasaka wrote:
> 
> Greg Shue wrote:
> >To highlight the issue:
> >   Exactly how does an initiator peer which supports CBT receive a 
> >   Credit packet from the target at any indeterminate time?
> >This is not provided directly by 1284.4.  How are you planning on 
> >solving it for your implementation of option A?
> 
> 1)	The initiator place $B!H(JCreditRequest$B!I(J packet in an out-ORB.(J
> 2)	If the target find an in-ORB in the linked list of ORBs, target
> fill out
> 	the buffer associated this ORB with $B!H(JCreditRequestReply$B!I(J
> packet.
> 3)	If the target could not find any in-ORB in the linked list of
> ORB,
> then the target send unsolicited status which requests the initiator
> to provide an in-ORB in the list. Then go to step #2. 
> 
> Am I missing any steps?
> I think step #3 becomes overhead. So CBT supportive SBP-2 profile
> does not mark higher speed than pure SBP-2 transaction.
> 
> --------------------------------------------
> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
> 
> 		-----Original Message-----
> 		From:	Greg Shue [SMTP:gregs@sdd.hp.com]
> 		Sent:	Friday, February 13, 1998 4:58 AM
> 		To:	pp1394 ML
> 		Subject:	[PP1394:00147] Re: P1394> 1284.4 over
> SBP-2
> 
> 		> 
> 		> 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_000_01BD3784.4C5B70D6
> 		> Content-Type: text/plain
> 		> 
> 		> Dear Eric,
> 		> Dear Larry,
> 		> 
> 		> Please find an attached document which shows issue
> Eric and myself
> 		> had discussed at December 3, 1997.
> 		>  <<Generation.PDF>> 
> 		> I am writing printer drivers that covers first
> generation of 1394
> 		> printing.
> 		> These printer drivers are supporting option A.
> 		> <<
> 		> A-	1284.4 with SBP-2
> 		> B-	New SBP-2 command set with SBP-2
> 		> >>
> 		> I also prefer to choose option A at least in these
> couple of years. One
> 		> of my reason is market reason same as Larry. Another
> my reason is
> 		> technical reason. As I mentioned before, a target peer
> which supports
> 		> CBT allows initiator peers to send ORBs safely. Any
> data link layer
> 		> which services only one data path has difficulties to
> support multiple
> 		> logical channels. Because, if once one of logical
> channels had been
> 		> stalled, other requests that goes same data path will
> be stalled.
> 		> The CBT set the data link layer free from these
> difficulties.
> 
> 		Yes, any link which supports only one data path has
> difficulties
> 		to support multiple logical channels.
> 
> 		This is exactly why I identified the major issue between
> option A
> 		and option B as whether multiple functions within a
> device are
> 		provided via:
> 
> 		  MUX layer for multiple functions access presented as
> one Unit (option A)
> 		vs.
> 		  separate units for each function  (option B)
> 
> 		This is really the choice between the two options.
> 
> 
> 
> 		The other topic of discussion under this thread deals
> with how to
> 		use SBP-2 to provide independent, opposing,
> unidirectional data
> 		streams over the same login.  Whether option A or option
> B is
> 		chosen, the issue of providing the specified
> bidirectional
> 		service to the layer above SBP-2 still exists.  And, I
> think it's
> 		exactly the same issue.
> 
> 		To highlight the issue:
> 
> 		  Exactly how does an initiator peer which supports CBT
> receive
> 		  a Credit packet from the target at any indeterminate
> time?
> 
> 		This is not provided directly by 1284.4.  How are you
> planning on
> 		solving it for your implementation of option A?
> 
> 
> 		> -------------------------------
> 		> Fumio Nagasaka
> 		> Epson Software Development Laboratory Inc.
> 		> Tel +81 268 25 4111,  Fax +81 268 25 4627
> 		> E-mail to nagasaka.fumio@exc.epson.co.jp
> 
> 
> 		-- 
> 		Greg Shue
> 		Hewlett-Packard Company
> 		Office Products
> Division			gregs@sdd.hp.com
> 	
> ----------------------------------------------------------------
> 





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


From gregs at sdd.hp.com  Tue Feb 17 14:45:10 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:48 2009
Subject: P1394> 1284.4 over SBP-2
In-Reply-To: <199802140140.KAA16985@bsdmail.bsd.canon.co.jp>
Message-ID: <199802171945.LAA08478@hpsdlgj1.sdd.hp.com>

> >From the discussions, I will ASSUME that SBP-2 has somehow been 
> 
> chosen to be THE transport for PC printing, and we will work the "glue"
> 
> for it. Has it ?  


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
----------------------------------------------------------------


From gregs at sdd.hp.com  Tue Feb 17 14:47:26 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:48 2009
Subject: P1394> 1284.4 over SBP-2
In-Reply-To: <01BD3AC2.FE1E31A0@p24-dn01ueda.nagano.ocn.ne.jp>
Message-ID: <199802171947.LAA08489@hpsdlgj1.sdd.hp.com>

> 
> Hi Greg,
> 
> S2 state will not happen, when your model uses "Credit Base Transport".
> The initiator will not send more packets than given credits by the target.


Correct.


> --------------------------------------------
> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp





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


From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Tue Feb 17 17:15:15 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:48 2009
Subject: P1394> Print Protocols
Message-ID: <H0000d930ed74897@MHS>

     
This was "RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes"
however I figured it was time for a new name.


--------------------------
     Ozay Oktay wrote:
     I have been quietly monitoring this discussion on the reflector. So 
     far this is the best analysis I have read.
     
     I agree with Brian almost entirely.. When preparing a standard we must 
     look into the future. We could be accommodating but we should never be 
     constricting for the sake of backward compatibility.
     
     Best Regards
     
     Ozay Oktay
     Canon Information Systems
-------------------------------
     
I will second that, good job Brian. 


So, from attempting to follow the discussion it seems to me that we have.


1) 1284.4 over SBP-2 over 1394.


Rough consensus that this is not a great idea.


2) 1284.4 over 1394.


I don't think this works by itself? We still need a layer that takes the 
1284.4 packet and puts it into a 1394 packet with a 1394 address. As Brian 
and others have mentioned DFA does this, however, DFA does not handle out 
of order, lost  or duplicate packets.


3) SBP-2 over 1394.


Has merit. Good native 1394 solution that takes advantage of 1394's memory 
address capabilities and works well with descriptor based DMA.


If PC nodes only want to be Initiators we don't have a symmetric solution. 
I think we can make it work, though, I am concerned that non PC peers that 
implement both Target/Initiator functions would need to communicate with 
each other in a different way than when they communicate with a PC?


4) DPP over 1394.


Sounds good. I have not seen enough of the detailed mechanism to determine 
if it delivers (I need to learn more about DPP). Did receive some comments 
at the TA about totally inventing a new mechanism instead of reusing 
existing protocols, though it could be the right answer.


5) TCP/IP over 1394.


I think this is a given. (IP happens). This could give us printing similar 
to the way it works today, as well as all the new internet possibilities. 
Address administration and configuration, (DNS and DHCP and others as 
Michael points out), make a full implementation larger than some devices 
might like. Not sure of the use model?


Conclusions?




Alan

From gregs at sdd.hp.com  Tue Feb 17 17:35:26 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:48 2009
Subject: How the solution B works? (Re: P1394> 1284.4 over SBP-2)
In-Reply-To: <P1394> 1284.4 over SBP-2)>
Message-ID: <199802172235.OAA08667@hpsdlgj1.sdd.hp.com>

Hi all,


It's time to respond to the discussion along this thread.
I hope this points out some areas of misunderstanding and
makes some of the issues easier to understand.


Akihiro Shimura wrote: (reformatted)
> If target request data transfer by "Data Available" flag in
> certain status block, initiator will subsequently append "SND
> data-in" ORB in the current task list.  It will be possible for
> the target to check if there is a "SND data-in" ORB in the task
> list BEFORE the initiator appends the "SND data-in" ORB.  After
> finding there is no "SND data-in" ORB, the target may issue
> another unsolicited status which indicates "Data Available".  By
> this status, the initiator may append one more (total two) "SND
> data-in" ORB in the task list.  After that, the target will need
> to abort the excessive ORB.
> 
> Is this a way the SBP-2 only solution works?


[Greg Shue]
No.  The behavior described assumes the ability to scan through the ORB
list and potentially process them out of order.  The proposal that Alan
and I gave used the ORDERED processing model.  In this model, only what
is at the head of the Task List can be used to make processing decisions.


[Akihiro Shimura]
> I would like to introduce these rules shown below,
> 1)      The initiator clear Unsolicited_Status_Enable register to forbid
> the target
>         to issue unsolicited status which says "Data Available", while
> the initiator
>         is appending new ORBs in the list.
> 2)      The target shall observe Unsolicited_Status_Enable register,
> whether or not it is
>         set to one, before it scans linked list of ORBs.
> 3)      When the target found Unsolicited_Status_Enable register is set
> to one,
> and there is no in-ORB in the list, then the target may send unsolicited
> status.
> 
> Then the initiator will not generate too many in-ORBs in the list.


[Greg Shue]
There are some problems with the rules:


  Rule 1 changes the definition of SBP-2.  SBP-2 does not provide a
  mechanism for the initiator to clear the Unsolicited_Status_Enable
  register.  A write of _any_ value to the register enables
  unsolicited status.


  Rules 2 & 3 assume that an Unordered processing model is used.
  See my previous comment.


Because the ORDERED processing model is used, the rules are unnecessary.




Akihiro Shimura wrote: (reformatted)
> It seems natural to make two independent logins for each
> direction, one for down-link and another for up-link by using the
> idea to map them into logical units.  Furthermore, by extending
> this to allow to allocate up-link in reverse fashion (i.e., the
> target of down-link makes a login to the initiator of down-link),
> the link between two devices will become symmetric if both ends
> have both initiator and target functionality.


[Greg Shue]
The idea of an task list for each direction to provide independent
data flow is a natural one.  The idea of requiring cross logins
(or 2 logins to the same device) would accomplish this.  Having
each login and task list on a separate device provides symmetry.


This is very similar to Alan's DFA proposal.  It is just abstracted
one layer.  The packet "write" is accomplished by an ORB rather than
an MTU.  The size of the FIFO is limited to the max size of the data
referenced by the ORB.


Can multiplexing of logical channels be provided on top of this?
Yes, but this could also be the communications profile for
services which are in independent Unit directories.


The ISSUE:
  The logins must deal with access control separately even though
  they are coupled together at the next higher layer.  No one has
  come up with a proposal to manage this.




Nagasaka Fumio write:
> If we choose 1284.4 as transport layer in PC printing architecture,
> we can use same transport layer to cover USB, 1394 and conventional
> parallel port. And if we adopt socket API on 1284.4 service, then we
> can use same interface for any local devices and for any network
> devices.
> 
> This feature greatly decrease development efforts to make protocol
> stack in PC printing area. And it would provide better usability even
> for end users.
> 
> If we choose new transport for SBP-2/1394 stack, then we need to
> develop different middle device driver to cover rest of other I/O(s).
> 
> How do you think this point?


Randy Turner writes:
> My point from all of this is that for the layering models discussed so
> far, we don't have to worry about providing a common API for
> applications. So we can keep our discussion focused on relevant
> technical transport issues.


[Greg Shue]
I agree with Randy that we don't have to worry about providing a
common API for applications.  We also don't have to worry about
providing a common transport stack since:


  - all that is required by the API is a common set of services
  - we are NOT going to get a common stack anyway, since IP1394
      will exist.


As for the thoughts expressed by Nagasaka Fumio, the idea is nice,
but impractical.


  - IP1394 will exist, so 1284.4 will not be THE (only) printing
       architecture.


  - I have not seen 1284.4 get strongly adopted over USB by the
       industry, though it makes sense for USB.


  - I think there is as much work developing an appropriate Data Link
       to fit beneath 1284.4 as there is to turn SBP-2 into an
       equivalent transport.  So I don't agree with it 'greatly
       decreasing development efforts,' especially since SBP-2
       will already be provided by OS vendors.


  - I don't think we have to keep the same transport protocol
       between USB (or 1284) and 1394.  I think that 1394 needs
       to provide at least the same kind of service.


  - We're not talking about only a _printing_ connection.  The PWG
       agreed to look at MFPs also, which is why I was brought on
       in the first place.  So, let's not forget scanning paradigms
       and preferred connection solutions.  This is where an SBP-2
       transport solution w/ multiple units really is preferred
       since it maps _directly_ to a SCSI model, and allows for
       other types of functionality.




Akihiro Shimura writes:
> As far as I understand, the "another unsolicited status" will not
> happen in this scenario by the definition given by Greg because the
> target is already in "Data Available" state. (Greg, thank you for the
> clarification.)
>
(snip)
>
> I'm not sure if I understand your question, but the functionality
> equivalent to multiple logical channel is already done in the SBP-2
> only solution (option B) via unit architecture. If the target does NOT
> behave as expected by the initiator, like asynchronous notification,
> "aborting task"(which implies subsequent retry) will be necessary to
> keep each direction independent.  To avoid the use of "aborting task"
> while keeping each direction independent, I thought it may be natural
> to allocate two independent links(logical units) for down-link and
> up-link instead of using "aborting task".


[Greg Shue]
You are correct about the unsolicited status behavior.
You are also correct about the Unit Architecture providing the
equivalent of "multiple logical channels."


You are also correct that the "task abort" mechanism is not
needed if the packets of data are kept on two different task lists.
But this leads to the issues I mentioned above.




Akihiro Shimura writes:
> Greg Shue <gregs@sdd.hp.com> wrote:
> >   If the target doesn't behave as expected and has lots of unsolicited
> >   data for the initiator, the target aborts the current task set and
> >   the initiator pauses sending data to the target until the target has
> >   no more data for the initiator.
> 
> The flow control part of "target-to-initiator" data transfer seems to
> be missing here.
> 
> I suppose that the condition follows to "until" in the above sentence
> would be "until the target has no more data for the initiator OR the
> initiator does not have resources to receive more data from the target."
> Is this what you intended or am I still missing something?
> 
> >   If we are doing unidirectional printing, then there is no data
> >   for the initiator, and the task set is never aborted.
> >
> >   If we are interacting with the device, and it behaves as expected,
> >   then there is no unexpected data for the initiator, so the task
> >   set is never aborted.  (For interactive Postscript, scanning models,
> >   and request/reply paradigms like SNMP)
> 
> This sounds like expectation (or requirement) for client applications
> to be master/slave.
> It seems that "request/reply" is expected to be done indivisibly and
> sequencially. Does the solution well cover the case "requests/replies"
> are done in parallel (more than one request are outstanding) as well?


The flow control occurs implicitly.  One "packet" gets transferred
from the target to the initiator per empty ORB queued.  The max
amount of data which may be sent has already been negotiated.  The
buffer is provided by the initiator and referenced by the ORB.  The
completion status indicates whether or not more data is immediately
available.  If more data is available and the initiator has buffer
space, the initiator will provide another ORB.  If no more data is
available, then the initiator may requeue the pending task set.  If
more data is available, but the initiator does not have buffer space
available, then both sides are blocked, so it doesn't really matter
what the initiator does.  It might as well requeue (at least the head
of) the task set and let the target proceed when possible.




As far as the expectation for client applications to be master/slave,
this is probably true.  I can't think of a client/server model
which isn't master/slave.  I also can't think of a scanning or
printing model which isn't master/slave.  I can't even think
of a case where request/replies aren't master/slave.


  Can anyone else come up with a good example to convince
  me otherwise?


Since there is no implicit association between data packets flowing
in each direction, it could work for multiple requests being issued
before multiple replies received.  BUT, I don't know how well it
would work.  If the device could buffer all the requests made
before having to send a reply, then it would work well.  If the
device can't buffer all the requests, then it must send the replies
before it can process more requests.  This case is covered because
deadlock is avoided.  You will have to determine for yourselves
exactly how _well_ this is covered.



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


From stephen at hpb16977.boi.hp.com  Tue Feb 17 17:54:55 1998
From: stephen at hpb16977.boi.hp.com (Stephen Holmstead)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
Message-ID: <199802172235.OAA08667@hpsdlgj1.sdd.hp.com>

Here's my opinion. 


1)  I agree that this option is dead.
2)  I think option 2 could work, but there is some political resistance
from the camera guys to adding 1284.4.  It's heavier than Thin Protocol
(Thin doesn't have multiple channels).  There would have to be a
definition of how 1284.4 sits on top of 1394, but I don't think that
there needs to be another layer between 1284.4 and 1394.
3)  I really don't like SBP-2.  SBP-2 is an EXCELLENT model for existing
storage devices.  It is NOT a good model for peer to peer devices.
Sure, the initiator/target model can be modified to have a target notify
the initiator that data is available, but it is kludgy.  Aborting the
task queue is an exceptable solution if your model is primarily single
direction data flow.  But in a peer to peer environment, the data
direction is going to switch a bunch.  That is just not an exceptable
design.  Bottom line, you can make initiator/target model do peer to
peer, but it won't do it well.
4)  DPP is not a transport layer.  The Thin Protocol (defined in the DPP
spec) that sits BELOW DPP is a transport layer.  I like Thin Protocol.
It's very lightweight.  I don't think anybody could complain about
adding the code to implement Thin Protocol.  It doesn't provide multiple
channels, but it does do segmentation/reassembly.  It provides a very
generic and simple "stream" transport.
5)  I would be happy with IP/1394.  It would allow us to have UDP and
TCP transport layers that are already familiar to many.  Unfortunately,
I think this option is viewed by many to be "heavy", but it doesn't have
to be.  I don't care about DHCP, DNS, and other administrative
protocols.  I just want the transport layer (UDP/TCP).  The real problem
here is that it's going to take a long time until committees decide what
IP/1394 is.  If we are in a rush, this option isn't it.


So, in summary, option 4 looks like the leader in my book.  Options 2
and 5 also have merit.  That's my opinion.  Anyone else?


Stephen Holmstead


> -----Original Message-----
> From:	ALAN_BERKEMA@hp-roseville-om2.om.hp.com
> [SMTP:ALAN_BERKEMA@hp-roseville-om2.om.hp.com]
> Sent:	Tuesday, February 17, 1998 3:15 PM
> To:	p1394@pwg.org; pp1394@cpdc.canon.co.jp
> Subject:	P1394> Print Protocols
> 
>      
> This was "RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes"
> however I figured it was time for a new name.
> 
> --------------------------
>      Ozay Oktay wrote:
>      I have been quietly monitoring this discussion on the reflector.
> So 
>      far this is the best analysis I have read.
>      
>      I agree with Brian almost entirely.. When preparing a standard we
> must 
>      look into the future. We could be accommodating but we should
> never be 
>      constricting for the sake of backward compatibility.
>      
>      Best Regards
>      
>      Ozay Oktay
>      Canon Information Systems
> -------------------------------
>      
> I will second that, good job Brian. 
> 
> So, from attempting to follow the discussion it seems to me that we
> have.
> 
> 1) 1284.4 over SBP-2 over 1394.
> 
> Rough consensus that this is not a great idea.
> 
> 2) 1284.4 over 1394.
> 
> I don't think this works by itself? We still need a layer that takes
> the 
> 1284.4 packet and puts it into a 1394 packet with a 1394 address. As
> Brian 
> and others have mentioned DFA does this, however, DFA does not handle
> out 
> of order, lost  or duplicate packets.
> 
> 3) SBP-2 over 1394.
> 
> Has merit. Good native 1394 solution that takes advantage of 1394's
> memory 
> address capabilities and works well with descriptor based DMA.
> 
> If PC nodes only want to be Initiators we don't have a symmetric
> solution. 
> I think we can make it work, though, I am concerned that non PC peers
> that 
> implement both Target/Initiator functions would need to communicate
> with 
> each other in a different way than when they communicate with a PC?
> 
> 4) DPP over 1394.
> 
> Sounds good. I have not seen enough of the detailed mechanism to
> determine 
> if it delivers (I need to learn more about DPP). Did receive some
> comments 
> at the TA about totally inventing a new mechanism instead of reusing 
> existing protocols, though it could be the right answer.
> 
> 5) TCP/IP over 1394.
> 
> I think this is a given. (IP happens). This could give us printing
> similar 
> to the way it works today, as well as all the new internet
> possibilities. 
> Address administration and configuration, (DNS and DHCP and others as 
> Michael points out), make a full implementation larger than some
> devices 
> might like. Not sure of the use model?
> 
> Conclusions?
> 
> 
> Alan

From gregs at sdd.hp.com  Tue Feb 17 18:49:26 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
In-Reply-To: <616C9498C73ED111857F0060B06ACD59132728@hpb26851.boi.hp.com>
Message-ID: <199802172349.PAA08725@hpsdlgj1.sdd.hp.com>

> 2)  I think option 2 could work, but there is some political resistance
> from the camera guys to adding 1284.4.  It's heavier than Thin Protocol
> (Thin doesn't have multiple channels).  There would have to be a
> definition of how 1284.4 sits on top of 1394, but I don't think that
> there needs to be another layer between 1284.4 and 1394.


Yes, there _does_ need to be a layer between 1284.4 and 1394.
This layer provides the functionality of _how_ 1284.4 sits on
top of 1394.  Specifically, it implements the Data Link layer
required by 1284.4.  This functionality is not directly provided
by 1394.  It must address the issues of access control, dynamically
changing topology, transient link interruptions, packetized transfers,
actual data transfer scheduling for each direction.  Not a trivial
piece of the puzzle.


> 3)  I really don't like SBP-2.  SBP-2 is an EXCELLENT model for existing
> storage devices.  It is NOT a good model for peer to peer devices.
> Sure, the initiator/target model can be modified to have a target notify
> the initiator that data is available, but it is kludgy.  Aborting the
> task queue is an exceptable solution if your model is primarily single
> direction data flow.  But in a peer to peer environment, the data
> direction is going to switch a bunch.  That is just not an exceptable
> design.  Bottom line, you can make initiator/target model do peer to
> peer, but it won't do it well.


If the applications which run above the transport are not
peer-to-peer in and of themselves, then there is no NEED for the
transport to really be peer-to-peer (though it doesn't hurt).


> 4)  DPP is not a transport layer.  The Thin Protocol (defined in the DPP
> spec) that sits BELOW DPP is a transport layer.  I like Thin Protocol.
> It's very lightweight.  I don't think anybody could complain about
> adding the code to implement Thin Protocol.  It doesn't provide multiple
> channels, but it does do segmentation/reassembly.  It provides a very
> generic and simple "stream" transport.


DPP Rev 0.71 has two distinct parts:  the DPP command set (which
lies above the transport), and the DPP transport stack (made up
of the "new" Thin Session, Thin Transaction, Isochronous, and
Asynchronous blocks).


I have just reread the DPP proposal, and it strikes me as equivalent
to SBP-2.


  The Connect sequence exactly mirrors an SBP-2 login (w/ command-set
    specific data).
  The Disconnect sequence exactly mirrors SBP-2 logout.
  The Reconnect sequence is similar to the SBP-2 reconnect sequence,
    though it's not specified which end is supposed to attempt the
    reconnect and what happens if both try it simultaneously.  Also,
    the reconnect window has been doubled from SBP-2.
  The Thin protocol requires both nodes to make memory available to
    the 1394 address space, instead of SBP-2's policy of initiator only.
  The Thin protocol does explicit segmentation and reassembly.
    SBP-2 does implicit segmentation and reassembly (it uses the
    naturally available 1394 address ranges).
  The Abort mechanism is provided by both.


  Section 5.7.2 Command, clearly talks about a master/slave paradigm
    in the two bullets spelling out the transfer sequences.


DPP is missing:


  - flow control
  - multiple logical channels
  - info about how this fits into a Unit Architecture
  - Actual command definitions
  - error detection/reporting


It also requires devices to support at least a 12 quadlet block write
instead of an 8 quadlet block write.


> 5)  I would be happy with IP/1394.  It would allow us to have UDP and
> TCP transport layers that are already familiar to many.  Unfortunately,
> I think this option is viewed by many to be "heavy", but it doesn't have
> to be.  I don't care about DHCP, DNS, and other administrative
> protocols.  I just want the transport layer (UDP/TCP).  The real problem
> here is that it's going to take a long time until committees decide what
> IP/1394 is.  If we are in a rush, this option isn't it.
> 
> So, in summary, option 4 looks like the leader in my book.  Options 2
> and 5 also have merit.  That's my opinion.  Anyone else?


I'll take SBP-2.  It's better defined, available, and probably equivalent.


> Stephen Holmstead



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


From brianb at vcd.hp.com  Tue Feb 17 19:02:23 1998
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
In-Reply-To: <H0000d930ed74897@MHS>
Message-ID: <3.0.3.32.19980217160223.007e9800@popmail1.vcd.hp.com>

At 02:15 PM 2/17/98 -0800, ALAN_BERKEMA@HP-Roseville-om2.om.hp.com wrote:
>     
>This was "RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes"
>however I figured it was time for a new name.
>
>--------------------------
>     Ozay Oktay wrote:
>     I have been quietly monitoring this discussion on the reflector. So 
>     far this is the best analysis I have read.
>     
>     I agree with Brian almost entirely.. When preparing a standard we must 
>     look into the future. We could be accommodating but we should never be 
>     constricting for the sake of backward compatibility.
>     
>     Best Regards
>     
>     Ozay Oktay
>     Canon Information Systems
>-------------------------------
>     
>I will second that, good job Brian. 


OK, stop it.  My head is getting too big.  ;-)


>So, from attempting to follow the discussion it seems to me that we have.
>
>1) 1284.4 over SBP-2 over 1394.
>
>Rough consensus that this is not a great idea.
>
>2) 1284.4 over 1394.
>
>I don't think this works by itself? We still need a layer that takes the 
>1284.4 packet and puts it into a 1394 packet with a 1394 address. As Brian 
>and others have mentioned DFA does this, however, DFA does not handle out 
>of order, lost  or duplicate packets.


I assume that we could take DFA and add the functionality required to
handle out-of-order, lost and duplicate packets.  If we did that, we would
need to compare our solution to SBP-2 to make sure that we didn't end up
re-inventing it.  I've seen that happen all too often...


>3) SBP-2 over 1394.
>
>Has merit. Good native 1394 solution that takes advantage of 1394's memory 
>address capabilities and works well with descriptor based DMA.
>
>If PC nodes only want to be Initiators we don't have a symmetric solution. 
>I think we can make it work, though, I am concerned that non PC peers that 
>implement both Target/Initiator functions would need to communicate with 
>each other in a different way than when they communicate with a PC?


I don't know if we should assume that PC-nodes will only be initiators,
even though George Chrysanthakopoulos at Microsoft indicated that PC
targets would not be supported.  I hope that we can change his mind by
showing him why PC targets are important.  BTW, I agree with him that
PC-connect devices could be implemented as targets, but, again, I would
prefer not to limit our future solutions in that way.


>4) DPP over 1394.
>
>Sounds good. I have not seen enough of the detailed mechanism to determine 
>if it delivers (I need to learn more about DPP). Did receive some comments 
>at the TA about totally inventing a new mechanism instead of reusing 
>existing protocols, though it could be the right answer.


I agree with the concerns of the TA.  Any protocols we specify MUST provide
solutions in a significantly better way than do the other available
protocols.  If they do not, companies will not implement our protocols, and
they will end up being a waste of time.  In addition, too many protocols
can confuse the industry and our customers, diluting the effect of the
primary ones.


>5) TCP/IP over 1394.
>
>I think this is a given. (IP happens). This could give us printing similar 
>to the way it works today, as well as all the new internet possibilities. 
>Address administration and configuration, (DNS and DHCP and others as 
>Michael points out), make a full implementation larger than some devices 
>might like. Not sure of the use model?
>
>Conclusions?


IMHO, there will be at least two printing protocols for 1394, TCP/IP and
something else.  If TCP/IP and that something else can't solve the needs of
low-end image printing, parallel-port replacement printing and "network"
printing, then we will need three printing protocols.  No matter what we
end up choosing, my personal goal is that, a few years from now, our
protocols are in widespread use, providing strong value to our customers.
(Hey, maybe I have a career in Marketing ahead!)  ;-)


Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227

From shimura at pure.cpdc.canon.co.jp  Tue Feb 17 19:13:43 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:49 2009
Subject: How the solution B works? (Re: P1394> 1284.4 over SBP-2)
In-Reply-To: <199802172235.OAA08667@hpsdlgj1.sdd.hp.com>
Message-ID: <199802180013.JAA21949@slant1.pure.cpdc.canon.co.jp>

Just clarification ....


On Tue, 17 Feb 1998 14:35:26 -0800 (PST)
Greg Shue <gregs@sdd.hp.com> wrote:
(snip)


Message below is not from me. It's from Nagasaka-san.


> [Akihiro Shimura]


[Fumio Nagasaka]


> > I would like to introduce these rules shown below,
> > 1)      The initiator clear Unsolicited_Status_Enable register to forbid
> > the target
> >         to issue unsolicited status which says "Data Available", while
> > the initiator
> >         is appending new ORBs in the list.
> > 2)      The target shall observe Unsolicited_Status_Enable register,
> > whether or not it is
> >         set to one, before it scans linked list of ORBs.
> > 3)      When the target found Unsolicited_Status_Enable register is set
> > to one,
> > and there is no in-ORB in the list, then the target may send unsolicited
> > status.
> > 
> > Then the initiator will not generate too many in-ORBs in the list.
> 
> [Greg Shue]
> There are some problems with the rules:
> 
>   Rule 1 changes the definition of SBP-2.  SBP-2 does not provide a
>   mechanism for the initiator to clear the Unsolicited_Status_Enable
>   register.  A write of _any_ value to the register enables
>   unsolicited status.
> 
>   Rules 2 & 3 assume that an Unordered processing model is used.
>   See my previous comment.
> 
> Because the ORDERED processing model is used, the rules are unnecessary.



--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.


From atsnaka at bsd.canon.co.jp  Tue Feb 17 19:42:03 1998
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:49 2009
Subject: [PP1394:00177] RE: P1394> Print Protocols
In-Reply-To: <616C9498C73ED111857F0060B06ACD59132728@hpb26851.boi.hp.com>
Message-ID: <199802180042.JAA01521@bsdmail.bsd.canon.co.jp>

1 clarifiaction, and 1 comment.






Stephen wrote ;






> 4)  DPP is not a transport layer.  The Thin Protocol (defined in the DPP


> spec) that sits BELOW DPP is a transport layer.  I like Thin Protocol.


> It's very lightweight.  I don't think anybody could complain about


> adding the code to implement Thin Protocol.  It doesn't provide multiple


> channels, but it does do segmentation/reassembly.  It provides a very


> generic and simple "stream" transport.






DPP(Direct Print Protocol) =


  Thin Protocol (transport) + DPP Command Set(application cmd set)






(DPP is the name for both the transport and command set.)






Everything else you mentioned is correct.










Brian wrote;






>>4) DPP over 1394.


>>


>>Sounds good. I have not seen enough of the detailed mechanism to determine 


>>if it delivers (I need to learn more about DPP). Did receive some comments 


>>at the TA about totally inventing a new mechanism instead of reusing 


>>existing protocols, though it could be the right answer.






>I agree with the concerns of the TA.  Any protocols we specify MUST provide


>solutions in a significantly better way than do the other available


>protocols.  If they do not, companies will not implement our protocols, and


>they will end up being a waste of time.  In addition, too many protocols


>can confuse the industry and our customers, diluting the effect of the


>primary ones.






I ,one of the proposing side of DPP also agree with everyone's concern.


However, we are not adding 10 more protocols, just ONE more.






AV/C+FCP(current) :most suited for isochronous data  


SBP-2                  :most suited for asynchronous pull






Thin would cover what would be missing :






thin transport         :most suited for symmetrical asynchronous "push"  


                           (connection-oriented)






"most suited", of course is MY observation, there may be other opinions,


but I assume Thin, with IP1394 would cover (almost) everthing.










P.S.


Of course I assume everyone would agree that the DPP application command set


is required for direct-printing, but that is out of the scope of this discussion.






-----------------------------------------


<bigger>Atsushi Nakamura


</bigger>-----------------------------------------




BJ Technology Develpoment 22,


Canon Inc.




53 Imai Kami-cho


Nakahara-Ku, Kawasaki-shi


postal no. 211




tel:+81-3-44-733-6111(ext.5593)


    +81-3-44-739-6634(direct)


fax:+81-3-44-739-6756


email(1):Atsushi_Nakamura@cbj.canon.co.jp


email(2):atsnaka@bsd.canon.co.jp


-----------------------------------------

From stephen at hpb16977.boi.hp.com  Tue Feb 17 20:02:10 1998
From: stephen at hpb16977.boi.hp.com (Stephen Holmstead)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
Message-ID: <199802180042.JAA01521@bsdmail.bsd.canon.co.jp>

Greg Shue wrote:
>If the applications which run above the transport are not
>peer-to-peer in and of themselves, then there is no NEED for the
>transport to really be peer-to-peer (though it doesn't hurt).


I need peer to peer.  PWG-C needs peer to peer.  I don't think it would
be incredibly intelligent to eliminate a feature of 1394 by a
restriction of the transport layer.


>I have just reread the DPP proposal, and it strikes me as equivalent
>to SBP-2.


I agree; it is similar.  The major difference is that Thin Protocol
provides a SYMMETRICAL connection.


>  The Connect sequence exactly mirrors an SBP-2 login (w/ command-set
>    specific data).


Also, either end can initiate the connect.  In SBP-2, the initiator logs
in with the target.


>  The Disconnect sequence exactly mirrors SBP-2 logout.
>  The Reconnect sequence is similar to the SBP-2 reconnect sequence,
>    though it's not specified which end is supposed to attempt the
>    reconnect and what happens if both try it simultaneously.  Also,
>    the reconnect window has been doubled from SBP-2.
>  The Thin protocol requires both nodes to make memory available to
>    the 1394 address space, instead of SBP-2's policy of initiator
only.


This allows for  the symmetrical connection missing from SBP-2.


>  The Thin protocol does explicit segmentation and reassembly.
>    SBP-2 does implicit segmentation and reassembly (it uses the
>    naturally available 1394 address ranges).
>  The Abort mechanism is provided by both.


>  Section 5.7.2 Command, clearly talks about a master/slave paradigm
>    in the two bullets spelling out the transfer sequences.


Yes, but it allows either end to issue commands.  In SBP-2, only the
initiator can issue commands.


>DPP is missing:
>
>  - flow control


Yes, but can be added at a higher level in the OSI model.  Many
transport layers do not provide flow control.  This is not a requirement
for my application.  Some "command sets" implicitly control pacing of
data.


>  - multiple logical channels


I don't recall reading how SBP-2 provides multiple logical channels
either.


>  - info about how this fits into a Unit Architecture


I don't recall the PWG having a "Unit Architecture" requirement.  This
may be a feature of SBP-2, but I wasn't listed as a requirement for the
PWG.


>  - Actual command definitions


This is not actually part of the OSI transport layer.


>  - error detection/reporting


I agree with this one, but I would word it slightly differently.  Thin
protocol does not provide a "reliable" connection.  However, the 1394
link layer does provide reliabilty on an MTU basis, so all that would
have to be added would be a reconnection mechanism to handle transient
link failures (cable temporarily unplugged).


> I'll take SBP-2.  It's better defined, available, and probably
equivalent.


It is NOT equivalent.  SBP-2 doesn't provide symmetrical connections.
But hey, if you don't need symmetrical connections, use SBP-2 if that's
what you like.  I'm just saying that SBP-2 doesn't work for me.  It also
doesn't work for the PWG-C.  And from what I've heard over the last
couple days on this thread, it doesn't work for many of the PWG people
either.  In my mind, SBP-2 doesn't fit the bill as a standard 1394
transport layer protocol.


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


Stephen Holmstead
Hewlett Packard Information Appliance Operation

From gregs at sdd.hp.com  Tue Feb 17 20:40:15 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
In-Reply-To: <H0000d930ed74897@MHS>
Message-ID: <199802180140.RAA08883@hpsdlgj1.sdd.hp.com>

Gee, so much discussion ...


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
----------------------------------------------------------------


From ewa at apple.com  Tue Feb 17 18:11:12 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
In-Reply-To: <P1394> Print Protocols>
Message-ID: <B10FD0D1-52853@17.219.105.215>

> So, from attempting to follow the discussion it seems to me that we have.
>
... 
> 
> 3) SBP-2 over 1394.
> 
> Has merit. Good native 1394 solution that takes advantage of 1394's
memory 
> address capabilities and works well with descriptor based DMA.
> 
> If PC nodes only want to be Initiators we don't have a symmetric
solution. 
> I think we can make it work, though, I am concerned that non PC peers
that 
> implement both Target/Initiator functions would need to communicate with 
> each other in a different way than when they communicate with a PC?


I still believe this is the way to go.  I'd like to clarify one
point and then ask a question:


Symmetry:  You are all correct that the peer-to-peer nature of
1394 favors symmetry.  For example, we'd like to have a scanner
send an image straight to a printer (less work for us OS folks!).
SBP-2 is not symmetric - it is an initiator/target model.  What
I would like to clarify is that this is not automatically a
problem.  In any particular session, we can define roles of
initiator and target, even between devices that are peers.  I
would suggest that generally whatever device has initiated the
operation is the initiator (simple, huh?).  In the scanner-printer
case, probably we pressed a button on the scanner to cause it to
print the image.  So the scanner is the initiator in this case.


By the way, Apple does plan to support SBP-2 target functions in
Mac OS.  We see SBP-2 as a good way for two computers on 1394 to
talk to each other.  We also want to emulate a 1394 printer so
that the 1394 scanner can print to a legacy device (through us).


Now the question:  I understand that printing is not a purely
one-way communication.  The printer may need to communicate various
information back to the iniator during a print job.  This need led
to much of the 1284.4-over-SBP-2 work, as far as I can tell.  But
I have never seen a careful explanation of exactly what need exists.
If reverse-flow communication is used only rarely, then we can use
a slow, awkward mechanism for it, as long as we don't slow down the
primary forward-flow data communicatin.  If reverse-flow
communication is used a lot, then maybe we need a more symmetric
transport.  But my guess is that reverse-flow communication is much
smaller and less frequent than forward-flow communication.  So
adding all the overhead of the 1284.4 credit-based transfer does
not pay off, because we don't need that for the forward-flow data.


So, when do we need printer-initiated data flow back to the host?
Error conditions are one obvious case.  But errors are rare.  Job
setup is the other obvious case.  We might negotiate a bit with
the printer before we start printing.  But that happens only once
at the start of a job, not during active data transfer.  Is there
any other reverse dataflow that matters?  If we can limit the
reverse data flow to error reporting, light status reporting, and
setup, then perhaps it's OK to use SBP-2 in a clumsy way for this,
leaving the normal dataflow to happen quickly and efficiently (in
SBP-2).


> 4) DPP over 1394.
> 
> Sounds good. I have not seen enough of the detailed mechanism to
determine 
> if it delivers (I need to learn more about DPP). Did receive some
comments 
> at the TA about totally inventing a new mechanism instead of reusing 
> existing protocols, though it could be the right answer.


As Greg wrote, my view of DPP is that it is almost as complex as
SBP-2, but less well documented, and it has holes such as flow
control.  When these things are all fixed, we essentially have
another SBP-2 (an incompatible one).  Also DPP was very expensive
on the host side, with lots of CPU-driven polling and transmission,
rather than the passive SBP-2 model where the printer just reads
data out of our memory.


> 5) TCP/IP over 1394.
> 
> I think this is a given. (IP happens). This could give us printing
similar 
> to the way it works today, as well as all the new internet possibilities.


> Address administration and configuration, (DNS and DHCP and others as 
> Michael points out), make a full implementation larger than some devices 
> might like. Not sure of the use model?


I also agree that IP-1394 will happen.  However, this is a low-
performance solution, because a lot of host software work is
required to send and receive IP, and the flow control does
not map well to printing and 1394.  Furthermore, this does nothing
for isochronous printing.  The value of IP-1394 is in compatibility,
not performance.  The shared-memory services of 1394 are lost with
IP, as far as I can tell.


> Conclusions?
> 
> Alan

From shimura at pure.cpdc.canon.co.jp  Wed Feb 18 03:02:07 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
In-Reply-To: <199802180140.RAA08883@hpsdlgj1.sdd.hp.com>
Message-ID: <199802180802.RAA24694@origin.pure.cpdc.canon.co.jp>

I feel it will not be so uncomfortable to have more than one data
transport mechanism as far as;
  - each has its own benefit,
  - choosing one from them makes the benefit lost.
  - and they can co-exist well and they are consistent.
(Though developers may be uncomfortable.)


In PC-to-Device case, the PC resources like processor power need to be
efficiently shared with many other tasks.


SBP-2 is based on the "message passing/shared memory" model. The
shared memory function is provided by "bus" nature of 1394 and bridge
feature of OHCI style link. The message passing is done using
initiator's request queue (linked list of ORB's) and target's
response queue (status_FIFO) pair in the initiator's memory space.
Because the message passing does not require synchronization with the
target response, (i.e., the "initiator" PC can queue messages as far
as it has resource), SBP-2 will greatly reduce OS involvement (of
latency critical code) in I/O activities. Also bridge feature of OHCI
style link will free the CPU from shared memory accesses. So, SBP-2
"initiator" will efficiently share PC resources with other tasks while
achieving high bandwidth.
Furthermore, "target" device can de-queue the request messages at its
own pace. 


As described above, SBP-2 has a benefit when used as a (possibly
uni-directional) data path between "initiator" PC and "target" device.


Though it will be technically possible to make link peer-to-peer by
"targiator" approach with SBP-2 and it will work on various link
implementations, I think it will be too tough to require expensive
bridge hardware in any device to be "initiator" device. The device
will be cost sensitive with doing dedicated task as contrast with PC
to be general purpose.


Without bridge hardware, the SBP-2 will lose its appeal because
"message passing/shared memory" model is not optimized for packet
exchange on the wire due to its indirect buffer reference.


So, I think Device-to-Device (or peer-to-peer) other than SBP-2
"targiator" should also be addressed.


It may be good to make device-to-device framework that has an extra
SBP-2 data path for "PC-to-device" (or PC-to-PC) in it.


Akihiro Shimura


On Tue, 17 Feb 1998 17:40:15 -0800 (PST)
Greg Shue <gregs@sdd.hp.com> wrote:


> 
> 
> Gee, so much discussion ...
> 
> 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
> ----------------------------------------------------------------
> 



--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.


From rturner at sharplabs.com  Wed Feb 18 04:01:11 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
Message-ID: <199802180802.RAA24694@origin.pure.cpdc.canon.co.jp>

As is too often the case, we seemed to have narrowed our focus only on
printing, when several members of both PWG and PWG-C produce peripherals
for which printing is only ONE function; and we DON'T want a separate
transport and datalink layer for every application we come up with. The
most common type of peripheral that provides more than just printing is
the multifunction fax, scan, and print device. In this scenario, in
which the scan and fax can theoretically operate independently of a
"host", its not hard to see where the peripheral might want to initiate
a connection to some other device (could be a PC, but might be something
else). This would typically mean the device just received a fax and
wants to transfer the contents of the fax (possibly post-OCR) to some
other device on the 1394 bus. Likewise, at any time, someone might walk
up to a networked digital copier/printer and scan something. The user
interface on the device may have given the user the ability to direct
this scanned image to some other device on the 1394 bus. 


In both fax and scan scenarios I have presented, the peripheral wants to
initiate the connection to some other device on the 1394 bus. Sure, its
possible to design this system to use an initiator / target model,
wherein the PC ALWAYS has connections to both fax and scan "logical
units" and is ready to receive data, but we should no way preclude the
design of systems that truly want to support "peer" transport
capability.


In the 1284.x working groups we were "electrically" bound to support the
single-initiator model, and we talked about some rather elaborate means
for simulating peer-to-peer capability for 1284.4. Let me emphasize the
word "simulating" because basically we were faking it at the datalink
layer. In the 1284 scenario, because of the nature of our underlying
physical layer, we were on fairly firm technical grounds for proposing
peer-to-peer simulation at some layer in the stack. However, in my
opinion, looking at the 1394 physical layer, I have seen NO technical
ground to justify implementing a single-initiator transport for what
will be the only alternative to TCP/IP on the 1394 bus (I hope).


Let me also say that my convictions with regard to symmetry do not
necessarily preclude the use of SBP-2. In my earlier mail messages,
which have been echoed in the last week by Greg Shue and (I think) Alan
Berkema, we can achieve the symmetry that we would all like to see by
requiring "compliant" devices to support both initiator and target
SBP-2.


However, we also may be able to use the "thin" transport design being
proposed by the PWG-C. Personally, I would like to see a detailed
side-by-side analysis of an SBP-2 (both initiator and target)
implementation and the PWG-C "thin" stack implementation. I have a
hunch, like Greg Shue stated earlier, that the actual implementation
differences between the two will be minor, in both code size and RAM
requirements. But this is just a hunch until I see more data on this
subject.


Randy
(Just my additional $0.02)


	-----Original Message-----
	From:	Eric Anderson [SMTP:ewa@apple.com]
	Sent:	Tuesday, February 17, 1998 3:11 PM
	To:	p1394@pwg.org; pp1394@cpdc.canon.co.jp
	Subject:	Re: P1394> Print Protocols




	> So, from attempting to follow the discussion it seems to me
that we have.
	>
	... 
	> 
	> 3) SBP-2 over 1394.
	> 
	> Has merit. Good native 1394 solution that takes advantage of
1394's
	memory 
	> address capabilities and works well with descriptor based DMA.
	> 
	> If PC nodes only want to be Initiators we don't have a
symmetric
	solution. 
	> I think we can make it work, though, I am concerned that non
PC peers
	that 
	> implement both Target/Initiator functions would need to
communicate with 
	> each other in a different way than when they communicate with
a PC?


	I still believe this is the way to go.  I'd like to clarify one
	point and then ask a question:


	Symmetry:  You are all correct that the peer-to-peer nature of
	1394 favors symmetry.  For example, we'd like to have a scanner
	send an image straight to a printer (less work for us OS
folks!).
	SBP-2 is not symmetric - it is an initiator/target model.  What
	I would like to clarify is that this is not automatically a
	problem.  In any particular session, we can define roles of
	initiator and target, even between devices that are peers.  I
	would suggest that generally whatever device has initiated the
	operation is the initiator (simple, huh?).  In the
scanner-printer
	case, probably we pressed a button on the scanner to cause it to
	print the image.  So the scanner is the initiator in this case.


	By the way, Apple does plan to support SBP-2 target functions in
	Mac OS.  We see SBP-2 as a good way for two computers on 1394 to
	talk to each other.  We also want to emulate a 1394 printer so
	that the 1394 scanner can print to a legacy device (through us).


	Now the question:  I understand that printing is not a purely
	one-way communication.  The printer may need to communicate
various
	information back to the iniator during a print job.  This need
led
	to much of the 1284.4-over-SBP-2 work, as far as I can tell.
But
	I have never seen a careful explanation of exactly what need
exists.
	If reverse-flow communication is used only rarely, then we can
use
	a slow, awkward mechanism for it, as long as we don't slow down
the
	primary forward-flow data communicatin.  If reverse-flow
	communication is used a lot, then maybe we need a more symmetric
	transport.  But my guess is that reverse-flow communication is
much
	smaller and less frequent than forward-flow communication.  So
	adding all the overhead of the 1284.4 credit-based transfer does
	not pay off, because we don't need that for the forward-flow
data.


	So, when do we need printer-initiated data flow back to the
host?
	Error conditions are one obvious case.  But errors are rare.
Job
	setup is the other obvious case.  We might negotiate a bit with
	the printer before we start printing.  But that happens only
once
	at the start of a job, not during active data transfer.  Is
there
	any other reverse dataflow that matters?  If we can limit the
	reverse data flow to error reporting, light status reporting,
and
	setup, then perhaps it's OK to use SBP-2 in a clumsy way for
this,
	leaving the normal dataflow to happen quickly and efficiently
(in
	SBP-2).


	> 4) DPP over 1394.
	> 
	> Sounds good. I have not seen enough of the detailed mechanism
to
	determine 
	> if it delivers (I need to learn more about DPP). Did receive
some
	comments 
	> at the TA about totally inventing a new mechanism instead of
reusing 
	> existing protocols, though it could be the right answer.


	As Greg wrote, my view of DPP is that it is almost as complex as
	SBP-2, but less well documented, and it has holes such as flow
	control.  When these things are all fixed, we essentially have
	another SBP-2 (an incompatible one).  Also DPP was very
expensive
	on the host side, with lots of CPU-driven polling and
transmission,
	rather than the passive SBP-2 model where the printer just reads
	data out of our memory.


	> 5) TCP/IP over 1394.
	> 
	> I think this is a given. (IP happens). This could give us
printing
	similar 
	> to the way it works today, as well as all the new internet
possibilities.


	> Address administration and configuration, (DNS and DHCP and
others as 
	> Michael points out), make a full implementation larger than
some devices 
	> might like. Not sure of the use model?


	I also agree that IP-1394 will happen.  However, this is a low-
	performance solution, because a lot of host software work is
	required to send and receive IP, and the flow control does
	not map well to printing and 1394.  Furthermore, this does
nothing
	for isochronous printing.  The value of IP-1394 is in
compatibility,
	not performance.  The shared-memory services of 1394 are lost
with
	IP, as far as I can tell.


	> Conclusions?
	> 
	> Alan

From ueda at slab.tnr.sharp.co.jp  Wed Feb 18 22:40:14 1998
From: ueda at slab.tnr.sharp.co.jp (Toru Ueda)
Date: Wed May  6 14:00:49 2009
Subject: [PP1394:00178] Re: P1394> Print Protocols
In-Reply-To: <199802172349.PAA08725@hpsdlgj1.sdd.hp.com>
Message-ID: <9802181340.AA11974@slab.slab.tnr.sharp.co.jp>

I don't believe DPP is equivalent to SBP-2.
Please see below.


On Wed, 18 Feb 98 08:49:57 +0900
Greg Shue <gregs@sdd.hp.com> wrote:


> 
> > 2)  I think option 2 could work, but there is some political resistance
> > from the camera guys to adding 1284.4.  It's heavier than Thin Protocol
> > (Thin doesn't have multiple channels).  There would have to be a
> > definition of how 1284.4 sits on top of 1394, but I don't think that
> > there needs to be another layer between 1284.4 and 1394.
> 
> Yes, there _does_ need to be a layer between 1284.4 and 1394.
> This layer provides the functionality of _how_ 1284.4 sits on
> top of 1394.  Specifically, it implements the Data Link layer
> required by 1284.4.  This functionality is not directly provided
> by 1394.  It must address the issues of access control, dynamically
> changing topology, transient link interruptions, packetized transfers,
> actual data transfer scheduling for each direction.  Not a trivial
> piece of the puzzle.
> 
> > 3)  I really don't like SBP-2.  SBP-2 is an EXCELLENT model for existing
> > storage devices.  It is NOT a good model for peer to peer devices.
> > Sure, the initiator/target model can be modified to have a target notify
> > the initiator that data is available, but it is kludgy.  Aborting the
> > task queue is an exceptable solution if your model is primarily single
> > direction data flow.  But in a peer to peer environment, the data
> > direction is going to switch a bunch.  That is just not an exceptable
> > design.  Bottom line, you can make initiator/target model do peer to
> > peer, but it won't do it well.
> 
> If the applications which run above the transport are not
> peer-to-peer in and of themselves, then there is no NEED for the
> transport to really be peer-to-peer (though it doesn't hurt).
> 
> > 4)  DPP is not a transport layer.  The Thin Protocol (defined in the DPP
> > spec) that sits BELOW DPP is a transport layer.  I like Thin Protocol.
> > It's very lightweight.  I don't think anybody could complain about
> > adding the code to implement Thin Protocol.  It doesn't provide multiple
> > channels, but it does do segmentation/reassembly.  It provides a very
> > generic and simple "stream" transport.
> 
> DPP Rev 0.71 has two distinct parts:  the DPP command set (which
> lies above the transport), and the DPP transport stack (made up
> of the "new" Thin Session, Thin Transaction, Isochronous, and
> Asynchronous blocks).
> 
> I have just reread the DPP proposal, and it strikes me as equivalent
> to SBP-2.


How can you measure the closeness of two protocols ?
I guess this is very difficult.


I believe most connection oriented protocols have Connect and Disconnect.
These functions are very similar.


>   The Connect sequence exactly mirrors an SBP-2 login (w/ command-set
>     specific data).
>   The Disconnect sequence exactly mirrors SBP-2 logout.
I guess reconnect may be very similar.


>   The Reconnect sequence is similar to the SBP-2 reconnect sequence,
>     though it's not specified which end is supposed to attempt the
>     reconnect and what happens if both try it simultaneously.  Also,
>     the reconnect window has been doubled from SBP-2.


Both end can send reconnect request.
We don't have any problem if both end send reconnect simultaneously.
The end who wants to send data can issue reconnect request.
If the end who issues reconnect request receives reconnect request from
another end, this end shall send reconnect ack. This is described in
footnote of page 24.


>   The Thin protocol requires both nodes to make memory available to
>     the 1394 address space, instead of SBP-2's policy of initiator only.


This comes from basic concept of DPP.
DPP is designed as a symmetrical protocol. This is the reason why any
DPP nodes have to assign memory space.
The biggest feature of DPP is dynamic memory allocation.
If a high end printer has 16M byte memory in it, 16M byte can be
allocated for data buffer. This will reduce packet iteration.


For low end consumer device, several hundred byte for data buffer is
enough.


Even if it has a small memory, large data can be received.


>   The Thin protocol does explicit segmentation and reassembly.
>     SBP-2 does implicit segmentation and reassembly (it uses the
>     naturally available 1394 address ranges).
>   The Abort mechanism is provided by both.


This also comes from basic concept of DPP.
DPP uses PUSH model. Sender node need to have the responsibility for
data segmentation.
I believe this model is very different from SBP2.
This is not an issue that which is good or bad. These models are very
different and each model has suitable applications.


If I understand SBP2 correctly, SBP2 needs segmentation when the node
has larger data than its local memory. Do I misunderstand this?


>   Section 5.7.2 Command, clearly talks about a master/slave paradigm
>     in the two bullets spelling out the transfer sequences.


It's not talking about master/slave. It's just talking a sender and
a responder.
This means each end can send and receive data in one connection. There
is no difference between two ends.
It might be unusual that one end sends and receive data in one
connection for printing function. However it is quit usual for typical
network applications including HTTP and FTP.
(These are not the scope of DPP though.)


> DPP is missing:
> 
>   - flow control
It's not true. We don't use sophisticated flow control like 1284.4 does.
However SDU ack means the next data can be sent. This may not be very
efficient but works. If the receiver node has another memory area for
next segmented data(for example memory bank), it can send ACK packet
immediately.


Also, if it has only one memory for received data, after processing(this
usually means printing) it can send ACK. ACK means next memory available
or I have only one credit.
If you need more sophisticated way of flow control, you can add 1284.4
or other flow control protocol on the top of THIN protocol.


>   - multiple logical channels
This is under discussion. Because each "Connect Request" assigns register
area for this specific connection, thin can support multiple login.
(Each login uses different register space.)
Also, to add channel number, it can support multiple logical channels.


The reason we are discussing about this is that we must select the
functionality very carefully. 


We know we can add sophisticated flow control or multiple logical
channels. However we don't want to develop SBP2 like protocol but
not-SBP2 protocol.
Our protocol for consumer devices should be very simple.
We have to decide which function should NOT be supported for consumer
products.


>   - info about how this fits into a Unit Architecture
I'm sorry but I cannot understand what does it mean.


>   - Actual command definitions
We are discussing about this. Current document has a lot of TBD command
definitions.


>   - error detection/reporting
Do you mention about application error?
If so, this is command level issue. This is under discussion.
Also any communication error should be indicated to upper layer.


> It also requires devices to support at least a 12 quadlet block write
> instead of an 8 quadlet block write.
> 
> > 5)  I would be happy with IP/1394.  It would allow us to have UDP and
> > TCP transport layers that are already familiar to many.  Unfortunately,
> > I think this option is viewed by many to be "heavy", but it doesn't have
> > to be.  I don't care about DHCP, DNS, and other administrative
> > protocols.  I just want the transport layer (UDP/TCP).  The real problem
> > here is that it's going to take a long time until committees decide what
> > IP/1394 is.  If we are in a rush, this option isn't it.
> > 
> > So, in summary, option 4 looks like the leader in my book.  Options 2
> > and 5 also have merit.  That's my opinion.  Anyone else?
> 
> I'll take SBP-2.  It's better defined, available, and probably equivalent.


I agree that you may add SBP2 initiator and target for PC or PC printer.
However we, as a consumer device manufacturer, cannot support both SBP2
initiator and target in $300 digital still camera.


If we choose 1284.4 over SBP2, it will require glue part between two.
If we need 1284.4 + glue + SBP2 for target and 1284.4 + glue + SBP2 for
initiator, I'm afraid that any consumer device can't support this.


I understand that 1284.4 and SBP2 are excellent protocols. 
The reason we don't want to use 1284.4 over SBP2 for our consumer
products is the model is quit different from our peer to peer, low cost
and symmetrical applications.


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


Toru Ueda
Sharp Corporation
Software Labs.

From rturner at sharplabs.com  Wed Feb 18 17:50:42 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Upcoming teleconference call for 1394 discussion
Message-ID: <9802181340.AA11974@slab.slab.tnr.sharp.co.jp>

I am tentatively setting up a teleconference to continue discussion on
1394 transports for Monday, 2/23 at 4:00 PM PST. The duration of the
call will be 90 minutes. Let me know if this time and date is ok.


Randy

From brianb at vcd.hp.com  Wed Feb 18 23:12:03 1998
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:49 2009
Subject: P1394> RE: p1212r Austin mtg
Message-ID: <3.0.3.32.19980218201203.009a1870@popmail1.vcd.hp.com>

1394 PWG members,


David James of the 1212 reaffirmation effort is trying to decide if they
should hold a 1212 meeting in Austin the day after our March meeting.  I
would like the opportunity to attend and participate.  If you share that
desire, I suggest you send a message to David and the 1212 reflector
(p1212r@mail.zayante.com).  I have attached David's message below.


Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


>Dear all,
>
>Just returned from Japan, to find that Ats will most likely not be
>the scheduled March meeting, which is unfortunate in several ways.
>However, I have heard (John Fuller) that it might still be useful
>talking with other members of the PWG.
>
>For me, the March 2-3 meeting isn't convenient, but is possible.
>However, I would hate to go to Texas and find no-one else.
>It's now also past the 2-weeks notice time, so we would have to
>save official voting for the following meeting in Tokyo.
>
>So far, I have heard from John Fuller who recommends that the
>meeting should still be held and is likely to be useful.
>I would like to sollicit suggestions from others, who might
>be thinking of attending, before making a go/no-go decision
>on this Friday.
>
>Please send your comments to myself as well as the reflector.
>
>David V. James
>
>
>******************************************************************
>* Dr. David V. James            * Tel: (408) 955-6295            *
>* Sony Research Laboratories    * Fax: (408) 955-5180            *
>* LSI Systems Laboratory        * email: jamesd@lsi.sel.sony.com *
>* 3300 Zanker Road, M/S SJ-3D3  *        dvj@ibm.net (home)      *
>* San Jose, CA 95134            *                                *
>******************************************************************
>
>
>[ To receive daily digests of this list send the one line message: ]
>[     "subscribe digest p1212r" to requests@zayante.com            ]
>[ To stop receiving messages send the one line message:            ]
>[     "unsubscribe p1212r" to requests@zayante.com                 ]
>
>

From bogus@does.not.exist.com  Thu Feb 19 13:54:19 1998
From: bogus@does.not.exist.com ()
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
In-Reply-To: <B10FD0D1-52853@17.219.105.215>
Message-ID: <v04003a01b1122e8595dc@[192.168.1.25]>

Eric, Greg, Brian ...


I really like the way this discussion is shaping up, but I have one small
comment on the following:


At 3:11 PM -0800 2/17/98, Eric Anderson wrote:
>I
>would suggest that generally whatever device has initiated the
>operation is the initiator (simple, huh?).  In the scanner-printer
>case, probably we pressed a button on the scanner to cause it to
>print the image.  So the scanner is the initiator in this case.


Actually, I think it is a bit more complicated.


1) In SBP-2, most of the pacing (flow control) is done by the target (it's
the target that fetches the ORBs and decides exactly when to do the data
transfer), it is best for the device that has the most constraints on
timing to be the target. It's a toss-up between a scanner and a printer,
but between a CPU and a printer *or* a scanner, it's the CPU that has the
most relaxed timing, so it should be the initiator.


2) Devices that have a natural memory model (CPUs come to mind) should be
initiators, since that allows them to implement a simple bus bridge
function to support the target read and write operations directly, without
software intervention.


===========================================================================
Michael D. Johas Teener, Chief Technical Officer & Chairman of the Board
Zayante, Inc., 269 Mt. Hermon Rd. #111, Scotts Valley, CA 95066-4000, USA
email: mike@zayante.com    voice: +1-408-461-4901   fax: +1-408-461-1394
======================== http://www.zayante.com ===========================

From gregs at sdd.hp.com  Thu Feb 19 14:44:22 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
In-Reply-To: <v04003a01b1122e8595dc@[192.168.1.25]>
Message-ID: <199802191944.LAA13255@hpsdlgj1.sdd.hp.com>

> At 3:11 PM -0800 2/17/98, Eric Anderson wrote:
> >I
> >would suggest that generally whatever device has initiated the
> >operation is the initiator (simple, huh?).  In the scanner-printer
> >case, probably we pressed a button on the scanner to cause it to
> >print the image.  So the scanner is the initiator in this case.
> 
> Actually, I think it is a bit more complicated.
> 
> 1) In SBP-2, most of the pacing (flow control) is done by the target (it's
> the target that fetches the ORBs and decides exactly when to do the data
> transfer), it is best for the device that has the most constraints on
> timing to be the target. It's a toss-up between a scanner and a printer,
> but between a CPU and a printer *or* a scanner, it's the CPU that has the
> most relaxed timing, so it should be the initiator.


"Actually, I think it is a bit more complicated."


Flow control:
  If "flow control" refers to the scheduling of bus transactions to
  process a task, then I agree it is done by the (target's) fetch
  agent.
  
  If "flow control" refers to the presentation of the task requests
  (ORBs) and shared memory space then it is managed the initiator,
  since we're talking about one task request (ORB) referring to one
  "packet" transfer.
  
  If "flow control" refers to the policy for availability of the
  shared memory space for doing transactions, then it's shared between
  the target and the initiator (depending on the direction of data flow).


I still prefer Eric's proposal that whatever device has initiated
the operation is the initiator.  It avoids having to have the
connected-to devices from polling the want-to-connect devices to
figure out when the connection needs to happen.  That's much more
wasteful of processing power and bus bandwidth than providing
target functionality on a PC and using it only when appropriate.


Besides, who said we had to use the same SBP-2 device profile
for PC printing and "peer-to-peer" printing?




> 2) Devices that have a natural memory model (CPUs come to mind) should be
> initiators, since that allows them to implement a simple bus bridge
> function to support the target read and write operations directly, without
> software intervention.


"Silly me, I thought that any device driven by a CPU (whether a PC
or embedded device) has a natural memory model."


I guess that you mean devices which effeciently support memory
accesses from other 1394 notes should be initiators.  No, that
doesn't sound quite right either.  How about:


  Devices which cannot provide timely scheduling of 1394 transactions
  should not be driving fetch agents?


> ===========================================================================
> Michael D. Johas Teener, Chief Technical Officer & Chairman of the Board
> Zayante, Inc., 269 Mt. Hermon Rd. #111, Scotts Valley, CA 95066-4000, USA
> email: mike@zayante.com    voice: +1-408-461-4901   fax: +1-408-461-1394
> ======================== http://www.zayante.com ===========================





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


From jhollins at eng.adaptec.com  Thu Feb 19 15:21:42 1998
From: jhollins at eng.adaptec.com (Jack Hollins x2309)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
In-Reply-To: <P1394> Print Protocols>
Message-ID: <199802191944.LAA13255@hpsdlgj1.sdd.hp.com>

See embedded comment below


Greg Shue wrote:


> > At 3:11 PM -0800 2/17/98, Eric Anderson wrote:
> > >I
> > >would suggest that generally whatever device has initiated the
> > >operation is the initiator (simple, huh?).  In the scanner-printer
> > >case, probably we pressed a button on the scanner to cause it to
> > >print the image.  So the scanner is the initiator in this case.
> >
> > Actually, I think it is a bit more complicated.
> >
> > 1) In SBP-2, most of the pacing (flow control) is done by the target (it's
> > the target that fetches the ORBs and decides exactly when to do the data
> > transfer), it is best for the device that has the most constraints on
> > timing to be the target. It's a toss-up between a scanner and a printer,
> > but between a CPU and a printer *or* a scanner, it's the CPU that has the
> > most relaxed timing, so it should be the initiator.
>
> "Actually, I think it is a bit more complicated."
>
> Flow control:
>   If "flow control" refers to the scheduling of bus transactions to
>   process a task, then I agree it is done by the (target's) fetch
>   agent.
>
>   If "flow control" refers to the presentation of the task requests
>   (ORBs) and shared memory space then it is managed the initiator,
>   since we're talking about one task request (ORB) referring to one
>   "packet" transfer.
>


Actually a single ORB can point to a data buffer which is larger than the
maximumlegal 1394 packet transfer size.  Therefore multiple data packet
transfers can be
caused by one ORB.


>   If "flow control" refers to the policy for availability of the
>   shared memory space for doing transactions, then it's shared between
>   the target and the initiator (depending on the direction of data flow).
>
> I still prefer Eric's proposal that whatever device has initiated
> the operation is the initiator.  It avoids having to have the
> connected-to devices from polling the want-to-connect devices to
> figure out when the connection needs to happen.  That's much more
> wasteful of processing power and bus bandwidth than providing
> target functionality on a PC and using it only when appropriate.
>
> Besides, who said we had to use the same SBP-2 device profile
> for PC printing and "peer-to-peer" printing?
>
> > 2) Devices that have a natural memory model (CPUs come to mind) should be
> > initiators, since that allows them to implement a simple bus bridge
> > function to support the target read and write operations directly, without
> > software intervention.
>
> "Silly me, I thought that any device driven by a CPU (whether a PC
> or embedded device) has a natural memory model."
>
> I guess that you mean devices which effeciently support memory
> accesses from other 1394 notes should be initiators.  No, that
> doesn't sound quite right either.  How about:
>
>   Devices which cannot provide timely scheduling of 1394 transactions
>   should not be driving fetch agents?
>
> > ===========================================================================
> > Michael D. Johas Teener, Chief Technical Officer & Chairman of the Board
> > Zayante, Inc., 269 Mt. Hermon Rd. #111, Scotts Valley, CA 95066-4000, USA
> > email: mike@zayante.com    voice: +1-408-461-4901   fax: +1-408-461-1394
> > ======================== http://www.zayante.com ===========================
>
> --
> Greg Shue
> Hewlett-Packard Company
> Office Products Division                        gregs@sdd.hp.com
> ----------------------------------------------------------------




Jack Hollins
ASIC Architect
Adaptec

From gregs at sdd.hp.com  Thu Feb 19 15:40:32 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
In-Reply-To: <34EC9455.90589DB3@eng.adaptec.com>
Message-ID: <199802192040.MAA13296@hpsdlgj1.sdd.hp.com>

> > "Actually, I think it is a bit more complicated."
> >
> > Flow control:
> >   If "flow control" refers to the scheduling of bus transactions to
> >   process a task, then I agree it is done by the (target's) fetch
> >   agent.
> >
> >   If "flow control" refers to the presentation of the task requests
> >   (ORBs) and shared memory space then it is managed the initiator,
> >   since we're talking about one task request (ORB) referring to one
> >   "packet" transfer.
> >
> 
> Actually a single ORB can point to a data buffer which is larger than the
> maximumlegal 1394 packet transfer size.  Therefore multiple data packet
> transfers can be
> caused by one ORB.


Ah, another case of overloaded terms.  Yes, an ORB can refer to
a much larger data buffer than the maximum possible MTU of the bus.
This results in many MTU transfers per ORB.  Thanks for keeping me
honest and consistent.


I was using "packet" with respect to the transaction layer.
I was thinking of the case where a 10 MByte print job is consumed by
a device with 1 MByte of buffer space, and the flow of data into the
1 MByte buffer space must be controlled.  In this case I was thinking
that ORBs with 0.5 MByte to 1 MByte data blocks would be reasonable.


> Jack Hollins
> ASIC Architect
> Adaptec





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


From rturner at sharplabs.com  Thu Feb 19 17:48:51 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Early ping for april meeting
Message-ID: <199802192040.MAA13296@hpsdlgj1.sdd.hp.com>

The April meeting of the PWG will be in Portland, OR and is scheduled
for April 6-10. The meeting location is tentatively planned for the new
Embassy Suites Hotel in downtown. The conference rate will be $135.00
per night with a daily meeting room fee of about $35.00. I'm assuming
the daily meeting breakdown would be


Mon,Tues: PWG1394 WG   Weds/Thurs: PWG/IPP WG   Fri: Host MIB, UPD,
Other business


As an alternative meeting location, Sharp could host the meeting at our
site, which is about a 25-minute drive from downtown Portland. If Sharp
hosts the meeting, then there would be no meeting room fee, and we could
provide lunch on whatever days the group wanted. Including our normal
break snacks. You would of course be on your own for lodging. You could
either stay in downtown Portland and drive each day, or we have 3 or 4
hotels within 10 - 15 minute drive of the Sharp campus. One of the
hotels is new (The Heathman Lodge) and is really a nice place. Its about
10 or so minutes away.


What I am interested in knowing is who would be attending the meeting in
Portland, in general, and secondly, at which location you would prefer
to meet (Embassy Suites/downtown or Sharp). It doesn't really make much
difference to me either way, although it might be somewhat less
expensive for folks flying in to meet at Sharp. Also I would like to
know which meetings you would be attending and if you want to meet in
town, I would need to know if you would be staying at the hotel. 


Thanks!


Randy

From lstein at fapo.com  Thu Feb 19 17:58:12 1998
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Early ping for april meeting
In-Reply-To: <D10983CAC30DD111B41400805FA6A1C127233D@admsrvnt02.enet.sha>
Message-ID: <199802192300.PAA17650@barley.adnc.com>

Randy,


Thanks for setting this up.  I vote for meeting at Sharp.


Will be there for 1394PWG.


-Larry


At 2/19/98 02:48 PM , Turner, Randy wrote:
>
>The April meeting of the PWG will be in Portland, OR and is scheduled
>for April 6-10. The meeting location is tentatively planned for the new
>Embassy Suites Hotel in downtown. The conference rate will be $135.00
>per night with a daily meeting room fee of about $35.00. I'm assuming
>the daily meeting breakdown would be
>
>Mon,Tues: PWG1394 WG   Weds/Thurs: PWG/IPP WG   Fri: Host MIB, UPD,
>Other business
>
>As an alternative meeting location, Sharp could host the meeting at our
>site, which is about a 25-minute drive from downtown Portland. If Sharp
>hosts the meeting, then there would be no meeting room fee, and we could
>provide lunch on whatever days the group wanted. Including our normal
>break snacks. You would of course be on your own for lodging. You could
>either stay in downtown Portland and drive each day, or we have 3 or 4
>hotels within 10 - 15 minute drive of the Sharp campus. One of the
>hotels is new (The Heathman Lodge) and is really a nice place. Its about
>10 or so minutes away.
>
>What I am interested in knowing is who would be attending the meeting in
>Portland, in general, and secondly, at which location you would prefer
>to meet (Embassy Suites/downtown or Sharp). It doesn't really make much
>difference to me either way, although it might be somewhat less
>expensive for folks flying in to meet at Sharp. Also I would like to
>know which meetings you would be attending and if you want to meet in
>town, I would need to know if you would be staying at the hotel. 
>
>Thanks!
>
>Randy
> 
***************************************************************
Larry A. Stein			Phone: 	(619)292-2742
Warp Nine Engineering		Fax:	(619)292-8020
				Web: 	http://www.fapo.com
***************************************************************

From jhollins at eng.adaptec.com  Thu Feb 19 18:57:32 1998
From: jhollins at eng.adaptec.com (Jack Hollins x2309)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
In-Reply-To: <P1394> Print Protocols>
Message-ID: <199802192300.PAA17650@barley.adnc.com>

Greg Shue wrote:


> > > "Actually, I think it is a bit more complicated."
> > >
> > > Flow control:
> > >   If "flow control" refers to the scheduling of bus transactions to
> > >   process a task, then I agree it is done by the (target's) fetch
> > >   agent.
> > >
> > >   If "flow control" refers to the presentation of the task requests
> > >   (ORBs) and shared memory space then it is managed the initiator,
> > >   since we're talking about one task request (ORB) referring to one
> > >   "packet" transfer.
> > >
> >
> > Actually a single ORB can point to a data buffer which is larger than the
> > maximumlegal 1394 packet transfer size.  Therefore multiple data packet
> > transfers can be
> > caused by one ORB.
>
> Ah, another case of overloaded terms.  Yes, an ORB can refer to
> a much larger data buffer than the maximum possible MTU of the bus.
> This results in many MTU transfers per ORB.  Thanks for keeping me
> honest and consistent.
>
> I was using "packet" with respect to the transaction layer.
> I was thinking of the case where a 10 MByte print job is consumed by
> a device with 1 MByte of buffer space, and the flow of data into the
> 1 MByte buffer space must be controlled.  In this case I was thinking
> that ORBs with 0.5 MByte to 1 MByte data blocks would be reasonable.
>


Actually the initiator does not need to be aware of buffer limitations of the
targetin regards to the initiator sizing the data buffers associated with an
ORB.  A target
is under complete control of the consumption rate once an ORB has been put in
the
initiator's linked list (assuming linked lists are used) or if the ORB pointer
CSR is
written in the non-linked list case.  This allows  different target
architecture
performance/cost tradeoffs to be made without impacting an initiator.  A more
cost
sensitive target might have a smaller buffer space than a higher performance
target.


> > Jack Hollins
> > ASIC Architect
> > Adaptec
>
> --
> Greg Shue
> Hewlett-Packard Company
> Office Products Division                        gregs@sdd.hp.com
> ----------------------------------------------------------------


Jack Hollins
ASIC Architect
Adaptec

From gregs at sdd.hp.com  Thu Feb 19 19:57:18 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
In-Reply-To: <34ECC6EC.B1A0713C@eng.adaptec.com>
Message-ID: <199802200057.QAA14162@hpsdlgj1.sdd.hp.com>

Jack Hollins (Adaptec) wrote:
> 
> Greg Shue wrote:
> 
> > > > "Actually, I think it is a bit more complicated."
> > > >
> > > > Flow control:
> > > >   If "flow control" refers to the scheduling of bus transactions to
> > > >   process a task, then I agree it is done by the (target's) fetch
> > > >   agent.
> > > >
> > > >   If "flow control" refers to the presentation of the task requests
> > > >   (ORBs) and shared memory space then it is managed the initiator,
> > > >   since we're talking about one task request (ORB) referring to one
> > > >   "packet" transfer.
> > > >
> > >
> > > Actually a single ORB can point to a data buffer which is larger than the
> > > maximumlegal 1394 packet transfer size.  Therefore multiple data packet
> > > transfers can be
> > > caused by one ORB.
> >
> > Ah, another case of overloaded terms.  Yes, an ORB can refer to
> > a much larger data buffer than the maximum possible MTU of the bus.
> > This results in many MTU transfers per ORB.  Thanks for keeping me
> > honest and consistent.
> >
> > I was using "packet" with respect to the transaction layer.
> > I was thinking of the case where a 10 MByte print job is consumed by
> > a device with 1 MByte of buffer space, and the flow of data into the
> > 1 MByte buffer space must be controlled.  In this case I was thinking
> > that ORBs with 0.5 MByte to 1 MByte data blocks would be reasonable.
> >
> 
> Actually the initiator does not need to be aware of buffer limitations of the
> targetin regards to the initiator sizing the data buffers associated with an
> ORB.  A target
> is under complete control of the consumption rate once an ORB has been put in
> the
> initiator's linked list (assuming linked lists are used) or if the ORB pointer
> CSR is
> written in the non-linked list case.  This allows  different target
> architecture
> performance/cost tradeoffs to be made without impacting an initiator.  A more
> cost
> sensitive target might have a smaller buffer space than a higher performance
> target.


This is true if the tasks being processed by the target are
idempotent.  (In other words, that they may be executed one or
more times and end up with exactly the same result.)  This
feature is needed to support the following situation:


  - a task to be partially processed
  - a Bus Reset to occur (which implicitly aborts the task)
  - the task requeued on the list
  - the task completely restarted
  
I think this is an inheirent attribute of mass storage commands.
Unfortunately, printers are not.


Sending a set of commands which are larger than the printer can
buffer forces the printer to process some commands before they
are all received.  If a Bus Reset occurs, then either the printer
must validate that the same ORB was requeued and try to resume
from the last valid offset fetched, OR the protocol can guarantee
that the ORB's data block has been completely transferred before
the data is processed.  The first case is difficult at best, the
second is easy and provides idempotency at the cost of
negotiating the maximum sizes of the data blocks referenced by
the ORBs.


So, it's easier for the initiator to be aware of the transport
packet sizes supportable by the target than it is to work around
the Bus Reset problem by another mechanism.  If you have a better
suggestion, I'll certainly consider it.


"Need" is relative to the context.  In this thread, we're talking
about using SBP-2 for printing services.





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


From ewa at apple.com  Fri Feb 20 00:11:20 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
In-Reply-To: <P1394> Print Protocols>
Message-ID: <B11257BA-50AF2@17.219.106.5>

As part of a truly native SBP-2 printer profile, I would expect
to include a sequence number or something in the ORB command,
so that a target can be sure not to execute the same command
twice.  I would also allow a target to abort at any point it
likes and communicate this to the initiator.  For example, 
"I ran out of paper between commands 4 and 5 in ORB 1129
and I flushed further execution.  Tell me what to do now.".


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.      408-974-8187
--------------------------------------


Greg wrote:
> This is true if the tasks being processed by the target are
> idempotent.  (In other words, that they may be executed one or
> more times and end up with exactly the same result.)  This
> feature is needed to support the following situation:
> 
>   - a task to be partially processed
>   - a Bus Reset to occur (which implicitly aborts the task)
>   - the task requeued on the list
>   - the task completely restarted
>   
> I think this is an inheirent attribute of mass storage commands.
> Unfortunately, printers are not.
> 
> Sending a set of commands which are larger than the printer can
> buffer forces the printer to process some commands before they
> are all received.  If a Bus Reset occurs, then either the printer
> must validate that the same ORB was requeued and try to resume
> from the last valid offset fetched, OR the protocol can guarantee
> that the ORB's data block has been completely transferred before
> the data is processed.  The first case is difficult at best, the
> second is easy and provides idempotency at the cost of
> negotiating the maximum sizes of the data blocks referenced by
> the ORBs.
> 
> So, it's easier for the initiator to be aware of the transport
> packet sizes supportable by the target than it is to work around
> the Bus Reset problem by another mechanism.  If you have a better
> suggestion, I'll certainly consider it.
> 
> "Need" is relative to the context.  In this thread, we're talking
> about using SBP-2 for printing services.

From Daniel.Meirsman at LEU.CE.philips.com  Fri Feb 20 04:11:09 1998
From: Daniel.Meirsman at LEU.CE.philips.com (Daniel.Meirsman@LEU.CE.philips.com)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Re[2]: p1212r Austin mtg
Message-ID: <B11257BA-50AF2@17.219.106.5>

I would certainly attend if the meeting is held.


I do not have any directions as to where this meeting will be held, exp=
ect
that is to be somewhere in Austin on March 4th.


Daniel


Daniel.Meirsman@LEU.CE.philips.com
Philips ITCL




______________________________ Reply Separator ________________________=
_________
Subject: RE: p1212r Austin mtg
Author:  p1212r@mail.zayante.com at #SMTP
Date:    19/2/98 18:53




1394 PWG members,


David James of the 1212 reaffirmation effort is trying to decide if the=
y
should hold a 1212 meeting in Austin the day after our March meeting.  =
I
would like the opportunity to attend and participate.  If you share tha=
t
desire, I suggest you send a message to David and the 1212 reflector
(p1212r@mail.zayante.com).  I have attached David's message below.


Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=


Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com=


Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=




>Dear all,
>
>Just returned from Japan, to find that Ats will most likely not be
>the scheduled March meeting, which is unfortunate in several ways.
>However, I have heard (John Fuller) that it might still be useful
>talking with other members of the PWG.
>
>For me, the March 2-3 meeting isn't convenient, but is possible.
>However, I would hate to go to Texas and find no-one else.
>It's now also past the 2-weeks notice time, so we would have to
>save official voting for the following meeting in Tokyo.
>
>So far, I have heard from John Fuller who recommends that the
>meeting should still be held and is likely to be useful.
>I would like to sollicit suggestions from others, who might
>be thinking of attending, before making a go/no-go decision
>on this Friday.
>
>Please send your comments to myself as well as the reflector.
>
>David V. James
>
>
>******************************************************************
>* Dr. David V. James            * Tel: (408) 955-6295            *
>* Sony Research Laboratories    * Fax: (408) 955-5180            *
>* LSI Systems Laboratory        * email: jamesd@lsi.sel.sony.com *
>* 3300 Zanker Road, M/S SJ-3D3  *        dvj@ibm.net (home)      *
>* San Jose, CA 95134            *                                *
>******************************************************************
>
>
>[ To receive daily digests of this list send the one line message: ]
>[     "subscribe digest p1212r" to requests@zayante.com            ]
>[ To stop receiving messages send the one line message:            ]
>[     "unsubscribe p1212r" to requests@zayante.com                 ]
>
>




[ To receive daily digests of this list send the one line message: ]
[     "subscribe digest p1212r" to requests@zayante.com            ]
[ To stop receiving messages send the one line message:            ]
[     "unsubscribe p1212r" to requests@zayante.com                 ]
=

From carterk at us.ibm.com  Fri Feb 20 09:24:55 1998
From: carterk at us.ibm.com (Keith Carter)
Date: Wed May  6 14:00:49 2009
Subject: P1394> IPP> UPD meeting
Message-ID: <B11257BA-50AF2@17.219.106.5>

>I have one of our printer driver guys that wants to come JUST for the
>discussion on UPD. But I really need to able to tell him a firm agenda
>for this meeting in Austin. Is there a final decision on when the UPD
>meeting will be held?
>
>Thanx
>
>R.


Ok, here's a stake in the lake.  The UPD meeting will be 7:00PM-10:00PM CST on
Tuesday, March 3.  The meeting is in the Texas 5 meeting room.  For directions
to the room,
look at the meeting board in the lobby or ask the hotel desk.  I am recruiting
a chair for the
meeting who can then drive the agenda.  I understand Paul Moore of Microsoft
will discuss
their Universal Print Driver at this meeting.


Is there a UPD mailing list?


Have a super day,


Keith Carter
Senior Software Engineer
IBM Network Computing Software Division in Austin, Texas
internet email: carterk@us.ibm.com
Notes email: Keith Carter/Austin/IBM@IBMUS
phone: 512-838-2155
tie-line: 678-2155
fax: 512-838-0169

From jds at underscore.com  Fri Feb 20 09:52:16 1998
From: jds at underscore.com (Jeffrey D. Schnitzer)
Date: Wed May  6 14:00:49 2009
Subject: P1394> UPD mailing list (was IPP> UPD meeting)
Message-ID: <B11257BA-50AF2@17.219.106.5>

Keith Carter asked:
> 
> Is there a UPD mailing list?
> 


The UPD mailing list is <upd.pwg.org>.  To add yourself to the list,
send mail to <majordomo@pwg.org> with the following as the body of
the message:


subscribe upd
end




The list has been in place since May'97, but there was little
traffic on it.  It's hypermail archive is at:


	http://www.pwg.org/hypermail/upd




/Jeff
 
---------------------------------------------------------------
Jeffrey D. Schnitzer      |   Email:  jds@underscore.com 
Underscore, Inc.          |   Voice:  (603) 889-7000
41-C Sagamore Park Rd     |     Fax:  (603) 889-2699   
Hudson, NH  03051-4915    |     Web:  http://www.underscore.com
---------------------------------------------------------------

From carterk at us.ibm.com  Fri Feb 20 09:51:32 1998
From: carterk at us.ibm.com (Keith Carter)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Meeting room information for PWG meeting in Austin on 3/2-6
Message-ID: <B11257BA-50AF2@17.219.106.5>

Print gurus,


The meeting room charge is $30 per person per day.  When you check in at the
Hyatt hotel, please inform the hotel person that you are with the "IBM Printer
Working Group" and ask for the form to specify meeting room charges.  Specify
your total charges for the week (number of meeting days you will attend x $30)
on the form, sign it, and return it to the hotel person.  This charge will then
be added to your hotel bill.


For those who are not staying at the hotel, the chair of each PWG meeting will
ask you to complete the form and return it to them with a check payable to the
"Hyatt".


There will be no charge for the UPD meeting on the evening of March 3 since we
are using the same room as the 1394 working group.


The meeting rooms by day are as follows:


March 2-5   Texas 5
March 6       Foothills 1


Directions to these rooms should be on the meeting board in the lobby under
"IBM Printer Working Group" or ask the hotel desk.


Have a super day,


Keith Carter
Senior Software Engineer
IBM Network Computing Software Division in Austin, Texas
internet email: carterk@us.ibm.com
Notes email: Keith Carter/Austin/IBM@IBMUS
phone: 512-838-2155
tie-line: 678-2155
fax: 512-838-0169

From gregs at sdd.hp.com  Fri Feb 20 13:07:02 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Native SBP-2 Printer Profile?
In-Reply-To: <B11257BA-50AF2@17.219.106.5>
Message-ID: <199802201807.KAA17651@hpsdlgj1.sdd.hp.com>

Interresting thoughts, though the PWG is not trying to create
a truly native SBP-2 printer profile.  As I think about it, I
don't know of _anyone_ that is.


Your thoughts imply that:


  - a truly native SBP-2 printer profile has a standard "printer"
    device model with standardized status info.


  - the printer is being driven by an intelligent agent which is
    aware of command boundaries.  So it's either driven directly
    by the printer driver, or by a command-set-intelligent spooler.




By the way, I don't want my printer to throw away the rest of
the data when it runs out of paper.  I want it to tell me it's
out of paper, wait for me to put paper in, and then continue
printing.  :-)


> As part of a truly native SBP-2 printer profile, I would expect
> to include a sequence number or something in the ORB command,
> so that a target can be sure not to execute the same command
> twice.  I would also allow a target to abort at any point it
> likes and communicate this to the initiator.  For example, 
> "I ran out of paper between commands 4 and 5 in ORB 1129
> and I flushed further execution.  Tell me what to do now.".
> 
> --------------------------------------
> Eric Anderson            ewa@apple.com
> Apple Computer, Inc.      408-974-8187
> --------------------------------------





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


From bogus@does.not.exist.com  Fri Feb 20 13:26:39 1998
From: bogus@does.not.exist.com ()
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
In-Reply-To: <199802191944.LAA13255@hpsdlgj1.sdd.hp.com>
Message-ID: <v04003a00b1137b44c9c8@[192.168.1.25]>

Very good wording ...


At 11:44 AM -0800 2/19/98, Greg Shue wrote:
>  Devices which cannot provide timely scheduling of 1394 transactions
>  should not be driving fetch agents?




===========================================================================
Michael D. Johas Teener, Chief Technical Officer & Chairman of the Board
Zayante, Inc., 269 Mt. Hermon Rd. #111, Scotts Valley, CA 95066-4000, USA
email: mike@zayante.com    voice: +1-408-461-4901   fax: +1-408-461-1394
======================== http://www.zayante.com ===========================

From ewa at apple.com  Fri Feb 20 14:38:15 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Re: Native SBP-2 Printer Profile?
In-Reply-To: <Native SBP-2 Printer Profile?>
Message-ID: <B1131BA9-34A9C@17.219.104.119>

I don't believe the entire printer model has to be standardized,
we just need a way to communicate basic operational steps, such
as start a job, report status, report errors, etc.  Within such
a framework, and number of formats, protocols, etc, are possible.


If after running out of paper you'd like to load more and continue,
you can just requeue the same ORB and let the printer pick up from
where it left off.  (I would design the native printer profile so
that the printer can remember where it was in that ORB, and not
execute the same parts twice.)  My statement shouldn't be read to
imply that any error causes a total shutdown - just that the
printer will wait for further instructions.


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.      408-974-8187
--------------------------------------


> Interresting thoughts, though the PWG is not trying to create
> a truly native SBP-2 printer profile.  As I think about it, I
> don't know of _anyone_ that is.
> 
> Your thoughts imply that:
> 
>   - a truly native SBP-2 printer profile has a standard "printer"
>     device model with standardized status info.
> 
>   - the printer is being driven by an intelligent agent which is
>     aware of command boundaries.  So it's either driven directly
>     by the printer driver, or by a command-set-intelligent spooler.
> 
> 
> By the way, I don't want my printer to throw away the rest of
> the data when it runs out of paper.  I want it to tell me it's
> out of paper, wait for me to put paper in, and then continue
> printing.  :-)
> 
> > As part of a truly native SBP-2 printer profile, I would expect
> > to include a sequence number or something in the ORB command,
> > so that a target can be sure not to execute the same command
> > twice.  I would also allow a target to abort at any point it
> > likes and communicate this to the initiator.  For example, 
> > "I ran out of paper between commands 4 and 5 in ORB 1129
> > and I flushed further execution.  Tell me what to do now.".
> > 
> > --------------------------------------
> > Eric Anderson            ewa@apple.com
> > Apple Computer, Inc.      408-974-8187
> > --------------------------------------
> 
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> Office Products Division			gregs@sdd.hp.com
> ----------------------------------------------------------------

From gregs at sdd.hp.com  Fri Feb 20 15:15:40 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Re: Native SBP-2 Printer Profile?
In-Reply-To: <B1131BA9-34A9C@17.219.104.119>
Message-ID: <199802202015.MAA18197@hpsdlgj1.sdd.hp.com>

> 
> I don't believe the entire printer model has to be standardized,
> we just need a way to communicate basic operational steps, such
> as start a job, report status, report errors, etc.  Within such
> a framework, and number of formats, protocols, etc, are possible.


Agreed.  The PWG has already agreed (?) that a print job is
a separate data path than device status.  No one has raised
the topic of reporting formatting errors.  I don't know if
it's a general issue or not.


> If after running out of paper you'd like to load more and continue,
> you can just requeue the same ORB and let the printer pick up from
> where it left off.  (I would design the native printer profile so
> that the printer can remember where it was in that ORB, and not
> execute the same parts twice.)  My statement shouldn't be read to
> imply that any error causes a total shutdown - just that the
> printer will wait for further instructions.
> 
> --------------------------------------
> Eric Anderson            ewa@apple.com
> Apple Computer, Inc.      408-974-8187
> --------------------------------------


I was trying to avoid the printer having to verify that the
same ORB was requeued and remembering the offset into it. I've
always had the impression that it would be more problematic
than breaking the data up into transport-level blocks.  Perhaps
you can convince me otherwise.  Would you try?



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


From jhollins at eng.adaptec.com  Fri Feb 20 18:56:51 1998
From: jhollins at eng.adaptec.com (Jack Hollins x2309)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Print Protocols
In-Reply-To: <P1394> Print Protocols>
Message-ID: <199802202015.MAA18197@hpsdlgj1.sdd.hp.com>

See embedded comments


Eric Anderson wrote:


> As part of a truly native SBP-2 printer profile, I would expect
> to include a sequence number or something in the ORB command,
> so that a target can be sure not to execute the same command
> twice.  I would also allow a target to abort at any point it
> likes and communicate this to the initiator.  For example,
> "I ran out of paper between commands 4 and 5 in ORB 1129
> and I flushed further execution.  Tell me what to do now.".
>


Since I think we are talking about SBP-2, I will expand on the above
statement tohave meant the following.  'I ran out of paper after
completing command 4 in ORB 1129
and I flushed further execution.  Tell me what to do now.'


I wanted to clarify that your original statement did not imply that
there could be
multiple commands per ORB.  This in not allowed in SBP-2 (section
5.1.2).


In fact I believe the appropriate sequence would be the return of good
completion
status for ORB 1129, detection of the out of paper condition,
unsolicited status
transfer from target to initiator indicating the out of paper condition.








> --------------------------------------
> Eric Anderson            ewa@apple.com
> Apple Computer, Inc.      408-974-8187
> --------------------------------------
>
> Greg wrote:
> > This is true if the tasks being processed by the target are
> > idempotent.  (In other words, that they may be executed one or
> > more times and end up with exactly the same result.)  This
> > feature is needed to support the following situation:
> >
> >   - a task to be partially processed
> >   - a Bus Reset to occur (which implicitly aborts the task)
> >   - the task requeued on the list
> >   - the task completely restarted
> >
> > I think this is an inheirent attribute of mass storage commands.
> > Unfortunately, printers are not.
> >
> > Sending a set of commands which are larger than the printer can
> > buffer forces the printer to process some commands before they
> > are all received.  If a Bus Reset occurs, then either the printer
> > must validate that the same ORB was requeued and try to resume
> > from the last valid offset fetched, OR the protocol can guarantee
> > that the ORB's data block has been completely transferred before
> > the data is processed.  The first case is difficult at best, the
> > second is easy and provides idempotency at the cost of
> > negotiating the maximum sizes of the data blocks referenced by
> > the ORBs.
> >


The printer fetches the ORBs from the initiator.  The printer is aware
of its
buffer limitations and I assume (maybe incorrectly) that it should take
its buffer
limitations in to account when determining when to fetch the next ORB.


If a bus reset occurs, the printer will clear any pending tasks and
transition to the
reset state.  The initiator knows exactly which ORBs in the task set
were executed
based on the return of completion status.  Therefore it should be clear
to the
initiator what ORB address to use in a write to the ORB fetch pointer
CSR to continue
execution of the task set after the fetch agent is initialized.


> > So, it's easier for the initiator to be aware of the transport
> > packet sizes supportable by the target than it is to work around
> > the Bus Reset problem by another mechanism.  If you have a better
> > suggestion, I'll certainly consider it.
> >
> > "Need" is relative to the context.  In this thread, we're talking
> > about using SBP-2 for printing services.

From gregs at sdd.hp.com  Fri Feb 20 19:46:07 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:49 2009
Subject: P1394> SBP-2 vs. DPP 0.71 Cheat Sheet (?)
Message-ID: <199802210046.QAA19482@hpsdlgj1.sdd.hp.com>

Hi all,


The more I look at DPP 0.71, the more similar it looks
to SBP-2.  So, I put together a concept "cheat sheet"
to see how the two really compared.  I thought you
might be interrested, so here it is...  What do you think?


- Greg Shue


===============================
SBP-2 vs. DPP v0.71 Cheat Sheet
===============================


There are many similar concepts between SBP-2 and DPP v0.71 which
may not be well understood.  The main difference between the
protocols revolves around the a/symmetry of the protocol stacks.
This "cheat sheet" is intended on laying the groundwork for a
direct comparison of the protocol stacks.




SBP-2 Model of Use for Comparison
---------------------------------
In order to get a reasonable comparison of the protocols, then
a Command Set and Model-of-use must be outlined for SBP-2.  Many
of the details can be left out of the outline as long as the
essence of the profile is maintained.


Model of Use
------------


  - cross-logins are established between the two devices.
      (This avoids a merged target/initiator driver)


  - each device provides a fetch engine and a task list.


  - each task list contains commands to transfer data in one direction
      (we'll choose it such that only WRITE transactions occur for
       moving the ORB data block)


  - each ORB allows one "data unit" to be processed.


Command Set Provides For
------------------------
  - cross-login information
  - negotiated max data block size per task per direction.
  - indicating byte-size of completed packet
  - carrying of Command IDs in CDB  (2 bytes)
  - carry "SDU segmentation number" in CDB  (4 bytes)
  - carry "SDU end of segment flag" in CDB  (1 bit)
  - carry routing info in CDB  (2 byte Dest PID, 2 bytes Src PID)




Cheat Sheet
===========


    CSR structures       Thin Protocol           SBP-2
    -----------------------------------------------------------------------
    Access Control i/f   Connection Reg          Mgmt Agent Reg


    Response Space       SDU Response Space      Fetch Agent Regs


    Completion status    SDU Control Space       Status FIFO


    Transfer block       SDU Register            data block referenced by ORB




    Functional layers    Thin Protocol           SBP-2
    -----------------------------------------------------------------------
    Connection mgmt      Thin Session            Management Agent


    Data Transfer eng    Thin Transaction        Fetch Agent




    Session Mgmt         Thin Protocol           SBP-2
    -----------------------------------------------------------------------
    Access Request       S_Connect               login


    Reconnect            T_Reconnect             reconnect


    Execute App Cmd      S_Command               ORB exists on task list


    Access Release       S_Disconnect            logout


    Error Notification   <none>                  Mgmt-ORB specified Status FIFO
						   completion notification




    Data Transfer        Thin Protocol           SBP-2
    -----------------------------------------------------------------------
    Transfer Space       SDUAck                  ORB exists on task list
      Available          (write implies avail)   (existance implies available)


    Transfer completion  SDUComp                 Notification write to
      notification                                 Status FIFO


    Transfer Abort from  SDUStop                 Abort Task (Set)
     data receiver


    Transfer Abort from  SDUStop                 Notification write to implicit
     data sender                                   Status FIFO - Abort


    Error Notification   T_error                 Notification write to implicit
						   Status FIFO - error ind.




Feature Comparison
==================


Feature                  Thin Protocol           SBP-2
-----------------------------------------------------------------------
Each node can send/rcv   Yes                     Yes
  data


Dynamically allocates    Yes                     Yes
  CSR Reg space when
  estab. connect


Selectable Transfer      Yes                     Yes, requires Create Stream
  Mode                                             request and separate
                                                   task list


Symmetric Structure      Yes                     Yes


Negotiated Data Unit     Yes                     Yes
  size independently
  per direction


Isochronous Support      Yes                     Yes


Multiple Cmd Support     Yes                     Yes


Bidirectional Cmds       Yes                     Yes


Multiple Independent     Unspecified (possible   Yes, via Multiple LUNs &
 Connection Support      w/ multiple UNIT Dirs)    multiple UNITS


Session segmentation     Yes                     Yes, in CDB
  support




Distinctive differences:


Feature                  Thin Protocol           SBP-2 w/ proposed profile
-----------------------------------------------------------------------
Reconnect Support        2 sec window;           1 sec window, proposal made
                         either end may          for programmable extension;
                         establish               both ends must reestablish


SDU Available            SDU Ack timeout exists  None (?)
  timeout                Does this imply a real-
                         time processing req. on
                         whatever data is sent
                         in an SDU?


Connection Process       2 block writes          6 block writes (probably)
                                                   (2 logins @ 2 per login,
                                                    2 for negotiated params)


Shared memory buffer     Fixed location during   Relocatable, partitionable
                         connection


Data Transfer            more efficient for      More flexible and standardized
                         data < MTU size


   data < MTU size       SDUAck +                WR Agent Reset + WR ORB ptr +
                         SDUComp +               ORB prefetch + data xfer +
                         SDUAck                  Completion Notify
                            (3 transactions vs. 5 transactions)


   MTU size << data <    SDUSend +               WR Agent Reset + WR ORB ptr +
   SDU size              SDUComp +               ORB prefetch + page table +
                                                 data xfer +
                         SDUAck                  Completion Notify
                            (SBP-2 costs 3 extra transactions,
                             but a small overhead



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


From fumiona at venus.dti.ne.jp  Sun Feb 22 09:37:21 1998
From: fumiona at venus.dti.ne.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Re: PWG> Early ping for april meeting
In-Reply-To: <D10983CAC30DD111B41400805FA6A1C127233D@admsrvnt02.enet.sharplabs.com>
Message-ID: <199802221437.XAA04248@smtp.dtinet.or.jp>

Dear Randy


I am going to attend the April meeting, and prefer
Embassy Suites/downtown.
-----
Fumio Nagasaka
EPSON Software Development Laboratory Inc.,
TEL: +81 268 25-4111 // FAX: +81 268 25-4627
HomePage = http://www.venus.dti.ne.jp/~fumiona/

From rturner at sharplabs.com  Sun Feb 22 22:23:37 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Upcoming teleconference call for 1394 discussion
Message-ID: <199802221437.XAA04248@smtp.dtinet.or.jp>

I will be emailing he telephone number for calling in on the 1394PWG
teleconference by 9:00 AM PST on Monday morning. I will email this list
with the information. Sorry for the short notice...


Randy




	-----Original Message-----
	From:	Akihiro Shimura [SMTP:shimura@pure.cpdc.canon.co.jp]
	Sent:	Sunday, February 22, 1998 6:21 PM
	To:	Turner, Randy
	Cc:	Shigeru Ueda; Takashi Isoda
	Subject:	Re: P1394> Upcoming teleconference call for 1394
discussion


	Hello,


	The time and date is ok for me.
	I would like to join this conference.
	Could you tell me a phone number?


	Thanks,


	Akihiro Shimura


	On Wed, 18 Feb 1998 14:50:42 -0800
	"Turner, Randy" <rturner@sharplabs.com> wrote:


	> 
	> I am tentatively setting up a teleconference to continue
discussion on
	> 1394 transports for Monday, 2/23 at 4:00 PM PST. The duration
of the
	> call will be 90 minutes. Let me know if this time and date is
ok.
	> 
	> Randy
	> 
	> 


	--
	 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
	 Office Imaging Products Development Center 3
	 CANON INC.

From ueda at slab.tnr.sharp.co.jp  Mon Feb 23 20:08:16 1998
From: ueda at slab.tnr.sharp.co.jp (Toru Ueda)
Date: Wed May  6 14:00:49 2009
Subject: P1394> SBP-2 vs. DPP 0.71 Cheat Sheet (?)
In-Reply-To: <199802210046.QAA19482@hpsdlgj1.sdd.hp.com>
Message-ID: <9802231108.AA08020@slab.slab.tnr.sharp.co.jp>

Greg,


Thank you for your effort to make the comparison table.


I agree that DPP has similar functions with SBP2 if you use two SBP2s
with cross-logins.
I guess the reason you need two SBP2s for single print task and DPP
needs only one comes from the differences of the models.
Because SBP2 is host-target model, you needs two logins for one peer to
peer connection.


I don't say DPP is more suitable to any tasks or any printing tasks. I
just want to say DPP is being defined for Peer to Peer printing.


Also I prefer one application uses only one session. Of course some task
requires more than one session but at least for very simple print task
or file transfer task, I prefer small number of sessions.


model 1)
---------------
|  Application  |   This is better for consumer products than model 2.
----------------
| One Protocol  |
| or One session|
----------------


model 2)
------------------
| Application     |
------------------
| more protocols  |
| or more sessions|
------------------


Again I don't want compete with SBP2. SBP2 has more functions like ORB and natural flow control.


We are developing DPP and THIN protocol. The biggest priority for THIN
protocol is  the size and simplicity. I cannot explain the reason we
need two logins for simple print task to our product engineers. Also I
cannot explain the reason we need 20 or 30KB for print protocol, while
the file transfer protocol using IR(Infra-Red) communication (called Ir
TranP) needs only several Kilo bytes.


Toru Ueda
Sharp Corp.
Software Labs.




On Fri, 20 Feb 1998 16:46:07 -0800 (PST)
Greg Shue <gregs@sdd.hp.com> wrote:


> 
> Hi all,
> 
> The more I look at DPP 0.71, the more similar it looks
> to SBP-2.  So, I put together a concept "cheat sheet"
> to see how the two really compared.  I thought you
> might be interrested, so here it is...  What do you think?
> 
> - Greg Shue
> 
> ===============================
> SBP-2 vs. DPP v0.71 Cheat Sheet
> ===============================
> 
> There are many similar concepts between SBP-2 and DPP v0.71 which
> may not be well understood.  The main difference between the
> protocols revolves around the a/symmetry of the protocol stacks.
> This "cheat sheet" is intended on laying the groundwork for a
> direct comparison of the protocol stacks.
> 
> 
> SBP-2 Model of Use for Comparison
> ---------------------------------
> In order to get a reasonable comparison of the protocols, then
> a Command Set and Model-of-use must be outlined for SBP-2.  Many
> of the details can be left out of the outline as long as the
> essence of the profile is maintained.
> 
> Model of Use
> ------------
> 
>   - cross-logins are established between the two devices.
>       (This avoids a merged target/initiator driver)
> 
>   - each device provides a fetch engine and a task list.
> 
>   - each task list contains commands to transfer data in one direction
>       (we'll choose it such that only WRITE transactions occur for
>        moving the ORB data block)
> 
>   - each ORB allows one "data unit" to be processed.
> 
> Command Set Provides For
> ------------------------
>   - cross-login information
>   - negotiated max data block size per task per direction.
>   - indicating byte-size of completed packet
>   - carrying of Command IDs in CDB  (2 bytes)
>   - carry "SDU segmentation number" in CDB  (4 bytes)
>   - carry "SDU end of segment flag" in CDB  (1 bit)
>   - carry routing info in CDB  (2 byte Dest PID, 2 bytes Src PID)
> 
> 
> Cheat Sheet
> ===========
> 
>     CSR structures       Thin Protocol           SBP-2
>     -----------------------------------------------------------------------
>     Access Control i/f   Connection Reg          Mgmt Agent Reg
> 
>     Response Space       SDU Response Space      Fetch Agent Regs
> 
>     Completion status    SDU Control Space       Status FIFO
> 
>     Transfer block       SDU Register            data block referenced by ORB
> 
> 
>     Functional layers    Thin Protocol           SBP-2
>     -----------------------------------------------------------------------
>     Connection mgmt      Thin Session            Management Agent
> 
>     Data Transfer eng    Thin Transaction        Fetch Agent
> 
> 
>     Session Mgmt         Thin Protocol           SBP-2
>     -----------------------------------------------------------------------
>     Access Request       S_Connect               login
> 
>     Reconnect            T_Reconnect             reconnect
> 
>     Execute App Cmd      S_Command               ORB exists on task list
> 
>     Access Release       S_Disconnect            logout
> 
>     Error Notification   <none>                  Mgmt-ORB specified Status FIFO
> 						   completion notification
> 
> 
>     Data Transfer        Thin Protocol           SBP-2
>     -----------------------------------------------------------------------
>     Transfer Space       SDUAck                  ORB exists on task list
>       Available          (write implies avail)   (existance implies available)
> 
>     Transfer completion  SDUComp                 Notification write to
>       notification                                 Status FIFO
> 
>     Transfer Abort from  SDUStop                 Abort Task (Set)
>      data receiver
> 
>     Transfer Abort from  SDUStop                 Notification write to implicit
>      data sender                                   Status FIFO - Abort
> 
>     Error Notification   T_error                 Notification write to implicit
> 						   Status FIFO - error ind.
> 
> 
> Feature Comparison
> ==================
> 
> Feature                  Thin Protocol           SBP-2
> -----------------------------------------------------------------------
> Each node can send/rcv   Yes                     Yes
>   data
> 
> Dynamically allocates    Yes                     Yes
>   CSR Reg space when
>   estab. connect
> 
> Selectable Transfer      Yes                     Yes, requires Create Stream
>   Mode                                             request and separate
>                                                    task list
> 
> Symmetric Structure      Yes                     Yes
> 
> Negotiated Data Unit     Yes                     Yes
>   size independently
>   per direction
> 
> Isochronous Support      Yes                     Yes
> 
> Multiple Cmd Support     Yes                     Yes
> 
> Bidirectional Cmds       Yes                     Yes
> 
> Multiple Independent     Unspecified (possible   Yes, via Multiple LUNs &
>  Connection Support      w/ multiple UNIT Dirs)    multiple UNITS
> 
> Session segmentation     Yes                     Yes, in CDB
>   support
> 
> 
> Distinctive differences:
> 
> Feature                  Thin Protocol           SBP-2 w/ proposed profile
> -----------------------------------------------------------------------
> Reconnect Support        2 sec window;           1 sec window, proposal made
>                          either end may          for programmable extension;
>                          establish               both ends must reestablish
> 
> SDU Available            SDU Ack timeout exists  None (?)
>   timeout                Does this imply a real-
>                          time processing req. on
>                          whatever data is sent
>                          in an SDU?
> 
> Connection Process       2 block writes          6 block writes (probably)
>                                                    (2 logins @ 2 per login,
>                                                     2 for negotiated params)
> 
> Shared memory buffer     Fixed location during   Relocatable, partitionable
>                          connection
> 
> Data Transfer            more efficient for      More flexible and standardized
>                          data < MTU size
> 
>    data < MTU size       SDUAck +                WR Agent Reset + WR ORB ptr +
>                          SDUComp +               ORB prefetch + data xfer +
>                          SDUAck                  Completion Notify
>                             (3 transactions vs. 5 transactions)
> 
>    MTU size << data <    SDUSend +               WR Agent Reset + WR ORB ptr +
>    SDU size              SDUComp +               ORB prefetch + page table +
>                                                  data xfer +
>                          SDUAck                  Completion Notify
>                             (SBP-2 costs 3 extra transactions,
>                              but a small overhead
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> Office Products Division			gregs@sdd.hp.com
> ----------------------------------------------------------------
> 

From hirata at vip.iwa.fujixerox.co.jp  Mon Feb 23 06:59:07 1998
From: hirata at vip.iwa.fujixerox.co.jp (Kazuhiro HiRATA)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Re: SBP-2 vs. DPP 0.71 Cheat Sheet (?)
In-Reply-To: <SBP-2 vs. DPP 0.71 Cheat Sheet (?)>
Message-ID: <199802231158.UAA08825@goudy.vip.iwa.fujixerox.co.jp>

Hi Greg,


[You wrote]
>What do you think?


I have question that which is your prefer to use for PC Printing.  So 
far, I thought you recommend to use SBP-2 for PC Printing.  However, I 
could not distinguish advantage to use SBP-2 for PC Printing in your 
comparison chart.


I feel that you are going to love THIN stack for PC Printing for keeping 
consistency with Peer-to-Peer devices.  Who does want to be fat for same 
function?


//HiRATA@Feb.23'98

From atsnaka at mxa.mesh.ne.jp  Mon Feb 23 10:13:51 1998
From: atsnaka at mxa.mesh.ne.jp (Atsushi Nakamura)
Date: Wed May  6 14:00:49 2009
Subject: P1394> SBP-2 vs. DPP 0.71 Cheat Sheet (?)
Message-ID: <199802231158.UAA08825@goudy.vip.iwa.fujixerox.co.jp>

Greg, and all


Though I think this is good effort,
my impression of the list is that it doesn't
look too different from the requirement list
we have been discussing for the past several months.


I think ANY (good) transport protocol would support
most of the items listed in the cheat sheet section one way
or another, thus look alike if you compare it this way.
SBP-2 and Thin are both good transports because they
both support the list of requirements !
I don't think one is better, or worse than the other.


I think it is HOW each protocol supports an item
that make the difference, not WHAT they support.


This relates to the thinking behind the development of each
protocol and the intended applications or solutions.
If each one(SBP-2, thin) has their benifits, and people see the
benifits, (which I think is the situation now )
we don't necessarily HAVE TO decide the ONLY one just now.


( After all, the thin transport is only  a few kilo-bytes....
  No big deal to add a few more KB to 30(?)KB of SBP-2 ? (^^;)
  Just joking ! )


Ats,


-------------------------------------------------------
Ats Nakamura
BJ Printing Technology Development 22
Canon Inc.


-----Original Message-----
�·�o�l : Greg Shue <gregs@sdd.hp.com>
ˆ¶�æ : gregs@sdd.hp.com <gregs@sdd.hp.com>
CC : p1394@pwg.org <p1394@pwg.org>; pp1394@cpdc.canon.co.jp
<pp1394@cpdc.canon.co.jp>
“úŽž : 1998”N2ŒŽ21“ú 9:49
Œ�–¼ : P1394> SBP-2 vs. DPP 0.71 Cheat Sheet (?)




>
>Hi all,
>
>The more I look at DPP 0.71, the more similar it looks
>to SBP-2.  So, I put together a concept "cheat sheet"
>to see how the two really compared.  I thought you
>might be interrested, so here it is...  What do you think?
>
>- Greg Shue
>
>===============================
>SBP-2 vs. DPP v0.71 Cheat Sheet
>===============================
>
>There are many similar concepts between SBP-2 and DPP v0.71 which
>may not be well understood.  The main difference between the
>protocols revolves around the a/symmetry of the protocol stacks.
>This "cheat sheet" is intended on laying the groundwork for a
>direct comparison of the protocol stacks.
>
>
>SBP-2 Model of Use for Comparison
>---------------------------------
>In order to get a reasonable comparison of the protocols, then
>a Command Set and Model-of-use must be outlined for SBP-2.  Many
>of the details can be left out of the outline as long as the
>essence of the profile is maintained.
>
>Model of Use
>------------
>
>  - cross-logins are established between the two devices.
>      (This avoids a merged target/initiator driver)
>
>  - each device provides a fetch engine and a task list.
>
>  - each task list contains commands to transfer data in one direction
>      (we'll choose it such that only WRITE transactions occur for
>       moving the ORB data block)
>
>  - each ORB allows one "data unit" to be processed.
>
>Command Set Provides For
>------------------------
>  - cross-login information
>  - negotiated max data block size per task per direction.
>  - indicating byte-size of completed packet
>  - carrying of Command IDs in CDB  (2 bytes)
>  - carry "SDU segmentation number" in CDB  (4 bytes)
>  - carry "SDU end of segment flag" in CDB  (1 bit)
>  - carry routing info in CDB  (2 byte Dest PID, 2 bytes Src PID)
>
>
>Cheat Sheet
>===========
>
>    CSR structures       Thin Protocol           SBP-2
>    -----------------------------------------------------------------------
>    Access Control i/f   Connection Reg          Mgmt Agent Reg
>
>    Response Space       SDU Response Space      Fetch Agent Regs
>
>    Completion status    SDU Control Space       Status FIFO
>
>    Transfer block       SDU Register            data block referenced by
ORB
>
>
>    Functional layers    Thin Protocol           SBP-2
>    -----------------------------------------------------------------------
>    Connection mgmt      Thin Session            Management Agent
>
>    Data Transfer eng    Thin Transaction        Fetch Agent
>
>
>    Session Mgmt         Thin Protocol           SBP-2
>    -----------------------------------------------------------------------
>    Access Request       S_Connect               login
>
>    Reconnect            T_Reconnect             reconnect
>
>    Execute App Cmd      S_Command               ORB exists on task list
>
>    Access Release       S_Disconnect            logout
>
>    Error Notification   <none>                  Mgmt-ORB specified Status
FIFO
>    completion notification
>
>
>    Data Transfer        Thin Protocol           SBP-2
>    -----------------------------------------------------------------------
>    Transfer Space       SDUAck                  ORB exists on task list
>      Available          (write implies avail)   (existance implies
available)
>
>    Transfer completion  SDUComp                 Notification write to
>      notification                                 Status FIFO
>
>    Transfer Abort from  SDUStop                 Abort Task (Set)
>     data receiver
>
>    Transfer Abort from  SDUStop                 Notification write to
implicit
>     data sender                                   Status FIFO - Abort
>
>    Error Notification   T_error                 Notification write to
implicit
>    Status FIFO - error ind.
>
>
>Feature Comparison
>==================
>
>Feature                  Thin Protocol           SBP-2
>-----------------------------------------------------------------------
>Each node can send/rcv   Yes                     Yes
>  data
>
>Dynamically allocates    Yes                     Yes
>  CSR Reg space when
>  estab. connect
>
>Selectable Transfer      Yes                     Yes, requires Create
Stream
>  Mode                                             request and separate
>                                                   task list
>
>Symmetric Structure      Yes                     Yes
>
>Negotiated Data Unit     Yes                     Yes
>  size independently
>  per direction
>
>Isochronous Support      Yes                     Yes
>
>Multiple Cmd Support     Yes                     Yes
>
>Bidirectional Cmds       Yes                     Yes
>
>Multiple Independent     Unspecified (possible   Yes, via Multiple LUNs &
> Connection Support      w/ multiple UNIT Dirs)    multiple UNITS
>
>Session segmentation     Yes                     Yes, in CDB
>  support
>
>
>Distinctive differences:
>
>Feature                  Thin Protocol           SBP-2 w/ proposed profile
>-----------------------------------------------------------------------
>Reconnect Support        2 sec window;           1 sec window, proposal
made
>                         either end may          for programmable
extension;
>                         establish               both ends must reestablish
>
>SDU Available            SDU Ack timeout exists  None (?)
>  timeout                Does this imply a real-
>                         time processing req. on
>                         whatever data is sent
>                         in an SDU?
>
>Connection Process       2 block writes          6 block writes (probably)
>                                                   (2 logins @ 2 per login,
>                                                    2 for negotiated
params)
>
>Shared memory buffer     Fixed location during   Relocatable, partitionable
>                         connection
>
>Data Transfer            more efficient for      More flexible and
standardized
>                         data < MTU size
>
>   data < MTU size       SDUAck +                WR Agent Reset + WR ORB
ptr +
>                         SDUComp +               ORB prefetch + data xfer +
>                         SDUAck                  Completion Notify
>                            (3 transactions vs. 5 transactions)
>
>   MTU size << data <    SDUSend +               WR Agent Reset + WR ORB
ptr +
>   SDU size              SDUComp +               ORB prefetch + page table
+
>                                                 data xfer +
>                         SDUAck                  Completion Notify
>                            (SBP-2 costs 3 extra transactions,
>                             but a small overhead
>
>--
>Greg Shue
>Hewlett-Packard Company
>Office Products Division gregs@sdd.hp.com
>----------------------------------------------------------------
>

From gregs at sdd.hp.com  Mon Feb 23 12:36:08 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Re: SBP-2 vs. DPP 0.71 Cheat Sheet (?)
In-Reply-To: <199802231158.UAA08825@goudy.vip.iwa.fujixerox.co.jp>
Message-ID: <199802231736.JAA27487@hpsdlgj1.sdd.hp.com>

> 
> Hi Greg,
> 
> [You wrote]
> >What do you think?
> 
> I have question that which is your prefer to use for PC Printing.  So 
> far, I thought you recommend to use SBP-2 for PC Printing.  However, I 
> could not distinguish advantage to use SBP-2 for PC Printing in your 
> comparison chart.


I intentionally avoided stating preferences.  I wanted to present
an "equivalent concept" chart, and see where the discussion goes.


> I feel that you are going to love THIN stack for PC Printing for keeping 
> consistency with Peer-to-Peer devices.  Who does want to be fat for same 
> function?




OK, here's my preference...


   "I am going to love using SBP-2 for peer-to-peer!


   (And, with a different SBP-2 command set, I'll love using it
   in a different way for PC printing!)"


Why?  Because:


  - Microsoft is supporting the SCSI model for scanning,
    so the standard scanning solution is built around SBP-2


  - Microsoft and Apple both prefer SBP-2 for printing,
    so I prefer an SBP-2 based printing protocol.


  - I want to support both PC printing and peer-to-peer
    interactions, so both protocols are going to exist.
    I don't see customers buying a printer which only
    supports peer-to-peer.


  As such, the SBP-2 based version only costs me the command set.
  I'm already paying for everything else (testing, ROM space, RAM
  space, tool support).  And, when I want to, I can easily build
  in access to other devices which use SBP-2 (e.g.  disk drives).


  No part of the Thin protocol comes for free.  And it may only
  work for the DPP protocol.


  To quote an interrested party:
     "Who does want to be fat for same function?"  :-)  :-)


  I am quite aware of product cost.  The "idea" of a $300 camera
  was mentioned as a cost-costrained device.  Let's not forget
  about the "idea" of a $500 MFP which prints, scans and faxes.
  They basically exist now...  I would guess that they are 
  equivalently constrained, and the MFP must support a greater
  variety of functionality (and protocols).


Also:


  I have no idea how the "30K +/- 10K" number fits into my
  environment.  There were:
  
    - no processors identified (CISC vs. RISC?),
    - no toolsets identified (C vs. C++? vendor A vs. vendor B),
    - no optimizations specified (none vs. compact vs. loop unrolling),
    - no design parameters identified (speed vs. space).
    
  (Hey, I might be able to do it in 10K!  Then again it might
  take 40K!)


  Those early numbers I shared really say that:


    sizeof(link driver) ~= sizeof(bus mgr) ~=
    sizeof(SBP-2 initiator) ~= sizeof(spb-2 target) ~=
    sizeof(IP1394 glue layer) ~= (1/3 -> 1/2) * sizeof(TCP/IP stack)


  Please don't get hung up on the absolute number of "30K".
  Besides, If you can't afford "30K" for the combined SBP-2
  layers, then you probably can't afford "30K" for the software
  to support a 1394 node, and you probably can't afford 1394 HW.


  (And, here is another reality check:  how big are ROMs these
  days?  Don't they come in practical package sizes of >= 0.5
  MBytes these days?  I have a hard time believing that anyone is
  considering putting 1394 in a product where they have less than
  7% headroom of one ROM package before they know what the
  technology really takes!)





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


From rturner at sharplabs.com  Mon Feb 23 12:58:56 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:49 2009
Subject: P1394> teleconference information
Message-ID: <199802231736.JAA27487@hpsdlgj1.sdd.hp.com>

	
The following are the details for today's teleconference:


When: 		 2/23/1998 4:00 PST 
Duration: 	90 Minutes
Participants:  	12
Number: 	(608) 250 - 9281
Access Code	465858




Randy

From atsnaka at bsd.canon.co.jp  Mon Feb 23 20:06:37 1998
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Re: [PP1394:00208] Re: SBP-2 vs. DPP 0.71 Cheat Sheet (?)
In-Reply-To: <199802231736.JAA27487@hpsdlgj1.sdd.hp.com>
Message-ID: <199802240106.KAA13562@bsdmail.bsd.canon.co.jp>

At 02:36 98/02/24 +0900, Greg Shue wrote:






> 


> OK, here's my preference...


> 


>    "I am going to love using SBP-2 for peer-to-peer!


> 


>    (And, with a different SBP-2 command set, I'll love using it


>    in a different way for PC printing!)"


> 






Has this been discussed with the "input" or "device-source" people ?






Peer to Peer is different from PC printing because we have to take 


requirements and restrictions of the input devices in to consideration,


whereas the PC has pratically no restrictions (PC can do anything.)  






No matter how much we, the printer guys may like SBP-2, peer to peer


can only be achieved if the image source support the (appropriate


functions of) same protocol.






Now, my question is : 






Q)Has anyone actually discussed with the input people about implementing


   BOTH initiator and target SBP-2 in input devices for peer to peer ?






Q)The scanner may prefer a SCSI-like solution , especially because of it's 


   origin as a PC peripheral, but how about digital cameras?,DV camcorders?






Toru Ueda wrote:


> We are developing DPP and THIN protocol. The biggest priority for THIN


> protocol is  the size and simplicity. I cannot explain the reason we


> need two logins for simple print task to our product engineers. Also I


> cannot explain the reason we need 20 or 30KB for print protocol, while


> the file transfer protocol using IR(Infra-Red) communication (called Ir


> TranP) needs only several Kilo bytes.






People like Ueda-san and others of the PWG-C HAS been discussing 


these issues with input people from not just the office products area, 


but the consumer market people as well, and we should consider the THIN


protocol as the outcome of these discussions.  










At 02:36 98/02/24 +0900, Greg Shue wrote:






>Why?  Because:


>


>  - Microsoft is supporting the SCSI model for scanning,


>    so the standard scanning solution is built around SBP-2


>


>  - Microsoft and Apple both prefer SBP-2 for printing,


>    so I prefer an SBP-2 based printing protocol.


>






I would also agree this may be a good reasoning from the 


PC printing point of view. 






-Differnt reasoning for differnt solutions....Both reasonable.






>  - I want to support both PC printing and peer-to-peer


>    interactions, so both protocols are going to exist.


>    I don't see customers buying a printer which only


>    supports peer-to-peer.






This is also VERY true. It's the manufacturer's responsibility 


to avoid end-user confusion.


If $300 digital cameras don't support SBP-2 but support DPP,  it's


our responsiblity to support it. Same opposite-wise.






My personal choice  






"I may not love it, but I will use BOTH situation by situation!"


 (I may have to implement AVC if that becomes necessary.)






That's why we proposed FDS right ?, 


(Whatever protocol, we know where the printer is...)






 




















-----------------------------------------


<bigger>Atsushi Nakamura


</bigger>-----------------------------------------




BJ Technology Develpoment 22,


Canon Inc.




53 Imai Kami-cho


Nakahara-Ku, Kawasaki-shi


postal no. 211




tel:+81-3-44-733-6111(ext.5593)


    +81-3-44-739-6634(direct)


fax:+81-3-44-739-6756


email(1):Atsushi_Nakamura@cbj.canon.co.jp


email(2):atsnaka@bsd.canon.co.jp


-----------------------------------------

From gleclair at agentz.com  Mon Feb 23 21:35:51 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:49 2009
Subject: P1394> EMAIL Poll
Message-ID: <199802240106.KAA13562@bsdmail.bsd.canon.co.jp>

During the 1394 PWG 2/23 telecon, it was suggested we undertake an non-binding email poll to 
gauge interest in various proposals being considered by the working group.


Please forward your reply to the 1394 PWG reflector - p1394@pwg.org


If possible, please reply by Friday, February 27th, 1998.


Thanks,
Greg LeClair


PS> If you have suggestions for this or future polls, please send them under a different
subject line.


===================================================================


1. Please rank the following proposals according to your interest level using the following scale ( 10 = High level 
of interest vs. 0 = No interest).


	(   )   1284.4 Over Data FIFO Architecture (DFA)
	(   )   1284.4 Over SBP-2
	(   )   Direct Printing Protocol - (current PWG-C proposal 0.71)
	(   )   SBP-2 Native - (current PWG proposal 0.1c)
	(   )   Other (describe)__________________


2. Please provide background comments on your ranking. 


	Why do you prefer to use the given solution?


	Why should others consider the given solution?


	Does the the given solution meet the existing requirements?


	What issues are you aware of (if any) with the given solution?


	What is your opinion on the best way to move the discussion forward?


	Other comments?

From atsnaka at bsd.canon.co.jp  Mon Feb 23 22:53:04 1998
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Scope of EMAIL Poll
In-Reply-To: <01BD4089.E26048A0.gleclair@agentz.com>
Message-ID: <199802240353.MAA16993@bsdmail.bsd.canon.co.jp>

1 question concerning the scope of this poll ;






 1) What is the scope of the "interest level"? PC prinitng, Consumer 


     peer to peer printing, or both ?






Also, 


If I was in charge of this poll, I would add another question to the survey.






3) Opinions on multiple printing protocols;






 	(   )   There should be ONLY 1 printing protocol in any case and any application.


 	(   )   2 protocols are ACCEPTABLE if necessary for different situations


 	(   )   I PREFER more than 2 protocols 


 	(   )   Other (describe)__________________










At 18:35 98/02/23 -0800, Gregory A. LeClair wrote:


> During the 1394 PWG 2/23 telecon, it was suggested we undertake an non-binding email poll to 


> gauge interest in various proposals being considered by the working group.


> 


> Please forward your reply to the 1394 PWG reflector - p1394@pwg.org


> 


> If possible, please reply by Friday, February 27th, 1998.


> 


> Thanks,


> Greg LeClair


> 


> PS> If you have suggestions for this or future polls, please send them under a different


> subject line.


> 


> ===================================================================


> 


> 1. Please rank the following proposals according to your interest level using the following scale ( 10 = High level 


> of interest vs. 0 = No interest).


> 


> 	(   )   1284.4 Over Data FIFO Architecture (DFA)


> 	(   )   1284.4 Over SBP-2


> 	(   )   Direct Printing Protocol - (current PWG-C proposal 0.71)


> 	(   )   SBP-2 Native - (current PWG proposal 0.1c)


> 	(   )   Other (describe)__________________


> 


> 2. Please provide background comments on your ranking. 


> 


> 	Why do you prefer to use the given solution?


> 


> 	Why should others consider the given solution?


> 


> 	Does the the given solution meet the existing requirements?


> 


> 	What issues are you aware of (if any) with the given solution?


> 


> 	What is your opinion on the best way to move the discussion forward?


> 


> 	Other comments?


> 


> 


> 


> 


> 


> 






-----------------------------------------


<bigger>Atsushi Nakamura


</bigger>-----------------------------------------




BJ Technology Develpoment 22,


Canon Inc.




53 Imai Kami-cho


Nakahara-Ku, Kawasaki-shi


postal no. 211




tel:+81-3-44-733-6111(ext.5593)


    +81-3-44-739-6634(direct)


fax:+81-3-44-739-6756


email(1):Atsushi_Nakamura@cbj.canon.co.jp


email(2):atsnaka@bsd.canon.co.jp


-----------------------------------------

From gleclair at agentz.com  Tue Feb 24 03:32:15 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Scope of EMAIL Poll
Message-ID: <199802240353.MAA16993@bsdmail.bsd.canon.co.jp>

The scope is printing. 


Feel free to elaborate if you want to answer the poll.


Regards,


Greg


-----Original Message-----
From:	Atsushi_Nakamura [SMTP:atsnaka@bsd.canon.co.jp]
Sent:	Monday, February 23, 1998 7:53 PM
To:	gleclair@agentz.com; '1394 PWG'
Subject:	P1394> Scope of EMAIL Poll






1 question concerning the scope of this poll ;






 1) What is the scope of the "interest level"? PC prinitng, Consumer 


     peer to peer printing, or both ?






Also, 


If I was in charge of this poll, I would add another question to the survey.






3) Opinions on multiple printing protocols;






 	(   )   There should be ONLY 1 printing protocol in any case and any application.


 	(   )   2 protocols are ACCEPTABLE if necessary for different situations


 	(   )   I PREFER more than 2 protocols 


 	(   )   Other (describe)__________________










At 18:35 98/02/23 -0800, Gregory A. LeClair wrote:


> During the 1394 PWG 2/23 telecon, it was suggested we undertake an non-binding email poll to 


> gauge interest in various proposals being considered by the working group.


> 


> Please forward your reply to the 1394 PWG reflector - p1394@pwg.org


> 


> If possible, please reply by Friday, February 27th, 1998.


> 


> Thanks,


> Greg LeClair


> 


> PS> If you have suggestions for this or future polls, please send them under a different


> subject line.


> 


> ===================================================================


> 


> 1. Please rank the following proposals according to your interest level using the following scale ( 10 = High level 


> of interest vs. 0 = No interest).


> 


> 	(   )   1284.4 Over Data FIFO Architecture (DFA)


> 	(   )   1284.4 Over SBP-2


> 	(   )   Direct Printing Protocol - (current PWG-C proposal 0.71)


> 	(   )   SBP-2 Native - (current PWG proposal 0.1c)


> 	(   )   Other (describe)__________________


> 


> 2. Please provide background comments on your ranking. 


> 


> 	Why do you prefer to use the given solution?


> 


> 	Why should others consider the given solution?


> 


> 	Does the the given solution meet the existing requirements?


> 


> 	What issues are you aware of (if any) with the given solution?


> 


> 	What is your opinion on the best way to move the discussion forward?


> 


> 	Other comments?


> 


> 


> 


> 


> 


> 






-----------------------------------------


<bigger>Atsushi Nakamura


</bigger>-----------------------------------------




BJ Technology Develpoment 22,


Canon Inc.




53 Imai Kami-cho


Nakahara-Ku, Kawasaki-shi


postal no. 211




tel:+81-3-44-733-6111(ext.5593)


    +81-3-44-739-6634(direct)


fax:+81-3-44-739-6756


email(1):Atsushi_Nakamura@cbj.canon.co.jp


email(2):atsnaka@bsd.canon.co.jp


-----------------------------------------

From colinws at bristol.st.com  Tue Feb 24 05:39:12 1998
From: colinws at bristol.st.com (Colin Whitby-Strevens)
Date: Wed May  6 14:00:49 2009
Subject: P1394> EMAIL Poll
In-Reply-To: <P1394> EMAIL Poll>
Message-ID: <19374.199802241039@fiscal.inmos.co.uk>

Hello Greg,


Any restrictions or guidance on who can vote? For example, I have been 
following the interesting debate, but I have not participated in any pwg 
meetings. Am I eligible? Or does the self-certification rule ("anyone who feels 
they are technically qualified") apply?


With best wishes


Colin Whitby-Strevens
 
> During the 1394 PWG 2/23 telecon, it was suggested we undertake an non-bindin
> g email poll to 
> gauge interest in various proposals being considered by the working group.
> 
> Please forward your reply to the 1394 PWG reflector - p1394@pwg.org
> 
> If possible, please reply by Friday, February 27th, 1998.
> 
> Thanks,
> Greg LeClair
> 
> PS> If you have suggestions for this or future polls, please send them under
>  a different
> subject line.
> 
> ===================================================================
> 
> 1. Please rank the following proposals according to your interest level
>  using the following scale ( 10 = High level 
> of interest vs. 0 = No interest).
> 
>       (   )   1284.4 Over Data FIFO Architecture (DFA)
>       (   )   1284.4 Over SBP-2
>       (   )   Direct Printing Protocol - (current PWG-C proposal 0.71)
>       (   )   SBP-2 Native - (current PWG proposal 0.1c)
>       (   )   Other (describe)__________________
> 
> 2. Please provide background comments on your ranking. 
> 
>       Why do you prefer to use the given solution?
> 
>       Why should others consider the given solution?
> 
>       Does the the given solution meet the existing requirements?
> 
>       What issues are you aware of (if any) with the given solution?
> 
>       What is your opinion on the best way to move the discussion forward?
> 
>       Other comments?
> 
> 
> 
> 
> 



--
Colin Whitby-Strevens             email:colinws@bristol.st.com
SGS-THOMSON Microelectronics      tel: +44 1454 611500
1000, Aztec West                  fax: +44 1454 617910
Almondsbury
BRISTOL BS32 4SQ 
UK


From gleclair at agentz.com  Tue Feb 24 11:12:48 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:49 2009
Subject: P1394> EMAIL Poll
Message-ID: <19374.199802241039@fiscal.inmos.co.uk>

I think more feedback from various points of view will be helpful.
Please feel free to contribute to the discussion.


Thanks and Regards,
Greg LeClair








-----Original Message-----
From:	Colin Whitby-Strevens [SMTP:colinws@bristol.st.com]
Sent:	Tuesday, February 24, 1998 2:39 AM
To:	gleclair@agentz.com; p1394@pwg.org
Subject:	Re: P1394> EMAIL Poll


Hello Greg,


Any restrictions or guidance on who can vote? For example, I have been 
following the interesting debate, but I have not participated in any pwg 
meetings. Am I eligible? Or does the self-certification rule ("anyone who feels 
they are technically qualified") apply?


With best wishes


Colin Whitby-Strevens
 
> During the 1394 PWG 2/23 telecon, it was suggested we undertake an non-bindin
> g email poll to 
> gauge interest in various proposals being considered by the working group.
> 
> Please forward your reply to the 1394 PWG reflector - p1394@pwg.org
> 
> If possible, please reply by Friday, February 27th, 1998.
> 
> Thanks,
> Greg LeClair
> 
> PS> If you have suggestions for this or future polls, please send them under
>  a different
> subject line.
> 
> ===================================================================
> 
> 1. Please rank the following proposals according to your interest level
>  using the following scale ( 10 = High level 
> of interest vs. 0 = No interest).
> 
>       (   )   1284.4 Over Data FIFO Architecture (DFA)
>       (   )   1284.4 Over SBP-2
>       (   )   Direct Printing Protocol - (current PWG-C proposal 0.71)
>       (   )   SBP-2 Native - (current PWG proposal 0.1c)
>       (   )   Other (describe)__________________
> 
> 2. Please provide background comments on your ranking. 
> 
>       Why do you prefer to use the given solution?
> 
>       Why should others consider the given solution?
> 
>       Does the the given solution meet the existing requirements?
> 
>       What issues are you aware of (if any) with the given solution?
> 
>       What is your opinion on the best way to move the discussion forward?
> 
>       Other comments?
> 
> 
> 
> 
> 



--
Colin Whitby-Strevens             email:colinws@bristol.st.com
SGS-THOMSON Microelectronics      tel: +44 1454 611500
1000, Aztec West                  fax: +44 1454 617910
Almondsbury
BRISTOL BS32 4SQ 
UK


From gregs at sdd.hp.com  Tue Feb 24 11:42:54 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Scope of EMAIL Poll
In-Reply-To: <01BD40BD.CED1E260.gleclair@agentz.com>
Message-ID: <199802241642.IAA00671@hpsdlgj1.sdd.hp.com>

Greg L. wrote:
> 
> The scope is printing. 




Atsushi Nakamura wrote:
> If I was in charge of this poll, I would add another question to the survey.
> 3) Opinions on multiple printing protocols;
> 
>  	(   )   There should be ONLY 1 printing protocol in any case and any application.
> 
>  	(   )   2 protocols are ACCEPTABLE if necessary for different situations
> 
>  	(   )   I PREFER more than 2 protocols 
> 
>  	(   )   Other (describe)__________________


I guess we all prefer _more_ than 3 protocols, right?
IP happens, AVC exists, and proprietary should be allowed.




By the way, I think it's a very good addition, Ats.



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


From gleclair at agentz.com  Tue Feb 24 12:47:01 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Minutes for telecon on 2/23
Message-ID: <199802241642.IAA00671@hpsdlgj1.sdd.hp.com>

BTW, it would be appreciated if anyone who was taking notes during the telecon could forward a 
copy to me for inclusion in the minutes. It's a bit hard to type and talk.....


Thanks,
Greg LeClair
greg@erc.epson.com

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Tue Feb 24 12:52:29 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:49 2009
Subject: P1394> EMAIL Poll
In-Reply-To: <01BD4089.E26048A0.gleclair@agentz.com>
Message-ID: <H0000d930edff438@MHS>

begin 777 1.txt
M4F5C96EV960Z(&9R;VT@<&%L<F5L,2YH<"YC;VT@*'!A;')E;#$N:'`N8V]M
M(%LQ-2XX,2XQ-C@N,3!=*2!B>2!V96YU<RYR;W-E+FAP+F-O;2!W:71H($53
M3510("@X+C<N,2\X+C<N,R!425,@-2XP($]P96YM86EL*2!I9"!304$Q.34W
M,B!F;W(@/&%L86Y?8F5R:V5M84!H<"UR;W-E=FEL;&4M;VTR+F]M+FAP+F-O
M;3X[($UO;BP@,C,@1F5B(#$Y.3@@,3@Z,SDZ,C$@+3`X,#`@*%!35"D*4F5C
M96EV960Z(&9R;VT@;&ES=',N=6YD97)S8V]R92YC;VT@*'5S8V]R92TQ+FUV
M+F-O;2!;,3DY+C$R-2XX-2XS,%TI"@EB>2!P86QR96PQ+FAP+F-O;2`H."XX
M+C8O."XX+C5T:7,I('=I=&@@15--5%`@:60@4T%!,34P,3$["@E-;VXL(#(S
M($9E8B`Q.3DX(#$X.C,Y.C$P("TP.#`P("A04U0I"E)E8V5I=F5D.B!F<F]M
M(&QO8V%L:&]S="`H9&%E;6]N0&QO8V%L:&]S="D@8GD@;&ES=',N=6YD97)S
M8V]R92YC;VT@*#@N-RXU+S@N-RXS*2!W:71H(%--5%`@:60@5D%!,3`V-#,[
M($UO;BP@,C,@1F5B(#$Y.3@@,C$Z,SDZ,#$@+3`U,#`@*$535"D*4F5C96EV
M960Z(&)Y('!W9RYO<F<@*&)U;&M?;6%I;&5R('8Q+C4I.R!-;VXL(#(S($9E
M8B`Q.3DX(#(Q.C,X.C`Q("TP-3`P"E)E8V5I=F5D.B`H9G)O;2!D865M;VY`
M;&]C86QH;W-T*2!B>2!L:7-T<RYU;F1E<G-C;W)E+F-O;2`H."XW+C4O."XW
M+C,I(&ED(%9!03$P-3`Y(&9O<B!P,3,Y-"UO=71G;VEN9SL@36]N+"`R,R!&
M96(@,3DY."`R,3HS-SHT-R`M,#4P,"`H15-4*0I-97-S86=E+4E$.B`\,#%"
M1#0P.#DN13(V,#0X03`N9VQE8VQA:7)`86=E;G1Z+F-O;3X*1G)O;3H@(D=R
M96=O<GD@02X@3&5#;&%I<B(@/&=L96-L86ER0&%G96YT>BYC;VT^"E)E<&QY
M+51O.B`B9VQE8VQA:7)`86=E;G1Z+F-O;2(@/&=L96-L86ER0&%G96YT>BYC
M;VT^"E1O.B`B)S$S.30@4%=')R(@/'`Q,SDT0'!W9RYO<F<^"E-U8FIE8W0Z
M(%`Q,SDT/B!%34%)3"!0;VQL"D1A=&4Z($UO;BP@,C,@1F5B(#$Y.3@@,3@Z
M,S4Z-3$@+3`X,#`*3W)G86YI>F%T:6]N.B!*87E'964@0V]M;75N8V%T:6]N
M<PI8+4UA:6QE<CH@36EC<F]S;V9T($EN=&5R;F5T($4M;6%I;"]-05!)("T@
M."XP+C`N-#(Q,0I%;F-O9&EN9SH@-#`@5$585`I396YD97(Z('`Q,SDT+6]W
,;F5R0'!W9RYO<F<*
`
end


     


     
===================================================================
     
1. Please rank the following proposals according to your interest level using 
the following scale ( 10 = High level 
of interest vs. 0 = No interest).
     
        ( 1 )   1284.4 Over Data FIFO Architecture (DFA)


+ Uses existing 1284.4 protocol.
+ Push Push Solution for efficient 1394 unified write transactions.
+ Basic Premise is fairly simple.
- Needs additions for lost, duplicate and out of order packets.
- Needs Fragmentation and re-assembly.
- Effort really turns out to out to be similar to solving the problems that 
  IP1394 is designed to address.
- Has same host side CPU intensive processing concerns that IP1394 has.


        ( 0 )   1284.4 Over SBP-2
+ Uses existing 1284.4 protocol.
- Don't need CBT with SBP-2 pull model.
- Has all the 1284.4 overhead as well as all the things needed to make SBP-2
  virtually symmetric.


        ( 2 )   Direct Printing Protocol - (current PWG-C proposal 0.71) 
Answering this question in the context of considering this for the PWG. This is
not intended to detract from the use of DPP by the PWG-C .


+ Has the goal of being thin. Less code and overhead than SBP-2.
+ Up front design to include Peer to Peer.
- Not an existing standard.
- Could grow to be almost as thick (complex) as SBP-2.
- Appears to have similar CPU intensive processing concerns as IP & DFA.
? Does it address multiple host to multiple devices?


        ( 7 )   SBP-2 Native - (current PWG proposal 0.1c)
+ Existing standard.
+ Designed for 1394 shared memory model.
+ Lends itself to efficient implementation using DMA descriptor based link 
  controller hardware.
+ Support by Microsoft.
+ Support by Apple.
- Need to abstract symmetry for peer to peer.
- Dual personality Initiator/Target roles also need to be hidden from 
  applications.


        (   )   Other (describe)__________________
     
2. Please provide background comments on your ranking. 
     
        Why do you prefer to use the given solution?
        Why should others consider the given solution?
        Does the given solution meet the existing requirements?
        What issues are you aware of (if any) with the given solution?
     
        What is your opinion on the best way to move the discussion forward?
o Decide. Implement. Have interoperability sessions to refine our profile based 
upon what we learn.


     
        Other comments?


---- 


1 question concerning the scope of this poll ; 
 1) What is the scope of the "interest level"? PC printing, Consumer  
     peer to peer printing, or both ? 


o Believe it to have a PWG scope.


Also,  
If I was in charge of this poll, I would add another question to the survey. 
3) Opinions on multiple printing protocols; 


  (   )   There should be ONLY 1 printing protocol in any case and any
application. 
  (   )   2 protocols are ACCEPTABLE if necessary for different situations 
  (   )   I PREFER more than 2 protocols  
  (   )   Other (describe)__________________ 


o Would prefer 1 or 2 protocols. As it turns out we will probably have


1) IP1394.
2) PWG protocol
3) PWG-C protocol.
4) AVC? Why was this mentioned as a separate item?


     

From gregs at sdd.hp.com  Tue Feb 24 14:00:37 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:49 2009
Subject: P1394> EMAIL Poll
In-Reply-To: <01BD4089.E26048A0.gleclair@agentz.com>
Message-ID: <199802241900.LAA00736@hpsdlgj1.sdd.hp.com>

1.  Please rank the following proposals according to your
interest level using the following scale ( 10 = High level of
interest vs.  0 = No interest).


	( 3 )   1284.4 Over Data FIFO Architecture (DFA)
	( 0 )   1284.4 Over SBP-2
	( 5 )   Direct Printing Protocol - (current PWG-C proposal 0.71)
	(10 )   SBP-2 Native - (current PWG proposal 0.1c)
	( 8 )   Other - IP1394
	( 4 )   Other - AVC
	( 6 )   Other - SBP-2 mirroring Thin Protocol


2. Please provide background comments on your ranking. 


For Unadiminstered PC connect:
	Why do you prefer to use the given solution?
	  Support by multiple major desktop OS vendors
	  Lower CPU overhead on PC
	  Can be used for other devices
	  Support for async and isoch
          Errors are testable/verifiable
	  Consistant with the CSR & Unit Directory Architecture
	  HW vendors providing HW assists already
	  Does not require support for large MTU sizes
	  Flow control is implicit, not explicit as with CBT


	Why should others consider the given solution?
	  See above comments


	Does the the given solution meet the existing requirements?
	  Yes


	What issues are you aware of (if any) with the given solution?
	  Obtaining access to a service instance is potentially inefficient.
	  Unexpect data transfers to PC are not optimally supported.
	  How to identify which Application command set is associated
	    with a service.


	What is your opinion on the best way to move the discussion forward?
	  Get concensus on how may protocols _will_ exist (see below).
	  Reaffirm the solution space being addressed.
	  Compare with other proposals.


	Other comments?
	  Work is under way to provide support within SBP-2 for
	  transient link interruption support.  No negative feedback
	  has been shared on the T10 reflector.  The proposal will be
	  reviewed on March 10, 1998.  If the extension is addopted,
	  then the complexity of the SBP-2 Native Profile proposed drops
	  by half.




3. Opinions on multiple printing protocols;


 	(10 )   Other


    IP happens - This provides a backwards compatible solution space
		 for enterprise environments.  This is a needed solution.
		 It removes a barrier to adopting the technology.


                 (This seems like the "luxury/full-size car" of protocols)


    AVC is (?) - This provides a solution for the current AV 1394
		 products which customers have already bought.  There
		 is not much that we can do about it, though it seems
		 to potentially waste a large amount of (shared) 1394
		 bus bandwidth.  I understand why it was based on Isoch,
		 bu I would have preferred an Async solution.


		 (This seems like the "alternate fuel cars" of protocols)


    Light      - There is now a _real_ application space associated with
    Peer-to-     printing which does not fit the traditional client/server
    peer will    model.  The current protocols are inappropriate or too
    be           heavy for this application space.  Because this is real,
		 this will happen.  Because it is a different paradigm,
		 this needs to happen.
		 
		 The only question is what will it look like.  We
		 need exactly one well-defined, thoroughly
		 testable, certafiable protocol in order to help
		 deliver interoperability of embedded devices.


		 (This seems like the Sport/Utility Vehicles of protocols)


    Proprietary - These will exist.  These must be allowed.  We can't
		 cover every need, so a safety net for custom solutions
		 must be acknowledged.  The best that we can do is try
    		 to educate the developers on any coexistance issues
		 and best practices that have been found during
		 our standardization efforts.


		 (This seems like the "custom" cars of protocols)


    Unadmin.   - This is really the "optional" area.  The other protocols
    PC connect   span the solution space, though none are optimal.  I
		 think this will happen because:


		   - MS and Apple prefer it for printer connectivity
		   - Printer vendors want it
		   - If it's not standardized, it will be there as a
		       proprietary solutions anyway


                 (This seems like the small/midsize cars of protocols)


    So,


      I think all five protocol categories except the Unadministered
      PC Connect _must_ exist because they provide non-overlapping
      solutions to real problems.


      I think the Unadministered PC Connect (i.e. "Parallel Port
      replacement) should exist for technology adoption and business
      opportunity reasons even more so than technical ones.  "The
      small/midsize car market is real."


      I think we should try hard to avoid having more than one
      protocol per category.  For various reasons, I would like to
      share as many mechanisms (e.g.  access control) as possible
      between the protocols.



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


From fumiona at venus.dti.ne.jp  Wed Feb 25 07:22:55 1998
From: fumiona at venus.dti.ne.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:49 2009
Subject: P1394> EMAIL Poll
In-Reply-To: <01BD4089.E26048A0.gleclair@agentz.com>
Message-ID: <199802251222.VAA22801@smtp.dtinet.or.jp>

On Mon, 23 Feb 1998 18:35:51 -0800
"Gregory A. LeClair" <gleclair@agentz.com> wrote:
> ===================================================================
> 
> 1. Please rank the following proposals according to your interest level using the following scale ( 10 = High level 
> of interest vs. 0 = No interest).
> 
	( 0 )   1284.4 Over Data FIFO Architecture (DFA)
	( 3 )   1284.4 Over SBP-2
	( 2 )   Direct Printing Protocol - (current PWG-C proposal 0.71)
	(10 )   SBP-2 Native - (current PWG proposal 0.1c)
	( 0 )   Other (describe)__________________


> 2. Please provide background comments on your ranking. 
> 
> 	Why do you prefer to use the given solution?
Provides shared memory system and pull transaction.
Supported by major consumer OS vender.
Existing standard.
Real physical devices are asymmetric, and SBP-2 is also
asymmetric. It could be optimized for high band throughput.


> 	Why should others consider the given solution?


Standard developments and marketing reasons,


> 
> 	Does the the given solution meet the existing requirements?


yes,


> 	What issues are you aware of (if any) with the given solution?


Unexpected In-ORB may cause fetch agent to be stalled.
Reverse directional flow control (credit control?) may
be required.


> 	What is your opinion on the best way to move the discussion forward?
> 
Design review for Alan's and Greg's proposal would be
effective to figure out 1394 transport requirements.


> 	Other comments?


-----
Fumio Nagasaka
EPSON Software Development Laboratory Inc.,
TEL: +81 268 25-4111 // FAX: +81 268 25-4627
HomePage = http://www.venus.dti.ne.jp/~fumiona/

From gleclair at agentz.com  Thu Feb 26 02:02:28 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Proposed Austin Agenda
Message-ID: <199802251222.VAA22801@smtp.dtinet.or.jp>

Here is the proposed agenda for Austin meeting (what a difference a year makes!!!)




 - Review the amended 1394 PWG proposal (w/Jan mtg feedback)


 - Walk through use scenarios for SBP-2 proposal


 - Comparison of proposals vs. the requirements list 
	- E-mail poll results - focus our choices


 - Best Practices discussion - How to use the PWG profile






Let me know if there are additional items you'd like to add or comments on changing order.


Regards,
Greg LeClair
greg@erc.epson.com

From gleclair at agentz.com  Thu Feb 26 02:13:10 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Minutes of Monday 2/23 Telecon
Message-ID: <199802251222.VAA22801@smtp.dtinet.or.jp>

Here's the minutes of Monday 2/23 telecon courtesy of Lee Farrell from Canon.


Thanks Lee.


Additional comments, clarification please forward to list.


Regards,
Greg LeClair
greg@erc.epson.com


===============================================================


Teleconference Participants
The attendees included :
Shigeru Ueda		Canon	
Akihiro Shimura		Canon	
Takashi Isoda		Canon	
Lee Farrell		Canon Information Systems	
Greg LeClair*		Epson	
Brian Batchelder	Hewlett Packard	
Alan Berkema		Hewlett Packard	
Greg Shue		Hewlett Packard	
Fumio Nagasaka	Seiko Epson	
Randy Turner		Sharp	


	* 1394 PWG Chairman




Discussion


Nagasaka-san started the meeting by asking how Greg Shue will implement
his SBP-2 approach according to the January proposal. Shue said that his
proposal has not changed since then. (Neither has Alan Berkema made any
changes, although he expects to do so soon.) According to Shue, the
recent e-mail has only been a discussion contrasting the features of
different alternatives. Shue is anxious to avoid confusion between his
proposal and the e-mail discussions.


When Greg LeClair arrived, he attempted to set an agenda. The three
proposal alternatives currently under discussion were identified:
	*	1284.4 over SBP-2 (there has not been much
discussion supporting this on the e-mail list, but Brian Batchelder says
he's not yet ready to abandon it completely. He said that most people
are agreeing that 1284.4 over SBP-2 is not very desirable because of the
significant feature overlap. Nagasaka-san says he still likes the use of
1284.4 because of its credit feature. Others are willing to consider
1284.4 over some datalink.)
	*	SBP-2 "native"
	*	DPP (Randy Turner wonders how heavy the session
layer will be for this.)


Greg LeClair concluded that today's discussion should cover technical
issues about SBP-2 vs. DPP. Brian suggested that he would like us to do
a trade-off analysis of SBP-2 and DPP at the next PWG meeting.


(Greg LeClair's comments - I felt it was more of a clarification of the technical issues 
being discussed on SBP-2 and DPP {not SBP-2 vs. DPP} as these had been the hotter topics 
on the reflector in the last few days.)


Both Greg LeClair and Alan Berkema think that Randy's topic of a Winsock
API on top of SBP-2 was interesting. However, Alan wants to see a more
detailed proposal. 


Randy Turner suggested that we also consider the DPP command set over a
different transport layer.


Of the several proposals currently under consideration, Randy wanted to
identify an alternative that could be rejected. However, no one could
agree on one to eliminate. (At least one person was interested in each.)


Alan Berkema suggested that we have an e-mail poll to rank the different
alternatives being considered. Greg LeClair will organize this. As part
of the "ranking poll", he will also ask respondents to offer a few words
describing why they rank the alternatives as they do.


Alan asked for a scenario walk-through of how SBP-2 really works to be
given at our next 1394 PWG meeting. 


Despite claims from George Chrysanthakopoulos (Microsoft), Brian is very
concerned that SBP-2 really won't work (as supported by Microsoft) for
printing. He is (at least) concerned about enumerating multiple logical
units as separate devices. Neither Brian nor Shue knows which is more
difficult: getting Microsoft to change an existing implementation of
SBP-2 or getting them to add a (new) different protocol.


Brian was confused as to why Nagasaka-san feels that crediting is so
important. Brian says that 1394 should be able to support the flow
control using something other than credit-based control. With SBP-2, if
each channel (logical unit service) has a different login, he believes
this should eliminate any problems that Nagasaka-san is worried about. 


Randy Turner is concerned that our requirements-especially regarding the
enumeration of different logical units-may conflict with Microsoft's
plans for their implementation of SBP-2 support. He is very anxious that
we do not compromise our 1394 PWG requirements simply because of current
OS support limitations.


Nagasaka-san (Brian?) said that someone from Microsoft will join the next 1394
PWG meeting. (GL - I've confirmed that Hitoshi Sekine plans to attend)


What should we have on the Austin meeting agenda? Suggestions included
the following:
	*	Summary of e-mail polls for ranking the alternative proposals
	*	Comparison of SBP-2 and DPP vs. the requirements list 
	*	Randy's ideas on creating a "best current practice" for layering above 1394
	*	Walk through scenarios on how a print session over SBP-2 really works: 
		login, print job, reverse channel communication, etc. 
		Start with real simple printer-basic example. 
		We need to work through the assumption of multiple logical units vs. single
		device. Greg Shue volunteered do this.
	*	Multiple logical units and how they are used (may be part of scenario walk-through)


Teleconference adjourned.


Next 1394 PWG Teleconference


None was scheduled. (TBD after Austin - GL)

From gleclair at agentz.com  Thu Feb 26 02:51:18 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Site Updated
Message-ID: <199802251222.VAA22801@smtp.dtinet.or.jp>

Web site updated with various documents, minutes, etc.


If you find something missing, please let me know.


FYI - Made note that FDS work is now primarily part of 1212r work and point off to 1212r group pages.


Regards,
Greg LeClair
greg@erc.epson.com

From atsnaka at bsd.canon.co.jp  Thu Feb 26 03:59:20 1998
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:49 2009
Subject: P1394> EMAIL Poll
In-Reply-To: <01BD4089.E26048A0.gleclair@agentz.com>
Message-ID: <199802260859.RAA24438@bsdmail.bsd.canon.co.jp>

snip>


I changed the order of the questions around to explain my position; 


FIRST,


> 3) Opinions on multiple printing protocols;
> 
  	(   )   There should be ONLY 1 printing protocol in any case and any application.
  	( X )   2 "or more" protocols are ACCEPTABLE if necessary for different situations
  	(   )   I PREFER more than 2 protocols 
  	(   )   Other (describe)__________________
 
 - I do not PREFER it, but I think there will be more than 2 "standard (=non-vendor unique)" 
  printing protocols, for different applications (PC printing, direct-printing, IP1394, AV/C etc.)
  and I do not think it is a good idea to force it to be one at least THIS point in time.


  Based on this thinking, 


I FOCUSED THE SCOPE OF THE REPLY BELOW ON THE WORK OF THE PWG-1394 project,
NOT 1394 PRINTING IN GENERAL, SO MY OPINION BELOW DOES NOT APPLY TO 
PEER TO PEER DIRECT-PRINTING.


> 	What is your opinion on the best way to move the discussion forward?


   - THE PWG-1394 PROJECT SHOULD CONCENTRATE ON PC PRINTING, and
    should aim to nail down the basic PC printing scheme and solve basic issues in 
    a short time period.


    In April of 97, when PWG and PWG-C discussed about the working together,
    it was decided that the PWG would concentrate on PC printing, and the PWG-C
    would concentrate on direct-print. 
    My impression is that the scope of recent discussion in PWG side has become 
    somewhat out of range from the original intent, encompassing the PWG-C's area
    of peer to peer direct-print.  
    The scope of the PWG printing profile should be narrowed to PC printing
    (if not for the final solution, at least until a draft solution stabilizes)
    Even though the charter may note direct printing as a scope, please recall that
    this charter is a unified charter for both PWG and PWG-C, and that is the reason
    for the large scope.  


NOW THE RANKING;


> ===================================================================
> 
> 1. Please rank the following proposals according to your interest level using the following scale ( 10 = High level 
> of interest vs. 0 = No interest).
> 


 	(   )   1284.4 Over Data FIFO Architecture (DFA)
 	(   )   1284.4 Over SBP-2
 	( 3 )   Direct Printing Protocol - (current PWG-C proposal 0.71)
 	(10)   SBP-2 Native - (current PWG proposal 0.1c)
 	(10)   Other (describe)_ HPT proposal by Canon
 


> 2. Please provide background comments on your ranking. 


   -I ranked SBP-2 native related proposals as 10 because
    SBP-2 is a well-defined, good assymetric transport, which
    is suitable for PC printing. Native is the natural way of building
    a efficient upper layer (command set) for SBP-2.


    HPT by Canon is one solution of SBP-2 native, and should be treated 
    equally for comparison and discussion with other SBP-2 native 
    proposals.


    I put in only 3 pts for DPP(Thin protocol) because
    I restricted the reply to the scope of PWG work.
    The 3 pts stands for my opinion that a discussion is valuable to
    consider the THIN protocol (as is) as a PC printing transport 
    candidiate.
    (REASON FOR "AS IS"
     .....In case PWG chooses SBP-2, we still don't intend
     to change the SBP-2 spec itself to achieve printing, right ?
    The thinking is the same for THIN transport. Consideration 
    on using THIN should be made without drastically changing the THIN.
    The changes are probably up to the originators of THIN ->PWG-C.)    


> Why do you prefer to use the given solution?
    -See above         


> 	Does the the given solution meet the existing requirements?


    -Basically, but not all.
     I STILL do not see a really fixed, (voted?) requirement list for PC printing.
     For example, is symmetric a must or want for PC printing ? 
     (incl. the question, how does PWG define symmetric?) 


 > 	What issues are you aware of (if any) with the given solution?


   -Many people mention OS support as one of the main reasons
    for choosing SBP-2,but also mention concern about whether
    the "OS version of SBP-2" is sufficient for printer usage.
    I think this is one issue which should be solved with high 
    priority IF we are going to mention OS support as one of the reasons.
    
> 	Other comments?


    If this was a PWG-"C" poll, my answer would be; 


 	(   )   1284.4 Over Data FIFO Architecture (DFA)
 	(   )   1284.4 Over SBP-2
 	(10)   Direct Printing Protocol - (current PWG-C proposal 0.71)
 	(  )   SBP-2 Native - (current PWG proposal 0.1c)
 	(10)   Other (describe)_ AV/C printing (PWG-C SWG2)




-----------------------------------------
Atsushi Nakamura
-----------------------------------------


BJ Technology Develpoment 22,
Canon Inc.


53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211


tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------

From ueda at pure.cpdc.canon.co.jp  Fri Feb 27 04:03:10 1998
From: ueda at pure.cpdc.canon.co.jp (Shigeru Ueda)
Date: Wed May  6 14:00:49 2009
Subject: P1394>EMAIL Poll
Message-ID: <199802270903.SAA02684@origin.pure.cpdc.canon.co.jp>

1. Please rank the following proposals according to your interest level
using the following scale ( 10 = High level 
of interest vs. 0 = No interest).


	( 3 )   1284.4 Over Data FIFO Architecture (DFA)
	( 0 )   1284.4 Over SBP-2
	( 5 )   Direct Printing Protocol - (current PWG-C proposal 0.71)
	( 7 )   SBP-2 Native - (current PWG proposal 0.1c)
	( 7 )   HPT 




2. Please provide background comments on your ranking. 


.1284.4 Over Data FIFO Architecture (DFA)
  Though the document describing DFA architecture is very poor, there is
  still the possibility that DFA can offer the true symmetrical
  transport.


.1284.4 Over SBP-2
  I think this  is not good (inefficient) as I explained at the  PWG
  meeting held in Nashua last June..
 
. Direct Printing Protocol 
  There is the possibility that DPP can offer true symmetrical transport.
  But DPP is discussed at PWG-C and the requirement of PWG-C is different
  from the one of PWG,so it will be difficult to make DPP to meet the
  requirement of PWG.
 
.SBP-2 Native - (current PWG proposal 0.1c)
  I think SBP-2 Native is the good (not the best) solution for PC-printing.
  But some amendment will be needed.(Especially to "Abort task" method)
 
 .HPT
 I believe that HPT is still the good  solution for PC-printing as SBP-2
 Native.it can offer the same level of service that 1284.4 offers.
 
Why do you prefer to use the given solution?
Why should others consider the given solution?
Does the the given solution meet the existing requirements?
What issues are you aware of (if any) with the given solution?


What is your opinion on the best way to move the discussion forward?
 I think that PWG1394 should concentrate to PC-printing only.
 SBP-2 is the good transport as far as it is used between PC(initiater)
 and Devices(target) on 1394 bus.But it will be also true that many
 Japanese vendors will not use SBP-2 based protocol for their low cost
 scanners,cameras, etc.. That is why over 30 vendors in Japan are
 discussing DPP as the transport for the peripherals of consumer market
 at PWG-C.
 So,PWG1394 should concentrate to PC-printing.
 If there is the printer which wants to talk to Non-PC device like
 low-cost scanner or digital camera,he should talk to by using DPP.
 That means that the printer which wants to talk to PC and Non-PC device
 should have more than 1 protocol.
 
 So,
 3) Opinions on multiple printing protocols; 


  (   )   There should be ONLY 1 printing protocol in any case and any
application. 
  ( X )   2 protocols are ACCEPTABLE if necessary for different
situations 
  (   )   I PREFER more than 2 protocols  
  (   )   Other (describe)__________________ 








----------------------------------------------------------
                Canon inc .
                Office Design Dept.313


                        Sigeru Ueda 


             $B!J(BTEL$B!K(B03-3757-6540(+81-3-3757-6540)
               E-mail : ueda@pure.cpdc.canon.co.jp
-----------------------------------------------------------

From ueda at slab.tnr.sharp.co.jp  Fri Feb 27 18:11:19 1998
From: ueda at slab.tnr.sharp.co.jp (Toru Ueda)
Date: Wed May  6 14:00:49 2009
Subject: P1394> EMAIL Poll
In-Reply-To: <01BD4089.E26048A0.gleclair@agentz.com>
Message-ID: <9802270911.AA06141@slab.slab.tnr.sharp.co.jp>

---- 


1 question concerning the scope of this poll ; 
 1) What is the scope of the "interest level"? PC printing, Consumer  
     peer to peer printing, or both ? 


The answer is for PC printing. 


Also,  
If I was in charge of this poll, I would add another question to the survey. 
3) Opinions on multiple printing protocols; 


  (   )   There should be ONLY 1 printing protocol in any case and any
application. 
  ( X )   2 protocols are ACCEPTABLE if necessary for different
situations


  (   )   I PREFER more than 2 protocols  
  (   )   Other (describe)__________________ 


Of course one protocol which covers all applications is a kind of dream
but in the current situation, it seems too far to me.
We have (at least) two protocols for printing, one is for
direct printing and another is for PC printing.


On Mon, 23 Feb 1998 18:35:51 -0800
"Gregory A. LeClair" <gleclair@agentz.com> wrote:


> ===================================================================




> 1. Please rank the following proposals according to your interest level using the following scale ( 10 = High level 
> of interest vs. 0 = No interest).
> 
	( 2 )   1284.4 Over Data FIFO Architecture (DFA)
	( 0 )   1284.4 Over SBP-2
	( 5 )   Direct Printing Protocol - (current PWG-C proposal 0.71)
	( 10)   SBP-2 Native - (current PWG proposal 0.1c)
	(   )   Other (describe)__________________
> 
> 2. Please provide background comments on your ranking. 
> 
> 	Why do you prefer to use the given solution?
	SBP2 is a excellent protocol for initiator-target model.
	This covers memory allocation, flow control and more.


> 	Why should others consider the given solution?
	DPP's focus is simple direct printing. This might not be suitable
	for PC printers.
	1284.4 is a quite good protocol but is not well-suited for the
	 protocol over SBP2.
	
> 	Does the the given solution meet the existing requirements?
	YES.
	
> 	What issues are you aware of (if any) with the given solution?
	The following is my technical impression. 
	Because I'm not an expert of PC printing, this opinion might be
	ridiculous. I don't intend to disturb PWG's symmetric protocol
	discussion.
	
	SBP2 with cross logins seems complicated idea.
	To support both a target function and a initiator function of
	SBP2 in one device is no problem.
	However these should be used separately. If one application (or
	one logical connection) uses both, many additional sequences
	must be defined.
	
	For example, in the login sequence, if login from node A to node
	B is OK but login from B to A is not OK, one sample sequence is
	the following.
	
	1) Application in node A calls connect routine.
		1-1) A --- SBP2 login --> B
		1-2) A <-- Login Ack  <-- B
		1-3) A <-- SBP2 login <-- B
		1-4) A --> No response--> B
		1-5) A --> SBP2 logout<-- B


	To get a symmetrical bi-directional channel, this may be 
complicated.


Toru Ueda
Sharp Corp.
Software Labs.

From shimura at pure.cpdc.canon.co.jp  Fri Feb 27 07:05:48 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Re: Native SBP-2 Printer Profile?
In-Reply-To: <199802202015.MAA18197@hpsdlgj1.sdd.hp.com>
Message-ID: <199802271205.VAA17517@slant1.pure.cpdc.canon.co.jp>

Hi,


I have a question regarding the necessity of buffer identifier (or
sequence number) in the ORB command.


In the Annex E. of SBP-2 Rev.3a, the following is described.


  E.4 Status FIFO write request
   When the target detects a missing acknowledgement after a write to
   an initiator's status FIFO, it should take no error recovery
   actions. Any target resources allocated to the ORB should be
   released by the target. The initiator is expected to discover the
   error by means of a higher-level mechanism, such as a command
   time-out and to initiate appropriate error recovery. The nature of
   the error recovery undertaken by the initiator likely depends
   whether or not the target processes ORB's and returns their status
   in order, but in any event is beyond the scope of this description.


If this happened and followed by bus reset, it seems initiator loses
synchronization with target. I suppose the sequence number or
something may be useful in this situation to avoid duplicated ORB.


Am I missing something?


Akihiro Shimura


On Fri, 20 Feb 1998 12:15:40 -0800 (PST)
Greg Shue <gregs@sdd.hp.com> wrote:


> > 
> > I don't believe the entire printer model has to be standardized,
> > we just need a way to communicate basic operational steps, such
> > as start a job, report status, report errors, etc.  Within such
> > a framework, and number of formats, protocols, etc, are possible.
> 
> Agreed.  The PWG has already agreed (?) that a print job is
> a separate data path than device status.  No one has raised
> the topic of reporting formatting errors.  I don't know if
> it's a general issue or not.
> 
> > If after running out of paper you'd like to load more and continue,
> > you can just requeue the same ORB and let the printer pick up from
> > where it left off.  (I would design the native printer profile so
> > that the printer can remember where it was in that ORB, and not
> > execute the same parts twice.)  My statement shouldn't be read to
> > imply that any error causes a total shutdown - just that the
> > printer will wait for further instructions.
> > 
> > --------------------------------------
> > Eric Anderson            ewa@apple.com
> > Apple Computer, Inc.      408-974-8187
> > --------------------------------------
> 
> I was trying to avoid the printer having to verify that the
> same ORB was requeued and remembering the offset into it. I've
> always had the impression that it would be more problematic
> than breaking the data up into transport-level blocks.  Perhaps
> you can convince me otherwise.  Would you try?
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> Office Products Division			gregs@sdd.hp.com
> ----------------------------------------------------------------
> 



--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.


From shimura at pure.cpdc.canon.co.jp  Fri Feb 27 08:33:42 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Re: How the solution B works?
In-Reply-To: <199802172235.OAA08667@hpsdlgj1.sdd.hp.com>
Message-ID: <199802271333.WAA17579@slant1.pure.cpdc.canon.co.jp>

Hi,


I have estimated the worst case (probably) in solution B.


At first, let me assume "n" write (initiator-to-target) ORB's are in
the task list, and the target has a small data available to the
initiator while the target is processing 1st write ORB in the list.
After finishing 1st write ORB, the target finds deadlock condition
(because the target is almost buffer full status by previous ORB's)
and aborts "n-1" write ORB's in the list.
The initiator appends a read (target-to-initiator) ORB in the task
list, and the target completes this ORB with no more data condition.
Because there is no available data from the target, the initiator
re-queues "n-1" write ORB's just aborted.
The target has another small data available to the initiator while the
target is processing 2nd write ORB in the list.
After finishing 2nd write ORB, the target finds deadlock condition and
aborts "n-2" write ORB's in the list.
The initiator appends a read (target-to-initiator) ORB in the task
list, and the target completes this ORB with no more data condition.
Because there is no available data from the target, the initiator
re-queues "n-2" write ORB's just aborted......, and so on.


This scenario requires the SECOND POWER order ("n-1"+"n-2"+...+1) of
aborts.


Because 1284.4 IS providing independent data flow in each direction in
LINEAR order, this scenario is likely to happen on the applications
expecting independent data flow in each direction(in linear order).


Though "Aborting task" may not be so many if "n" is small enough, "n"
will depend on its bandwidth and latency requirement, but not on the
transport behavior.


I don't want to restrict every applications implicitly to work around
this transport behavior.


So, I prefer to make a login per direction because it provides
independent flow in each direction in LINEAR order, though there is an
issue how to bundle two logins.


I think having multiplexing in two places (multiplex sessions by
logical unit and multiplex each directions by abort) makes the
protocol more complex.


Is this estimation correct? Any comments?


Akihiro Shimura




On Tue, 17 Feb 1998 14:35:26 -0800 (PST)
Greg Shue <gregs@sdd.hp.com> wrote:
(snip)
> Akihiro Shimura wrote: (reformatted)
> > It seems natural to make two independent logins for each
> > direction, one for down-link and another for up-link by using the
> > idea to map them into logical units.  Furthermore, by extending
> > this to allow to allocate up-link in reverse fashion (i.e., the
> > target of down-link makes a login to the initiator of down-link),
> > the link between two devices will become symmetric if both ends
> > have both initiator and target functionality.
> 
> [Greg Shue]
> The idea of an task list for each direction to provide independent
> data flow is a natural one.  The idea of requiring cross logins
> (or 2 logins to the same device) would accomplish this.  Having
> each login and task list on a separate device provides symmetry.
> 
> This is very similar to Alan's DFA proposal.  It is just abstracted
> one layer.  The packet "write" is accomplished by an ORB rather than
> an MTU.  The size of the FIFO is limited to the max size of the data
> referenced by the ORB.
> 
> Can multiplexing of logical channels be provided on top of this?
> Yes, but this could also be the communications profile for
> services which are in independent Unit directories.
> 
> The ISSUE:
>   The logins must deal with access control separately even though
>   they are coupled together at the next higher layer.  No one has
>   come up with a proposal to manage this.
(snip)

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.


From shimura at pure.cpdc.canon.co.jp  Fri Feb 27 10:24:46 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:49 2009
Subject: P1394> EMAIL Poll
In-Reply-To: <01BD4089.E26048A0.gleclair@agentz.com>
Message-ID: <199802271524.AAA17630@slant1.pure.cpdc.canon.co.jp>

On Mon, 23 Feb 1998 18:35:51 -0800
"Gregory A. LeClair" <gleclair@agentz.com> wrote:


1. Please rank the following proposals according to your interest
level using the following scale ( 10 = High level of interest vs. 0 =
No interest).


	( 0 )   1284.4 Over Data FIFO Architecture (DFA)
	( 0 )   1284.4 Over SBP-2
	( 5 )   Direct Printing Protocol - (current PWG-C proposal 0.71)
	( 7 )   SBP-2 Native - (current PWG proposal 0.1c)
	( 9 )   Other --- SBP-2 NON-mirroring
	( 5 )   Other --- SBP-2 mirroring




2. Please provide background comments on your ranking. 


Why do you prefer to use the given solution?
   SBP-2 is well defined for "PC initiator" and "device target"  
   combination by the message passing/shared memory architecture.
   "SBP-2 NON-mirroring" means that the initiator makes two logins
   for each data transfer direction to the target.
   Because single SBP-2 initiator/target pair has only initiator's  
   request queue and target's response queue and in-order execution
   model does not allow to multiplex target's  request and initiator's
   response in them, it seems essential to prepare another queue pair
   to achieve bi-directional message passing.


Why should others consider the given solution?
   See above.


What issues are you aware of (if any) with the given solution?
   How to bundle two logins in one connection.
  
>From: Atsushi_Nakamura <atsnaka@bsd.canon.co.jp>
 To: "gleclair@agentz.com" <gleclair@agentz.com>, "'1394 PWG'" <p1394@pwg.org>
 Date: Tue, 24 Feb 1998 12:53:04 +0900
 Subject: P1394> Scope of EMAIL Poll


3) Opinions on multiple printing protocols;
	(   )   There should be ONLY 1 printing protocol in any case
                and any application.
	(   )   2 protocols are ACCEPTABLE if necessary for different
                situations
 	(   )   I PREFER more than 2 protocols 
 	( O )   Other --- Even more than 2 protocols are ACCEPTABLE
                          if necessary for different situations



--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.


From gregs at sdd.hp.com  Fri Feb 27 15:12:29 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Re: Native SBP-2 Printer Profile?
In-Reply-To: <199802271205.VAA17517@slant1.pure.cpdc.canon.co.jp>
Message-ID: <199802272012.MAA08015@hpsdlgj1.sdd.hp.com>

> 
> Hi,
> 
> I have a question regarding the necessity of buffer identifier (or
> sequence number) in the ORB command.
> 
> In the Annex E. of SBP-2 Rev.3a, the following is described.
> 
>   E.4 Status FIFO write request
>    When the target detects a missing acknowledgement after a write to
>    an initiator's status FIFO, it should take no error recovery
>    actions. Any target resources allocated to the ORB should be
>    released by the target. The initiator is expected to discover the
>    error by means of a higher-level mechanism, such as a command
>    time-out and to initiate appropriate error recovery. The nature of
>    the error recovery undertaken by the initiator likely depends
>    whether or not the target processes ORB's and returns their status
>    in order, but in any event is beyond the scope of this description.
> 
> If this happened and followed by bus reset, it seems initiator loses
> synchronization with target. I suppose the sequence number or
> something may be useful in this situation to avoid duplicated ORB.
> 
> Am I missing something?
> 
> Akihiro Shimura


I know you caught something which I have missed.  I wasn't fully
aware of this clause, and it certainly needs to be addressed to
deliver reliability.


The buffer identifier (or sequence number) helps filter out
redundant buffers, which solves part of the problem.  The more
signficant issue is:


  How does a PWG Imaging Communications Profile initiator
  _detect_ that it should try to recover from a lost Status_FIFO
  write acknowledge?


    The Status_FIFO is written to:
      A) at the end of every Management Agent request
	  (so this should be defined by SBP-2 for Management
	   Agent commands.  I don't recall that it is.)


      B) at the end of every request on the task list
	  (within the scope of the device profile)


      C) as the mechanism for communicating Unsolicited Status


I'll be thinking about these for a while ...



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


From gregs at sdd.hp.com  Fri Feb 27 15:28:01 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Re: How the solution B works?
In-Reply-To: <199802271333.WAA17579@slant1.pure.cpdc.canon.co.jp>
Message-ID: <199802272028.MAA08032@hpsdlgj1.sdd.hp.com>

Akihiro Shimura wrote:


> I have estimated the worst case (probably) in solution B.
> 
(snip)
> 
> This scenario requires the SECOND POWER order ("n-1"+"n-2"+...+1) of
> aborts.


Yes, this is the worst case.  And, it only occurs with
an unexpected data flow in the reverse direction.  So far
this has been considered an exception, not typical behavior.
So, I didn't mind poor performance for exception handling.
We never said that SBP-2 worked well for the atypical data flow.


> Because 1284.4 IS providing independent data flow in each direction in
> LINEAR order, this scenario is likely to happen on the applications
> expecting independent data flow in each direction(in linear order).


True.
Are these applications of high bandwidth?
Are they typical?
I don't think that attribute is typical of the device models
used for PC printing (or PC scanning).


> Though "Aborting task" may not be so many if "n" is small enough, "n"
> will depend on its bandwidth and latency requirement, but not on the
> transport behavior.
> 
> I don't want to restrict every applications implicitly to work around
> this transport behavior.


They don't have to.  That is why the behavior is hidden in the
transport layer.  If the data flow goes as expected, things work
smoothly.  If it doesn't then the transport is basically doing
exception handling beneath the application.  Also, the transport
driver can easily keep "n" small (1-4) without the application
caring or knowing.


> So, I prefer to make a login per direction because it provides
> independent flow in each direction in LINEAR order, though there is an
> issue how to bundle two logins.
> 
> I think having multiplexing in two places (multiplex sessions by
> logical unit and multiplex each directions by abort) makes the
> protocol more complex.
> 
> Is this estimation correct? Any comments?


Yes, please make a proposal for supporting dual fetch-agents in
the target under one login, and a plan for getting major OS vendors
to support it, and I'll be happy.  I've just by trying to
address the less formidable problem of using the SBP-2 protocol
and the implemented drivers without change.  :-)


While you're at it, how about figuring out a means of supporting
a fetch agent on each node under a single login.  It's a
related problem that we keep coming back to.  :-)


> Akihiro Shimura
> 
> 
> On Tue, 17 Feb 1998 14:35:26 -0800 (PST)
> Greg Shue <gregs@sdd.hp.com> wrote:
> (snip)
> > Akihiro Shimura wrote: (reformatted)
> > > It seems natural to make two independent logins for each
> > > direction, one for down-link and another for up-link by using the
> > > idea to map them into logical units.  Furthermore, by extending
> > > this to allow to allocate up-link in reverse fashion (i.e., the
> > > target of down-link makes a login to the initiator of down-link),
> > > the link between two devices will become symmetric if both ends
> > > have both initiator and target functionality.
> > 
> > [Greg Shue]
> > The idea of an task list for each direction to provide independent
> > data flow is a natural one.  The idea of requiring cross logins
> > (or 2 logins to the same device) would accomplish this.  Having
> > each login and task list on a separate device provides symmetry.
> > 
> > This is very similar to Alan's DFA proposal.  It is just abstracted
> > one layer.  The packet "write" is accomplished by an ORB rather than
> > an MTU.  The size of the FIFO is limited to the max size of the data
> > referenced by the ORB.
> > 
> > Can multiplexing of logical channels be provided on top of this?
> > Yes, but this could also be the communications profile for
> > services which are in independent Unit directories.
> > 
> > The ISSUE:
> >   The logins must deal with access control separately even though
> >   they are coupled together at the next higher layer.  No one has
> >   come up with a proposal to manage this.
> (snip)
> --
>  Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
>  Office Imaging Products Development Center 3
>  CANON INC.
> 





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


From colinws at bristol.st.com  Fri Feb 27 16:46:35 1998
From: colinws at bristol.st.com (Colin Whitby-strevens)
Date: Wed May  6 14:00:49 2009
Subject: P1394> EMAIL Poll
In-Reply-To: <P1394> EMAIL Poll>
Message-ID: <E0y8Xc3-0003dM-00.1998-02-27-21-46-35@thistle.inmos.co.uk>

> ===================================================================
> 
> 1. Please rank the following proposals according to your interest level
>  using the following scale ( 10 = High level 
> of interest vs. 0 = No interest).
> 
>       (   )   1284.4 Over Data FIFO Architecture (DFA)
>       (   )   1284.4 Over SBP-2
>       (   )   Direct Printing Protocol - (current PWG-C proposal 0.71)
>       ( 10)   SBP-2 Native - (current PWG proposal 0.1c)
>       (   )   Other (describe)__________________
> 
> 2. Please provide background comments on your ranking. 
> 
>       Why do you prefer to use the given solution?
PC:- synergy with other host/target standards - reuse the expertise, 
experience, software and silicon design;
good for the whole range from cheap-cheap devices to printer servers;
when interfacing by bus, use a bus-based protocol;
need a decision quickly to enable the market;


> 
>       Why should others consider the given solution?
Everyone will benefit by backing a single solution;


> 
>       Does the the given solution meet the existing requirements?
I believe so


> 
>       What issues are you aware of (if any) with the given solution?
Less than optimal for Direct Print.


> 
>       What is your opinion on the best way to move the discussion forward?
Consensus as a result fo this vote!!!!


> 
>       Other comments?
> 
> 
> 
> 
> 



--
Colin Whitby-Strevens             email:colinws@bristol.st.com
SGS-THOMSON Microelectronics      tel: +44 1454 611500
1000, Aztec West                  fax: +44 1454 617910
Almondsbury
BRISTOL BS32 4SQ 
UK


From fzhao at ix.netcom.com  Fri Feb 27 18:08:18 1998
From: fzhao at ix.netcom.com (Frank Zhao)
Date: Wed May  6 14:00:49 2009
Subject: P1394> EMAIL Poll
In-Reply-To: <P1394> EMAIL Poll>
Message-ID: <E0y8Xc3-0003dM-00.1998-02-27-21-46-35@thistle.inmos.co.uk>

On Mon, 23 Feb 1998 18:35:51 -0800
"Gregory A. LeClair" <gleclair@agentz.com> wrote:


1. Please rank the following proposals according to your interest
level using the following scale ( 10 = High level of interest vs. 0 =
No interest).


        (   )   1284.4 Over Data FIFO Architecture (DFA)
        (   )   1284.4 Over SBP-2
        ( 7 )   Direct Printing Protocol - (current PWG-C proposal 0.71)
        ( 10 )   SBP-2 Native - (current PWG proposal 0.1c)
        (   )   Other --- SBP-2 NON-mirroring
        (   )   Other --- SBP-2 mirroring




2. Please provide background comments on your ranking. 


Why do you prefer to use the given solution?


   DPP can be a very good solution for consumer products, but may not
necessarily be suitable for office applications. I think the DPP command
set is very interesting. It can be a basis for setting up a common API
set for different transport protocols.
   Since PWG-C is working hard on DPP for consumer products, PWG should
focus on high performance solutions (it may cost more than DPP
solution). I think SBP-2 is the best cadidate so far for this category.


Why should others consider the given solution?
   See above.


What issues are you aware of (if any) with the given solution?
   How to solve the "peer-to-peer" connection problem.
  


3) Opinions on multiple printing protocols;
        (   )   There should be ONLY 1 printing protocol in any case
                and any application.
        ( 8 )   2 protocols are ACCEPTABLE if necessary for different
                situations
        (   )   I PREFER more than 2 protocols 
        (   )   Other --- Even more than 2 protocols are ACCEPTABLE
                          if necessary for different situations



-- 
**************************************************************
*  Frank Z. Zhao                                             *
*  Panasonic/MTDC-West                          Panazip: 24  *
*  4701 Patrick Henry Drive             Tel: (408) 653-4077  *
*  Suite 1501                           Fax: (408) 654-9714  *
*  Santa Clara, CA 95054         Email: fzhao@ix.netcom.com  *
**************************************************************


From carterk at us.ibm.com  Sat Feb 28 15:25:20 1998
From: carterk at us.ibm.com (Keith Carter)
Date: Wed May  6 14:00:49 2009
Subject: P1394> PING list for PWG meetings
Message-ID: <E0y8Xc3-0003dM-00.1998-02-27-21-46-35@thistle.inmos.co.uk>

Attached is the current ping list for the PWG meetings.  I did not request
pings for the UPD meeting at 7:00PM CST on Tuesday, March 3 - whomever is
interested, please show up at the Texas 5 meeting room.


Have a super day,


Keith Carter
Senior Software Engineer
IBM Network Computing Software Division in Austin, Texas
internet email: carterk@us.ibm.com
Notes email: Keith Carter/Austin/IBM@IBMUS
phone: 512-838-2155
tie-line: 678-2155
fax: 512-838-0169


PWG PING LIST AS OF 2/28/98


Name                 Company      PWG   Hyatt?  Arrive  Depart


Chuck Adams          Tektronix    3/4-6   Y     3/3     3/6
Shivaun Albright     HP           3/4-5   Y     3/3     3/5
Carlos Becerra       HP           3/6     Y     3/5     3/6
Ron Bergman          Dataproducts 3/4-6   Y     3/3     3/6
Brian Batchelder     HP           3/2-3   Y     3/1     3/4
Alan Berkema         HP           3/2-3   N     - -     - -
Keith Carter         IBM          3/4-5   N     - -     - -
Roger deBry          IBM          3/4-5   Y     3/3     3/5
Mabry Dozier         QMS Inc.     3/4-6   Y     3/3     3/6
Mark Edmead          Warp Nine    3/2-3   Y     3/1     3/4
Lee Farrell          Canon        3/2-6   Y     3/1     3/6
Richard Hart         Digital      3/4-6   Y     3/3     3/6
Tom Hastings         XEROX        3/4-6   Y     3/3     3/6
Marvin Heffler       IBM          3/4-5   N     - -     - -
Bob Herriot          SUN          3/4-5   Y     3/3     3/6
Osamu Hirata         Canon        3/2-3   Y     3/1     3/4
Stephen Holmstead    HP           3/2-3   Y     3/1     3/3
Henrik Holst         i-data Int'l 3/2-5   Y     3/1     3/6
Takashi Isoda        Canon        3/2-3   Y     3/1     3/5
Scott Isaacson       Novell       3/4-5   Y     3/3     3/5
David Kellerman      Northlake SW 3/4-6   Y     3/3     3/6
Greg LeClair         EPSON        3/2-4   Y     3/1     3/4
Harry Lewis          IBM          3/4-6   Y     3/3     3/6
Carl-Uno Manros      XEROX        3/4-5   Y     3/3     3/5
Jay Martin           Underscore   3/4-5   Y     3/3     3/6
Peter Michalek       Shinesoft    3/4-5   N     - -     - -
Paul Moore           Microsoft    3/4     Y     3/3     3/4
Yoshinori Murakami   EPSON        3/2-3   Y     3/1     3/4
Fumio Nagasaka       EPSON        3/2-4   Y     3/1     3/5
Bob Pentecost        HP           3/4-6   Y     3/3     3/6
Yuji Sasaki          - - - -      3/2-5   N     - -     - -
Kris Schoff          HP           3/4-5   ?     ?       ?
Hitoshi Sekine       Microsoft    3/2-3   Y     3/1     3/4
Akihiro Shimura      Canon        3/2-3   Y     3/1     3/5
Greg Shue            HP           3/2-3   Y     3/1     3/3
Larry Stein          Warp Nine    3/2-3   Y     3/1     3/4
Philip Thambidurai   Okidata     3/3-5   Y     3/2     3/6
Jerry Thrasher       Lexmark      3/2-3   Y     3/1     3/4
Randy Turner         Sharp Labs   3/2-5   Y     3/1     3/6
Bill Wagner          OSICOM/DPI   3/2-6   Y     3/2     3/6
Jim Walker           DAZEL        3/4-6   N     - -     - -
Don Wright           Lexmark      3/2-6   Y     3/1     3/6
Lloyd Young          Lexmark      3/4-6   Y     3/3     3/6
Peter Zehler         XEROX        3/4-5   Y     3/3     3/6




PWG Meeting Confirmed Attendance by Date


P1394  P1394 IPP   IPP   JMP/FIN
3/2    3/3   3/4   3/5   3/6
20     21    32    29    14


Additional people who might attend.  I do not know which meetings they will
attend.


Mike Fenelon         Microsoft    ?       ?     ?       ?
? Shockey            JRL Systems  ?       N     - -     - -

From mark at mtesoft.com  Sat Feb 28 17:28:39 1998
From: mark at mtesoft.com (Mark T. Edmead)
Date: Wed May  6 14:00:49 2009
Subject: P1394> RE: PWG> PING list for PWG meetings
Message-ID: <E0y8Xc3-0003dM-00.1998-02-27-21-46-35@thistle.inmos.co.uk>

Keith:


Unfortunately, due to my being sick with the flu, I  will have to cancel my trip to Austin...


--Mark




****************************************************************
Mark T. Edmead
MTE Software, Inc.
Microsoft Windows Systems Design and Engineering Consultants
Microsoft Certified Solution Providers
3645 Ruffin Road, Suite 350
San Diego, CA 92123
(619) 292-2050
(619) 292-5977 FAX
http://www.mtesoft.com
e-mail: mark@mtesoft.com   
*********************************************************
            _\^|^/_
             (o  o)
 --o0O0----(_)----0O0o--






On Saturday, February 28, 1998 12:25 PM, Keith Carter [SMTP:carterk@us.ibm.com] wrote:
> Attached is the current ping list for the PWG meetings.  I did not request
> pings for the UPD meeting at 7:00PM CST on Tuesday, March 3 - whomever is
> interested, please show up at the Texas 5 meeting room.
> 
> Have a super day,
> 
> Keith Carter
> Senior Software Engineer
> IBM Network Computing Software Division in Austin, Texas
> internet email: carterk@us.ibm.com
> Notes email: Keith Carter/Austin/IBM@IBMUS
> phone: 512-838-2155
> tie-line: 678-2155
> fax: 512-838-0169
> 
> PWG PING LIST AS OF 2/28/98
> 
> Name                 Company      PWG   Hyatt?  Arrive  Depart
> 
> Chuck Adams          Tektronix    3/4-6   Y     3/3     3/6
> Shivaun Albright     HP           3/4-5   Y     3/3     3/5
> Carlos Becerra       HP           3/6     Y     3/5     3/6
> Ron Bergman          Dataproducts 3/4-6   Y     3/3     3/6
> Brian Batchelder     HP           3/2-3   Y     3/1     3/4
> Alan Berkema         HP           3/2-3   N     - -     - -
> Keith Carter         IBM          3/4-5   N     - -     - -
> Roger deBry          IBM          3/4-5   Y     3/3     3/5
> Mabry Dozier         QMS Inc.     3/4-6   Y     3/3     3/6
> Mark Edmead          Warp Nine    3/2-3   Y     3/1     3/4
> Lee Farrell          Canon        3/2-6   Y     3/1     3/6
> Richard Hart         Digital      3/4-6   Y     3/3     3/6
> Tom Hastings         XEROX        3/4-6   Y     3/3     3/6
> Marvin Heffler       IBM          3/4-5   N     - -     - -
> Bob Herriot          SUN          3/4-5   Y     3/3     3/6
> Osamu Hirata         Canon        3/2-3   Y     3/1     3/4
> Stephen Holmstead    HP           3/2-3   Y     3/1     3/3
> Henrik Holst         i-data Int'l 3/2-5   Y     3/1     3/6
> Takashi Isoda        Canon        3/2-3   Y     3/1     3/5
> Scott Isaacson       Novell       3/4-5   Y     3/3     3/5
> David Kellerman      Northlake SW 3/4-6   Y     3/3     3/6
> Greg LeClair         EPSON        3/2-4   Y     3/1     3/4
> Harry Lewis          IBM          3/4-6   Y     3/3     3/6
> Carl-Uno Manros      XEROX        3/4-5   Y     3/3     3/5
> Jay Martin           Underscore   3/4-5   Y     3/3     3/6
> Peter Michalek       Shinesoft    3/4-5   N     - -     - -
> Paul Moore           Microsoft    3/4     Y     3/3     3/4
> Yoshinori Murakami   EPSON        3/2-3   Y     3/1     3/4
> Fumio Nagasaka       EPSON        3/2-4   Y     3/1     3/5
> Bob Pentecost        HP           3/4-6   Y     3/3     3/6
> Yuji Sasaki          - - - -      3/2-5   N     - -     - -
> Kris Schoff          HP           3/4-5   ?     ?       ?
> Hitoshi Sekine       Microsoft    3/2-3   Y     3/1     3/4
> Akihiro Shimura      Canon        3/2-3   Y     3/1     3/5
> Greg Shue            HP           3/2-3   Y     3/1     3/3
> Larry Stein          Warp Nine    3/2-3   Y     3/1     3/4
> Philip Thambidurai   Okidata     3/3-5   Y     3/2     3/6
> Jerry Thrasher       Lexmark      3/2-3   Y     3/1     3/4
> Randy Turner         Sharp Labs   3/2-5   Y     3/1     3/6
> Bill Wagner          OSICOM/DPI   3/2-6   Y     3/2     3/6
> Jim Walker           DAZEL        3/4-6   N     - -     - -
> Don Wright           Lexmark      3/2-6   Y     3/1     3/6
> Lloyd Young          Lexmark      3/4-6   Y     3/3     3/6
> Peter Zehler         XEROX        3/4-5   Y     3/3     3/6
> 
> 
> PWG Meeting Confirmed Attendance by Date
> 
> P1394  P1394 IPP   IPP   JMP/FIN
> 3/2    3/3   3/4   3/5   3/6
> 20     21    32    29    14
> 
> Additional people who might attend.  I do not know which meetings they will
> attend.
> 
> Mike Fenelon         Microsoft    ?       ?     ?       ?
> ? Shockey            JRL Systems  ?       N     - -     - -

From gleclair at agentz.com  Sun Mar  1 17:04:32 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Site Update - Latest Profile Rev 0.1d Posted
Message-ID: <E0y8Xc3-0003dM-00.1998-02-27-21-46-35@thistle.inmos.co.uk>

Posted the Rev 0.1d profile with change bars this afternoon before departing to Austin.


Regards,
Greg LeClair

From ewa at apple.com  Wed Mar  4 00:21:55 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:49 2009
Subject: P1394> EMAIL Poll
In-Reply-To: <P1394> EMAIL Poll>
Message-ID: <B12232AC-135504@17.219.105.1>

> During the 1394 PWG 2/23 telecon, it was suggested we undertake an non-
> binding email poll to 
> gauge interest in various proposals being considered by the working
group.
> 
> Please forward your reply to the 1394 PWG reflector - p1394@pwg.org
> 
> If possible, please reply by Friday, February 27th, 1998.


Oops, it's March 3 already.  Sorry!


> ===================================================================
> 
> 1. Please rank the following proposals according to your interest level
using
> the following scale ( 10 = High level 
> of interest vs. 0 = No interest).
> 
> 	(   )   1284.4 Over Data FIFO Architecture (DFA)
> 	(   )   1284.4 Over SBP-2
> 	(   )   Direct Printing Protocol - (current PWG-C proposal 0.71)
> 	(10 )   SBP-2 Native - (current PWG proposal 0.1c)
> 	(   )   Other (describe)__________________


I haven't studied PWG 0.1c (or 0.1d) in detail, but a native SBP-2
printing protocol is most interesting to me.


> 2. Please provide background comments on your ranking. 
> 
> 	Why do you prefer to use the given solution?
> 	Why should others consider the given solution?


SBP-2 offers the best performance and the best fit with 1394.
It leads us in a direction that will scale well over many years.
It is also easy for OS vendors to support well.


> 	Does the the given solution meet the existing requirements?


I believe that SBP-2, with a single login, can meet all of the
existing requirements.  However, I haven't seen a concise report
of those requirements, nor have I been able to participate in
depth, so I could be wrong.


> 	What issues are you aware of (if any) with the given solution?


SBP-2 is still hard to understand.  Since so many people have
supported it in this poll, hopefully more clear and detailed
proposals will start to emerge.


> 	What is your opinion on the best way to move the discussion forward?


This poll seems to help a lot.  I would like to see Microsoft
continue to participate more in the discussion.


> 3) Opinions on multiple printing protocols;
> 
>  	(   )   There should be ONLY 1 printing protocol in any case and any
>            application.
>  	(   )   2 protocols are ACCEPTABLE if necessary for different
situations
>  	(   )   I PREFER more than 2 protocols 
>  	(   )   Other (describe)__________________


I think that the reality is that we will see several protocols at
first, including SBP2, IP1394, proprietary, and DPP.  Then after
some time, we will see even more new protocols (many proprietary).
But only a small number of those protocols will dominate, being
supported by almost all printers.  Probably this will include SBP2,
maybe IP1394, and probably DPP or something similar.  When we have
a small number of protocols that dominate, then most people can
start to benefit from common protocols and interoperability, and
this will further strengthen the use of a small set of core
protocols.


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.      408-974-8187
--------------------------------------

From gleclair at agentz.com  Fri Mar  6 15:13:19 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:49 2009
Subject: P1394> Site Update - Austin Meeting
Message-ID: <B12232AC-135504@17.219.105.1>

The 1394 PWG web site has been updated with minutes, comparison tables, requirements, and the presentation 
on the SBP-2 profile work made by Greg Shue.


Please send comments to the reflector.


Thanks,
Greg LeClair
greg@erc.epson.com

From Nagasaka.Fumio at exc.epson.co.jp  Sun Mar  8 20:14:15 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:49 2009
Subject: P1394> unordered execution
Message-ID: <B12232AC-135504@17.219.105.1>

Does SBP-2 printing protocol need to have out of order execution for ORB
list?


Let me assume one case shown below.
When an initiator puts an input ORB in linked list of ORBs.
[out::ORB] - [out::ORB] - [out::ORB] - [in::ORB] - [out::ORB] $B!D(J
If our SBP-2 target consume them by in order execution. The target
will stop at fourth ORB and will examine whether it has reverse data
or not. It is normal and reasonable.
We might have an analogy of C language source code outlines
below.
{
    putchar(..);    // step 1
    putchar(..);    // step 2
    putchar(..);    // step 3
    getchar( );     // step 4  * INPUT*
    putchar(..);    // step 5
    $B!D(J..(J
}
This process will stop at step 4 and will wait input from TTY.


OK?, next, let$B!G(Js go back to SBP-2 target problem. Even if(J
the target does not have any thing to replay at step 4. The
transport layer shall *not* return $B!H(Jno data flag$B!I(J or $B!H(Jsomething(J
to say there is nothing to reply$B!I(J. The target$B!G(Js application may reply(J
$B!H(Jno data$B!I(J , $B!H(Jthis is data$B!I(J or any thing. This action shall be taken(J
by application$B!G(Js responsibility.(J


By the way, for second case is shown below.
When the initiator has some requests which shall be delivered to
each logical channels like these,$B!D(J(#k means logical channel $B!F(Jk$B!G(J).(J
[out::#1::ORB] - [out::#1::ORB] - [out::#1::ORB] - [in::#2::ORB] -
[out::#1::ORB] $B!D(J
Then if the transport layer in the target waits reverse data is passed
through from the application, fifth ORB which shall be delivered to
channel #1 will not be delivered while the transport is pending on
fourth ORB.


If our SBP-2 protocol may allow out of order execution. The
target is able to consume sixth ORB earlier than fifth. Then
the protocol provides concurrent executive opportunity for
each logical channels.


*	Shall the transport provide out of order execution ?


I want to say no. The initiator shall place [input::ORB] if
it expects reverse data will be sent from the target. I would
like to say, the currents SBP-2 protocol has enough facility.


I am curious why unordered execution is required for $B!F(JHPT$B!G(J.(J
May be there are something I am missing.


Thank you, best regard.
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp

From rturner at sharplabs.com  Mon Mar  9 00:09:48 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:49 2009
Subject: P1394> unordered execution
Message-ID: <B12232AC-135504@17.219.105.1>

See my comments below...


Randy




	-----Original Message-----
	From:	Nagasaka Fumio [SMTP:Nagasaka.Fumio@exc.epson.co.jp]
	Sent:	Sunday, March 08, 1998 5:14 PM
	To:	p1394@pwg.org
	Cc:	PWG-C mailing
	Subject:	P1394> unordered execution


	Does SBP-2 printing protocol need to have out of order execution
for ORB
	list?


	Let me assume one case shown below.
	When an initiator puts an input ORB in linked list of ORBs.
	[out::ORB] - [out::ORB] - [out::ORB] - [in::ORB] - [out::ORB] ?
	If our SBP-2 target consume them by in order execution. The
target
	will stop at fourth ORB and will examine whether it has reverse
data
	or not. It is normal and reasonable.
	We might have an analogy of C language source code outlines
	below.
	{
	    putchar(..);    // step 1
	    putchar(..);    // step 2
	    putchar(..);    // step 3
	    getchar( );     // step 4  * INPUT*
	    putchar(..);    // step 5
	    ?..
	}
	This process will stop at step 4 and will wait input from TTY.


	OK?, next, let?s go back to SBP-2 target problem. Even if
	the target does not have any thing to replay at step 4. The
	transport layer shall *not* return ?no data flag? or ?something
	to say there is nothing to reply?. The target?s application may
reply
	?no data? , ?this is data? or any thing. This action shall be
taken
	by application?s responsibility.


	Yes, the requesting application code would not issue a READ
operation if no application response was expected.  The application
would return an application level response *no-data*, or the application
would return some other appropriate response.




	By the way, for second case is shown below.
	When the initiator has some requests which shall be delivered to
	each logical channels like these,?(#k means logical channel
?k?).
	[out::#1::ORB] - [out::#1::ORB] - [out::#1::ORB] - [in::#2::ORB]
-
	[out::#1::ORB] ?
	Then if the transport layer in the target waits reverse data is
passed
	through from the application, fifth ORB which shall be delivered
to
	channel #1 will not be delivered while the transport is pending
on
	fourth ORB.


	We should never have a single ORB list processing multiple
logical channels. Each ORB list handles a single logical channel, at
least according to the current profile document decisions we have made.




	If our SBP-2 protocol may allow out of order execution. The
	target is able to consume sixth ORB earlier than fifth. Then
	the protocol provides concurrent executive opportunity for
	each logical channels.


	*	Shall the transport provide out of order execution ?


	I want to say no. The initiator shall place [input::ORB] if
	it expects reverse data will be sent from the target. I would
	like to say, the currents SBP-2 protocol has enough facility.


	I am curious why unordered execution is required for ?HPT?.
	May be there are something I am missing.


	Thank you, best regard.
	--------------------------------------------
	-------------------------------
	Fumio Nagasaka
	Epson Software Development Laboratory Inc.
	Tel +81 268 25 4111,  Fax +81 268 25 4627
	E-mail to nagasaka.fumio@exc.epson.co.jp

From rturner at sharplabs.com  Mon Mar  9 01:24:59 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:49 2009
Subject: FW: P1394> unordered execution
Message-ID: <B12232AC-135504@17.219.105.1>

Sorry everyone, my comments on the previous message were not 
Discernable or readable from Nagasaka-san's mail. I've modified the
Message so you can pick out my comments. My comments are 
Marked <RT>


Randy




-----Original Message-----
From:	Turner, Randy [SMTP:rturner@sharplabs.com]
Sent:	Sunday, March 08, 1998 9:10 PM
To:	'Nagasaka Fumio'; p1394@pwg.org
Cc:	PWG-C mailing
Subject:	RE: P1394> unordered execution




See my comments below...
Randy


	-----Original Message-----
	From:	Nagasaka Fumio [SMTP:Nagasaka.Fumio@exc.epson.co.jp]
	Sent:	Sunday, March 08, 1998 5:14 PM
	To:	p1394@pwg.org
	Cc:	PWG-C mailing
	Subject:	P1394> unordered execution


Does SBP-2 printing protocol need to have out of order execution
for ORB
list?
Let me assume one case shown below.
When an initiator puts an input ORB in linked list of ORBs.
[out::ORB] - [out::ORB] - [out::ORB] - [in::ORB] - [out::ORB] ?
If our SBP-2 target consume them by in order execution. The
target
will stop at fourth ORB and will examine whether it has reverse
data
or not. It is normal and reasonable.
We might have an analogy of C language source code outlines below.
	{
	    putchar(..);    // step 1
	    putchar(..);    // step 2
	    putchar(..);    // step 3
	    getchar( );     // step 4  * INPUT*
	    putchar(..);    // step 5
	    ?..
	}
This process will stop at step 4 and will wait input from TTY.
OK?, next, let?s go back to SBP-2 target problem. Even if
the target does not have any thing to replay at step 4. The
transport layer shall *not* return ?no data flag? or ?something
to say there is nothing to reply?. The target?s application may
reply
?no data? , ?this is data? or any thing. This action shall be
taken
by application?s responsibility.


<RT>Yes, the requesting application code would not issue a READ
operation if no application <RT>response was expected.  The application
would return an application level response *no-<RT>data*, or the
application would return some other appropriate response.


By the way, for second case is shown below.
When the initiator has some requests which shall be delivered to
each logical channels like these,?(#k means logical channel
?k?).
[out::#1::ORB] - [out::#1::ORB] - [out::#1::ORB] - [in::#2::ORB]
-
[out::#1::ORB] ?
Then if the transport layer in the target waits reverse data is
passed
through from the application, fifth ORB which shall be delivered
to
channel #1 will not be delivered while the transport is pending
on
fourth ORB.


<RT>We should never have a single ORB list processing multiple logical
channels. Each ORB <RT>list handles a single logical channel, at least
according to the current profile document <RT>decisions we have made.


If our SBP-2 protocol may allow out of order execution. The target is
able to consume sixth ORB earlier than fifth. Then the protocol provides
concurrent executive opportunity for each logical channels.
*	Shall the transport provide out of order execution ?


I want to say no. The initiator shall place [input::ORB] if it expects
reverse data will be sent from the target. I would like to say, the
currents SBP-2 protocol has enough facility.
I am curious why unordered execution is required for ?HPT?.
May be there are something I am missing.
Thank you, best regard.
	--------------------------------------------
	-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp

From shimura at pure.cpdc.canon.co.jp  Mon Mar  9 04:41:46 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:49 2009
Subject: P1394> unordered execution
In-Reply-To: <01376112D7AFD011911E0020AF70BEC5088E81@cpuex1.ued.epson.co.jp>
Message-ID: <199803090941.SAA01254@origin.pure.cpdc.canon.co.jp>

On Mon, 9 Mar 1998 10:14:15 +0900
Nagasaka Fumio <Nagasaka.Fumio@exc.epson.co.jp> wrote:


> I am curious why unordered execution is required for $B!F(BHPT$B!G(B.
> May be there are something I am missing.


The HPT(High Performance Transport) essentially requires unordered
execution model in order to multiplex two independent sequences of
operation requests (read request sequence and write request sequence)
into single linked list of ORB's. In other words, the HPT provides
full duplex communication path (independent flow for each direction)
by using unordered execution model with one fetch agent (one login).


The unordered model under the basic task management model allows the
target to unrestrictedly reorder the active tasks, but does not allow
to append a new task to the task list until all tasks in the current
task set completed.
Though this model will be suitable for multi-cluster or multi-track
access to the disk drive since the disk drive may optimize track
seeking, etc., it will not meet the requirement from multiplexing two
ordered request sequences because it prohibits to append a new task
when previous tasks are in progress.


The SBP-2 describes following sentences as a note.


	"NOTE - In multitasking operating system environments,
	independent execution threads may generate tasks that have
	ordering constraints within each thread but not with respect
	to other threads. If this is the case, an initiator may
	manage the constraints of each thread yet still keep the
	target substantially busy. This avoids the undesirable
	latencies that occur if the target is allowed to become idle
	before new ORB's are signaled."


The HPT uses this model. Essentially, the independent execution
threads are read thread and write thread in the HPT. Each thread
generates tasks that have ordering constraints within each thread but
not with respect to another thread. So, the HPT provides in-order
delivery in each direction while keeping each direction independent.


A certain operating system uses two I/O request queues for each
direction to serve as full duplex. The requests in these I/O request
queues are multiplexed into single linked list of ORB by message(ORB
or status_block, but NOT data itself) flow control in the HPT. The
ordering constraints are maintained in these two I/O request queues
as usual. The status_block returned by the target indicates to which
of the head of these I/O request queues the completed I/O request
belongs. Since the message flow control does not require additional
packet exchange with another peer in the HPT, the flow control does
not have an overhead from the peer's latency.
(The HPT also uses the same mechanism to multiplex multiple channels.)




There will be three places to put multiplexing information for
independent data paths within on using SBP-2.


	a) Data buffer
	b) ORB
	c) 1394 bus address


The protocol uses "a)" will be 1284.4 over SBP-2. 
       (Single fetch agent, single execution agent, data flow control)
The protocol uses "b)" will be HPT.
       (Single fetch agent, independent execution agents, message flow control)
The protocol uses "c)" will be dual login or cross login.
       (Independent fetch agents, independent execution agents)


Since plain SBP-2 provides master controlled half duplex path, the
profile (rev. 0.1d) may be between half duplex "plain SBP-2" and full
duplex "SBP-2 dual or cross login" because it may require some sort
of retries(re-ordering in the initiator) in case of asynchronous back
channel data though it uses ordered model. (Three quarters duplex?)

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.


From shimura at pure.cpdc.canon.co.jp  Mon Mar  9 06:32:36 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:49 2009
Subject: Fw: Re: P1394> unordered execution
In-Reply-To: <01376112D7AFD011911E0020AF70BEC5088E81@cpuex1.ued.epson.co.jp>
Message-ID: <199803091132.UAA01519@origin.pure.cpdc.canon.co.jp>

Oops, I've corrected some errors. Sorry for the duplicated posting.


Forwarded by Akihiro Shimura <shimura@pure.cpdc.canon.co.jp>
---------------- Original message follows ----------------
 From: Akihiro Shimura <shimura@pure.cpdc.canon.co.jp>
 To: Nagasaka Fumio <Nagasaka.Fumio@exc.epson.co.jp>
 Cc: p1394@pwg.org
 Date: Mon, 9 Mar 1998 18:41:46 +0900 (JST)
 Subject: Re: P1394> unordered execution

--


On Mon, 9 Mar 1998 10:14:15 +0900
Nagasaka Fumio <Nagasaka.Fumio@exc.epson.co.jp> wrote:


> I am curious why unordered execution is required for 'HPT'.
> May be there are something I am missing.


The HPT(High Performance Transport) essentially requires unordered
execution model in order to multiplex two independent sequences of
operation requests (read request sequence and write request sequence)
into single linked list of ORB's. In other words, the HPT provides
full duplex communication path (independent flow for each direction)
by using unordered execution model with one fetch agent (one login).


The unordered model under the basic task management model allows the
target to unrestrictedly reorder the active tasks, and the responsibility
for the assurance of data integrity is left with the initiator.


The SBP-2 describes following sentences as a note.


	"NOTE - In multitasking operating system environments,
	independent execution threads may generate tasks that have
	ordering constraints within each thread but not with respect
	to other threads. If this is the case, an initiator may
	manage the constraints of each thread yet still keep the
	target substantially busy. This avoids the undesirable
	latencies that occur if the target is allowed to become idle
	before new ORB's are signaled."


The HPT uses this model. Essentially, the independent execution
threads are read thread and write thread in the HPT. Each thread
generates tasks that have ordering constraints within each thread but
not with respect to another thread. So, the HPT provides in-order
delivery in each direction while keeping each direction independent.


A certain operating system uses two I/O request queues for each
direction to serve as full duplex. The requests in these I/O request
queues are multiplexed into single linked list of ORB by message(ORB
or status_block, but NOT data itself) flow control in the HPT. The
ordering constraints are maintained in these two I/O request queues
as usual. The status_block returned by the target indicates to which
of the head of these I/O request queues the completed I/O request
belongs. Since the message flow control does not require additional
packet exchange with another peer in the HPT, the flow control does
not have an overhead from the peer's latency.
(The HPT also uses the same mechanism to multiplex multiple channels.)




There will be three places to put multiplexing information for
independent data paths within on using SBP-2.


	a) Data buffer
	b) ORB
	c) 1394 bus address


The protocol uses "a)" will be 1284.4 over SBP-2. 
       (Single fetch agent, single execution agent, data flow control)
The protocol uses "b)" will be HPT.
       (Single fetch agent, independent execution agents, message flow control)
The protocol uses "c)" will be dual login or cross login.
       (Independent fetch agents, independent execution agents)


Since plain SBP-2 provides master controlled half duplex path, the
profile (rev. 0.1d) may be between half duplex "plain SBP-2" and full
duplex "SBP-2 dual or cross login" because it may require some sort
of retries(re-ordering in the initiator) in case of asynchronous back
channel data though it uses ordered model. (Three quarters duplex?)

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.


From fumiona at venus.dti.ne.jp  Tue Mar 10 20:13:19 1998
From: fumiona at venus.dti.ne.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:49 2009
Subject: P1394> unordered execution
In-Reply-To: <D10983CAC30DD111B41400805FA6A1C138CF46@admsrvnt02.enet.sharplabs.com>
Message-ID: <199803110113.KAA24604@smtp.dtinet.or.jp>

Dear Randy,
Thank you, you pointed what I want to say.


On Sun, 8 Mar 1998 22:24:59 -0800
"Turner, Randy" <rturner@sharplabs.com> wrote:


> <RT>We should never have a single ORB list processing multiple logical
> channels. Each ORB <RT>list handles a single logical channel, at least
> according to the current profile document <RT>decisions we have made.
> 


We need to invoke some login(s) to make some fetch agents.
I don't like it, because,...


1) Multiple logical channel shell be involved with a LUN.
   For example, FAX LUN may have several logical channels.
   According to the current profile document, we are
   required to invoke login(s) to a LUN or to some LUNs.


2) However Sekine-san told us, a consumer OS invokes one
   login to a LUN.


3) So we need to have a facility to provide MLC in a single
   ORB List.


The current profile document is good and well designed. Even
so we need to revise some points to make it is executable on
existing Operating System.
-----
Fumio Nagasaka
EPSON Software Development Laboratory Inc.,
TEL: +81 268 25-4111 // FAX: +81 268 25-4627
HomePage = http://www.venus.dti.ne.jp/~fumiona/

From gregs at sdd.hp.com  Wed Mar 11 12:07:30 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:49 2009
Subject: P1394> unordered execution
In-Reply-To: <199803110113.KAA24604@smtp.dtinet.or.jp>
Message-ID: <199803111707.JAA05608@hpsdlgj1.sdd.hp.com>

[Shue, Greg]
Your concern comes because you have a new requirement under issue 1:


  multiple channels being _associated_ with a single session (login
  to a LUN).


This should have been brought up many, many months ago.
The current requirements are for multiple _independent_ channels.


No discussion has occurred about what the standard FAX model
should look like.  Apparently your model is different from
others as no one else has raised this requirement.


If we want to have a standard FAX driver stack, then I would
encourage us to start an e-mail discussion about how a standard
FAX device should be modeled.


I'm not suprised that a consumer OS provides one login per LUN.
Nothing has been clearly stated about how SBP-2 LUNs should
be treated.  The Microsoft SBP-2 implementation has it's own
behaviors which must be addressed.  I don't have any issues
with saying that "this is the standard way of supporting XXX
device."


Nothing prevents providing a 1284.4 service on top of the current
proposal.  This may be the direction you choose to go if your FAX
service is modeled as having more than a unidirectional SEND
channel and a unidirectional RECEIVE channel, and you don't want
to model each data source/data sink as a different service.


I have a couple of issues with supporting "MLC" over a single ORB
list, so I'll assume you meant "CBT" (1284.4).  That provision
already exists by using the current proposal in packet mode and
making the supported packet size (per direction) be able to hold
the largest packet transferred in that direction.  Since the
current proposal supports packets of 65535+6 bytes, nothing needs
to be changed.  The nature of CBT will prevent the fetch agent
from blocking while waiting for a data transfer.  No data
transfer commands will be sent which could not be immediatly
processed.  No out-of-order processing is required.




> On Sun, 8 Mar 1998 22:24:59 -0800
> "Turner, Randy" <rturner@sharplabs.com> wrote:
> 
> > <RT>We should never have a single ORB list processing multiple logical
> > channels. Each ORB <RT>list handles a single logical channel, at least
> > according to the current profile document <RT>decisions we have made.
> > 
> 
> We need to invoke some login(s) to make some fetch agents.
> I don't like it, because,...
> 
> 1) Multiple logical channel shell be involved with a LUN.
>    For example, FAX LUN may have several logical channels.
>    According to the current profile document, we are
>    required to invoke login(s) to a LUN or to some LUNs.
> 
> 2) However Sekine-san told us, a consumer OS invokes one
>    login to a LUN.
> 
> 3) So we need to have a facility to provide MLC in a single
>    ORB List.
> 
> The current profile document is good and well designed. Even
> so we need to revise some points to make it is executable on
> existing Operating System.
> -----
> Fumio Nagasaka
> EPSON Software Development Laboratory Inc.,
> TEL: +81 268 25-4111 // FAX: +81 268 25-4627
> HomePage = http://www.venus.dti.ne.jp/~fumiona/
> 
> 





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


From Nagasaka.Fumio at exc.epson.co.jp  Fri Mar 13 05:05:18 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:49 2009
Subject: P1394> unordered execution
Message-ID: <199803111707.JAA05608@hpsdlgj1.sdd.hp.com>

Greg Shue wrote:
> [Shue, Greg]
> Your concern comes because you have a new requirement under issue 1:
>        multiple channels being _associated_ with a single session
(login to a LUN).
> This should have been brought up many, many months ago.


I brought up this idea at 1394 PWG on September 15, 1997.
Please show the meeting minutes posted below.  Was it many,
many months ago?


<<<
ftp://ftp.pwg.org/pub/pwg/p1394/mtg091597/9709_min.pdf


III.B.2 Fumio Nagasaka-Epson
SBP2 Printing Model
Minimal requirements for PC Printing protocol
Multiple Logical Channels
Flow Control
Multiple Hosts Connectivity
Multiple Targets Connectibility
Reconnection after bus reset
Multiplexing to support multiple clients for the transport.
Implementation of multiple logical channels through SBP2
How many logins does one printing session require
    *1-Build MLC internally within one login*
    2-Requires multiple login as same number of logical
           channel
    3-Prioritize logins
>>>


Unfortunately we spent many months getting few results.


Greg Shue wrote:
*	If we want to have a standard FAX driver stack, then I would
*	encourage us to start an e-mail discussion about how a standard
*	FAX device should be modeled.


I just said for example any unit may have multiple logical channels.
Not only printer but also scanner or FAX could have MLC.
I have no urge to discuss FAX driver stack in this e-mail.


Greg Shue wrote: (reformatted)


> $B!D(J.. That provision(J
> already exists by using the current proposal in packet mode and
> making the supported packet size (per direction) be able to hold
> the largest packet transferred in that direction.  Since the
> current proposal supports packets of 65535+6 bytes, nothing needs
> to be changed.  The nature of CBT will prevent the fetch agent
> >from blocking while waiting for a data transfer.  No data
> transfer commands will be sent which could not be immediately
> processed.  No out-of-order processing is required.


Agreed. I think we can eliminate out-of-order processing model.
My motion is to vote elimination of out-of-order processing model
at Portland meeting.
To have productive result we must move forward. We shall start
from Greg and Alan$B!G(Js proposal.(J
-------------------------------------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to Nagasaka.Fumio@exc.epson.co.jp


	-----Original Message-----
	From:	Greg Shue [SMTP:gregs@sdd.hp.com]
	Sent:	Thursday, March 12, 1998 2:08 AM
	To:	Nagasaka Fumio
	Cc:	p1394@pwg.org; pp1394@cpdc.canon.co.jp
	Subject:	Re: P1394> unordered execution




	[Shue, Greg]
	Your concern comes because you have a new requirement under
issue 1:
			multiple channels being _associated_ with a
single session (login to a LUN).
	This should have been brought up many, many months ago.
	The current requirements are for multiple _independent_
channels.
	No discussion has occurred about what the standard FAX model
should look like.  Apparently your model is different from others as no
one else has raised this requirement.
	If we want to have a standard FAX driver stack, then I would
encourage us to start an e-mail discussion about how a standard FAX
device should be modeled.
	I$B!G(Jm not suprised that a consumer OS provides one login per LUN.(J
Nothing has been clearly stated about how SBP-2 LUNs should be treated.
The Microsoft SBP-2 implementation has it$B!G(Js own behaviors which must be(J
addressed.  I don$B!G(Jt have any issues with saying that $B!H(Jthis is the(J
standard way of supporting XXX device.$B!I(J
	Nothing prevents providing a 1284.4 service on top of the
current proposal.  This may be the direction you choose to go if your
FAX service is modeled as having more than a unidirectional SEND channel
and a unidirectional RECEIVE channel, and you don$B!G(Jt want to model each(J
data source/data sink as a different service.
	I have a couple of issues with supporting $B!H(JMLC$B!I(J over a single(J
ORB
	list, so I$B!G(Jll assume you meant $B!H(JCBT$B!I(J (1284.4).  That(J
provision
	already exists by using the current proposal in packet mode and
	making the supported packet size (per direction) be able to hold
	the largest packet transferred in that direction.  Since the
	current proposal supports packets of 65535+6 bytes, nothing
needs
	to be changed.  The nature of CBT will prevent the fetch agent
		>from blocking while waiting for a data transfer.  No
data
	transfer commands will be sent which could not be immediatly
processed.  No out-of-order processing is required.


		> On Sun, 8 Mar 1998 22:24:59 -0800
		> $B!H(JTurner, Randy$B!I(J <rturner@sharplabs.com> wrote:(J
		> 
			> > <RT>We should never have a single ORB list
processing multiple logical
			> > channels. Each ORB <RT>list handles a single
logical channel, at least
			> > according to the current profile document
<RT>decisions we have made.
			> > 
		> 
		> We need to invoke some login(s) to make some fetch
agents.
		> I don$B!G(Jt like it, because,...(J
		> 
		> 1) Multiple logical channel shell be involved with a
LUN.
		>    For example, FAX LUN may have several logical
channels.
		>    According to the current profile document, we are
		>    required to invoke login(s) to a LUN or to some
LUNs.
		> 
		> 2) However Sekine-san told us, a consumer OS invokes
one
		>    login to a LUN.
		> 
		> 3) So we need to have a facility to provide MLC in a
single
		>    ORB List.
		> 
		> The current profile document is good and well
designed. Even
		> so we need to revise some points to make it is
executable on
		> existing Operating System.
		> -----
		> Fumio Nagasaka
		> EPSON Software Development Laboratory Inc.,
		> TEL: +81 268 25-4111 // FAX: +81 268 25-4627
		> HomePage = http://www.venus.dti.ne.jp/~fumiona/
		> 
		> 




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

From atsnaka at bsd.canon.co.jp  Mon Mar 16 06:58:11 1998
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:49 2009
Subject: P1394> units and logical units definition
Message-ID: <199803161158.UAA18317@bsdmail.bsd.canon.co.jp>

I have a questions about the current profile.


I am still wondering if the usage method of SBP-2
logical units(and "unit"s) in the printer profile 
matches with the meaning of logical units 
described in SBP-2.


In the SBP-2 spec, it says ;


  "A logical unit is part of the unit architecture and is
   an instance of a device model e.g., mass storage, 
   CD-ROM or printer"


In section 17:Model Configuration of document 0.1d -PWG 
printer profile, it says ;


  "Each unique combination of the above information represents
    a unique service provided by the device and is identified as a 
    separate Unit within the device. Zero or more instances of
    a unit may exist within the device at any given time. 
    All instances of a unit have identical functionality."


It may be my lack of mis-understanding, but doesn't the 
2 statements conflict ? 
SBP-2 considers logical units as instances of "device" models
whereas the printer profile considers logical units as instances
of a "logical channels".


If there is 1 instance of a printer device with multiple 
SBP-2 logical channels, how do I address this device as a
unit architecture following both rules ?


1 "printer" unit with 2 logical unit directories?... 
but then,a logical unit has to be "an instance" of a 
device model,so there should be only 1 logical unit ????
 
Ats










-----------------------------------------
Atsushi Nakamura
-----------------------------------------


BJ Technology Develpoment 22,
Canon Inc.


53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211


tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------

From gregs at sdd.hp.com  Mon Mar 16 12:57:26 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:49 2009
Subject: P1394> units and logical units definition
In-Reply-To: <199803161158.UAA18317@bsdmail.bsd.canon.co.jp>
Message-ID: <199803161757.JAA18988@hpsdlgj1.sdd.hp.com>

Ats asks:
> In the SBP-2 spec, it says ;
> 
>   "A logical unit is part of the unit architecture and is
>    an instance of a device model e.g., mass storage, 
>    CD-ROM or printer"
> 
> In section 17:Model Configuration of document 0.1d -PWG 
> printer profile, it says ;
> 
>   "Each unique combination of the above information represents
>     a unique service provided by the device and is identified as a 
>     separate Unit within the device. Zero or more instances of
>     a unit may exist within the device at any given time. 
>     All instances of a unit have identical functionality."
> 
> It may be my lack of mis-understanding, but doesn't the 
> 2 statements conflict ? 


The two statements do not conflict.  The PWG profile is more
restrictive than the SBP-2 proposal.


Note that SBP-2's concept of a printer certainly does not match
well with our devices.  Disks are easily modeled.  Scanners are
fairly easily modeled.  Printers definitely are not.  (They would
have fits trying to deal with the degree of flexability in the
Printer MIB!  :-)


> SBP-2 considers logical units as instances of "device" models
> whereas the printer profile considers logical units as instances
> of a "logical channels".


Almost.  The PWG profile considers a logical unit as an instance
of a service.  The login establishes an instance of a
communications channel to the associated service.  If you think
of the service definition as being it's own device model, then
everything should line up.


> If there is 1 instance of a printer device with multiple 
> SBP-2 logical channels, how do I address this device as a
> unit architecture following both rules ?
> 
> 1 "printer" unit with 2 logical unit directories?... 
> but then,a logical unit has to be "an instance" of a 
> device model,so there should be only 1 logical unit ????


The confusion comes from trying to model a printer as "1" device.
There are really many independent services, which is why
everybody wants Multiple Independent Channels.


In my mind, a "printer" is composed of (at least):


  1+ Print Job interpretors (PRINTING service) running concurrently
  1+ Printer Status monitors (DEVICE STATUS service) running concurrently
  1+ Printer Control services (DEVICE CONTROL service) running concurrently


There are a number of ways in which this could be arranged according
to SBP-2, and fewer according to the PWG proposal.  Let's take the
case of a "printer" which can simultaneously manage accepting and
parsing 2 print files, servicing N different remote queries, and
allows 1 client control access at a time:


The SBP-2 proposal allows this to be modeled as:
    1 unit with:
      2 logins to the Print Job logical unit
      N logins to the Printer Status logical unit
      1 login  to the Printer control logical unit


  Similarly, since each of these services operate independently
  of each other (and may be used by other protocol stacks), SBP-2
  allows for them to be modeled as:
    2 + N + 3 units with 1 logical unit each
  or:
    1 Print Job Unit Directory with 2 logical units (instances)
    1 Device Status Unit Directory with N logical units (instances)
    1 Device Control Unit Directory with 1 exclusive logical unit 


The current PWG proposal restricts the options to the last one.
For the "Disk & Media Changer" example, we would have to ask the
question "Do the 2 functions operate independently of each other?"
I don't know.  If they do, then they would be modeled as 2 units
with one logical unit per supported connection to each.


Does this help?


Just to check my assumptions:
  Am I incorrectly modeling a "printer"?


> Ats



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


From ewa at apple.com  Mon Mar 16 14:07:42 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:49 2009
Subject: P1394> units and logical units definition
In-Reply-To: <P1394> units and logical units definition>
Message-ID: <B132BB3F-4985A@17.219.104.99>

Greg Shue writes:
> The SBP-2 proposal allows this to be modeled as:
>     1 unit with:
>       2 logins to the Print Job logical unit
>       N logins to the Printer Status logical unit
>       1 login  to the Printer control logical unit
> 
>   Similarly, since each of these services operate independently
>   of each other (and may be used by other protocol stacks), SBP-2
>   allows for them to be modeled as:
>     2 + N + 3 units with 1 logical unit each
>   or:
>     1 Print Job Unit Directory with 2 logical units (instances)
>     1 Device Status Unit Directory with N logical units (instances)
>     1 Device Control Unit Directory with 1 exclusive logical unit 
> 
> The current PWG proposal restricts the options to the last one.


Even if each of those models is allowed by SBP-2, I think
the first one (a single unit with multiple LUNs) is both more
in the spirit of SBP-2 and more in the spirit of 1394.  This
model allows a 1394 node to have any number of independent
printer units, which is good if you are a multi-function node
like a computer or a fancy printer.


The other model is difficult if you want to have multiple
independent units in a node, because there is no clear way
to match up which Device Status Unit Directory goes with which
Device Control Unit Directory, or Print Job Unit Directory.
Rev 0.1d of the profile doesn't show how to do this (or I
missed it...)


So at face value I would prefer the first model (above) over
the second.


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.      408-974-8187
--------------------------------------

From gregs at sdd.hp.com  Mon Mar 16 14:41:47 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:50 2009
Subject: P1394> units and logical units definition
In-Reply-To: <B132BB3F-4985A@17.219.104.99>
Message-ID: <199803161941.LAA20698@hpsdlgj1.sdd.hp.com>

> 
> Greg Shue writes:
> > The SBP-2 proposal allows this to be modeled as:
> >     1 unit with:
> >       2 logins to the Print Job logical unit
> >       N logins to the Printer Status logical unit
> >       1 login  to the Printer control logical unit
> > 
> >   Similarly, since each of these services operate independently
> >   of each other (and may be used by other protocol stacks), SBP-2
> >   allows for them to be modeled as:
> >     2 + N + 3 units with 1 logical unit each
> >   or:
> >     1 Print Job Unit Directory with 2 logical units (instances)
> >     1 Device Status Unit Directory with N logical units (instances)
> >     1 Device Control Unit Directory with 1 exclusive logical unit 
> > 
> > The current PWG proposal restricts the options to the last one.
> 
> Even if each of those models is allowed by SBP-2, I think
> the first one (a single unit with multiple LUNs) is both more
> in the spirit of SBP-2 and more in the spirit of 1394.  This
> model allows a 1394 node to have any number of independent
> printer units, which is good if you are a multi-function node
> like a computer or a fancy printer.
> 
> The other model is difficult if you want to have multiple
> independent units in a node, because there is no clear way
> to match up which Device Status Unit Directory goes with which
> Device Control Unit Directory, or Print Job Unit Directory.
> Rev 0.1d of the profile doesn't show how to do this (or I
> missed it...)


No, you didn't miss it.  It is not there.  This may be an issue.


> So at face value I would prefer the first model (above) over
> the second.


The big problem with the first model is that you cannot have
multiple connections between device status applications and
device status services when the applications reside on the same
node.  This _requires_ that multiplexing be done somewhere in the
system.


Smaller problems include how to figure out which LUNs are
associated with which type of service.


(Note: I was really figuring that device control would just be
a password-protected access into device status.)


Suggestions?


> --------------------------------------
> Eric Anderson            ewa@apple.com
> Apple Computer, Inc.      408-974-8187
> --------------------------------------



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


From ewa at apple.com  Mon Mar 16 17:23:47 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:50 2009
Subject: P1394> units and logical units definition
In-Reply-To: <P1394> units and logical units definition>
Message-ID: <B132E678-C44AC@17.219.104.99>

> > 
> > Greg Shue writes:
> > > The SBP-2 proposal allows this to be modeled as:
> > >     1 unit with:
> > >       2 logins to the Print Job logical unit
> > >       N logins to the Printer Status logical unit
> > >       1 login  to the Printer control logical unit
> > > 
> Eric Anderson:
> > So at face value I would prefer the first model (above) over
> > the second.
> >
Greg Shue:
> The big problem with the first model is that you cannot have
> multiple connections between device status applications and
> device status services when the applications reside on the same
> node.  This _requires_ that multiplexing be done somewhere in the
> system.


Hmm, this is an interesting part of SBP-2.  No initiator node is
allowed to have more than one login to the same LUN in a target.
I believe it was assumed that any initiator that is so complex
that it might want multiple logins to the same LUN must also be
so smart that it would be able to multiplex a single login in
software.


If this problem only comes up in computers (and similar devices)
then maybe us software folks can do the multiplexing.  I didn't
see details of the Status logical unit in the latest profile,
but if it has no side-effects, multiplexing access to it might
not be too hard.


On the other hand, if you forsee devices like printers or scanners
that might have two or more independent functions that both want
status from the same target, then it might be more difficult for
them to share one login, because of the nature of their implemen-
tations.  Do you think this second case is likely, and if so, do
you think that the difficulty of multiplexing one connection is
sufficient to warrant using another model of units and logins?


Or should we consider asking SBP-2 to allow multiple logins to one
LUN from the same initiator?  It's not clear to me that the limit
of one login per LUN per initiator causes any real savings in cost
or complexity in the target.


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.      408-974-8187
--------------------------------------

From atsnaka at bsd.canon.co.jp  Mon Mar 16 20:30:07 1998
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:50 2009
Subject: P1394> units and logical units definition
In-Reply-To: <199803161941.LAA20698@hpsdlgj1.sdd.hp.com>
Message-ID: <199803170130.KAA22755@bsdmail.bsd.canon.co.jp>

Eric wrote ; 
> > 
> > The other model is difficult if you want to have multiple
> > independent units in a node, because there is no clear way
> > to match up which Device Status Unit Directory goes with which
> > Device Control Unit Directory, or Print Job Unit Directory.
> > Rev 0.1d of the profile doesn't show how to do this (or I
> > missed it...)
> 
Greg wrote ; 
> No, you didn't miss it.  It is not there.  This may be an issue.


It is SORT of there....


This can be handled with FDS, the Function Discovery Service
discussed in p1212r, IF we want to match units up by (physycal)
function instances.
(although it is not the original intent of FDS..)
FDS is a ROM structure that acutally matches up an functional
physical instance with all of it's associated (unit) directories.
The problem is that there is no telling whether those multiple units
 have to be "activated" simultaneously in order to achieve a function,
or just "choices"(ex. "A function can either talk in SBP-2 or DPP").


Rev0.1d states the use of FDS, so it's SORT of there... 


Eric worte ; 


> Even if each of those models is allowed by SBP-2, I think
> the first one (a single unit with multiple LUNs) is both more
> in the spirit of SBP-2 and more in the spirit of 1394. 


I do not know if it is right or not, but this is a similar 
response I get from 1394-ers around me. 
I have a hard time explaining that a 1394 printer (will probably)
consist of 2 or more unit (directories).
Most people had imagined a printer with only 1 unit with 1 LUN.


Because there still is some talk about desires for mutiple
independent channels within 1 LUN even inside PWG, I think this 
matter is worth going back to, get in synch and confirming again. 
(We forgot to give examples the last time, I think Greg's examples in
the last few mails helped some people to get the idea, Thanks Greg.)




P.S.
On radical comment I got was, 
If the printer was going to consist of multiple LUNs anyway, 
why not go further and restrict 1 LUN to 1 direction only ?
  


-----------------------------------------
Atsushi Nakamura
-----------------------------------------


BJ Technology Develpoment 22,
Canon Inc.


53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211


tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------

From atsnaka at bsd.canon.co.jp  Mon Mar 16 21:46:22 1998
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Pre-announce:next p1212r mtg
Message-ID: <199803170246.LAA24336@bsdmail.bsd.canon.co.jp>

***PRELIMINARY ANNOUNCEMENT***


The next p1212r (IEEE 1212 reaffermation WG) meeting
is planned on April 20-21 in Tokyo, Japan.
Participation of all interested people are welcome.


April 20 is the next Monday after the 1394TA in Korea.


An official announcement, with details will be made 
soon by the p1212r chair.


To get an image of the number of attendees (for mtg setup)
I would appreciate if people willing to attend
can respond to :
  atsnaka@bsd.canon.co.jp


THIS IS NOT AN OFFICIAL PING REQUEST


Thank you for the cooperation.


***PRELIMINARY ANNOUNCEMENT END***






-----------------------------------------
Atsushi Nakamura
-----------------------------------------


BJ Technology Development 22,
Canon Inc.


53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211


tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------

From gregs at sdd.hp.com  Mon Mar 16 20:47:41 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:50 2009
Subject: P1394> units and logical units definition
In-Reply-To: <199803170130.KAA22755@bsdmail.bsd.canon.co.jp>
Message-ID: <199803170147.RAA21046@hpsdlgj1.sdd.hp.com>

Ats wrote:
> This can be handled with FDS, the Function Discovery Service
> discussed in p1212r, IF we want to match units up by (physycal)
> function instances.
> (although it is not the original intent of FDS..)
> FDS is a ROM structure that acutally matches up an functional
> physical instance with all of it's associated (unit) directories.


The piece that is missing is if a node provides the services
of multiple printers (e.g. a PC being a bridge to all the non-1394
printers to which it is directly connected).  How do you know
that "printer status" L is associated with "printer parser" Q?



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


From atsnaka at bsd.canon.co.jp  Mon Mar 16 23:22:06 1998
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:50 2009
Subject: P1394> units and logical units definition
In-Reply-To: <199803170147.RAA21046@hpsdlgj1.sdd.hp.com>
Message-ID: <199803170422.NAA26257@bsdmail.bsd.canon.co.jp>

At $B8a8e(J 05:47 98/03/16 -0800, Greg Shue wrote:
> 
> Ats wrote:
> > This can be handled with FDS, the Function Discovery Service
> > discussed in p1212r, IF we want to match units up by (physycal)
> > function instances.
> > (although it is not the original intent of FDS..)
> > FDS is a ROM structure that acutally matches up an functional
> > physical instance with all of it's associated (unit) directories.
> 
> The piece that is missing is if a node provides the services
> of multiple printers (e.g. a PC being a bridge to all the non-1394
> printers to which it is directly connected).  How do you know
> that "printer status" L is associated with "printer parser" Q?
> 


Very true.This is why I said "SORT OF..."


> > (although it is not the original intent of FDS..)


I will emphasize that FDS's initial objective is  
device discovery(and U/I purposes),not to solve issues like these,
so the scope of FDS ends at "unit" level.


As you said, FDS does not solve"The piece that is missing" so 
I think some other mechanism is needed for a match up at the
LUN level.


> > > The other model is difficult if you want to have multiple
> > > independent units in a node, because there is no clear way
> > > to match up which Device Status Unit Directory goes with which
> > > Device Control Unit Directory, or Print Job Unit Directory.
> > > Rev 0.1d of the profile doesn't show how to do this (or I
> > > missed it...)


The above statement did not say anything about LUNs, so I thought
that FDS can be utilized if a match up at the unit level is all 
that's needed (which apparently is not...I should of figured that
out myself.) 














-----------------------------------------
Atsushi Nakamura
-----------------------------------------


BJ Technology Development 22,
Canon Inc.


53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211


tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------

From rturner at sharplabs.com  Tue Mar 17 00:20:58 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:50 2009
Subject: P1394> units and logical units definition
Message-ID: <199803170422.NAA26257@bsdmail.bsd.canon.co.jp>

I thought we had a pretty firm idea on the handling of logical units.


Does this discussion require clarification of the current profile
document, for full understanding?


Also, is there need for a teleconference on this or any other subject
prior to the next face-to-face meeting?


Randy

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Tue Mar 17 14:17:24 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:50 2009
Subject: P1394> units and logical units definition
In-Reply-To: <D10983CAC30DD111B41400805FA6A1C138CF88@admsrvnt02.enet.sharpla>
Message-ID: <H0000d930f04c77b@MHS>

--openmail-part-1210634f-00000001
Content-Type: application/octet-stream; name="1.txt"
Content-Disposition: attachment; filename="1.txt"
Content-Transfer-Encoding: base64


UmVjZWl2ZWQ6IGZyb20gcGFscmVsMy5ocC5jb20gKHBhbHJlbDMuaHAuY29tIFsxNS44MS4x
ODQuMTBdKSBieSB2ZW51cy5yb3NlLmhwLmNvbSB3aXRoIEVTTVRQICg4LjcuMS84LjcuMyBU
SVMgNS4wIE9wZW5tYWlsKSBpZCBWQUEyNDQ1NiBmb3IgPGFsYW5fYmVya2VtYUBocC1yb3Nl
dmlsbGUtb20yLm9tLmhwLmNvbT47IE1vbiwgMTYgTWFyIDE5OTggMjE6MjI6MjAgLTA4MDAg
KFBTVCkKUmVjZWl2ZWQ6IGZyb20gbGlzdHMudW5kZXJzY29yZS5jb20gKHVzY29yZS0xLm12
LmNvbSBbMTk5LjEyNS44NS4zMF0pCglieSBwYWxyZWwzLmhwLmNvbSAoOC44LjUvOC44LjV0
aXMpIHdpdGggRVNNVFAgaWQgVkFBMTU0MjY7CglNb24sIDE2IE1hciAxOTk4IDIxOjIyOjEy
IC0wODAwIChQU1QpClJlY2VpdmVkOiBmcm9tIGxvY2FsaG9zdCAoZGFlbW9uQGxvY2FsaG9z
dCkgYnkgbGlzdHMudW5kZXJzY29yZS5jb20gKDguNy41LzguNy4zKSB3aXRoIFNNVFAgaWQg
QUFBMTI3MjU7IFR1ZSwgMTcgTWFyIDE5OTggMDA6MjI6MTEgLTA1MDAgKEVTVCkKUmVjZWl2
ZWQ6IGJ5IHB3Zy5vcmcgKGJ1bGtfbWFpbGVyIHYxLjUpOyBUdWUsIDE3IE1hciAxOTk4IDAw
OjIxOjE0IC0wNTAwClJlY2VpdmVkOiAoZnJvbSBkYWVtb25AbG9jYWxob3N0KSBieSBsaXN0
cy51bmRlcnNjb3JlLmNvbSAoOC43LjUvOC43LjMpIGlkIEFBQTEyNTg0IGZvciBwMTM5NC1v
dXRnb2luZzsgVHVlLCAxNyBNYXIgMTk5OCAwMDoyMDo1OSAtMDUwMCAoRVNUKQpNZXNzYWdl
LUlEOiA8RDEwOTgzQ0FDMzBERDExMUI0MTQwMDgwNUZBNkExQzEzOENGODhAYWRtc3J2bnQw
Mi5lbmV0LnNoYXJwbGFicy5jb20+CkZyb206ICJUdXJuZXIsIFJhbmR5IiA8cnR1cm5lckBz
aGFycGxhYnMuY29tPgpUbzogIidwMTM5NEBwd2cub3JnJyIgPHAxMzk0QHB3Zy5vcmc+ClN1
YmplY3Q6IFJFOiBQMTM5ND4gdW5pdHMgYW5kIGxvZ2ljYWwgdW5pdHMgZGVmaW5pdGlvbgpE
YXRlOiBNb24sIDE2IE1hciAxOTk4IDIxOjIwOjU4IC0wODAwClgtUHJpb3JpdHk6IDMKTUlN
RS1WZXJzaW9uOiAxLjAKWC1NYWlsZXI6IEludGVybmV0IE1haWwgU2VydmljZSAoNS4wLjE0
NTguNDkpCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbgpTZW5kZXI6IHAxMzk0LW93bmVyQHB3
Zy5vcmcK


--openmail-part-1210634f-00000001
Content-Type: text/plain
Content-Disposition: inline; filename="RE:"
Content-Transfer-Encoding: 7bit


     




______________________________ Reply Separator _________________________________
Subject: RE: P1394> units and logical units definition
Author:  Non-HP-rturner (rturner@sharplabs.com) at HP-Roseville,mimegw3
Date:    3/16/98 9:20 PM




> I thought we had a pretty firm idea on the handling of logical units.
     
     From the discussion it still seems hazy to me.
     
     I think a detailed picture matching services to Unit Directories to 
     LUNs might help.
     
> Does this discussion require clarification of the current profile 
> document, for full understanding?
     
     Absolutely.
     
> Also, is there need for a teleconference on this or any other subject 
> prior to the next face-to-face meeting?
     
     Would be nice, schedule could be tight.
     How about 3/19 at 4:00PM?
     
     3/20 could be bad for folks in Japan.
     3/23 is due date for the next rev of the spec.
     
Randy


--openmail-part-1210634f-00000001--

From rturner at sharplabs.com  Tue Mar 17 17:24:51 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call proposal
Message-ID: <H0000d930f04c77b@MHS>

Alan Berkema has suggested a PWG1394 conference be held on 3/19 at 4:00
PM PST.


Is everyone in agreement with the need for the call, as well as the date
and time?


Randy

From srao at trinc.com  Tue Mar 17 19:13:07 1998
From: srao at trinc.com (Srinivasa Addepalli)
Date: Wed May  6 14:00:50 2009
Subject: P1394> units and logical units definition
In-Reply-To: <P1394> units and logical units definition>
Message-ID: <H0000d930f04c77b@MHS>

We also had to face similar kind of problem of multiple
logins from one initiator to the same LUN. Since, it is
not allowed by the SBP-2 protocol, we are thinking of implementing
this in following way. I donot know whether this
strategy has merits or not. But I thought I will share
my thoughts.


The SBP2 application needs two type of logins for
the same device. One to transfer data and another to
inquire the device status. To allow two logins ( one
for data and another for status ), for each physical
instance of device,   two LUNs can be defined. One LUN
number is used for data login and another one for
status login.


For example, if the target supports two of similar devices,
then target is configured with 4 LUNS.
0th LUN - For data login on device 1
1st LUN - For status login on device 1
2nd LUN - For data login on device 2
3rd LUN - For status login on device 2.


All of them are defined in one UNIT directory.


If the target supports more than one type of devices. Then for
each device, one unit directory can be defined.
In each unit, based on number of similar devices, we can
have so many LUNs.




For example, if SBP2 target needs to support 2 printer devices
and 3 scanner devices. Assume that printer needs to have two
type of logins and scanner needs to have 4 type of logins.


   Then the target system will have two unit directories.
    One for printer and another for scanner.
    Printer unit directory needs to be defined with 2 * 2 = 4 LUNs.
    Scanner unit directory needs to be defined with 3 * 4 = 12 LUNs.


    Initiator application and execution agent will have understanding
that
    0 and 1st LUNs  correspond to first printer device
    2nd and 2rd LUNs  correspond to second printer device  for printer
unit.


    For scanner unit,
      0,1,2 and 3 are for first scanner device
      4,5,6,7 for second scanner device
      8,9,10,11 for thrid scanner device.


The above text is example only.


Regards
Srini




Eric Anderson wrote:


> > >
> > > Greg Shue writes:
> > > > The SBP-2 proposal allows this to be modeled as:
> > > >     1 unit with:
> > > >       2 logins to the Print Job logical unit
> > > >       N logins to the Printer Status logical unit
> > > >       1 login  to the Printer control logical unit
> > > >
> > Eric Anderson:
> > > So at face value I would prefer the first model (above) over
> > > the second.
> > >
> Greg Shue:
> > The big problem with the first model is that you cannot have
> > multiple connections between device status applications and
> > device status services when the applications reside on the same
> > node.  This _requires_ that multiplexing be done somewhere in the
> > system.
>
> Hmm, this is an interesting part of SBP-2.  No initiator node is
> allowed to have more than one login to the same LUN in a target.
> I believe it was assumed that any initiator that is so complex
> that it might want multiple logins to the same LUN must also be
> so smart that it would be able to multiplex a single login in
> software.
>
> If this problem only comes up in computers (and similar devices)
> then maybe us software folks can do the multiplexing.  I didn't
> see details of the Status logical unit in the latest profile,
> but if it has no side-effects, multiplexing access to it might
> not be too hard.
>
> On the other hand, if you forsee devices like printers or scanners
> that might have two or more independent functions that both want
> status from the same target, then it might be more difficult for
> them to share one login, because of the nature of their implemen-
> tations.  Do you think this second case is likely, and if so, do
> you think that the difficulty of multiplexing one connection is
> sufficient to warrant using another model of units and logins?
>
> Or should we consider asking SBP-2 to allow multiple logins to one
> LUN from the same initiator?  It's not clear to me that the limit
> of one login per LUN per initiator causes any real savings in cost
> or complexity in the target.
>
> --------------------------------------
> Eric Anderson            ewa@apple.com
> Apple Computer, Inc.      408-974-8187
> --------------------------------------

From atsnaka at bsd.canon.co.jp  Tue Mar 17 20:17:31 1998
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:50 2009
Subject: P1394> units and logical units definition
In-Reply-To: <H0000d930f04c77b@MHS>
Message-ID: <199803180117.KAA08581@bsdmail.bsd.canon.co.jp>

It would help to convince me (and probably others)
that we are going the right way, 
and that everybodyis in synch. if we can :


1. Confirm that the current usage of SBP-2 unit(directory)s and 
   LUNs are consistant with the idea ("with the spirit")of units
   and LUNs defined in the SBP-2 spec. 


>Note that SBP-2's concept of a printer certainly does not match
>well with our devices.  Disks are easily modeled.  Scanners are
>fairly easily modeled.  Printers definitely are not.


   As Greg mentioned, printers are modeled differently(more complex)
   from disks, and I think we are starting to define a new usage 
   of SBP-2 units and LUNs in the current printer profile 0.1d that are 
   different from other SBP-2 devices.
   (where 1 (printer) function is comprised of multiple units
    of the same transport protocol (PWG profile over SBP-2) within
    1 node, and a combination of specific LUNs across these differnt
    units need to work simultaneously to achieve the (printer) function.)


  Greg (Shue)'s explanation about an example of a printer model
  by considering logical units as a service (the cuurent profile0.1d) made
  sense within itself, but the question whether that usage is the 
  intended usage or not has not been answered. There also is the issue
  on how to match up the LUNs


Eric says;
>Even if each of those models is allowed by SBP-2, I think
>the first one (a single unit with multiple LUNs) is both more
>in the spirit of SBP-2 and more in the spirit of 1394.  


  The above comment increased the magnitude of my concern.     
  I think this is a question of how the SBP-2 people intended 
  units and LUNs to be used, so confirmation with (or a comment from)
  a SBP-2 expert would help.


2. Confirm that the current usage of units(and LUNs) are consistant
   and "in spirit" with 1394 and 1212 (and other protocols aside from 
   SBP-2.)
   Same as above, other protocols(such as AVC/FCP, DPP/Thin,
   Conf.camera spec. ) achieve the functionality within one "1212"unit.
   (Services are MUXed within the transport and above)      
   The current profile will be the first of it's kind to achieve a 
   functionality by using differnt LUNS across different "1212" units so
   there is a possiblity that the 1394 PC printer may look "odd"
   in the 1394 world.


3. Confirm within PWG that this is the way to go.
   As I mentioned, the discussion about desires for mutiple
   independent channels within 1 LUN is still continuing, so I also agree with
   Alan that this is still hazy.


4. Lastly, 


>      I think a detailed picture matching services to Unit Directories to 
>      LUNs might help.


I agree with this idea.
Modelling a printer application may be out of the scope of the profile,
but I think an example of a what a "basic" printer should look like 
will help understanding (even within PWG to keep everyone in synch !)




>      Would be nice, schedule could be tight.
>      How about 3/19 at 4:00PM?
>      
I won't make this, but please go ahead if this schedule is reasonable
for everyone else.
I also apologize for not being able to contribute face-to face.


Ats






At 11:17 98/03/17 -0800, ALAN_BERKEMA@hp-roseville-om2.om.hp.com wrote:


> > I thought we had a pretty firm idea on the handling of logical units.
>      
>      From the discussion it still seems hazy to me.
>      
>      I think a detailed picture matching services to Unit Directories to 
>      LUNs might help.
>      
> > Does this discussion require clarification of the current profile 
> > document, for full understanding?
>      
>      Absolutely.
>      
> > Also, is there need for a teleconference on this or any other subject 
> > prior to the next face-to-face meeting?
>      
>      Would be nice, schedule could be tight.
>      How about 3/19 at 4:00PM?
>      
>      3/20 could be bad for folks in Japan.
>      3/23 is due date for the next rev of the spec.
>      
> Randy
> 


-----------------------------------------
Atsushi Nakamura
-----------------------------------------


BJ Technology Development 22,
Canon Inc.


53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211


tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------

From don at lexmark.com  Wed Mar 18 07:02:54 1998
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call proposal
In-Reply-To: <P1394> Conference call proposal>
Message-ID: <199803181203.AA02035@interlock2.lexmark.com>

Don't you think that's a little late for the east coast?


Don












To:   p1394%pwg.org@interlock.lexmark.com
cc:    (bcc: Don Wright)
bcc:  Don Wright
Subject:  P1394> Conference call proposal










Alan Berkema has suggested a PWG1394 conference be held on 3/19 at 4:00
PM PST.
Is everyone in agreement with the need for the call, as well as the date
and time?
Randy

From rturner at sharplabs.com  Wed Mar 18 13:16:11 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call proposal
Message-ID: <199803181203.AA02035@interlock2.lexmark.com>

Uh, make that 4 PM EST. on 3/19 Is that ok?


Randy




	-----Original Message-----
	From:	don@lexmark.com [SMTP:don@lexmark.com]
	Sent:	Wednesday, March 18, 1998 4:03 AM
	To:	rturner@sharplabs.com
	Cc:	P1394@Pwg.Org
	Subject:	Re: P1394> Conference call proposal




	Don't you think that's a little late for the east coast?


	Don












	To:   p1394%pwg.org@interlock.lexmark.com
	cc:    (bcc: Don Wright)
	bcc:  Don Wright
	Subject:  P1394> Conference call proposal










	Alan Berkema has suggested a PWG1394 conference be held on 3/19
at 4:00
	PM PST.
	Is everyone in agreement with the need for the call, as well as
the date
	and time?
	Randy

From gregs at sdd.hp.com  Wed Mar 18 14:45:31 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call proposal
In-Reply-To: <D10983CAC30DD111B41400805FA6A1C138CF8E@admsrvnt02.enet.sharplabs.com>
Message-ID: <199803181945.LAA25383@hpsdlgj1.sdd.hp.com>

I agree that we need to call it.  The time frames
are OK for me, but 4PM EST is too early in Japan.
(8 or 9 hrs before 1pm Pacific, i.e. 4-5 AM Japan!)


Greg Shue


> 
> 
> Uh, make that 4 PM EST. on 3/19 Is that ok?
> 
> Randy





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


From gregoryl at spider.epson.com  Wed Mar 18 21:12:42 1998
From: gregoryl at spider.epson.com (Greg LeClair)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call Agenda
Message-ID: <01BD5299.72446200.gregoryl@spider.epson.com>

Do we have a telecon scheduled?
If not tomorrow(Thurs), then Friday or Monday.


Idea for an Agenda


Revised proposal summary 
- Alan Berkema tells me we'll have revision up by Monday 3/23


Feedback received 
- How does it revise the model?
- Is it a Unit Directory that provides a Function?
- Is a Function is provided by one or more Services?
- Individual Services are accessed via LUNs?
- Glossary terms to consider adding to profile document


Issues with revised model
- Different LUNs represent different services
- List of functions and required services
- Do we know everything we need to access a function?


Other issues?




Regards,


Greg LeClair










-----Original Message-----
From:	Greg Shue [SMTP:gregs@sdd.hp.com]
Sent:	Wednesday, March 18, 1998 11:46 AM
To:	Turner, Randy
Cc:	don@lexmark.com; p1394@pwg.org
Subject:	Re: P1394> Conference call proposal




I agree that we need to call it.  The time frames
are OK for me, but 4PM EST is too early in Japan.
(8 or 9 hrs before 1pm Pacific, i.e. 4-5 AM Japan!)


Greg Shue


> 
> 
> Uh, make that 4 PM EST. on 3/19 Is that ok?
> 
> Randy





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


From rturner at sharplabs.com  Thu Mar 19 13:02:21 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call Agenda
Message-ID: <01BD5299.72446200.gregoryl@spider.epson.com>

Concerning the conference call...


Someone needs to give me a time that is convenient for both U.S and
Japan participants....


What did we use last time?


Randy




	-----Original Message-----
	From:	Greg LeClair [SMTP:gregoryl@spider.epson.com]
	Sent:	Wednesday, March 18, 1998 6:13 PM
	To:	'Greg Shue'; Turner, Randy
	Cc:	don@lexmark.com; p1394@pwg.org
	Subject:	RE: P1394> Conference call Agenda


	Do we have a telecon scheduled?
	If not tomorrow(Thurs), then Friday or Monday.


	Idea for an Agenda


	Revised proposal summary 
	- Alan Berkema tells me we'll have revision up by Monday 3/23


	Feedback received 
	- How does it revise the model?
	- Is it a Unit Directory that provides a Function?
	- Is a Function is provided by one or more Services?
	- Individual Services are accessed via LUNs?
	- Glossary terms to consider adding to profile document


	Issues with revised model
	- Different LUNs represent different services
	- List of functions and required services
	- Do we know everything we need to access a function?


	Other issues?




	Regards,


	Greg LeClair










	-----Original Message-----
	From:	Greg Shue [SMTP:gregs@sdd.hp.com]
	Sent:	Wednesday, March 18, 1998 11:46 AM
	To:	Turner, Randy
	Cc:	don@lexmark.com; p1394@pwg.org
	Subject:	Re: P1394> Conference call proposal




	I agree that we need to call it.  The time frames
	are OK for me, but 4PM EST is too early in Japan.
	(8 or 9 hrs before 1pm Pacific, i.e. 4-5 AM Japan!)


	Greg Shue


	> 
	> 
	> Uh, make that 4 PM EST. on 3/19 Is that ok?
	> 
	> Randy




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

From gregs at sdd.hp.com  Thu Mar 19 13:11:38 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call Agenda
In-Reply-To: <D10983CAC30DD111B41400805FA6A1C138CF97@admsrvnt02.enet.sharplabs.com>
Message-ID: <199803191811.KAA27712@hpsdlgj1.sdd.hp.com>

4pm PST. (7pm EST; 9am+1day Japan)


> Concerning the conference call...
> 
> Someone needs to give me a time that is convenient for both U.S and
> Japan participants....
> 
> What did we use last time?
> 
> Randy



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


From don at lexmark.com  Thu Mar 19 13:16:47 1998
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call Agenda
In-Reply-To: <P1394> Conference call Agenda>
Message-ID: <199803191817.AA23675@interlock2.lexmark.com>

So it;s OK for me to hang around the office for hours but not OK for the
folks in Japan to come in early????


By your math:


4 PM Eastern
1 PM Pacific
6AM + 1 day in Japan




**********************************************
* Don Wright                 don@lexmark.com *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************












To:   rturner%sharplabs.com@interlock.lexmark.com
cc:   p1394%pwg.org@interlock.lexmark.com (bcc: Don Wright)
bcc:  Don Wright
Subject:  Re: P1394> Conference call Agenda










4pm PST. (7pm EST; 9am+1day Japan)
> Concerning the conference call...
>
> Someone needs to give me a time that is convenient for both U.S and
> Japan participants....
>
> What did we use last time?
>
> Randy

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


From Lee_Farrell at cissc.canon.com  Thu Mar 19 13:21:44 1998
From: Lee_Farrell at cissc.canon.com (Farrell, Lee)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call Agenda
Message-ID: <199803191817.AA23675@interlock2.lexmark.com>

Randy,


Last time our compromise was 4:00pm PST to accomodate the people from
Japan.


However, because of the time difference, some of them *might* not even
discover the e-mail that announces the teleconference before it starts
-- if we hold it today.  (And tommorrow is Saturday for Tokyo.)


lee


> ----------
> From: 	Turner, Randy[SMTP:rturner@sharplabs.com]
> Sent: 	Thursday, March 19, 1998 10:02 AM
> To: 	'p1394@pwg.org'
> Subject: 	RE: P1394> Conference call Agenda
> 
> 
> Concerning the conference call...
> 
> Someone needs to give me a time that is convenient for both U.S and
> Japan participants....
> 
> What did we use last time?
> 
> Randy
> 
> 
> 	-----Original Message-----
> 	From:	Greg LeClair [SMTP:gregoryl@spider.epson.com]
> 	Sent:	Wednesday, March 18, 1998 6:13 PM
> 	To:	'Greg Shue'; Turner, Randy
> 	Cc:	don@lexmark.com; p1394@pwg.org
> 	Subject:	RE: P1394> Conference call Agenda
> 
> 	Do we have a telecon scheduled?
> 	If not tomorrow(Thurs), then Friday or Monday.
> 
> 	Idea for an Agenda
> 
> 	Revised proposal summary 
> 	- Alan Berkema tells me we'll have revision up by Monday 3/23
> 
> 	Feedback received 
> 	- How does it revise the model?
> 	- Is it a Unit Directory that provides a Function?
> 	- Is a Function is provided by one or more Services?
> 	- Individual Services are accessed via LUNs?
> 	- Glossary terms to consider adding to profile document
> 
> 	Issues with revised model
> 	- Different LUNs represent different services
> 	- List of functions and required services
> 	- Do we know everything we need to access a function?
> 
> 	Other issues?
> 
> 
> 	Regards,
> 
> 	Greg LeClair
> 
> 
> 
> 
> 
> 	-----Original Message-----
> 	From:	Greg Shue [SMTP:gregs@sdd.hp.com]
> 	Sent:	Wednesday, March 18, 1998 11:46 AM
> 	To:	Turner, Randy
> 	Cc:	don@lexmark.com; p1394@pwg.org
> 	Subject:	Re: P1394> Conference call proposal
> 
> 
> 	I agree that we need to call it.  The time frames
> 	are OK for me, but 4PM EST is too early in Japan.
> 	(8 or 9 hrs before 1pm Pacific, i.e. 4-5 AM Japan!)
> 
> 	Greg Shue
> 
> 	> 
> 	> 
> 	> Uh, make that 4 PM EST. on 3/19 Is that ok?
> 	> 
> 	> Randy
> 
> 
> 	-- 
> 	Greg Shue
> 	Hewlett-Packard Company
> 	Office Products Division			gregs@sdd.hp.com
> 	----------------------------------------------------------------
> 

From rturner at sharplabs.com  Thu Mar 19 13:43:30 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call Agenda
Message-ID: <199803191817.AA23675@interlock2.lexmark.com>

Concerning the 1394 conference call...


is 4 PM PST on Monday, 3/23 ok for everyone?


Randy




	-----Original Message-----
	From:	Farrell, Lee [SMTP:Lee_Farrell@cissc.canon.com]
	Sent:	Thursday, March 19, 1998 10:22 AM
	To:	'p1394@pwg.org'; 'Randy Turner'
	Subject:	RE: P1394> Conference call Agenda


	Randy,


	Last time our compromise was 4:00pm PST to accomodate the people
from
	Japan.


	However, because of the time difference, some of them *might*
not even
	discover the e-mail that announces the teleconference before it
starts
	-- if we hold it today.  (And tommorrow is Saturday for Tokyo.)


	lee


	> ----------
	> From: 	Turner, Randy[SMTP:rturner@sharplabs.com]
	> Sent: 	Thursday, March 19, 1998 10:02 AM
	> To: 	'p1394@pwg.org'
	> Subject: 	RE: P1394> Conference call Agenda
	> 
	> 
	> Concerning the conference call...
	> 
	> Someone needs to give me a time that is convenient for both
U.S and
	> Japan participants....
	> 
	> What did we use last time?
	> 
	> Randy
	> 
	> 
	> 	-----Original Message-----
	> 	From:	Greg LeClair [SMTP:gregoryl@spider.epson.com]
	> 	Sent:	Wednesday, March 18, 1998 6:13 PM
	> 	To:	'Greg Shue'; Turner, Randy
	> 	Cc:	don@lexmark.com; p1394@pwg.org
	> 	Subject:	RE: P1394> Conference call Agenda
	> 
	> 	Do we have a telecon scheduled?
	> 	If not tomorrow(Thurs), then Friday or Monday.
	> 
	> 	Idea for an Agenda
	> 
	> 	Revised proposal summary 
	> 	- Alan Berkema tells me we'll have revision up by Monday
3/23
	> 
	> 	Feedback received 
	> 	- How does it revise the model?
	> 	- Is it a Unit Directory that provides a Function?
	> 	- Is a Function is provided by one or more Services?
	> 	- Individual Services are accessed via LUNs?
	> 	- Glossary terms to consider adding to profile document
	> 
	> 	Issues with revised model
	> 	- Different LUNs represent different services
	> 	- List of functions and required services
	> 	- Do we know everything we need to access a function?
	> 
	> 	Other issues?
	> 
	> 
	> 	Regards,
	> 
	> 	Greg LeClair
	> 
	> 
	> 
	> 
	> 
	> 	-----Original Message-----
	> 	From:	Greg Shue [SMTP:gregs@sdd.hp.com]
	> 	Sent:	Wednesday, March 18, 1998 11:46 AM
	> 	To:	Turner, Randy
	> 	Cc:	don@lexmark.com; p1394@pwg.org
	> 	Subject:	Re: P1394> Conference call proposal
	> 
	> 
	> 	I agree that we need to call it.  The time frames
	> 	are OK for me, but 4PM EST is too early in Japan.
	> 	(8 or 9 hrs before 1pm Pacific, i.e. 4-5 AM Japan!)
	> 
	> 	Greg Shue
	> 
	> 	> 
	> 	> 
	> 	> Uh, make that 4 PM EST. on 3/19 Is that ok?
	> 	> 
	> 	> Randy
	> 
	> 
	> 	-- 
	> 	Greg Shue
	> 	Hewlett-Packard Company
	> 	Office Products Division
gregs@sdd.hp.com
	>
----------------------------------------------------------------
	> 

From gregs at sdd.hp.com  Thu Mar 19 14:36:59 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:50 2009
Subject: P1394> units and logical units definition
In-Reply-To: <D10983CAC30DD111B41400805FA6A1C138CF88@admsrvnt02.enet.sharplabs.com>
Message-ID: <199803191936.LAA27763@hpsdlgj1.sdd.hp.com>

Hi all,


I've been thinking about the Unit/Logical Unit/LUN modeling a
bit, and there may be a better way to approach figuring out an
appropriate solution.  Let's see if the following makes sense.


The following associations come directly out of the SBP-2 spec
(rev 3a):


  SBP-2 "targets" are Units.
  Each target (unit) shares one Management Agent across all it's LUNs.
  Units are made up of one or more Logical Units. (SBP-2 sec 4.2)


  Each Logical Unit within a Unit may be of a different type.
  Each Logical Unit represents a "device model" and has a
  specific "type" which ammends the "command set" parameter.


  The "Command Set" is LUN specific (wither the value is found in
  the Logical Unit Directory or inheirited from the Unit
  directory).  It identifies the class of commands transferred in
  the "command block" field within the CDB.


  The SBP-2 "device server" is a component of a logical unit
  responsible to execute tasks initiated by _command_blocks_
  that specify data transfer or other device operation.




Now, I think the PWG has concensus that we do NOT want any transport
client data transferred within the CDB.  All the transport client
data should be contained within the data block associated with the
ORB carrying the commands.


Is this true?  (I'll assume so. :-)




So, our SBP-2 based solutions requires that the "Command Set"
field indicate (only) that the "PWG 1394 communications standard"
commands are supported.


I haven't thought about the multi-login implications,
but for our single-login solution:


  Our command set is providing one reliable, bidirectional,
  connection-oriented, byte- or buffer-style communications path
  within one login, within one LUN.
  
  So:


    The Logical Unit provides transport services to exactly one
    associated service (transport client).


    It may be easily modeled as having, per login:
      
      one message queue for data traveling from initiator through target
      one message queue for data traveling through target to initiator
      status associated with those queues
      configuration parameters associated with those queues
      an SBP-2 Fetch Agent (for moving data between queues & 1394 memory)
      an SBP-2 Unsolicited Status sending agent
      a command execution agent which coordinates everything.


      an ideal link between the other end of the message queues and
	_the_ assicated service.


    The Execution Agent processing the "PWG 1394 communications
    command set" fits the definition of an SBP-2 "device server".


      So our SBP-2 device is really a communications device
      associated with (routed to) a (remote) service!
      


  Now, this model means that:


    Login scope:
      The AGENT_RESET register write only affects the Fetch Agent.




    Logical Unit scope:
      Each Logical Unit (indirectly) provides a Service
      (one session per node at a time).


      The characteristics of that service (remaining protocol
      layers, application command sets and revisions) are not
      appropriately described by using the current 1212 fields
      found in a Logical Unit Directory or Unit Directory.


      The device_type field found in the Logical_Unit_Number entry
      indicates the "peripheral device type implemented by the
      logical unit."  This is most appropriately used to indicate
      that the SBP-2 "device server" is a "communications type",
      as opposed to indicating the "type" of the assocaited service.
      (This is especially true given that it is only 5 bits in size!)


      The LOGICAL_UNIT_RESET command (sent to the encapsulating
      Unit's Management Agent) affects all the connections
      (Logins) established through only this Logical Unit.




    Unit scope:
      Each Unit (indirectly) provides a set of Services (Is this
      a Function?  It's consistent with our original FDS ideas.)


      The TARGET_RESET command (sent to the encapsulating Unit's
      Management Agent) affects all the connections (Logins)
      established through ALL Logical Units within the Unit.




Does this make sense?  Is it reasonable?



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


From gregs at sdd.hp.com  Thu Mar 19 14:41:58 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call Agenda
In-Reply-To: <D10983CAC30DD111B41400805FA6A1C138CF9C@admsrvnt02.enet.sharplabs.com>
Message-ID: <199803191941.LAA27798@hpsdlgj1.sdd.hp.com>

So folks going to WinHEC will have to call in from there?
I'm not going, so it's OK with me.




> Concerning the 1394 conference call...
> 
> is 4 PM PST on Monday, 3/23 ok for everyone?
> 
> Randy
> 



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


From laurie at sdd.hp.com  Thu Mar 19 16:23:23 1998
From: laurie at sdd.hp.com (Laurie Lasslo)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call Agenda
Message-ID: <01BD533A.31F39EE0.laurie@sdd.hp.com>

WinHec starts Wens 3/25, 
- Laurie


-----Original Message-----
From:	Greg Shue [SMTP:gregs@sdd.hp.com]
Sent:	Thursday, March 19, 1998 11:42 AM
To:	Turner, Randy
Cc:	p1394@pwg.org
Subject:	Re: P1394> Conference call Agenda




So folks going to WinHEC will have to call in from there?
I'm not going, so it's OK with me.




> Concerning the 1394 conference call...
> 
> is 4 PM PST on Monday, 3/23 ok for everyone?
> 
> Randy
> 



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


From rturner at sharplabs.com  Thu Mar 19 16:32:25 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call Agenda
Message-ID: <01BD533A.31F39EE0.laurie@sdd.hp.com>

It was too late to make the conference call for today or tomorrow
because the Japanese are 1 day ahead and would miss the announcement.
I'm assuming WinHec is all week so the week after next might be too
late, or too close to the face-to-face meeting.


Randy




	-----Original Message-----
	From:	Laurie Lasslo [SMTP:laurie@sdd.hp.com]
	Sent:	Thursday, March 19, 1998 1:23 PM
	To:	'Greg Shue'; Turner, Randy
	Cc:	p1394@pwg.org
	Subject:	RE: P1394> Conference call Agenda


	WinHec starts Wens 3/25, 
	- Laurie


	-----Original Message-----
	From:	Greg Shue [SMTP:gregs@sdd.hp.com]
	Sent:	Thursday, March 19, 1998 11:42 AM
	To:	Turner, Randy
	Cc:	p1394@pwg.org
	Subject:	Re: P1394> Conference call Agenda




	So folks going to WinHEC will have to call in from there?
	I'm not going, so it's OK with me.




	> Concerning the 1394 conference call...
	> 
	> is 4 PM PST on Monday, 3/23 ok for everyone?
	> 
	> Randy
	> 


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

From greg at erc.epson.com  Thu Mar 19 16:44:00 1998
From: greg at erc.epson.com (greg@erc.epson.com)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call Agenda
Message-ID: <199803192148.NAA00434@proxy3.ba.best.com>

Randy, 


For this one, let's go with 4PM on 3/23


Future thoughts(to ALL):
1. My concern is that we're discussing things and some people on west coast may have to leave early and therefore we may lose info that needs to have some content prepared for spec or profile.
2. East Coast & Japan & (Europe?) - possible separate telecons?
3. Just use voice telecon or consider something like IRC 




Regards,


Greg LeClair
greg@erc.epson.com


----Original Message-----
   >From:    	"Turner, Randy" <rturner@sharplabs.com>
   >To:        	"'p1394@pwg.org'" <p1394@pwg.org>
   >Subject:    	RE: P1394> Conference call Agenda
   >Date:    	Thursday, March 19, 1998 10:02 AM
   >
   >
   >Concerning the conference call...
   >
   >Someone needs to give me a time that is convenient for both U.S and
   >Japan participants....
   >
   >What did we use last time?
   >
   >Randy
   >
   >
   >	-----Original Message-----
   >	From:	Greg LeClair [SMTP:gregoryl@spider.epson.com]
   >	Sent:	Wednesday, March 18, 1998 6:13 PM
   >	To:	'Greg Shue'; Turner, Randy
   >	Cc:	don@lexmark.com; p1394@pwg.org
   >	Subject:	RE: P1394> Conference call Agenda
   >
   >	Do we have a telecon scheduled?
   >	If not tomorrow(Thurs), then Friday or Monday.
   >
   >	Idea for an Agenda
   >
   >	Revised proposal summary 
   >	- Alan Berkema tells me we'll have revision up by Monday 3/23
   >
   >	Feedback received 
   >	- How does it revise the model?
   >	- Is it a Unit Directory that provides a Function?
   >	- Is a Function is provided by one or more Services?
   >	- Individual Services are accessed via LUNs?
   >	- Glossary terms to consider adding to profile document
   >
   >	Issues with revised model
   >	- Different LUNs represent different services
   >	- List of functions and required services
   >	- Do we know everything we need to access a function?
   >
   >	Other issues?
   >
   >
   >	Regards,
   >
   >	Greg LeClair
   >
   >
   >
   >
   >
   >	-----Original Message-----
   >	From:	Greg Shue [SMTP:gregs@sdd.hp.com]
   >	Sent:	Wednesday, March 18, 1998 11:46 AM
   >	To:	Turner, Randy
   >	Cc:	don@lexmark.com; p1394@pwg.org
   >	Subject:	Re: P1394> Conference call proposal
   >
   >
   >	I agree that we need to call it.  The time frames
   >	are OK for me, but 4PM EST is too early in Japan.
   >	(8 or 9 hrs before 1pm Pacific, i.e. 4-5 AM Japan!)
   >
   >	Greg Shue
   >
   >	> 
   >	> 
   >	> Uh, make that 4 PM EST. on 3/19 Is that ok?
   >	> 
   >	> Randy
   >
   >
   >	-- 
   >	Greg Shue
   >	Hewlett-Packard Company
   >	Office Products Division			gregs@sdd.hp.com
   >	----------------------------------------------------------------
   >
   >

From laurie at sdd.hp.com  Thu Mar 19 16:56:56 1998
From: laurie at sdd.hp.com (Laurie Lasslo)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call Agenda
Message-ID: <01BD533E.E1C3DF70.laurie@sdd.hp.com>

Again, Win Hec is Wens, Thurs and Friday of next week. Not Monday
- Laurie


-----Original Message-----
From:	Turner, Randy [SMTP:rturner@sharplabs.com]
Sent:	Thursday, March 19, 1998 1:32 PM
To:	'Laurie Lasslo'
Cc:	'p1394@pwg.org'
Subject:	RE: P1394> Conference call Agenda


It was too late to make the conference call for today or tomorrow
because the Japanese are 1 day ahead and would miss the announcement.
I'm assuming WinHec is all week so the week after next might be too
late, or too close to the face-to-face meeting.


Randy




	-----Original Message-----
	From:	Laurie Lasslo [SMTP:laurie@sdd.hp.com]
	Sent:	Thursday, March 19, 1998 1:23 PM
	To:	'Greg Shue'; Turner, Randy
	Cc:	p1394@pwg.org
	Subject:	RE: P1394> Conference call Agenda


	WinHec starts Wens 3/25, 
	- Laurie


	-----Original Message-----
	From:	Greg Shue [SMTP:gregs@sdd.hp.com]
	Sent:	Thursday, March 19, 1998 11:42 AM
	To:	Turner, Randy
	Cc:	p1394@pwg.org
	Subject:	Re: P1394> Conference call Agenda




	So folks going to WinHEC will have to call in from there?
	I'm not going, so it's OK with me.




	> Concerning the 1394 conference call...
	> 
	> is 4 PM PST on Monday, 3/23 ok for everyone?
	> 
	> Randy
	> 


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

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Thu Mar 19 17:16:34 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call Agenda
Message-ID: <H0000d930f091b95@MHS>

--openmail-part-121c0383-00000001
Content-Type: application/octet-stream; name="1.txt"
Content-Disposition: attachment; filename="1.txt"
Content-Transfer-Encoding: base64


UmVjZWl2ZWQ6IGZyb20gcGFscmVsMy5ocC5jb20gKHBhbHJlbDMuaHAuY29tIFsxNS44MS4x
ODQuMTBdKSBieSB2ZW51cy5yb3NlLmhwLmNvbSB3aXRoIEVTTVRQICg4LjcuMS84LjcuMyBU
SVMgNS4wIE9wZW5tYWlsKSBpZCBLQUEwMjcwMSBmb3IgPGFsYW5fYmVya2VtYUBocC1yb3Nl
dmlsbGUtb20yLm9tLmhwLmNvbT47IFRodSwgMTkgTWFyIDE5OTggMTA6NDU6MDAgLTA4MDAg
KFBTVCkKUmVjZWl2ZWQ6IGZyb20gbGlzdHMudW5kZXJzY29yZS5jb20gKHVzY29yZS0xLm12
LmNvbSBbMTk5LjEyNS44NS4zMF0pCglieSBwYWxyZWwzLmhwLmNvbSAoOC44LjUvOC44LjV0
aXMpIHdpdGggRVNNVFAgaWQgS0FBMTM3NDk7CglUaHUsIDE5IE1hciAxOTk4IDEwOjQ0OjQ0
IC0wODAwIChQU1QpClJlY2VpdmVkOiBmcm9tIGxvY2FsaG9zdCAoZGFlbW9uQGxvY2FsaG9z
dCkgYnkgbGlzdHMudW5kZXJzY29yZS5jb20gKDguNy41LzguNy4zKSB3aXRoIFNNVFAgaWQg
TkFBMDgwOTg7IFRodSwgMTkgTWFyIDE5OTggMTM6NDQ6NDMgLTA1MDAgKEVTVCkKUmVjZWl2
ZWQ6IGJ5IHB3Zy5vcmcgKGJ1bGtfbWFpbGVyIHYxLjUpOyBUaHUsIDE5IE1hciAxOTk4IDEz
OjQzOjQ3IC0wNTAwClJlY2VpdmVkOiAoZnJvbSBkYWVtb25AbG9jYWxob3N0KSBieSBsaXN0
cy51bmRlcnNjb3JlLmNvbSAoOC43LjUvOC43LjMpIGlkIE5BQTA3OTYxIGZvciBwMTM5NC1v
dXRnb2luZzsgVGh1LCAxOSBNYXIgMTk5OCAxMzo0MzozMiAtMDUwMCAoRVNUKQpNZXNzYWdl
LUlEOiA8RDEwOTgzQ0FDMzBERDExMUI0MTQwMDgwNUZBNkExQzEzOENGOUNAYWRtc3J2bnQw
Mi5lbmV0LnNoYXJwbGFicy5jb20+CkZyb206ICJUdXJuZXIsIFJhbmR5IiA8cnR1cm5lckBz
aGFycGxhYnMuY29tPgpUbzogIidwMTM5NEBwd2cub3JnJyIgPHAxMzk0QHB3Zy5vcmc+ClN1
YmplY3Q6IFJFOiBQMTM5ND4gQ29uZmVyZW5jZSBjYWxsIEFnZW5kYQpEYXRlOiBUaHUsIDE5
IE1hciAxOTk4IDEwOjQzOjMwIC0wODAwClgtUHJpb3JpdHk6IDMKTUlNRS1WZXJzaW9uOiAx
LjAKWC1NYWlsZXI6IEludGVybmV0IE1haWwgU2VydmljZSAoNS4wLjE0NTguNDkpCkNvbnRl
bnQtVHlwZTogdGV4dC9wbGFpbjsKCWNoYXJzZXQ9Imlzby04ODU5LTEiClNlbmRlcjogcDEz
OTQtb3duZXJAcHdnLm9yZwo=


--openmail-part-121c0383-00000001
Content-Type: text/plain;charset="iso-8859-1"
Content-Disposition: inline; filename="RE:"
Content-Transfer-Encoding: 7bit


     
     I am not leaving for WINHEC until 3/24.
     
     How about 3 PM PST on Monday, 3/23 ?
     
     This would make it 6PM for East Coast & 8AM:+1day for Japan.
     
     Alan
     
______________________________ Reply Separator _________________________________
Subject: RE: P1394> Conference call Agenda
Author:  Non-HP-rturner (rturner@sharplabs.com) at HP-Roseville,mimegw3 
Date:    3/19/98 10:43 AM
     
     
     
Concerning the 1394 conference call...
     
is 
     
Randy
     
     
        -----Original Message-----
        From:   Farrell, Lee [SMTP:Lee_Farrell@cissc.canon.com] 
        Sent:   Thursday, March 19, 1998 10:22 AM
        To:     'p1394@pwg.org'; 'Randy Turner'
        Subject:        RE: P1394> Conference call Agenda
     
        Randy,
     
        Last time our compromise was 4:00pm PST to accomodate the people
from
        Japan.
     
        However, because of the time difference, some of them *might*
not even
        discover the e-mail that announces the teleconference before it
starts
        -- if we hold it today.  (And tommorrow is Saturday for Tokyo.)
     
        lee
     
        > ----------
        > From:         Turner, Randy[SMTP:rturner@sharplabs.com] 
        > Sent:         Thursday, March 19, 1998 10:02 AM
        > To:   'p1394@pwg.org'
        > Subject:      RE: P1394> Conference call Agenda 
        > 
        > 
        > Concerning the conference call...
        > 
        > Someone needs to give me a time that is convenient for both
U.S and
        > Japan participants....
        > 
        > What did we use last time?
        > 
        > Randy
        > 
        > 
        >       -----Original Message-----
        >       From:   Greg LeClair [SMTP:gregoryl@spider.epson.com] 
        >       Sent:   Wednesday, March 18, 1998 6:13 PM
        >       To:     'Greg Shue'; Turner, Randy
        >       Cc:     don@lexmark.com; p1394@pwg.org
        >       Subject:        RE: P1394> Conference call Agenda 
        > 
        >       Do we have a telecon scheduled?
        >       If not tomorrow(Thurs), then Friday or Monday. 
        > 
        >       Idea for an Agenda
        > 
        >       Revised proposal summary 
        >       - Alan Berkema tells me we'll have revision up by Monday
3/23
        > 
        >       Feedback received 
        >       - How does it revise the model?
        >       - Is it a Unit Directory that provides a Function?
        >       - Is a Function is provided by one or more Services? 
        >       - Individual Services are accessed via LUNs?
        >       - Glossary terms to consider adding to profile document 
        > 
        >       Issues with revised model
        >       - Different LUNs represent different services 
        >       - List of functions and required services
        >       - Do we know everything we need to access a function? 
        > 
        >       Other issues?
        > 
        > 
        >       Regards,
        > 
        >       Greg LeClair
        > 
        > 
        > 
        > 
        > 
        >       -----Original Message-----
        >       From:   Greg Shue [SMTP:gregs@sdd.hp.com] 
        >       Sent:   Wednesday, March 18, 1998 11:46 AM 
        >       To:     Turner, Randy
        >       Cc:     don@lexmark.com; p1394@pwg.org
        >       Subject:        Re: P1394> Conference call proposal 
        > 
        > 
        >       I agree that we need to call it.  The time frames 
        >       are OK for me, but 4PM EST is too early in Japan.
        >       (8 or 9 hrs before 1pm Pacific, i.e. 4-5 AM Japan!) 
        > 
        >       Greg Shue
        > 
        >       > 
        >       > 
        >       > Uh, make that 4 PM EST. on 3/19 Is that ok? 
        >       > 
        >       > Randy
        > 
        > 
        >       -- 
        >       Greg Shue
        >       Hewlett-Packard Company
        >       Office Products Division
gregs@sdd.hp.com
        >
----------------------------------------------------------------
        > 


--openmail-part-121c0383-00000001
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


TO: rturner@sharplabs.com


--openmail-part-121c0383-00000001--

From rturner at sharplabs.com  Thu Mar 19 19:20:58 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call details
Message-ID: <H0000d930f091b95@MHS>

Ok, here goes:


1394PWG Conference Call
Monday 3/23/1998
3 PM PST
90 minutes
10 slots


You don't have to RSVP unless someone strongly objects to one or more of
these details.


Randy

From shimura at pure.cpdc.canon.co.jp  Mon Mar 23 09:12:51 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Alternative Bi-Di proposal utilizing unordered model(Was Re: unordered execution)
In-Reply-To: <01376112D7AFD011911E0020AF70BEC5088F6E@cpuex1.ued.epson.co.jp>
Message-ID: <199803231412.XAA12937@slant1.pure.cpdc.canon.co.jp>

--TW9uLCAyMyBNYXIgMTk5OCAyMzoxMzowOSArMDkwMA==
Content-Type: text/plain; charset=ISO-2022-JP


Hello, All,


I have prepared an alternative proposal for bi-di communication
mechanism utilizing unordered model to overcome inefficiencies
potentially caused by the ordered model.


Unfortunately, I cannot attend the next Portland meeting, so 
Mr.Isoda from Canon will make a presentation on this document in the
meeting instead of me.


I appreciate if 20 or 30 minutes slot is assigned for the presentation.


Please find attached model part of the document and comment below....


On Fri, 13 Mar 1998 19:05:18 +0900
Nagasaka Fumio <Nagasaka.Fumio@exc.epson.co.jp> wrote:


> Greg Shue wrote: (reformatted)
> 
> > $B!D(B.. That provision
> > already exists by using the current proposal in packet mode and
> > making the supported packet size (per direction) be able to hold
> > the largest packet transferred in that direction.  Since the
> > current proposal supports packets of 65535+6 bytes, nothing needs
> > to be changed.  The nature of CBT will prevent the fetch agent
> > >from blocking while waiting for a data transfer.  No data
> > transfer commands will be sent which could not be immediately
> > processed.  No out-of-order processing is required.
> 
> Agreed. I think we can eliminate out-of-order processing model.


I don't think so.


Though the CBT may prevent deferring(re-ordering or retrying) the ORB
for initiator-to-target transfer in the initiator, there still exists
an inefficiency on target-to-initiator transfer.
In order to prevent ORB re-ordering in the initiator, it is necessary
to guarantee the completion of each request. In case of target-to-
initiator transfer, the CBT may only guarantee the receiving space on
the initiator and does not necessarily guarantee the completion on
the target because the target may not be ready to send a data. 
To prevent this, it will be necessary for the initiator to defer
appending target-to-initiator request ORB until ready-to-send is
indicated by the target. Because appending pending read request to
the task set requires indication from the target and the initiator
need appending process based on the indication after the indication
arrived, this procedure will not so efficient as shown by the spirit
of SBP-2.


I have prepared a "Model" part of a document utilizing "Unordered
Model" to overcome these inefficiencies potentially caused by the
"Ordered Model".
Though the model part of the document(Simple HPT or SHPT) is revised
>from the HPT document, the model itself is very different from the
original HPT model.


In this SHPT model, re-ordering the ORB between write and read
request in the initiator is not required at all because the target
does re-order between them.
In the "ordered model", the ORB re-ordering in the initiator will
occur whenever the requested order in the task set is not appropriate
for the "target" to execute.
Because the ORB re-ordering in the initiator requires aborting tasks
by the target, re-appending the tasks to the task list by the
initiator and re-fetching the tasks by the target potentially in
non-linear order of retries, it will be expensive for the initiator,
the target and the bus.


Also, in this SHPT model, the initiator does not need to synchronize
with the indication from the target to append the pending read request
to the task set because the pending state is achieved in the execution
agent on the target.
In the "ordered model", if the initiator limits the number of
requests in the task set very small (e.g., one) to avoid potential ORB
re-ordering in the initiator, the target will enter suspend state
frequently before requests are appended to the task list. In this case,
the bandwidth benefit of the SBP-2 will be reduced by the latencies on
each side.


In addition, this SHPT model does not require to limit maximum data
payload size, and does not need to prepare the maximum data payload
size of (intermediate) receive buffer to guarantee the delivery.




Regards,


Akihiro Shimura

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.




--TW9uLCAyMyBNYXIgMTk5OCAyMzoxMzowOSArMDkwMA==
Content-Type: application/octet-stream; name="shpt04c_model.pdf"
Content-Disposition: attachment;
 filename="shpt04c_model.pdf"
Content-Transfer-Encoding: base64


[encoded data, 33649 characters]
Mw0lJUVPRg0=


--TW9uLCAyMyBNYXIgMTk5OCAyMzoxMzowOSArMDkwMA==--


From gregs at sdd.hp.com  Mon Mar 23 12:55:37 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Alternative Bi-Di proposal utilizing unordered model(Was Re: unordered execution)
In-Reply-To: <199803231412.XAA12937@slant1.pure.cpdc.canon.co.jp>
Message-ID: <199803231755.JAA09208@hpsdlgj1.sdd.hp.com>

Akihiro Shimura wrote:


> > Agreed. I think we can eliminate out-of-order processing model.
> 
> I don't think so.
> 
> Though the CBT may prevent deferring(re-ordering or retrying) the ORB
> for initiator-to-target transfer in the initiator, there still exists
> an inefficiency on target-to-initiator transfer.
> In order to prevent ORB re-ordering in the initiator, it is necessary
> to guarantee the completion of each request. In case of target-to-
> initiator transfer, the CBT may only guarantee the receiving space on
> the initiator and does not necessarily guarantee the completion on
> the target because the target may not be ready to send a data. 


A CBT-style mechanism covers data flow in both directions.


> To prevent this, it will be necessary for the initiator to defer
> appending target-to-initiator request ORB until ready-to-send is
> indicated by the target. Because appending pending read request to
> the task set requires indication from the target and the initiator
> need appending process based on the indication after the indication
> arrived, this procedure will not so efficient as shown by the spirit
> of SBP-2.


The "ready-to-send indication" from the target is implicit with
each credit.


> In this SHPT model, re-ordering the ORB between write and read
> request in the initiator is not required at all because the target
> does re-order between them.
> In the "ordered model", the ORB re-ordering in the initiator will
> occur whenever the requested order in the task set is not appropriate
> for the "target" to execute.
> Because the ORB re-ordering in the initiator requires aborting tasks
> by the target, re-appending the tasks to the task list by the
> initiator and re-fetching the tasks by the target potentially in
> non-linear order of retries, it will be expensive for the initiator,
> the target and the bus.
> 
> Also, in this SHPT model, the initiator does not need to synchronize
> with the indication from the target to append the pending read request
> to the task set because the pending state is achieved in the execution
> agent on the target.
> In the "ordered model", if the initiator limits the number of
> requests in the task set very small (e.g., one) to avoid potential ORB
> re-ordering in the initiator, the target will enter suspend state
> frequently before requests are appended to the task list. In this case,
> the bandwidth benefit of the SBP-2 will be reduced by the latencies on
> each side.


I think you're missing one big clause about the Unordered Execution
Model.  SBP-2 spec rev 3a, Section 4.6 states:


  "The unordered model is usually appropriate for direct-access
  devices for which no poisitional or other context information
  is inherited from one command to the next."


  "Unrestricted reordering leaves the responsibility for the
  assurance of data integrity with the initiator.  If the integrity
  of data on the device medium could be compromised by unrestricted
  reordering involving a set of active tasks, {T0, T1, T2, ... Tn}
  and a new task T', the initiator shall wait until {T0, T1, T2, ... Tn}
  have completed before appending T' to an active request list."


We have talked quite a bit in various threads on this reflector
about the "spirit" of SBP-2.  In continuing with this emphasis,
the spirit of the Unordered Execution model is _completely_
unordered.  Since the nature of our buffer transfers are ordered
within each direction, the previous clauses really require no
more than one message be queued for each direction at a time!
Anything else is really not consistent with the Unordered
Execution model.


The only possible supported way around this is to set the 'q' bit
in the Logical_Unit_Characteristics entry to be one and define a
command-set dependent queuing model.  But I'm still not sure that
the interpretation of the 'o' bit in the same entry is affected.




> In addition, this SHPT model does not require to limit maximum data
> payload size, and does not need to prepare the maximum data payload
> size of (intermediate) receive buffer to guarantee the delivery.


In order to support transient link interruptions, either
additional restrictions are placed on ORBs being queued (that
they MUST be explicitly completed or aborted to be removed from
the task set), or maximum sizes must be set.  If neither of these
mechanisms are defined, then it is possible for the data stream
to be corrupted because of a Bus Reset which resulted in a
partially processed ORB being requeued, or a new ORB being
queued, but interpreted as a partially fetched one.





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


From rturner at sharplabs.com  Mon Mar 23 17:17:57 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Conference call details
Message-ID: <199803231755.JAA09208@hpsdlgj1.sdd.hp.com>

Sorry for the last minute details....I almost forgot!....thanks to
Shimura-san for the reminder.


For the 1394PWG conference call...


Phone Number:  334-262-0740
Access Code:  484541
Time: 3 PM PST
10 slots
90 minutes






	-----Original Message-----
	From:	Akihiro Shimura [SMTP:shimura@pure.cpdc.canon.co.jp]
	Sent:	Monday, March 23, 1998 1:40 PM
	To:	Turner, Randy
	Cc:	Shigeru Ueda; Takashi Isoda
	Subject:	Re: P1394> Conference call details


	Hello,


	Could you tell me a phone number information for this conference
call?


	Thanks in advance,


	Akihiro Shimura


	On Thu, 19 Mar 1998 16:20:58 -0800
	"Turner, Randy" <rturner@sharplabs.com> wrote:


	> 
	> Ok, here goes:
	> 
	> 1394PWG Conference Call
	> Monday 3/23/1998
	> 3 PM PST
	> 90 minutes
	> 10 slots
	> 
	> You don't have to RSVP unless someone strongly objects to one
or more of
	> these details.
	> 
	> Randy
	> 
	> 


	--
	 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
	 Office Imaging Products Development Center 3
	 CANON INC.

From shimura at pure.cpdc.canon.co.jp  Tue Mar 24 08:02:25 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Alternative Bi-Di proposal utilizing unordered model(Was Re: unordered execution)
In-Reply-To: <199803231755.JAA09208@hpsdlgj1.sdd.hp.com>
Message-ID: <199803241302.WAA20679@origin.pure.cpdc.canon.co.jp>

See comment below....


On Mon, 23 Mar 1998 09:55:37 -0800 (PST)
Greg Shue <gregs@sdd.hp.com> wrote:


> Akihiro Shimura wrote:
(snip)
> > In this SHPT model, re-ordering the ORB between write and read
> > request in the initiator is not required at all because the target
> > does re-order between them.
> > In the "ordered model", the ORB re-ordering in the initiator will
> > occur whenever the requested order in the task set is not appropriate
> > for the "target" to execute.
> > Because the ORB re-ordering in the initiator requires aborting tasks
> > by the target, re-appending the tasks to the task list by the
> > initiator and re-fetching the tasks by the target potentially in
> > non-linear order of retries, it will be expensive for the initiator,
> > the target and the bus.
> > 
> > Also, in this SHPT model, the initiator does not need to synchronize
> > with the indication from the target to append the pending read request
> > to the task set because the pending state is achieved in the execution
> > agent on the target.
> > In the "ordered model", if the initiator limits the number of
> > requests in the task set very small (e.g., one) to avoid potential ORB
> > re-ordering in the initiator, the target will enter suspend state
> > frequently before requests are appended to the task list. In this case,
> > the bandwidth benefit of the SBP-2 will be reduced by the latencies on
> > each side.
> 
> I think you're missing one big clause about the Unordered Execution
> Model.  SBP-2 spec rev 3a, Section 4.6 states:
> 
>   "The unordered model is usually appropriate for direct-access
>   devices for which no poisitional or other context information
>   is inherited from one command to the next."
> 
>   "Unrestricted reordering leaves the responsibility for the
>   assurance of data integrity with the initiator.  If the integrity
>   of data on the device medium could be compromised by unrestricted
>   reordering involving a set of active tasks, {T0, T1, T2, ... Tn}
>   and a new task T', the initiator shall wait until {T0, T1, T2, ... Tn}
>   have completed before appending T' to an active request list."


Thank you for the clarification.
In this mean, the SHPT model will not be an "Unordered Model" under
the "Basic task management model" but be sort of an "Unordered Model"
under the "Queuing Model".


> We have talked quite a bit in various threads on this reflector
> about the "spirit" of SBP-2.  In continuing with this emphasis,
> the spirit of the Unordered Execution model is _completely_
> unordered.  Since the nature of our buffer transfers are ordered
> within each direction, the previous clauses really require no
> more than one message be queued for each direction at a time!
> Anything else is really not consistent with the Unordered
> Execution model.


I'm not sure but I suppose the SHPT model will be still in the "spirit"
of SBP-2 because its features seem to be maintained.


> The only possible supported way around this is to set the 'q' bit
> in the Logical_Unit_Characteristics entry to be one and define a
> command-set dependent queuing model.  But I'm still not sure that
> the interpretation of the 'o' bit in the same entry is affected.


The SHPT model will set the 'q' bit as it was in the original HPT.


> > In addition, this SHPT model does not require to limit maximum data
> > payload size, and does not need to prepare the maximum data payload
> > size of (intermediate) receive buffer to guarantee the delivery.
> 
> In order to support transient link interruptions, either
> additional restrictions are placed on ORBs being queued (that
> they MUST be explicitly completed or aborted to be removed from
> the task set), or maximum sizes must be set.  If neither of these
> mechanisms are defined, then it is possible for the data stream
> to be corrupted because of a Bus Reset which resulted in a
> partially processed ORB being requeued, or a new ORB being
> queued, but interpreted as a partially fetched one.


The SHPT model requires two things as briefly described in the
document.
One is that the initiator shall keep up the "CONTENTS" of buffer until
the request is completed, and shall keep up the relationship between
"sequence identifier" and associated buffer (contents).
Another is that the target shall maintain the "sequence identifier"
and "offset" for the incomplete request, and shall be responsible in
avoiding the duplicated execution.


Since the synchronization between the initiator and the target may be
lost in the way that initiator is behind (the target is ahead), the
target examines the "sequence identifier" provided just after the
re-synchronization is taken by the initiator(possibly behind) and the
target completes without duplicated execution.
Because the "CONTENTS" of buffer and related "sequence identifier"
are kept up by the initiator and the target avoids the duplicated
execution by using maintained "sequence identifier" and "offset", the
data stream will not be corrupted.


Am I still missing something?


Akihiro Shimura

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.


From atsnaka at bsd.canon.co.jp  Tue Mar 24 19:32:46 1998
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Jan 1212 minutes
Message-ID: <199803250032.JAA29522@bsdmail.bsd.canon.co.jp>

--=====================_890753566==_
Content-Type: text/plain; charset="us-ascii"




The meeting minutes from the January 1212r WG mtg
has been issued.


Attached are the minutes as a pdf, uuencoded.


Ats


> Subject: 1212 minutes
> Date: Tue, 24 Mar 98 09:47:06 -0800
> X-Sender: aaronl@newt.lsi.sel.sony.com
> X-Mailer: Claris Emailer 2.0v2, June 6, 1997
> X-UIDL: 890762790.000
> From: Aaron Ludtke <aaronl@lsi.sel.sony.com>
> To: "1212 Reflector" <p1212r@zayante.com>
> Reply-To: IEEE 1212 reaffirmation <p1212r@zayante.com>
> Sender: <p1212r@zayante.com>
> List-Software: LetterRip 2.1.2 by Fog City Software, Inc.
> List-Subscribe: 
>  <mailto:requests@mail.zayante.com?subject=subscribe%20p1212r>
> List-Unsubscribe: 
>  <mailto:requests@mail.zayante.com?subject=unsubscribe%20p1212r>
> 
> Hey folks,
> 
> Sorry about the confusion regarding the last 1212 meeting minutes. I had 
> these done a while ago and had asked someone to post them for me (I've 
> been on several weeks of business travel), but there was some 
> mis-communication.
> 
> Attached are the minutes as a pdf, uuencoded.
> 
> Aaron




--=====================_890753566==_
Content-Type: application/pdf; name="Jan_98_minutes.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Jan_98_minutes.pdf"


[encoded data, 21406 characters]
NTJjZmJjZDY2NTI1NmU+XQ0+Pg1zdGFydHhyZWYNMTUwMzQNJSVFT0YN
--=====================_890753566==_
Content-Type: text/plain; charset="us-ascii"




-----------------------------------------
Atsushi Nakamura
-----------------------------------------


BJ Technology Development 22,
Canon Inc.


53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211


tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------
--=====================_890753566==_--

From fumiona at venus.dti.ne.jp  Tue Mar 24 20:19:34 1998
From: fumiona at venus.dti.ne.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Alternative Bi-Di proposal utilizing unordered model(Was Re: unordered execution)
In-Reply-To: <P1394> Alternative Bi-Di proposal utilizing unordered model(Was Re: unordered execution)>
Message-ID: <199803250032.JAA29522@bsdmail.bsd.canon.co.jp>

Dear Akihiro,


Akihiro Shimura wrote:
>I'm not sure but I suppose the SHPT model will be still in the "spirit"
>of SBP-2 because its features seem to be maintained.


Let me clear "sprit of SBP-2".
1) Are you going to make something new protocol which has SBP-2 flavor?
2) Or, are you going to expand SBP-2 specification?
3) Or, are you going to define standard implementation for SBP-2 queuing model? 


Akihiro Shimura wrote:
> The SHPT model requires two things as briefly described in the
> document.
> One is that the initiator shall keep up the "CONTENTS" of buffer until
> the request is completed, and shall keep up the relationship between
> "sequence identifier" and associated buffer (contents).
> Another is that the target shall maintain the "sequence identifier"
> and "offset" for the incomplete request, and shall be responsible in
> avoiding the duplicated execution.


I feel 1394 PWG does *not* need to make standard for implementation of
SBP-2 devices. May be I am misunderstanding your points. But we may
use ORB fetch queuing utilizing SBP-2. It would be beyond the specification.  
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


-----Original Message-----
From:	Akihiro Shimura [SMTP:shimura@pure.cpdc.canon.co.jp]
Sent:	Tuesday, March 24, 1998 10:02 PM
To:	Greg Shue
Cc:	p1394@pwg.org
Subject:	Re: P1394> Alternative Bi-Di proposal utilizing unordered model(Was Re: unordered execution)




See comment below....


On Mon, 23 Mar 1998 09:55:37 -0800 (PST)
Greg Shue <gregs@sdd.hp.com> wrote:


> Akihiro Shimura wrote:
(snip)
> > In this SHPT model, re-ordering the ORB between write and read
> > request in the initiator is not required at all because the target
> > does re-order between them.
> > In the "ordered model", the ORB re-ordering in the initiator will
> > occur whenever the requested order in the task set is not appropriate
> > for the "target" to execute.
> > Because the ORB re-ordering in the initiator requires aborting tasks
> > by the target, re-appending the tasks to the task list by the
> > initiator and re-fetching the tasks by the target potentially in
> > non-linear order of retries, it will be expensive for the initiator,
> > the target and the bus.
> > 
> > Also, in this SHPT model, the initiator does not need to synchronize
> > with the indication from the target to append the pending read request
> > to the task set because the pending state is achieved in the execution
> > agent on the target.
> > In the "ordered model", if the initiator limits the number of
> > requests in the task set very small (e.g., one) to avoid potential ORB
> > re-ordering in the initiator, the target will enter suspend state
> > frequently before requests are appended to the task list. In this case,
> > the bandwidth benefit of the SBP-2 will be reduced by the latencies on
> > each side.
> 
> I think you're missing one big clause about the Unordered Execution
> Model.  SBP-2 spec rev 3a, Section 4.6 states:
> 
>   "The unordered model is usually appropriate for direct-access
>   devices for which no poisitional or other context information
>   is inherited from one command to the next."
> 
>   "Unrestricted reordering leaves the responsibility for the
>   assurance of data integrity with the initiator.  If the integrity
>   of data on the device medium could be compromised by unrestricted
>   reordering involving a set of active tasks, {T0, T1, T2, ... Tn}
>   and a new task T', the initiator shall wait until {T0, T1, T2, ... Tn}
>   have completed before appending T' to an active request list."


Thank you for the clarification.
In this mean, the SHPT model will not be an "Unordered Model" under
the "Basic task management model" but be sort of an "Unordered Model"
under the "Queuing Model".


> We have talked quite a bit in various threads on this reflector
> about the "spirit" of SBP-2.  In continuing with this emphasis,
> the spirit of the Unordered Execution model is _completely_
> unordered.  Since the nature of our buffer transfers are ordered
> within each direction, the previous clauses really require no
> more than one message be queued for each direction at a time!
> Anything else is really not consistent with the Unordered
> Execution model.


I'm not sure but I suppose the SHPT model will be still in the "spirit"
of SBP-2 because its features seem to be maintained.


> The only possible supported way around this is to set the 'q' bit
> in the Logical_Unit_Characteristics entry to be one and define a
> command-set dependent queuing model.  But I'm still not sure that
> the interpretation of the 'o' bit in the same entry is affected.


The SHPT model will set the 'q' bit as it was in the original HPT.


> > In addition, this SHPT model does not require to limit maximum data
> > payload size, and does not need to prepare the maximum data payload
> > size of (intermediate) receive buffer to guarantee the delivery.
> 
> In order to support transient link interruptions, either
> additional restrictions are placed on ORBs being queued (that
> they MUST be explicitly completed or aborted to be removed from
> the task set), or maximum sizes must be set.  If neither of these
> mechanisms are defined, then it is possible for the data stream
> to be corrupted because of a Bus Reset which resulted in a
> partially processed ORB being requeued, or a new ORB being
> queued, but interpreted as a partially fetched one.


The SHPT model requires two things as briefly described in the
document.
One is that the initiator shall keep up the "CONTENTS" of buffer until
the request is completed, and shall keep up the relationship between
"sequence identifier" and associated buffer (contents).
Another is that the target shall maintain the "sequence identifier"
and "offset" for the incomplete request, and shall be responsible in
avoiding the duplicated execution.


Since the synchronization between the initiator and the target may be
lost in the way that initiator is behind (the target is ahead), the
target examines the "sequence identifier" provided just after the
re-synchronization is taken by the initiator(possibly behind) and the
target completes without duplicated execution.
Because the "CONTENTS" of buffer and related "sequence identifier"
are kept up by the initiator and the target avoids the duplicated
execution by using maintained "sequence identifier" and "offset", the
data stream will not be corrupted.


Am I still missing something?


Akihiro Shimura

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.


From shimura at pure.cpdc.canon.co.jp  Tue Mar 24 22:59:06 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Alternative Bi-Di proposal utilizing unordered model(Was Re: unordered execution)
In-Reply-To: <01BD57DA.87656C60@INS1.maebashi.dtinet.or.jp>
Message-ID: <199803250359.MAA16742@slant1.pure.cpdc.canon.co.jp>

On Wed, 25 Mar 1998 10:19:34 +0900
Fumio Nagasaka <fumiona@venus.dti.ne.jp> wrote:


> Dear Akihiro,
> 
> Akihiro Shimura wrote:
> >I'm not sure but I suppose the SHPT model will be still in the "spirit"
> >of SBP-2 because its features seem to be maintained.
> 
> Let me clear "sprit of SBP-2".
> 1) Are you going to make something new protocol which has SBP-2 flavor?
> 2) Or, are you going to expand SBP-2 specification?
> 3) Or, are you going to define standard implementation for SBP-2 queuing model? 


4) I am going to define a "command set" that includes command-set
   dependent task management model(queuing model).


Akihiro Shimura

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.


From atsnaka at bsd.canon.co.jp  Thu Mar 26 04:12:27 1998
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:50 2009
Subject: P1394> p1212r WG Tokyo meeting
Message-ID: <199803260912.SAA26694@bsdmail.bsd.canon.co.jp>

--=====================_890871147==_
Content-Type: text/plain; charset="us-ascii"


Everyone,


Here are the meeting details for 
the next p1212r WG meeting in Tokyo Japan.
I will attach a map that shows the way to 
the Canon office from Musashi-Kosugi station.


Musashi-Kosugi station is about 30min. train ride from
Shibuya.


Dave, can everyone consider this as a p1212r
official announcement ?


------------------------------------------
  -Meeting Details-


date  : April 20-Mon, (April 21...1/2 day max ?) 1998
          (Next Monday after the 1394 TA Korea meeting)
time  : 10:30 am- 17:00 pm
place :  Tokyo(Kawasaki), Japan


          Canon Inc. Kosugi-office
          53 Imai Kami-cho
          Nakahara-Ku, Kawasaki-shi
          Japan
          
          There will be some guidance to the meeting room
          from the office lobby.


          (10-15 minutes walk from Musashi-Kosugi Station
           of either JR Nanbu-line, or Tokyu Toyoko-line.)     
        
------------------------------------------


There is a hotel 2 min. walk from Musashi-Kosugi Station.
I don't have the details now, so I will send out information
on that hotel tomorrow.


Please ping me if you plan to attend this meeting.
This is necessary for renting  meeting 
space, etc.






--=====================_890871147==_
Content-Type: application/pdf; name="ksgmapE.PDF"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ksgmapE.PDF"


[encoded data, 32417 characters]
Pl0NCj4+DQpzdGFydHhyZWYNCjIzMTQ0DQolJUVPRg0K
--=====================_890871147==_
Content-Type: text/plain; charset="us-ascii"




-----------------------------------------
Atsushi Nakamura
-----------------------------------------


BJ Technology Development 22,
Canon Inc.


53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211


tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------
--=====================_890871147==_--

From don at lexmark.com  Tue Mar 31 08:05:34 1998
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Microsoft dangles 1394 carrot
Message-ID: <199803311305.AA04054@interlock2.lexmark.com>

fyi....


**********************************************
* Don Wright                 don@lexmark.com *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************


---------------------------------------------------------------------------
--------




                       Microsoft dangles 1394 carrot


 Electronic Engineering Times via NewsEdge Corporation : Redmond, Wash. -
 In an effort to promote two of the particulars of its current hardware
 vision, Microsoft Corp. has inserted a clause into market-development
 agreements (MDAs) it routinely signs with PC makers. The clause promises a
 cash incentive to OEMs that ship as much as 15 percent of their systems
 starting this July with either the 1394 interface or a TV tuner on board.


 At least three PC makers contacted by EE Times said the clause has
 appeared in their MDAs this year.


 For some time, Microsoft has offered PC makers MDAs that allow OEMs to
 earn what essentially are rebates for the royalty payments on systems
 shipped with Windows. The incentives are earned by agreeing to support
 specific Microsoft marketing objectives, such as putting a Windows logo on
 their PCs.


 The new clause has raised eyebrows for some OEMs that fear Microsoft is
 exerting inappropriate influence over hardware directions. "Microsoft is
 trying to make it revenue-neutral for the OEM to add these new
 technologies, but I'm not convinced it's a totally healthy thing to try to
 force acceptance of a product that a user might not want," said one
 PC-company executive familiar with the agreements who asked not to be
 named.


 Carl Stork, Microsoft's general manager for Windows platforms, countered
 that any such marketing incentives are purely voluntary and benefit the
 industry as a whole. "Every year we have stretch goals," he said.


 The call for TV tuners comes as Windows 98 builds in first-time support
 under Windows for an analog TV tuner, electronic program guide and data
 broadcasting over the TV's vertical blanking interval. The features are
 being marketed as "WebTV for Windows," referring to Microsoft's WebTV
 Networks subsidiary purchased last year that makes Internet-based TV
 set-top boxes.


 As for the incentives to support 1394, Stork said, "1394 is desirable.
 Everybody will benefit from it because it will help sell PCs." He also
 pointed out the financial incentives only serve to defray a fraction of
 the actual costs OEMs take on to support the new technologies.


 OEMs grouse that the MDAs represent a way the software maker unfairly
 wields its monopoly power in PC operating systems. The price any given PC
 maker pays for Windows varies based on the number of PCs a company ships
 and the particulars of its MDA. "We would like a published price schedule
 for Windows, but my guess is nobody is paying the same price," said the
 source. "Microsoft keeps playing these games where everything is hidden."


 Copyright (c) 1998 CMP Media Inc.


 <<Electronic Engineering Times -- 03-30-98, p. PG178>>


 [03-30-98 at 15:22 EDT, Copyright 1998, CMP Publications, Inc., File:
 c0330239.8mp]


Entire contents (C) 1998 by INDIVIDUAL, Inc., 8 New England Executive Park
West, Burlington, MA  01803.

From gregs at sdd.hp.com  Tue Mar 31 12:31:53 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:50 2009
Subject: P1394> SBP-2 Extended Reconnect Interval proposal
Message-ID: <199803311731.JAA18101@hpsdlgj1.sdd.hp.com>

FYI,


The current SBP-2 Extended Reconnect Interval proposal
(document T10/98-121r1) is now available as:


  ftp://www.symbios.com/pub/standards/io/x3t10/document.98/98-121r1.pdf



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


From davej at lsi.sel.sony.com  Tue Mar 31 15:53:32 1998
From: davej at lsi.sel.sony.com (Dave James)
Date: Wed May  6 14:00:50 2009
Subject: P1394> RE: p1212r WG Tokyo meeting
Message-ID: <3.0.3.32.19980331125332.006ccdf4@newt.lsi.sel.sony.com>

--=====================_891406412==_
Content-Type: text/plain; charset="us-ascii"


To:      1212r Working Group (and interested individuals)
From:    David V. James, 1212r Chair
Subject: Next p1212r meeting, in Japan


This a minor revision of the previous Email that was
distributed by our host for the next p1212r meeting:


  Host: Atsushi_Nakamura
  Location: Canon, Japan


Please contact our host (Atsushi-san) if you plan
to attend, so that he can better plan for meeting
space and refreshments.


This p1212r meeting is intended to provide a
convenient forum for information sharing between
groups with similar interests. This intent is to
allow  1212r members to better respond to
the needs of active 1394 developers.


****************  -Meeting Details-  ***************


  1212r meeting, Tokyo Japan
  Monday April 20/21 1998 (intended to end early on April 21)
   (the Monday after the 1394 TA Korea meeting)
  10:30(AM)-17:00(PM)
  Tokyo(Kawasaki), Japan


  Hosted by:
  Canon Inc. Kosugi-office
  53 Imai Kami-cho
  Nakahara-Ku, Kawasaki-shi
  Japan
          
  (directions to the meeting room will be
   available in the office lobby)


  10-15 minutes walk from Musashi-Kosugi Station
  of either JR Nanbu-line, or Tokyu Toyoko-line.    
  The attached map shows the way to the
  Canon office from Musashi-Kosugi station.
  Musashi-Kosugi station is about 30min.
  train ride from Shibuya.


-------------- HOTEL -------------------


This hotel is a 2 minute walk from Musashi-Kosugi Station.
There are many other hotels in the Tokyo area,
and the train system is quite efficient.


Hotel The Ellcy
1-403 Kosugi-cho, Nakahara-ku
Kawasaki-shi
tel: 044-733-1111
(2 min walk from Musashi-Kosugi station )


-------------- HOST -------------------


Atsushi Nakamura
BJ Technology Development 22,
Canon Inc.


53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211


tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp


-------------- AGENDA TOPICS ---------------


The following items have been submitted for discussion
at this meeting. Other items are welcome, but can be
best understood if distributed through the reflector
before the meeting.


We will start the meeting with a short introduction to
the CSR Architecture:
  Current specification
  Defined additions (SDD, FDS, language localization)
  Possible additions (proxy's, async channels, messages)
  Related services: number registry services 
  
At the end of the introduction, we will review agenda
requests, including the following, an schedule the
remaining time accordingly.


** Atsushi Nakamura agenda topics **


ITEM-1:
Discussion and voting to freeze the following key values:


1) Key value 1A......FDS Instance_Count
2) Key value 1B......FDS Function_Set(Affinity) directory
3) Key value 19.......FDS Function Info directory


according to the definition discussed in January, and
documented in the FDS document 98-002r0.pdf.


ITEM-2:
In order to effectively utilize the FDS addition for 1394,
a function_class listing registry is necessary either
at 1212 level, or 1394(TA) level.
My understanding is this is unlikely to happen at 1212 level,
so I would like to suggest that this issue (about a
function_class registry) be brought up at the
1394TA architecture liason report, or the 1212
study group, and that the p1212r WG proposes that the
1394TA would be a registry point for a extendable
function_class listing for 1394.
(Of course, we would have to come up with a initial list.)


ITEM-3:
Review the usage of "currentspecID".
Is it (will it be?) the rule that a
current spec ID entry is required as the
first enrty(the smallest ROM address)
for every directory ?


**** Dr. David V. James (Chair) topics ******
          (if time permits...)


ITEM-4: Asynchronous Channels.
Recent presentations (in several forums) by the Chair
have attempted to address the issue of streaming asynchronous
data between source and destination nodes. The intent
is to provide an asynchronous equivalent for isoch
channels and CIP headers. Inputs will be sollicited,
no decisions will be made.


ITEM-5: Message Passing.
The current CSR Architecture defines MESSAGE_REQUEST
and MESSAGE_RESPONSE registers, for use as target
addresses of unsollicited request and response
messages respectively. To be useful, these need
to be uniquely labeled, and perhaps tagged with
source and sequence numbers. An overview of the
possibilities will be presented; inputs will
be sollicited; no decisions will be made.
--=====================_891406412==_
Content-Type: application/pdf; name="ksgmapE2.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ksgmapE2.pdf"


[encoded data, 50512 characters]
OWM+XQ0KPj4NCnN0YXJ0eHJlZg0KMzU3MjENCiUlRU9GDQo=
--=====================_891406412==_
Content-Type: text/plain; charset="us-ascii"




******************************************************************
* Dr. David V. James            * Tel: (408) 955-6295            *
* Sony Research Laboratories    * Fax: (408) 955-5180            *
* LSI Systems Laboratory        * email: jamesd@lsi.sel.sony.com *
* 3300 Zanker Road, M/S SJ-3D3  *        dvj@ibm.net (home)      *
* San Jose, CA 95134            *                                *
******************************************************************
--=====================_891406412==_--

From shimura at pure.cpdc.canon.co.jp  Wed Apr  1 00:46:34 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:50 2009
Subject: P1394> Alternative Bi-Di proposal utilizing unordered model(Was Re: unordered execution)
In-Reply-To: <199803231412.XAA12937@slant1.pure.cpdc.canon.co.jp>
Message-ID: <199804010546.OAA07076@slant1.pure.cpdc.canon.co.jp>

Hello, All,


Preliminary presentation material and documentation of the unordered
queuing model(SHPT) are now available at;


ftp://ftp.tokyoweb.or.jp/pwgc1394/pub/proposals/canon/SHPTprs4.pdf
and
ftp://ftp.tokyoweb.or.jp/pwgc1394/pub/proposals/canon/SHPT04d.pdf


Regards,


Akihiro Shimura




On Mon, 23 Mar 1998 23:12:51 +0900 (JST)
Akihiro Shimura <shimura@pure.cpdc.canon.co.jp> wrote:


> Hello, All,
> 
> I have prepared an alternative proposal for bi-di communication
> mechanism utilizing unordered model to overcome inefficiencies
> potentially caused by the ordered model.
(snip)

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.


From don at lexmark.com  Fri Apr  3 08:38:46 1998
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:50 2009
Subject: P1394> July Meeting
Message-ID: <199804031339.AA06366@interlock2.lexmark.com>

We had previously discussed moving the July meeting around a little (dates
and order or meetings) in  order to make it easier for those attending the
1394 Developer's conference in San Jose to be able attend.  Now, according
to the TA Web site, the developer's conference is June 29th through July
2nd.  Having the July meeting July 6&7 in the San Jose area is right on the
money.  Those flying in for the Developer's conference could have a
wonderful 4th of July in the Bay area between the two meeting.  Am I
missing something?  I don't think we need to change the plans at all.


Don


**********************************************
* Don Wright                 don@lexmark.com *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

From gleclair at agentz.com  Sun Apr  5 20:02:18 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Profile 0.2, FDS update, and SHPT materials posted
Message-ID: <199804031339.AA06366@interlock2.lexmark.com>

Web site is updated as of 4/5/98 - 5 PM PDT.


Sorry for the lateness of this update. See you in Portland.


FYI - I hear Larry may not make it, I'll need someone else to take minutes. Volunteers?


Thanks,
Greg LeClair

From hitoshis at MICROSOFT.com  Wed Apr  8 01:50:20 1998
From: hitoshis at MICROSOFT.com (Hitoshi Sekine)
Date: Wed May  6 14:00:51 2009
Subject: P1394> units and logical units definition
Message-ID: <199804031339.AA06366@interlock2.lexmark.com>

Hi,


I missed this discussion. I am not sure why you had the kind of requirement.
I have never seen that multiple Logical Units are required by a single
function or service. I couldn't find a reason why it is needed. What kind of
function needs to support multiple logical units?


Thanks,
Hitoshi


> -----Original Message-----
> From:	Atsushi_Nakamura [SMTP:atsnaka@bsd.canon.co.jp]
> Sent:	Tuesday, March 17, 1998 5:18 PM
> To:	ALAN_BERKEMA@hp-roseville-om2.om.hp.com; rturner@sharplabs.com
> Cc:	p1394@pwg.org
> Subject:	RE: P1394> units and logical units definition
> 
> 
> It would help to convince me (and probably others)
> that we are going the right way, 
> and that everybodyis in synch. if we can :
> 
> 1. Confirm that the current usage of SBP-2 unit(directory)s and 
>    LUNs are consistant with the idea ("with the spirit")of units
>    and LUNs defined in the SBP-2 spec. 
> 
> >Note that SBP-2's concept of a printer certainly does not match
> >well with our devices.  Disks are easily modeled.  Scanners are
> >fairly easily modeled.  Printers definitely are not.
> 
>    As Greg mentioned, printers are modeled differently(more complex)
>    from disks, and I think we are starting to define a new usage 
>    of SBP-2 units and LUNs in the current printer profile 0.1d that are 
>    different from other SBP-2 devices.
>    (where 1 (printer) function is comprised of multiple units
>     of the same transport protocol (PWG profile over SBP-2) within
>     1 node, and a combination of specific LUNs across these differnt
>     units need to work simultaneously to achieve the (printer) function.)
> 
>   Greg (Shue)'s explanation about an example of a printer model
>   by considering logical units as a service (the cuurent profile0.1d) made
>   sense within itself, but the question whether that usage is the 
>   intended usage or not has not been answered. There also is the issue
>   on how to match up the LUNs
> 
> Eric says;
> >Even if each of those models is allowed by SBP-2, I think
> >the first one (a single unit with multiple LUNs) is both more
> >in the spirit of SBP-2 and more in the spirit of 1394.  
> 
>   The above comment increased the magnitude of my concern.     
>   I think this is a question of how the SBP-2 people intended 
>   units and LUNs to be used, so confirmation with (or a comment from)
>   a SBP-2 expert would help.
> 
> 2. Confirm that the current usage of units(and LUNs) are consistant
>    and "in spirit" with 1394 and 1212 (and other protocols aside from 
>    SBP-2.)
>    Same as above, other protocols(such as AVC/FCP, DPP/Thin,
>    Conf.camera spec. ) achieve the functionality within one "1212"unit.
>    (Services are MUXed within the transport and above)      
>    The current profile will be the first of it's kind to achieve a 
>    functionality by using differnt LUNS across different "1212" units so
>    there is a possiblity that the 1394 PC printer may look "odd"
>    in the 1394 world.
> 
> 3. Confirm within PWG that this is the way to go.
>    As I mentioned, the discussion about desires for mutiple
>    independent channels within 1 LUN is still continuing, so I also agree
> with
>    Alan that this is still hazy.
> 
> 4. Lastly, 
> 
> >      I think a detailed picture matching services to Unit Directories to
> 
> >      LUNs might help.
> 
> I agree with this idea.
> Modelling a printer application may be out of the scope of the profile,
> but I think an example of a what a "basic" printer should look like 
> will help understanding (even within PWG to keep everyone in synch !)
> 
> 
> >      Would be nice, schedule could be tight.
> >      How about 3/19 at 4:00PM?
> >      
> I won't make this, but please go ahead if this schedule is reasonable
> for everyone else.
> I also apologize for not being able to contribute face-to face.
> 
> Ats
> 
> 
> 
> At 11:17 98/03/17 -0800, ALAN_BERKEMA@hp-roseville-om2.om.hp.com wrote:
> 
> > > I thought we had a pretty firm idea on the handling of logical units.
> >      
> >      From the discussion it still seems hazy to me.
> >      
> >      I think a detailed picture matching services to Unit Directories to
> 
> >      LUNs might help.
> >      
> > > Does this discussion require clarification of the current profile 
> > > document, for full understanding?
> >      
> >      Absolutely.
> >      
> > > Also, is there need for a teleconference on this or any other subject 
> > > prior to the next face-to-face meeting?
> >      
> >      Would be nice, schedule could be tight.
> >      How about 3/19 at 4:00PM?
> >      
> >      3/20 could be bad for folks in Japan.
> >      3/23 is due date for the next rev of the spec.
> >      
> > Randy
> > 
> 
> -----------------------------------------
> Atsushi Nakamura
> -----------------------------------------
> 
> BJ Technology Development 22,
> Canon Inc.
> 
> 53 Imai Kami-cho
> Nakahara-Ku, Kawasaki-shi
> postal no. 211
> 
> tel:+81-3-44-733-6111(ext.5593)
>     +81-3-44-739-6634(direct)
> fax:+81-3-44-739-6756
> email(1):Atsushi_Nakamura@cbj.canon.co.jp
> email(2):atsnaka@bsd.canon.co.jp
> -----------------------------------------

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Wed Apr 29 17:04:46 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Call for Command Set Proposals
Message-ID: <H0000d930f3d3c64@MHS>

     Hello all,
     
     I am working on the profile and I just yanked out the current start at 
     the command set as we agreed in Portland. Now I would like to ask for 
     proposals for the new command set to be discussed at VA.
     
     Possible choices:
     
     1) DPP command set (I like this idea)
     2) RBC derivative - Reduce Block Command set used with SBP-2 for Mass 
     storage. Anybody know the web site for this one?
     3) HPT - Cannon proposal
     4) PWG invention something new along the lines of what we started 
     before (seems like we would need a good reason to invent something 
     new)
     5) Other ideas?
     
     If anybody has ideas on these please post and be prepared to present 
     and discuss at the next meeting.
     
     regards,
     Alan

From greg at erc.epson.com  Wed Apr 29 17:14:00 1998
From: greg at erc.epson.com (greg@erc.epson.com)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Call for Command Set Proposals
Message-ID: <199804292119.OAA07084@proxy4.ba.best.com>

RBC spec is on Symbios FTP site just like SBP-2 - different directory.


Greg




----Original Message-----
   >From:    	ALAN_BERKEMA@HP-Roseville-om2.om.hp.com
   >To:        	p1394@pwg.org; pp1394@cpdc.canon.co.jp
   >Subject:    	P1394> Call for Command Set Proposals
   >Date:    	Wednesday, April 29, 1998 2:04 PM
   >
   >     Hello all,
   >     
   >     I am working on the profile and I just yanked out the current start at 
   >     the command set as we agreed in Portland. Now I would like to ask for 
   >     proposals for the new command set to be discussed at VA.
   >     
   >     Possible choices:
   >     
   >     1) DPP command set (I like this idea)
   >     2) RBC derivative - Reduce Block Command set used with SBP-2 for Mass 
   >     storage. Anybody know the web site for this one?
   >     3) HPT - Cannon proposal
   >     4) PWG invention something new along the lines of what we started 
   >     before (seems like we would need a good reason to invent something 
   >     new)
   >     5) Other ideas?
   >     
   >     If anybody has ideas on these please post and be prepared to present 
   >     and discuss at the next meeting.
   >     
   >     regards,
   >     Alan
   >
   >
   >

From jfuller at MICROSOFT.com  Thu Apr 30 03:12:29 1998
From: jfuller at MICROSOFT.com (John Nels Fuller)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Call for Command Set Proposals
Message-ID: <199804292119.OAA07084@proxy4.ba.best.com>

Hi,


RBC is at ftp://ftp.symbios.com/pub/standards/io/t10/drafts/rbc although I
don't know how useful a disk command set will be for printing.


jnf


-----Original Message-----
From: ALAN_BERKEMA@HP-Roseville-om2.om.hp.com
[mailto:ALAN_BERKEMA@HP-Roseville-om2.om.hp.com]
Sent: Wednesday, April 29, 1998 2:05 PM
To: p1394@pwg.org; pp1394@cpdc.canon.co.jp
Subject: P1394> Call for Command Set Proposals




     Hello all,
     
     I am working on the profile and I just yanked out the current start at 
     the command set as we agreed in Portland. Now I would like to ask for 
     proposals for the new command set to be discussed at VA.
     
     Possible choices:
     
     1) DPP command set (I like this idea)
     2) RBC derivative - Reduce Block Command set used with SBP-2 for Mass 
     storage. Anybody know the web site for this one?
     3) HPT - Cannon proposal
     4) PWG invention something new along the lines of what we started 
     before (seems like we would need a good reason to invent something 
     new)
     5) Other ideas?
     
     If anybody has ideas on these please post and be prepared to present 
     and discuss at the next meeting.
     
     regards,
     Alan

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Tue May 12 13:35:52 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Dynamic LUNs
Message-ID: <H0000d930f4e09c3@MHS>

--openmail-part-12ed3a9b-00000001
Content-Type: text/plain; charset=US-ASCII; name="cc:Mail"
Content-Disposition: inline; filename="cc:Mail"
Content-Transfer-Encoding: 7bit


     Please comment on the attached pdf
     
     Thanks,
     Alan


--openmail-part-12ed3a9b-00000001
Content-Type: application/pdf; name="dlun.pdf"
Content-Disposition: attachment; filename="dlun.pdf"
Content-Transfer-Encoding: base64


[encoded data, 37522 characters]
MWQ4Pl0NCj4+DQpzdGFydHhyZWYNCjI2NTA0DQolJUVPRg0K


--openmail-part-12ed3a9b-00000001--

From gleclair at agentz.com  Thu May 14 17:59:14 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Agenda Items - Presentations etc.
Message-ID: <H0000d930f4e09c3@MHS>

Pardon my lateness.


If anyone has specific agenda ideas, needs, etc. please let me know.
I'm putting together the agenda for WASH / VA meeting now.


My rough idea follows:


Thanks,
Greg LeClair
greg@erc.epson.com


================
Rough Ideas


Discussion items
 - Monterey PWG mtg.
 - PWG-C / PWG mtg.
 - p1212r colocation for Monterey mtg.


 - p1212r activities - Greg / Others?
 - ip/1394 activities 
 - Rev 0.3 profile issues - Alan?
	- Dynamic LUNs - Alan
	- Config ROM - Greg
	- SBP-2 Model Issues - Alan
 - Profile Publication
	- Need RAC assigned number
 - Schedule next meeting / telecon

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Thu May 14 18:18:29 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Agenda Items - Presentations etc.
In-Reply-To: <01BD7F49.00066080.gleclair@agentz.com>
Message-ID: <H0000d930f527a76@MHS>

     
Hi Greg,


Please add command set proposals to the agenda.


Thanks,
Alan


______________________________ Reply Separator _________________________________
Subject: P1394> Agenda Items - Presentations etc.
Author:  Non-HP-gleclair (gleclair@agentz.com) at HP-Roseville,uugw3
Date:    5/14/98 2:59 PM




Pardon my lateness.
     
If anyone has specific agenda ideas, needs, etc. please let me know. 
I'm putting together the agenda for WASH / VA meeting now.
     
My rough idea follows:
     
Thanks,
Greg LeClair
greg@erc.epson.com
     
================
Rough Ideas
     
Discussion items
 - Monterey PWG mtg.
 - PWG-C / PWG mtg.
 - p1212r colocation for Monterey mtg.
     
 - p1212r activities - Greg / Others? 
 - ip/1394 activities 
 - Rev 0.3 profile issues - Alan?
        - Dynamic LUNs - Alan
        - Config ROM - Greg
        - SBP-2 Model Issues - Alan
 - Profile Publication
        - Need RAC assigned number
 - Schedule next meeting / telecon
     
     
     

From gregs at sdd.hp.com  Thu May 14 20:03:08 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Dynamic LUNs
In-Reply-To: <H0000d930f4e09c3@MHS>
Message-ID: <199805150003.RAA28893@hpsdlgj1.sdd.hp.com>

Here's some comments on the Dynamic LUN notes sent out by Alan.


A)  I don't think the Dynamic Logical Unit Number scheme was
    intended to _multiplex_ applications to device functions.
    I think it is intended on providing the ability for a node
    to establish a unique connection to identical instances of
    a service without having to:


      1-  Assign fixed LUNs for each service instance
      2-  Crowd the Config ROM with redundant information


B)  After discussions with folks from Microsoft, I would strongly
    recommend NOT using LUN 0 (zero) for anything but a direct
    connection to an instance of the transport client.  The LUN-server
    could easily be identified in the Config ROM as belonging to
    a different LUN.  (Since it's really a different service
    than the transport client.)


C)  The SBP-2 initiator and target drivers do not change a bit.
    Reconnect proceeds normally.  The initiator and target SBP-2
    drivers must already remember LUNs, EUI-64 values, and LoginIDs.


D)  The SBP-2 driver probably will already map connections (LoginIDs?)
    to a socket ID or some other appropriate OS mechanism.


It still strikes me as a clean, simple way to get beyond the constraints
of SBP-2 when appropriate.  Best of all, it's optional!



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


From atsnaka at bsd.canon.co.jp  Thu May 14 20:34:43 1998
From: atsnaka at bsd.canon.co.jp (Atsushi Nakamura)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Agenda Items - Presentations etc.
Message-ID: <001a01bd7f99$411d3940$776a14ac@atsnaka01ii.bsd.canon.co.jp>

Please add FDS review and usage examples to the agenda.
Thank you.


Ats Nakamura


-----Original Message-----
$B:9=P?M(B : Gregory A. LeClair <gleclair@agentz.com>
$B08@h(B : '1394 PWG' <p1394@pwg.org>
$BF|;~(B : 1998$BG/(B5$B7n(B15$BF|(B 7:06
$B7oL>(B : P1394> Agenda Items - Presentations etc.




>Pardon my lateness.
>
>If anyone has specific agenda ideas, needs, etc. please let me know.
>I'm putting together the agenda for WASH / VA meeting now.
>
>My rough idea follows:
>
>Thanks,
>Greg LeClair
>greg@erc.epson.com
>
>================
>Rough Ideas
>
>Discussion items
> - Monterey PWG mtg.
> - PWG-C / PWG mtg.
> - p1212r colocation for Monterey mtg.
>
> - p1212r activities - Greg / Others?
> - ip/1394 activities 
> - Rev 0.3 profile issues - Alan?
> - Dynamic LUNs - Alan
> - Config ROM - Greg
> - SBP-2 Model Issues - Alan
> - Profile Publication
> - Need RAC assigned number
> - Schedule next meeting / telecon
>
>
>
>
>

From Nagasaka.Fumio at exc.epson.co.jp  Thu May 14 20:48:57 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Agenda Items - Presentations etc.
Message-ID: <001a01bd7f99$411d3940$776a14ac@atsnaka01ii.bsd.canon.co.jp>

Hi Greg,


Please add short review for SBP-2 printing under current OS in the
agenda.


Some consumer OS do not support unsolicited status, thus we need to
discuss whether we shall define reverse direction without unsolicited
status
or not. Also please see my PDF file attached previous e-mail,


Thank you,
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


	-----Original Message-----
	From:	Gregory A. LeClair [SMTP:gleclair@agentz.com]
	Sent:	Friday, May 15, 1998 6:59 AM
	To:	'1394 PWG'
	Subject:	P1394> Agenda Items - Presentations etc.


	Pardon my lateness.


	If anyone has specific agenda ideas, needs, etc. please let me
know.
	I'm putting together the agenda for WASH / VA meeting now.


	My rough idea follows:


	Thanks,
	Greg LeClair
	greg@erc.epson.com


	================
	Rough Ideas


	Discussion items
	 - Monterey PWG mtg.
	 - PWG-C / PWG mtg.
	 - p1212r colocation for Monterey mtg.


	 - p1212r activities - Greg / Others?
	 - ip/1394 activities 
	 - Rev 0.3 profile issues - Alan?
		- Dynamic LUNs - Alan
		- Config ROM - Greg
		- SBP-2 Model Issues - Alan
	 - Profile Publication
		- Need RAC assigned number
	 - Schedule next meeting / telecon




	

From gleclair at agentz.com  Fri May 15 16:17:18 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Web site updated
Message-ID: <001a01bd7f99$411d3940$776a14ac@atsnaka01ii.bsd.canon.co.jp>

If your doc is missing pleasde let me know.


Thanks,


Greg
greg@erc.epson.com

From ewa at apple.com  Mon May 18 01:16:24 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Agenda Items - Presentations etc.
Message-ID: <B1851E3F-B6BDD@17.219.108.12>

In my opinion, if an OS does not support unsolicited status, then
that OS does not support SBP-2.  I cannot imagine that a consumer
OS would not have full SBP-2 support.  I suggest that you should
ask the OS vendor to support unsolicited status, or to explain how
it can be used.


Mac OS will have full support for unsolicited status in SBP-2.


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.      408-974-8187
--------------------------------------


>Hi Greg,
>
>Please add short review for SBP-2 printing under current OS in the
>agenda.
>
>Some consumer OS do not support unsolicited status, thus we need to
>discuss whether we shall define reverse direction without unsolicited
>status
>or not. Also please see my PDF file attached previous e-mail,
>
>Thank you,
>--------------------------------------------
>-------------------------------
>Fumio Nagasaka
>Epson Software Development Laboratory Inc.
>Tel +81 268 25 4111,  Fax +81 268 25 4627
>E-mail to nagasaka.fumio@exc.epson.co.jp
>
>	-----Original Message-----
>	From:	Gregory A. LeClair [SMTP:gleclair@agentz.com]
>	Sent:	Friday, May 15, 1998 6:59 AM
>	To:	'1394 PWG'
>	Subject:	P1394> Agenda Items - Presentations etc.
>
>	Pardon my lateness.
>
>	If anyone has specific agenda ideas, needs, etc. please let me
>know.
>	I'm putting together the agenda for WASH / VA meeting now.
>
>	My rough idea follows:
>
>	Thanks,
>	Greg LeClair
>	greg@erc.epson.com
>
>	================
>	Rough Ideas
>
>	Discussion items
>	 - Monterey PWG mtg.
>	 - PWG-C / PWG mtg.
>	 - p1212r colocation for Monterey mtg.
>
>	 - p1212r activities - Greg / Others?
>	 - ip/1394 activities 
>	 - Rev 0.3 profile issues - Alan?
>		- Dynamic LUNs - Alan
>		- Config ROM - Greg
>		- SBP-2 Model Issues - Alan
>	 - Profile Publication
>		- Need RAC assigned number
>	 - Schedule next meeting / telecon

From Nagasaka.Fumio at exc.epson.co.jp  Mon May 18 07:24:44 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Agenda Items - Presentations etc.
Message-ID: <B1851E3F-B6BDD@17.219.108.12>

Hi Eric,


Thanks for your comment.


I think this unsolicited status problem is not a problem of SBP-2 driver
layer.


In Macintosh OS, a PDEF code resource of a higher level printer driver
usually
uses PBWrite(&pb, Async) and PBRead(&pb, Async).


In Windows OS, a SPOOLER user mode application usually uses WriteFile()
and ReadFile().


As PBRead() or ReadFile() is higher level interface, naturally these
APIs are
abstracted from a specific device level driver. In Mac OS8, a Printer
Expert or
PDEFs shall be abstracted from the FSL. Also in Windows, a SPOOLER
shall be abstracted from the SBP-2 Class Driver. Usually these input
functions
are associated with input queues for normal reverse data path from
peripherals.

From gleclair at agentz.com  Mon May 18 07:26:52 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> 1394 PWG - Agenda
Message-ID: <B1851E3F-B6BDD@17.219.108.12>

Here is the proposed agenda for WASH / VA meeting


 - Intro & Info


 - p1212r activities
	- FDS review and usage examples - Ats Nakamura
	- PDS concept discussion - Greg LeClair
	- Future Meetings - Invite to co-locate at July Mtg in Monterey 
		
 - ip/1394 activities
	- <Anybody?>


 - SBP-2 printing issues
	- Current OS implementations - Fumio Nagasaka


 - Review open issues with Rev 0.3 - 1394 PWG printing profile - Alan
	- Dynamic LUNs - Alan
	- Config ROM - Greg
		- Impact of Config ROM - Greg LeClair
	- SBP-2 Model Issues - Alan
		- Command Set proposals - Greg Shue
		- CDB Requirements per Command

From Nagasaka.Fumio at exc.epson.co.jp  Tue May 19 00:19:13 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:51 2009
Subject: FW: P1394> Agenda Items - Presentations etc.
Message-ID: <B1851E3F-B6BDD@17.219.108.12>

[Re-send]


My previous mail was broken. I am sorry for inconvenience. 
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


-----Original Message-----
From:	Nagasaka Fumio 
Sent:	Monday, May 18, 1998 8:25 PM
To:	'Eric Anderson'; p1394@pwg.org
Subject:	RE: P1394> Agenda Items - Presentations etc.


Hi Eric,


Thanks for your comment.


I think this unsolicited status problem is not a problem of SBP-2 driver
layer.


In Macintosh OS, a PDEF code resource of a higher level printer driver
usually
uses PBWrite(&pb, Async) and PBRead(&pb, Async).


In Windows OS, a SPOOLER user mode application usually uses WriteFile()
and ReadFile().


As PBRead() or ReadFile() is higher level interface, naturally these
APIs are
abstracted from a specific device level driver. In Mac OS8, a Printer
Expert or
PDEFs shall be abstracted from the FSL. Also in Windows, a SPOOLER
shall be abstracted from the SBP-2 Class Driver. Usually these input
functions
are associated with input queues for normal reverse data path from
peripherals.

From fumiona at venus.dti.ne.jp  Wed May 20 00:34:37 1998
From: fumiona at venus.dti.ne.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:51 2009
Subject: P1394> unsolicited status
Message-ID: <19980520132838.AKG4FDD@smtp.venus.dti.ne.jp>

Dear Eric,


Today we had a productive result from 1394 PWG.
To support 1394 PWG profile, reverse directional data transfer (a printer send
data to a PC) does not require unsolicited status as a trigger to ask the
initiator to place input ORB for data sent from the printer.


The unsolicited status is an important portion of SBP-2 specification, I agree
with you. However to support this feature, a SBP-2 driver is required to have
several API functions to allow client software to use this functionality.


SetFSL_unsoicited_status_Enable(&fsl, true,...)
SetFSL_universalProcPtr_for_unsolicited_status(&fsl, ProcPtr,...)


If an Operating System don't like to open APIs of a SBP-2 driver, due to some
unknown reason, and if these is a filter driver over the SBP-2 driver to
generalize it as a usual read/write function driver,....
then any software developer who is writing a client software for this drivers
stack can not use this SBP-2 specific functionality.


Thus one of simple solution is to design transport protocol which does not
need unsolicited status.






Fumio Nagasaka wrote:
$B!U(BHi Eric,
$B!U(B
$B!U(BThanks for your comment.
$B!U(B
$B!U(BI think this unsolicited status problem is not a problem of SBP-2 driver layer.
$B!U(B
$B!U(BIn Macintosh OS, a PDEF code resource of a higher level printer driver usually
$B!U(Buses PBWrite(&pb, Async) and PBRead(&pb, Async).
$B!U(B
$B!U(BIn Windows OS, a SPOOLER user mode application usually uses WriteFile()
$B!U(Band ReadFile().
$B!U(B
$B!U(BAs PBRead() or ReadFile() is higher level interface, naturally these APIs are
$B!U(Babstracted from a specific device level driver. In Mac OS8, a Printer Expert or
$B!U(BPDEFs shall be abstracted from the FSL. Also in Windows, a SPOOLER
$B!U(Bshall be abstracted from the SBP-2 Class Driver. Usually these input functions
$B!U(Bare associated with input queues for normal reverse data path from peripherals.
$B!U(B
$B!U(BHowever unsolicited status seems unexpected input, thus higher level driver
$B!U(Bdoes not queued any input parameter block in the input queue, in this case.
$B!U(BAn OS is required to have SBP-2 specific input queue to cover unsolicited
$B!U(Bstatus, which is not required for USB, IrDA or MacSerial I/F.
$B!U(B
$B!U(BSo even in Macintosh OS, if we need to make a Printer Expert which is not
$B!U(BSBP-2 specific, and is applicable for other I/F, this layer shall have some
$B!U(Bnotification method to ping a client driver when unsolicited status has come.
$B!U(BAnd this notification does not work when this Printer Expert is connected to
$B!U(BUSB Expert or other device drivers. Is it neat? I think no.
$B!U(B
$B!U(BOne possible solution is to develop a SBP-2 specific filter layer driver which
$B!U(Binvoke notification when unsolicited status has reported from SBP-2 layer.
$B!U(BHowever then can this layer insert input data into input queue which was
$B!U(Bprovided by higher level driver? I think it cannot.
$B!U(B--------------------------------------------
$B!U(B-------------------------------
$B!U(BFumio Nagasaka
$B!U(BEpson Software Development Laboratory Inc.
$B!U(BTel +81 268 25 4111,  Fax +81 268 25 4627
$B!U(BE-mail to nagasaka.fumio@exc.epson.co.jp
$B!U(B
$B!U(B-----Original Message-----
$B!U(BFrom:	Eric Anderson [SMTP:ewa@apple.com]
$B!U(BSent:	Monday, May 18, 1998 2:16 PM
$B!U(BTo:	p1394@pwg.org
$B!U(BSubject:	RE: P1394> Agenda Items - Presentations etc.
$B!U(B
$B!U(BIn my opinion, if an OS does not support unsolicited status, then
$B!U(Bthat OS does not support SBP-2.  I cannot imagine that a consumer
$B!U(BOS would not have full SBP-2 support.  I suggest that you should
$B!U(Bask the OS vendor to support unsolicited status, or to explain how
$B!U(Bit can be used.
$B!U(B
$B!U(BMac OS will have full support for unsolicited status in SBP-2.
$B!U(B
$B!U(B--------------------------------------
$B!U(BEric Anderson            ewa@apple.com
$B!U(BApple Computer, Inc.      408-974-8187
$B!U(B--------------------------------------
$B!U(B
$B!U(B>Hi Greg,
$B!U(B>
$B!U(B>Please add short review for SBP-2 printing under current OS in the
$B!U(B>agenda.
$B!U(B>
$B!U(B>Some consumer OS do not support unsolicited status, thus we need to
$B!U(B>discuss whether we shall define reverse direction without unsolicited
$B!U(B>status
$B!U(B>or not. Also please see my PDF file attached previous e-mail,
$B!U(B>
$B!U(B>Thank you,
$B!U(B>--------------------------------------------
$B!U(B>-------------------------------
$B!U(B>Fumio Nagasaka
$B!U(B>Epson Software Development Laboratory Inc.
$B!U(B>Tel +81 268 25 4111,  Fax +81 268 25 4627
$B!U(B>E-mail to nagasaka.fumio@exc.epson.co.jp
$B!U(B>
$B!U(B>	-----Original Message-----
$B!U(B>	From:	Gregory A. LeClair [SMTP:gleclair@agentz.com]
$B!U(B>	Sent:	Friday, May 15, 1998 6:59 AM
$B!U(B>	To:	'1394 PWG'
$B!U(B>	Subject:	P1394> Agenda Items - Presentations etc.
$B!U(B>
$B!U(B>	Pardon my lateness.
$B!U(B>
$B!U(B>	If anyone has specific agenda ideas, needs, etc. please let me
$B!U(B>know.
$B!U(B>	I'm putting together the agenda for WASH / VA meeting now.
$B!U(B>
$B!U(B>	My rough idea follows:
$B!U(B>
$B!U(B>	Thanks,
$B!U(B>	Greg LeClair
$B!U(B>	greg@erc.epson.com
$B!U(B>
$B!U(B>	================
$B!U(B>	Rough Ideas
$B!U(B>
$B!U(B>	Discussion items
$B!U(B>	 - Monterey PWG mtg.
$B!U(B>	 - PWG-C / PWG mtg.
$B!U(B>	 - p1212r colocation for Monterey mtg.
$B!U(B>
$B!U(B>	 - p1212r activities - Greg / Others?
$B!U(B>	 - ip/1394 activities 
$B!U(B>	 - Rev 0.3 profile issues - Alan?
$B!U(B>		- Dynamic LUNs - Alan
$B!U(B>		- Config ROM - Greg
$B!U(B>		- SBP-2 Model Issues - Alan
$B!U(B>	 - Profile Publication
$B!U(B>		- Need RAC assigned number
$B!U(B>	 - Schedule next meeting / telecon
$B!U(B
$B!U(B


-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp

From gleclair at agentz.com  Thu May 21 08:51:38 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Materials from Wash DC Meeting.
Message-ID: <19980520132838.AKG4FDD@smtp.venus.dti.ne.jp>

Hi all.


If you have not already done so, please forward a copy of any materials presented, 
minutes, etc. so I can put related info into place on the Web site with the updated profile.


I'd like to get this done by Friday 5/29.


Thanks,
Greg LeClair

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Thu May 21 18:05:08 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:51 2009
Subject: P1394> May 1394 PWG Definitions
Message-ID: <H0000d930f5b20ad@MHS>

Here are the definitions that we came up with at the May 1394, PWG meeting. We 
did not achieve rough consensus on the definitions for a queue and a function so
please comment.


Thanks,
Alan




-----
Unit: Synonymous with a Unit Directory. A unit has a one to one correspondence 
with a device driver. From SBP-2: A component of a Serial Bus node that provides
processing, memory, I/O or some other functionality. Once the node is 
initialized, the unit provides a CSR interface that is typically accessed by 
device driver software at an initiator. A node may have multiple units, which 
normally operate independently of each other. Within this standard, a unit is 
equivalent to a target.


Service: A sub component of a unit that operates on a set of tasks independent 
of other services of the same unit. For SBP-2, there is a one-to-one 
correspondence between a service and a logical unit (LUN). For example, a 
printer (unit) might implement a PDL service responsible for data flow to the 
printer and a management service responsible for control and status.


-----
Queue: A collection of ORBS that proceed or block independent of other queues.




by Atsushi Nakamura
----
My shot at definition of "function":
A function is part of the unit architecture and is an instance of a device 
model, e.g.,   mass storage, CD-ROM or printer. A function is usually a 
collection of services that are user identifiable.
-----


The definition of a function seems to indicate that a function is a unit.

From rturner at sharplabs.com  Fri May 22 00:34:10 1998
From: rturner at sharplabs.com (Randy Turner)
Date: Wed May  6 14:00:51 2009
Subject: P1394> May 1394 PWG Definitions
In-Reply-To: <H0000d930f5b20ad@MHS>
Message-ID: <Version.32.19980521213129.00ddaa40@admsrvnt02.enet.sharplabs.com>

Hi guys,


Help me refresh my memory.


The definition of a service below says there is a one-to-one correspondence
between a LUN and a service, and that services are independent of each
other. Does this imply that LUN (1)  and LUN (2) within a particular unit
CANNOT be "instances" of the same service?


Randy


At 03:05 PM 5/21/98 -0700, you wrote:
>Here are the definitions that we came up with at the May 1394, PWG
meeting. We 
>did not achieve rough consensus on the definitions for a queue and a
function so
>please comment.
>
>Thanks,
>Alan
>
>
>-----
>Unit: Synonymous with a Unit Directory. A unit has a one to one
correspondence 
>with a device driver. From SBP-2: A component of a Serial Bus node that
provides
>processing, memory, I/O or some other functionality. Once the node is 
>initialized, the unit provides a CSR interface that is typically accessed by 
>device driver software at an initiator. A node may have multiple units,
which 
>normally operate independently of each other. Within this standard, a unit
is 
>equivalent to a target.
>
>Service: A sub component of a unit that operates on a set of tasks
independent 
>of other services of the same unit. For SBP-2, there is a one-to-one 
>correspondence between a service and a logical unit (LUN). For example, a 
>printer (unit) might implement a PDL service responsible for data flow to
the 
>printer and a management service responsible for control and status.
>
>-----
>Queue: A collection of ORBS that proceed or block independent of other
queues.
>
>
>by Atsushi Nakamura
>----
>My shot at definition of "function":
>A function is part of the unit architecture and is an instance of a device 
>model, e.g.,   mass storage, CD-ROM or printer. A function is usually a 
>collection of services that are user identifiable.
>-----
>
>The definition of a function seems to indicate that a function is a unit.
> 

From atsnaka at bsd.canon.co.jp  Fri May 22 03:14:27 1998
From: atsnaka at bsd.canon.co.jp (Atsushi Nakamura)
Date: Wed May  6 14:00:51 2009
Subject: P1394> May 1394 PWG Definitions
Message-ID: <Version.32.19980521213129.00ddaa40@admsrvnt02.enet.sharplabs.com>

First of all,
The defintion of "function" is for p1212r FDS purposes.
We may not even have to define "function" for the PWG profile, but it is needed
 for FDS.
I apologize if I should of done this in the 1212 reflector.


Alan said; 
>
>The definition of a function seems to indicate that a function is a unit.
>


It CAN be considered that way in a ceratin implementation, but we CONNOT 
say that is the ONLY way we have to see it.
 (Especially in the case of FDS, where we have to start thinking
about other protocols.)
At one point in the discussison, Brian had mentioned that some people may
consider a service as a function, and visa-versa. I agree to this idea, and I guess
we are not allowed to give an answer (restriction) to the relationship between a
function and a  unit.
We agreed a unit corresponds to a driver (in the case of the PWG profile). 
If so, the relationship of a driver to a function is implementation specific.


The only restrictions I think I can make for "function" are : 


1) A part of the unit architecture (not meaning a part of the unit, but meaning
    a part of this architecture i.e. part of a node, module, or whatever)
2) A collection(meaning 1 or more) of services
3) User identifiable


I cannot think of more resrtictions to add and still make the definition consistant
within 1212  


ats


>
>by Atsushi Nakamura
>----
>My shot at definition of "function":
>A function is part of the unit architecture and is an instance of a device 
>model, e.g.,   mass storage, CD-ROM or printer. A function is usually a 
>collection of services that are user identifiable.
>-----
>
>The definition of a function seems to indicate that a function is a unit.
>

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Fri May 22 11:22:36 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:51 2009
Subject: P1394> May 1394 PWG Definitions
In-Reply-To: <005101bd8551$5d5f1700$082fcd85@atsnaka01ii.bsd.canon.c>
Message-ID: <H0000d930f5c6072@MHS>

--openmail-part-13194c3c-00000001
Content-Type: application/octet-stream; name="1.txt"
Content-Disposition: attachment; filename="1.txt"
Content-Transfer-Encoding: base64


UmVjZWl2ZWQ6IGZyb20gcGFscmVsMy5ocC5jb20gKHBhbHJlbDMuaHAuY29tIFsxNS44MS4x
ODQuMTBdKSBieSB2ZW51cy5yb3NlLmhwLmNvbSB3aXRoIEVTTVRQICg4LjcuMS84LjcuMyBU
SVMgNS4wIE9wZW5tYWlsKSBpZCBBQUExOTA3NiBmb3IgPEFMQU5fQkVSS0VNQUBocC1yb3Nl
dmlsbGUtb20yLm9tLmhwLmNvbT47IEZyaSwgMjIgTWF5IDE5OTggMDA6MTc6NDAgLTA3MDAg
KFBEVCkKUmVjZWl2ZWQ6IGZyb20gbWVzaHN2MDIudGsubWVzaC5hZC5qcCAobWVzaHN2MDIu
dGsubWVzaC5hZC5qcCBbMTMzLjIwNS4xNi4xMzBdKQoJYnkgcGFscmVsMy5ocC5jb20gKDgu
OC41LzguOC41dGlzKSB3aXRoIEVTTVRQIGlkIEFBQTE3OTU5Cglmb3IgPEFMQU5fQkVSS0VN
QUBocC1yb3NldmlsbGUtb20yLm9tLmhwLmNvbT47IEZyaSwgMjIgTWF5IDE5OTggMDA6MTc6
MzYgLTA3MDAgKFBEVCkKUmVjZWl2ZWQ6IGZyb20gYXRzbmFrYTAxaWkuYnNkLmNhbm9uLmNv
LmpwIChrd3NrNURVMDMua25nLm1lc2guYWQuanAgWzEzMy4yMDUuMjM3LjNdKSBieSBtZXNo
c3YwMi50ay5tZXNoLmFkLmpwICg4LjguOCsyLjdXYmV0YTcvMy41V3BsMS05ODA0MDgxMSkg
d2l0aCBTTVRQIGlkIFFBQTAzMTQ0OyBGcmksIDIyIE1heSAxOTk4IDE2OjEwOjQ4ICswOTAw
IChKU1QpCk1lc3NhZ2UtSUQ6IDwwMDUxMDFiZDg1NTEkNWQ1ZjE3MDAkMDgyZmNkODVAYXRz
bmFrYTAxaWkuYnNkLmNhbm9uLmNvLmpwPgpSZXBseS1UbzogIkF0c3VzaGkgTmFrYW11cmEi
IDxhdHNuYWthQGJzZC5jYW5vbi5jby5qcD4KRnJvbTogIkF0c3VzaGkgTmFrYW11cmEiIDxh
dHNuYWthQGJzZC5jYW5vbi5jby5qcD4KVG86IDxBTEFOX0JFUktFTUFAaHAtcm9zZXZpbGxl
LW9tMi5vbS5ocC5jb20+LCA8cDEzOTRAcHdnLm9yZz4KU3ViamVjdDogUkU6IFAxMzk0PiBN
YXkgMTM5NCBQV0cgRGVmaW5pdGlvbnMKRGF0ZTogRnJpLCAyMiBNYXkgMTk5OCAxNjoxNDoy
NyArMDkwMApNSU1FLVZlcnNpb246IDEuMApDb250ZW50LVR5cGU6IHRleHQvcGxhaW47Cglj
aGFyc2V0PSJpc28tODg1OS0xIgpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0Clgt
UHJpb3JpdHk6IDMKWC1NU01haWwtUHJpb3JpdHk6IE5vcm1hbApYLU1haWxlcjogTWljcm9z
b2Z0IE91dGxvb2sgRXhwcmVzcyA0LjcyLjIxMDYuNApYLU1pbWVPTEU6IFByb2R1Y2VkIEJ5
IE1pY3Jvc29mdCBNaW1lT0xFIFY0LjcyLjIxMDYuNAo=


--openmail-part-13194c3c-00000001
Content-Type: text/plain;charset="iso-8859-1"
Content-Disposition: inline; filename="RE:"
Content-Transfer-Encoding: 7bit


     I am still unclear about the definition of a function vs unit & 
     service.
     
     I do believe that since the PWG has found 1212 to be normative the 
     1212 definition and the PWG definition should serve the same purpose.
     
     Alan




______________________________ Reply Separator _________________________________
Subject: RE: P1394> May 1394 PWG Definitions
Author:  Non-HP-atsnaka (atsnaka@bsd.canon.co.jp) at HP-Roseville,mimegw3
Date:    5/22/98 12:14 AM




First of all,
The defintion of "function" is for p1212r FDS purposes.
We may not even have to define "function" for the PWG profile, but it is needed
 for FDS.
I apologize if I should of done this in the 1212 reflector.
     
Alan said; 
>
>The definition of a function seems to indicate that a function is a unit. 
>
     
It CAN be considered that way in a ceratin implementation, but we CONNOT 
say that is the ONLY way we have to see it.
 (Especially in the case of FDS, where we have to start thinking
about other protocols.)
At one point in the discussison, Brian had mentioned that some people may 
consider a service as a function, and visa-versa. I agree to this idea, and I gu
ess
we are not allowed to give an answer (restriction) to the relationship between a
function and a  unit.
We agreed a unit corresponds to a driver (in the case of the PWG profile). 
If so, the relationship of a driver to a function is implementation specific.
     
The only restrictions I think I can make for "function" are : 
     
1) A part of the unit architecture (not meaning a part of the unit, but meaning
    a part of this architecture i.e. part of a node, module, or whatever)
2) A collection(meaning 1 or more) of services 
3) User identifiable
     
I cannot think of more resrtictions to add and still make the definition consist
ant
within 1212  
     
ats
     
>
>by Atsushi Nakamura
>----
>My shot at definition of "function":
>A function is part of the unit architecture and is an instance of a device 
>model, e.g.,   mass storage, CD-ROM or printer. A function is usually a 
>collection of services that are user identifiable.
>-----
>
>The definition of a function seems to indicate that a function is a unit. 
>
     


--openmail-part-13194c3c-00000001--

From gleclair at agentz.com  Fri May 22 12:15:53 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> May 1394 PWG Definitions
Message-ID: <H0000d930f5c6072@MHS>

We equated a function to a unit directory. We called it a 'Unit' to equate 
it to the 1212 unit definition.


If we need to include function from the point of view of 1212r - (based on 
what we've been discussing)


A printer (Function) may be implemented with one or more protocols (Units) 
which may allow access to one or more services (LUNs)


Therefore, the definition of function would seem to be
'The higher level capability of the Module / device which is accessed by 
one of the Units. A singular function may be supported by more than one 
Unit.'


Comments?


Greg






-----Original Message-----
From:	ALAN_BERKEMA@HP-Roseville-om2.om.hp.com 
[SMTP:ALAN_BERKEMA@HP-Roseville-om2.om.hp.com]
Sent:	Friday, May 22, 1998 8:23 AM
To:	atsnaka@bsd.canon.co.jp
Cc:	ALAN_BERKEMA@HP-Roseville-om2.om.hp.com; p1394@pwg.org
Subject:	RE: P1394> May 1394 PWG Definitions


I am still unclear about the definition of a function vs unit & service.


I do believe that since the PWG has found 1212 to be normative the 1212 
definition and the PWG definition should serve the same purpose.


     Alan




______________________________ Reply Separator 
_________________________________
Subject: RE: P1394> May 1394 PWG Definitions
Author:  Non-HP-atsnaka (atsnaka@bsd.canon.co.jp) at HP-Roseville,mimegw3
Date:    5/22/98 12:14 AM




First of all,
The defintion of "function" is for p1212r FDS purposes.
We may not even have to define "function" for the PWG profile, but it is 
needed
 for FDS.
I apologize if I should of done this in the 1212 reflector.


Alan said;
>
>The definition of a function seems to indicate that a function is a unit.
>


It CAN be considered that way in a ceratin implementation, but we CONNOT
say that is the ONLY way we have to see it.
 (Especially in the case of FDS, where we have to start thinking
about other protocols.)
At one point in the discussison, Brian had mentioned that some people may
consider a service as a function, and visa-versa. I agree to this idea, and 
I gu
ess
we are not allowed to give an answer (restriction) to the relationship 
between a
function and a  unit.
We agreed a unit corresponds to a driver (in the case of the PWG profile).
If so, the relationship of a driver to a function is implementation 
specific.


The only restrictions I think I can make for "function" are :


1) A part of the unit architecture (not meaning a part of the unit, but 
meaning
    a part of this architecture i.e. part of a node, module, or whatever)
2) A collection(meaning 1 or more) of services
3) User identifiable


I cannot think of more resrtictions to add and still make the definition 
consist
ant
within 1212


ats


>
>by Atsushi Nakamura
>----
>My shot at definition of "function":
>A function is part of the unit architecture and is an instance of a device 
>model, e.g.,   mass storage, CD-ROM or printer. A function is usually a
>collection of services that are user identifiable.
>-----
>
>The definition of a function seems to indicate that a function is a unit.
>

From gleclair at agentz.com  Fri May 22 12:23:31 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> May 1394 PWG Definitions
Message-ID: <H0000d930f5c6072@MHS>

Hi Randy,


I don't see where this would preclude two different LUNs from being 'instances' of the same service.


It becomes an implementation decision.


Greg




-----Original Message-----
From:	Randy Turner [SMTP:rturner@sharplabs.com]
Sent:	Thursday, May 21, 1998 9:34 PM
To:	ALAN_BERKEMA@HP-Roseville-om2.om.hp.com
Cc:	p1394@pwg.org
Subject:	Re: P1394> May 1394 PWG Definitions






Hi guys,


Help me refresh my memory.


The definition of a service below says there is a one-to-one correspondence
between a LUN and a service, and that services are independent of each
other. Does this imply that LUN (1)  and LUN (2) within a particular unit
CANNOT be "instances" of the same service?


Randy


At 03:05 PM 5/21/98 -0700, you wrote:
>Here are the definitions that we came up with at the May 1394, PWG
meeting. We 
>did not achieve rough consensus on the definitions for a queue and a
function so
>please comment.
>
>Thanks,
>Alan
>
>
>-----
>Unit: Synonymous with a Unit Directory. A unit has a one to one
correspondence 
>with a device driver. From SBP-2: A component of a Serial Bus node that
provides
>processing, memory, I/O or some other functionality. Once the node is 
>initialized, the unit provides a CSR interface that is typically accessed by 
>device driver software at an initiator. A node may have multiple units,
which 
>normally operate independently of each other. Within this standard, a unit
is 
>equivalent to a target.
>
>Service: A sub component of a unit that operates on a set of tasks
independent 
>of other services of the same unit. For SBP-2, there is a one-to-one 
>correspondence between a service and a logical unit (LUN). For example, a 
>printer (unit) might implement a PDL service responsible for data flow to
the 
>printer and a management service responsible for control and status.
>
>-----
>Queue: A collection of ORBS that proceed or block independent of other
queues.
>
>
>by Atsushi Nakamura
>----
>My shot at definition of "function":
>A function is part of the unit architecture and is an instance of a device 
>model, e.g.,   mass storage, CD-ROM or printer. A function is usually a 
>collection of services that are user identifiable.
>-----
>
>The definition of a function seems to indicate that a function is a unit.
> 

From hitoshis at MICROSOFT.com  Fri May 22 15:58:36 1998
From: hitoshis at MICROSOFT.com (Hitoshi Sekine)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Co-meeting of 1394 PWG and PWG-C in June
Message-ID: <H0000d930f5c6072@MHS>

Hi,


Is there any final schedule and detail of the co-meeting of 1394 PWG and
PWG-C in June?


Thanks,
Hitoshi

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Fri May 22 17:04:25 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:51 2009
Subject: P1394> May 1394 PWG Definitions
In-Reply-To: <01BD8562.42BB43E0.gleclair@agentz.com>
Message-ID: <H0000d930f5d2724@MHS>

begin 777 1.txt
M4F5C96EV960Z(&9R;VT@871L<F5L,2YH<"YC;VT@*&%T;')E;#$N:'`N8V]M
M(%LQ-2XQ,"XQ-S8N,3!=*2!B>2!V96YU<RYR;W-E+FAP+F-O;2!W:71H($53
M3510("@X+C<N,2\X+C<N,R!425,@-2XP($]P96YM86EL*2!I9"!*04$Q-#8R
M-"!F;W(@/$%,04Y?0D522T5-04!(4"U2;W-E=FEL;&4M;VTR+F]M+FAP+F-O
M;3X[($9R:2P@,C(@36%Y(#$Y.3@@,#DZ,3DZ-#(@+3`W,#`@*%!$5"D*4F5C
M96EV960Z(&9R;VT@<')O>'DT+F)A+F)E<W0N8V]M("AR;V]T0'!R;WAY-"YB
M82YB97-T+F-O;2!;,C`V+C$X-"XQ,SDN,35=*0H)8GD@871L<F5L,2YH<"YC
M;VT@*#@N."XV+S@N."XU=&ES*2!W:71H($533510(&ED($U!03`Y,3<X"@EF
M;W(@/$%,04Y?0D522T5-04!(4"U2;W-E=FEL;&4M;VTR+F]M+FAP+F-O;3X[
M($9R:2P@,C(@36%Y(#$Y.3@@,3(Z,3DZ,C`@+3`T,#`@*$5$5"D*4F5C96EV
M960Z(&9R;VT@<#4N86=E;G1Z+F-O;2`H9VQE8VQA:7(N=FEP+F)E<W0N8V]M
M(%LR,#4N,30Y+C$V."XR,3A=*2!B>2!P<F]X>30N8F$N8F5S="YC;VT@*#@N
M."XX+S@N."Y"15-4*2!W:71H(%--5%`@:60@2D%!,CDW.3,[($9R:2P@,C(@
M36%Y(#$Y.3@@,#DZ,3<Z-#,@+3`W,#`@*%!$5"D*4F5C96EV960Z(&)Y(&QO
M8V%L:&]S="!W:71H($UI8W)O<V]F="!-05!).R!&<FDL(#(R($UA>2`Q.3DX
M(#`Y.C$V.C$P("TP-S`P"DUE<W-A9V4M240Z(#PP,4)$.#4V,BXT,D)"-#-%
M,"YG;&5C;&%I<D!A9V5N='HN8V]M/@I&<F]M.B`B1W)E9V]R>2!!+B!,94-L
M86ER(B`\9VQE8VQA:7)`86=E;G1Z+F-O;3X*4F5P;'DM5&\Z(")G;&5C;&%I
M<D!A9V5N='HN8V]M(B`\9VQE8VQA:7)`86=E;G1Z+F-O;3X*5&\Z("(G04Q!
M3E]"15)+14U!0$A0+5)O<V5V:6QL92UO;3(N;VTN:'`N8V]M)R(*"2`\04Q!
M3E]"15)+14U!0$A0+5)O<V5V:6QL92UO;3(N;VTN:'`N8V]M/BP*("`@("`@
M("`B871S;F%K84!B<V0N8V%N;VXN8V\N:G`B(#QA='-N86MA0&)S9"YC86YO
M;BYC;RYJ<#X*0V,Z(")P,3,Y-$!P=V<N;W)G(B`\<#$S.31`<'=G+F]R9SX*
M4W5B:F5C=#H@4D4Z(%`Q,SDT/B!-87D@,3,Y-"!05T<@1&5F:6YI=&EO;G,*
M1&%T93H@1G)I+"`R,B!-87D@,3DY."`P.3HQ-3HU,R`M,#<P,`I/<F=A;FEZ
M871I;VXZ($IA>4=E92!#;VUM=6YC871I;VYS"E@M36%I;&5R.B!-:6-R;W-O
M9G0@26YT97)N970@12UM86EL+TU!4$D@+2`X+C`N,"XT,C$Q"D5N8V]D:6YG
*.B`Y."!415A4"G0@
`
end


     Sounds to me like Greg is starting to zone in on what a function is.


     Only part that does not quit gel is that since a function can be made up of 
     one or more units then do we differ from the 1212 function == unit view?


     Alan


______________________________ Reply Separator _________________________________
Subject: RE: P1394> May 1394 PWG Definitions
Author:  Non-HP-gleclair (gleclair@agentz.com) at HP-Roseville,uugw3
Date:    5/22/98 9:15 AM




We equated a function to a unit directory. We called it a 'Unit' to equate 
it to the 1212 unit definition.
     
If we need to include function from the point of view of 1212r - (based on 
what we've been discussing)
     
A printer (Function) may be implemented with one or more protocols (Units) 
which may allow access to one or more services (LUNs)
     
Therefore, the definition of function would seem to be
'The higher level capability of the Module / device which is accessed by 
one of the Units. A singular function may be supported by more than one 
Unit.'
     
Comments?
     
Greg
     
     
     
-----Original Message-----
From:   ALAN_BERKEMA@HP-Roseville-om2.om.hp.com 
[SMTP:ALAN_BERKEMA@HP-Roseville-om2.om.hp.com] 
Sent:   Friday, May 22, 1998 8:23 AM
To:     atsnaka@bsd.canon.co.jp
Cc:     ALAN_BERKEMA@HP-Roseville-om2.om.hp.com; p1394@pwg.org 
Subject:        RE: P1394> May 1394 PWG Definitions
     
I am still unclear about the definition of a function vs unit & service.
     
I do believe that since the PWG has found 1212 to be normative the 1212 
definition and the PWG definition should serve the same purpose.
     
     Alan
     
     
______________________________ Reply Separator 
_________________________________
Subject: RE: P1394> May 1394 PWG Definitions
Author:  Non-HP-atsnaka (atsnaka@bsd.canon.co.jp) at HP-Roseville,mimegw3 
Date:    5/22/98 12:14 AM
     
     
First of all,
The defintion of "function" is for p1212r FDS purposes.
We may not even have to define "function" for the PWG profile, but it is 
needed
 for FDS.
I apologize if I should of done this in the 1212 reflector.
     
Alan said;
>
>The definition of a function seems to indicate that a function is a unit. 
>
     
It CAN be considered that way in a ceratin implementation, but we CONNOT 
say that is the ONLY way we have to see it.
 (Especially in the case of FDS, where we have to start thinking
about other protocols.)
At one point in the discussison, Brian had mentioned that some people may 
consider a service as a function, and visa-versa. I agree to this idea, and 
I gu
ess
we are not allowed to give an answer (restriction) to the relationship 
between a
function and a  unit.
We agreed a unit corresponds to a driver (in the case of the PWG profile). 
If so, the relationship of a driver to a function is implementation 
specific.
     
The only restrictions I think I can make for "function" are :
     
1) A part of the unit architecture (not meaning a part of the unit, but 
meaning
    a part of this architecture i.e. part of a node, module, or whatever)
2) A collection(meaning 1 or more) of services 
3) User identifiable
     
I cannot think of more resrtictions to add and still make the definition 
consist
ant
within 1212
     
ats
     
>
>by Atsushi Nakamura
>----
>My shot at definition of "function":
>A function is part of the unit architecture and is an instance of a device 
>model, e.g.,   mass storage, CD-ROM or printer. A function is usually a 
>collection of services that are user identifiable.
>-----
>
>The definition of a function seems to indicate that a function is a unit. 
>
     
     

From gleclair at agentz.com  Sat May 23 13:12:59 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> May 1394 PWG Definitions
Message-ID: <H0000d930f5d2724@MHS>

I think we need to expand the idea of function == unit on a 1:1 ratio


More like function == unit on a 1:n ratio


Isn't this where we came up with the term Function in the beginning?


A physical device (functional unit) or portion thereof (MFP case)
that uses one or more protocols (unit dir[s] level)
and has a 'unit architecture' which is represented in 
Configuration ROM by one or more Unit Directory entries
which contain one or more service entry points.


GregL




-----Original Message-----
From:	ALAN_BERKEMA@HP-Roseville-om2.om.hp.com [SMTP:ALAN_BERKEMA@HP-Roseville-om2.om.hp.com]
Sent:	Friday, May 22, 1998 2:04 PM
To:	gleclair@agentz.com
Cc:	ALAN_BERKEMA@HP-Roseville-om2.om.hp.com; atsnaka@bsd.canon.co.jp; p1394@pwg.org
Subject:	RE: P1394> May 1394 PWG Definitions


     Sounds to me like Greg is starting to zone in on what a function is.


     Only part that does not quit gel is that since a function can be made up of 
     one or more units then do we differ from the 1212 function == unit view?


     Alan


______________________________ Reply Separator _________________________________
Subject: RE: P1394> May 1394 PWG Definitions
Author:  Non-HP-gleclair (gleclair@agentz.com) at HP-Roseville,uugw3
Date:    5/22/98 9:15 AM




We equated a function to a unit directory. We called it a 'Unit' to equate 
it to the 1212 unit definition.
     
If we need to include function from the point of view of 1212r - (based on 
what we've been discussing)
     
A printer (Function) may be implemented with one or more protocols (Units) 
which may allow access to one or more services (LUNs)
     
Therefore, the definition of function would seem to be
'The higher level capability of the Module / device which is accessed by 
one of the Units. A singular function may be supported by more than one 
Unit.'
     
Comments?
     
Greg
     
     
     
-----Original Message-----
From:   ALAN_BERKEMA@HP-Roseville-om2.om.hp.com 
[SMTP:ALAN_BERKEMA@HP-Roseville-om2.om.hp.com] 
Sent:   Friday, May 22, 1998 8:23 AM
To:     atsnaka@bsd.canon.co.jp
Cc:     ALAN_BERKEMA@HP-Roseville-om2.om.hp.com; p1394@pwg.org 
Subject:        RE: P1394> May 1394 PWG Definitions
     
I am still unclear about the definition of a function vs unit & service.
     
I do believe that since the PWG has found 1212 to be normative the 1212 
definition and the PWG definition should serve the same purpose.
     
     Alan
     
     
______________________________ Reply Separator 
_________________________________
Subject: RE: P1394> May 1394 PWG Definitions
Author:  Non-HP-atsnaka (atsnaka@bsd.canon.co.jp) at HP-Roseville,mimegw3 
Date:    5/22/98 12:14 AM
     
     
First of all,
The defintion of "function" is for p1212r FDS purposes.
We may not even have to define "function" for the PWG profile, but it is 
needed
 for FDS.
I apologize if I should of done this in the 1212 reflector.
     
Alan said;
>
>The definition of a function seems to indicate that a function is a unit. 
>
     
It CAN be considered that way in a ceratin implementation, but we CONNOT 
say that is the ONLY way we have to see it.
 (Especially in the case of FDS, where we have to start thinking
about other protocols.)
At one point in the discussison, Brian had mentioned that some people may 
consider a service as a function, and visa-versa. I agree to this idea, and 
I gu
ess
we are not allowed to give an answer (restriction) to the relationship 
between a
function and a  unit.
We agreed a unit corresponds to a driver (in the case of the PWG profile). 
If so, the relationship of a driver to a function is implementation 
specific.
     
The only restrictions I think I can make for "function" are :
     
1) A part of the unit architecture (not meaning a part of the unit, but 
meaning
    a part of this architecture i.e. part of a node, module, or whatever)
2) A collection(meaning 1 or more) of services 
3) User identifiable
     
I cannot think of more resrtictions to add and still make the definition 
consist
ant
within 1212
     
ats
     
>
>by Atsushi Nakamura
>----
>My shot at definition of "function":
>A function is part of the unit architecture and is an instance of a device 
>model, e.g.,   mass storage, CD-ROM or printer. A function is usually a 
>collection of services that are user identifiable.
>-----
>
>The definition of a function seems to indicate that a function is a unit. 
>
     
     

From rturner at sharplabs.com  Sun May 24 05:46:39 1998
From: rturner at sharplabs.com (Randy Turner)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Dynamic LUNs
In-Reply-To: <199805150003.RAA28893@hpsdlgj1.sdd.hp.com>
Message-ID: <199805240938.CAA04781@slafw.enet.sharplabs.com>

I'm not sure what you are recommending in comment (B) below. If this came
up at the Virginia meeting, can someone elaborate as if LUN 0 for a
particular unit has been "allocated" by Microsoft or some other group?


Randy






At 05:03 PM 5/14/98 -0700, Greg Shue wrote:
>
>Here's some comments on the Dynamic LUN notes sent out by Alan.
>
>A)  I don't think the Dynamic Logical Unit Number scheme was
>    intended to _multiplex_ applications to device functions.
>    I think it is intended on providing the ability for a node
>    to establish a unique connection to identical instances of
>    a service without having to:
>
>      1-  Assign fixed LUNs for each service instance
>      2-  Crowd the Config ROM with redundant information
>
>B)  After discussions with folks from Microsoft, I would strongly
>    recommend NOT using LUN 0 (zero) for anything but a direct
>    connection to an instance of the transport client.  The LUN-server
>    could easily be identified in the Config ROM as belonging to
>    a different LUN.  (Since it's really a different service
>    than the transport client.)
>
>C)  The SBP-2 initiator and target drivers do not change a bit.
>    Reconnect proceeds normally.  The initiator and target SBP-2
>    drivers must already remember LUNs, EUI-64 values, and LoginIDs.
>
>D)  The SBP-2 driver probably will already map connections (LoginIDs?)
>    to a socket ID or some other appropriate OS mechanism.
>
>It still strikes me as a clean, simple way to get beyond the constraints
>of SBP-2 when appropriate.  Best of all, it's optional!
>
>-- 
>Greg Shue
>Hewlett-Packard Company
>Office Products Division			gregs@sdd.hp.com
>----------------------------------------------------------------
> 

From atsnaka at bsd.canon.co.jp  Sun May 24 22:48:22 1998
From: atsnaka at bsd.canon.co.jp (Atsushi Nakamura)
Date: Wed May  6 14:00:51 2009
Subject: P1394> May 1394 PWG Definitions
Message-ID: <000f01bd8787$955740a0$776a14ac@atsnaka01ii.bsd.canon.co.jp>

I had thought that units were equated to drivers from the discussions
in Virginia and it sounded good to me. (Sorry if I misunderstood) 


Greg said : 


>We equated a function to a unit directory. We called it a 'Unit' to equate 
>it to the 1212 unit definition.


but Greg ALSO said : 


>A printer (Function) may be implemented with one or more protocols (Units) 


Your comments seems to say function==unit==protocols. 


No personal offense. In fact, you stated one of my initial concerns when I saw 
the 1212 definition of units for the first time, and how 1394 uses it. I felt some
inconsistency with the 1212 definition of units, and actual usage.
I do not intend to take this up as a problem, but I feel 1394 protocols
(current actual usage) do not equate units with functions, but as
protocols. (ex. AV/C unit, SBP-2 unit, etc.)
Under this circumstances and understanding, equating units to drivers seemed
to fit. 



--
Anyway, I think the following comments will make sense either way.
(units==drivers and units==functions)


Greg said : 
>I think we need to expand the idea of function : unit on a 1:1 ratio


True. Another point is 
1) function : unit on a 1:n ratio......1 function using/supported by one or more protocols
                                                                                                (unit dir level)
2) function : unit on a n:1 ratio......one or more functions supported by 1 protocol.
                                                                                                (unit dir level)


Though the PWG profile may allow  only 1), both have to be allowed  
looking from the point of 1212 (and any protocols).




So...
My 2nd try at "function" : 
'The higher level capability of the Module / node which is accessed by
one or more units, e.g., mass storage, CD-ROM or printer. 
A function is usually a collection of services that are user identifiable.
A function can be accessed by multiple units, and multiple functions can 
be accessed by one unit.'

--


The "function_class entry" of  FDS will represent :
an (physical) instance model of a function




Ats


-----Original Message-----


>I think we need to expand the idea of function == unit on a 1:1 ratio
>
>More like function == unit on a 1:n ratio
>
>Isn't this where we came up with the term Function in the beginning?
>
>A physical device (functional unit) or portion thereof (MFP case)
>that uses one or more protocols (unit dir[s] level)
>and has a 'unit architecture' which is represented in 
>Configuration ROM by one or more Unit Directory entries
>which contain one or more service entry points.
>
>GregL
>
>
>-----Original Message-----
>From: ALAN_BERKEMA@HP-Roseville-om2.om.hp.com [SMTP:ALAN_BERKEMA@HP-Roseville-om2.om.hp.com]
>Sent: Friday, May 22, 1998 2:04 PM
>To: gleclair@agentz.com
>Cc: ALAN_BERKEMA@HP-Roseville-om2.om.hp.com; atsnaka@bsd.canon.co.jp; p1394@pwg.org
>Subject: RE: P1394> May 1394 PWG Definitions
>
>     Sounds to me like Greg is starting to zone in on what a function is.
>
>     Only part that does not quit gel is that since a function can be made up of 
>     one or more units then do we differ from the 1212 function == unit view?
>
>     Alan
>
>______________________________ Reply Separator _________________________________
>Subject: RE: P1394> May 1394 PWG Definitions
>Author:  Non-HP-gleclair (gleclair@agentz.com) at HP-Roseville,uugw3
>Date:    5/22/98 9:15 AM
>
>
>We equated a function to a unit directory. We called it a 'Unit' to equate 
>it to the 1212 unit definition.
>     
>If we need to include function from the point of view of 1212r - (based on 
>what we've been discussing)
>     
>A printer (Function) may be implemented with one or more protocols (Units) 
>which may allow access to one or more services (LUNs)
>     
>Therefore, the definition of function would seem to be
>'The higher level capability of the Module / device which is accessed by 
>one of the Units. A singular function may be supported by more than one 
>Unit.'
>     
>Comments?
>     
>Greg
>     
>     
>     
>-----Original Message-----
>From:   ALAN_BERKEMA@HP-Roseville-om2.om.hp.com 
>[SMTP:ALAN_BERKEMA@HP-Roseville-om2.om.hp.com] 
>Sent:   Friday, May 22, 1998 8:23 AM
>To:     atsnaka@bsd.canon.co.jp
>Cc:     ALAN_BERKEMA@HP-Roseville-om2.om.hp.com; p1394@pwg.org 
>Subject:        RE: P1394> May 1394 PWG Definitions
>     
>I am still unclear about the definition of a function vs unit & service.
>     
>I do believe that since the PWG has found 1212 to be normative the 1212 
>definition and the PWG definition should serve the same purpose.
>     
>     Alan
>     
>     
>______________________________ Reply Separator 
>_________________________________
>Subject: RE: P1394> May 1394 PWG Definitions
>Author:  Non-HP-atsnaka (atsnaka@bsd.canon.co.jp) at HP-Roseville,mimegw3 
>Date:    5/22/98 12:14 AM
>     
>     
>First of all,
>The defintion of "function" is for p1212r FDS purposes.
>We may not even have to define "function" for the PWG profile, but it is 
>needed
> for FDS.
>I apologize if I should of done this in the 1212 reflector.
>     
>Alan said;
>>
>>The definition of a function seems to indicate that a function is a unit. 
>>
>     
>It CAN be considered that way in a ceratin implementation, but we CONNOT 
>say that is the ONLY way we have to see it.
> (Especially in the case of FDS, where we have to start thinking
>about other protocols.)
>At one point in the discussison, Brian had mentioned that some people may 
>consider a service as a function, and visa-versa. I agree to this idea, and 
>I gu
>ess
>we are not allowed to give an answer (restriction) to the relationship 
>between a
>function and a  unit.
>We agreed a unit corresponds to a driver (in the case of the PWG profile). 
>If so, the relationship of a driver to a function is implementation 
>specific.
>     
>The only restrictions I think I can make for "function" are :
>     
>1) A part of the unit architecture (not meaning a part of the unit, but 
>meaning
>    a part of this architecture i.e. part of a node, module, or whatever)
>2) A collection(meaning 1 or more) of services 
>3) User identifiable
>     
>I cannot think of more resrtictions to add and still make the definition 
>consist
>ant
>within 1212
>     
>ats
>     
>>
>>by Atsushi Nakamura
>>----
>>My shot at definition of "function":
>>A function is part of the unit architecture and is an instance of a device 
>>model, e.g.,   mass storage, CD-ROM or printer. A function is usually a 
>>collection of services that are user identifiable.
>>-----
>>
>>The definition of a function seems to indicate that a function is a unit. 
>>
>     
>     
>
>
>
>


From gregs at sdd.hp.com  Tue May 26 12:36:44 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Dynamic LUNs
In-Reply-To: <199805240938.CAA04781@slafw.enet.sharplabs.com>
Message-ID: <199805261636.JAA08455@hpsdlgj1.sdd.hp.com>

SBP-2 says that LUN zero must exist.


When PWG representatives went to Redmond, Microsoft said that
their driver only supports LUN zero.  They also said that LUN
zero needs to be directly mapped to a higher layer, because they
won't support dynamic LUNs.


So, we should think of LUN zero as being "allocated".


NOTE:  Someone (Brian?)  in VA.  said that Microsoft's driver
will be extended to support more LUNs.  There was a comment made
(from the Microsoft rep?)  that Microsoft still will not support
dynamic LUNs.


> 
> 
> I'm not sure what you are recommending in comment (B) below. If this came
> up at the Virginia meeting, can someone elaborate as if LUN 0 for a
> particular unit has been "allocated" by Microsoft or some other group?
> 
> Randy
> 
> 
> 
> At 05:03 PM 5/14/98 -0700, Greg Shue wrote:
> >
> >Here's some comments on the Dynamic LUN notes sent out by Alan.
> >
> >A)  I don't think the Dynamic Logical Unit Number scheme was
> >    intended to _multiplex_ applications to device functions.
> >    I think it is intended on providing the ability for a node
> >    to establish a unique connection to identical instances of
> >    a service without having to:
> >
> >      1-  Assign fixed LUNs for each service instance
> >      2-  Crowd the Config ROM with redundant information
> >
> >B)  After discussions with folks from Microsoft, I would strongly
> >    recommend NOT using LUN 0 (zero) for anything but a direct
> >    connection to an instance of the transport client.  The LUN-server
> >    could easily be identified in the Config ROM as belonging to
> >    a different LUN.  (Since it's really a different service
> >    than the transport client.)
> >
> >C)  The SBP-2 initiator and target drivers do not change a bit.
> >    Reconnect proceeds normally.  The initiator and target SBP-2
> >    drivers must already remember LUNs, EUI-64 values, and LoginIDs.
> >
> >D)  The SBP-2 driver probably will already map connections (LoginIDs?)
> >    to a socket ID or some other appropriate OS mechanism.
> >
> >It still strikes me as a clean, simple way to get beyond the constraints
> >of SBP-2 when appropriate.  Best of all, it's optional!
> >
> >-- 
> >Greg Shue
> >Hewlett-Packard Company
> >Office Products Division			gregs@sdd.hp.com
> >----------------------------------------------------------------
> > 
> 
> 





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


From gregs at sdd.hp.com  Tue May 26 13:11:04 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:51 2009
Subject: P1394> May 1394 PWG Definitions
In-Reply-To: <000f01bd8787$955740a0$776a14ac@atsnaka01ii.bsd.canon.co.jp>
Message-ID: <199805261711.KAA08689@hpsdlgj1.sdd.hp.com>

Ats wrote:
> I do not intend to take this up as a problem, but I feel 1394 protocols
> (current actual usage) do not equate units with functions, but as
> protocols. (ex. AV/C unit, SBP-2 unit, etc.)
> Under this circumstances and understanding, equating units to drivers seemed
> to fit. 


The big struggle I have with current 1212 definitions is that
they do equate *_SW_VERSION with a monolithic driver (where *
could be either Module, Node, or Unit), and they don't provide a
way of encoding arbitrary number of layers of drivers into the
Config ROM.  Under this idea, all other layers would have to
be queried using the identified driver.  And this makes sense
when we remember that 1212 is a Control and Status REGISTER
Architecture.  Now we're trying to encode things well beyond
the register layer.  :-)


> Greg said : 
> >I think we need to expand the idea of function : unit on a 1:1 ratio
> 
> True. Another point is 
> 1) function : unit on a 1:n ratio......1 function using/supported by one or more protocols
>                                                                                                 (unit dir level)
> 2) function : unit on a n:1 ratio......one or more functions supported by 1 protocol.
>                                                                                                 (unit dir level)
> 
> Though the PWG profile may allow  only 1), both have to be allowed  
> looking from the point of 1212 (and any protocols).


We may also need to look at the problem of how to encode multiple
layers of protocols needed to access a function.



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


From rturner at sharplabs.com  Tue May 26 13:32:09 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Dynamic LUNs
Message-ID: <199805261711.KAA08689@hpsdlgj1.sdd.hp.com>

This LUN 0 allocation would only affect us if a Win98/NT5.0 host was the
"target" in a particular config...I didn't think the Microsoft driver
would interfere with us trying to access any arbitrary LUN on "another"
node...(?)


Randy




	-----Original Message-----
	From:	Greg Shue [SMTP:gregs@sdd.hp.com]
	Sent:	Tuesday, May 26, 1998 9:37 AM
	To:	rturner@sharplabs.com
	Cc:	p1394@pwg.org
	Subject:	Re: P1394> Dynamic LUNs




	SBP-2 says that LUN zero must exist.


	When PWG representatives went to Redmond, Microsoft said that
	their driver only supports LUN zero.  They also said that LUN
	zero needs to be directly mapped to a higher layer, because they
	won't support dynamic LUNs.


	So, we should think of LUN zero as being "allocated".


	NOTE:  Someone (Brian?)  in VA.  said that Microsoft's driver
	will be extended to support more LUNs.  There was a comment made
	(from the Microsoft rep?)  that Microsoft still will not support
	dynamic LUNs.


	> 
	> 
	> I'm not sure what you are recommending in comment (B) below.
If this came
	> up at the Virginia meeting, can someone elaborate as if LUN 0
for a
	> particular unit has been "allocated" by Microsoft or some
other group?
	> 
	> Randy
	> 
	> 
	> 
	> At 05:03 PM 5/14/98 -0700, Greg Shue wrote:
	> >
	> >Here's some comments on the Dynamic LUN notes sent out by
Alan.
	> >
	> >A)  I don't think the Dynamic Logical Unit Number scheme was
	> >    intended to _multiplex_ applications to device functions.
	> >    I think it is intended on providing the ability for a
node
	> >    to establish a unique connection to identical instances
of
	> >    a service without having to:
	> >
	> >      1-  Assign fixed LUNs for each service instance
	> >      2-  Crowd the Config ROM with redundant information
	> >
	> >B)  After discussions with folks from Microsoft, I would
strongly
	> >    recommend NOT using LUN 0 (zero) for anything but a
direct
	> >    connection to an instance of the transport client.  The
LUN-server
	> >    could easily be identified in the Config ROM as belonging
to
	> >    a different LUN.  (Since it's really a different service
	> >    than the transport client.)
	> >
	> >C)  The SBP-2 initiator and target drivers do not change a
bit.
	> >    Reconnect proceeds normally.  The initiator and target
SBP-2
	> >    drivers must already remember LUNs, EUI-64 values, and
LoginIDs.
	> >
	> >D)  The SBP-2 driver probably will already map connections
(LoginIDs?)
	> >    to a socket ID or some other appropriate OS mechanism.
	> >
	> >It still strikes me as a clean, simple way to get beyond the
constraints
	> >of SBP-2 when appropriate.  Best of all, it's optional!
	> >
	> >-- 
	> >Greg Shue
	> >Hewlett-Packard Company
	> >Office Products Division			gregs@sdd.hp.com
	>
>----------------------------------------------------------------
	> > 
	> 
	> 




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

From gregs at sdd.hp.com  Tue May 26 13:38:27 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Dynamic LUNs
In-Reply-To: <D10983CAC30DD111B41400805FA6A1C14AB0F2@admsrvnt02.enet.sharplabs.com>
Message-ID: <199805261738.KAA08753@hpsdlgj1.sdd.hp.com>

Microsoft has indicated that Win98/NT5.0 are not going to provide
"target" functionality.  So those comments refer to how a Win98/NT5.0
"initiator" driver expects to interact with Units on other nodes.


You are correct that interactions between other nodes are independent
of Win98/NT5.0.


> 
> 
> This LUN 0 allocation would only affect us if a Win98/NT5.0 host was the
> "target" in a particular config...I didn't think the Microsoft driver
> would interfere with us trying to access any arbitrary LUN on "another"
> node...(?)
> 
> Randy
> 
> 
> 	-----Original Message-----
> 	From:	Greg Shue [SMTP:gregs@sdd.hp.com]
> 	Sent:	Tuesday, May 26, 1998 9:37 AM
> 	To:	rturner@sharplabs.com
> 	Cc:	p1394@pwg.org
> 	Subject:	Re: P1394> Dynamic LUNs
> 
> 
> 	SBP-2 says that LUN zero must exist.
> 
> 	When PWG representatives went to Redmond, Microsoft said that
> 	their driver only supports LUN zero.  They also said that LUN
> 	zero needs to be directly mapped to a higher layer, because they
> 	won't support dynamic LUNs.
> 
> 	So, we should think of LUN zero as being "allocated".
> 
> 	NOTE:  Someone (Brian?)  in VA.  said that Microsoft's driver
> 	will be extended to support more LUNs.  There was a comment made
> 	(from the Microsoft rep?)  that Microsoft still will not support
> 	dynamic LUNs.
> 
> 	> 
> 	> 
> 	> I'm not sure what you are recommending in comment (B) below.
> If this came
> 	> up at the Virginia meeting, can someone elaborate as if LUN 0
> for a
> 	> particular unit has been "allocated" by Microsoft or some
> other group?
> 	> 
> 	> Randy
> 	> 
> 	> 
> 	> 
> 	> At 05:03 PM 5/14/98 -0700, Greg Shue wrote:
> 	> >
> 	> >Here's some comments on the Dynamic LUN notes sent out by
> Alan.
> 	> >
> 	> >A)  I don't think the Dynamic Logical Unit Number scheme was
> 	> >    intended to _multiplex_ applications to device functions.
> 	> >    I think it is intended on providing the ability for a
> node
> 	> >    to establish a unique connection to identical instances
> of
> 	> >    a service without having to:
> 	> >
> 	> >      1-  Assign fixed LUNs for each service instance
> 	> >      2-  Crowd the Config ROM with redundant information
> 	> >
> 	> >B)  After discussions with folks from Microsoft, I would
> strongly
> 	> >    recommend NOT using LUN 0 (zero) for anything but a
> direct
> 	> >    connection to an instance of the transport client.  The
> LUN-server
> 	> >    could easily be identified in the Config ROM as belonging
> to
> 	> >    a different LUN.  (Since it's really a different service
> 	> >    than the transport client.)
> 	> >
> 	> >C)  The SBP-2 initiator and target drivers do not change a
> bit.
> 	> >    Reconnect proceeds normally.  The initiator and target
> SBP-2
> 	> >    drivers must already remember LUNs, EUI-64 values, and
> LoginIDs.
> 	> >
> 	> >D)  The SBP-2 driver probably will already map connections
> (LoginIDs?)
> 	> >    to a socket ID or some other appropriate OS mechanism.
> 	> >
> 	> >It still strikes me as a clean, simple way to get beyond the
> constraints
> 	> >of SBP-2 when appropriate.  Best of all, it's optional!
> 	> >
> 	> >-- 
> 	> >Greg Shue
> 	> >Hewlett-Packard Company
> 	> >Office Products Division			gregs@sdd.hp.com
> 	>
> >----------------------------------------------------------------
> 	> > 
> 	> 
> 	> 
> 
> 
> 	-- 
> 	Greg Shue
> 	Hewlett-Packard Company
> 	Office Products Division			gregs@sdd.hp.com
> 	----------------------------------------------------------------
> 





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


From jds at underscore.com  Wed May 27 09:34:26 1998
From: jds at underscore.com (Jeff Schnitzer)
Date: Wed May  6 14:00:51 2009
Subject: P1394> May 1394 PWG Definitions
Message-ID: <199805261738.KAA08753@hpsdlgj1.sdd.hp.com>

From: "Turner, Randy" <rturner@sharplabs.com>
To: "'p1394@pwg.org'" <p1394@pwg.org>
Subject: RE: P1394> May 1394 PWG Definitions
Date: Tue, 26 May 1998 10:29:44 -0700




I was assuming that "current 1212 definitions" would not be an issue,
and that p1212r would take our requirements into account and revise how
config ROM is structured? With the almost non-existent 1394 product
base, I'm also assuming there are no legacy 1212 issues do deal with.


Randy


	-----Original Message-----
	From:	Greg Shue [SMTP:gregs@sdd.hp.com]
	Sent:	Tuesday, May 26, 1998 10:11 AM
	To:	atsnaka@bsd.canon.co.jp
	Cc:	p1394@pwg.org
	Subject:	Re: P1394> May 1394 PWG Definitions




	Ats wrote:
	> I do not intend to take this up as a problem, but I feel 1394 protocols
	> (current actual usage) do not equate units with functions, but as
	> protocols. (ex. AV/C unit, SBP-2 unit, etc.)
	> Under this circumstances and understanding, equating units to drivers seemed
	> to fit. 


	The big struggle I have with current 1212 definitions is that
	they do equate *_SW_VERSION with a monolithic driver (where *
	could be either Module, Node, or Unit), and they don't provide a
	way of encoding arbitrary number of layers of drivers into the
	Config ROM.  Under this idea, all other layers would have to
	be queried using the identified driver.  And this makes sense
	when we remember that 1212 is a Control and Status REGISTER
	Architecture.  Now we're trying to encode things well beyond
	the register layer.  :-)


	> Greg said : 
	> >I think we need to expand the idea of function : unit on a 1:1 ratio
	> 
	> True. Another point is 
	> 1) function : unit on a 1:n ratio......1 function using/supported by one or more protocols
	>               (unit dir level)
	> 2) function : unit on a n:1 ratio......one or more functions supported by 1 protocol.
	>               (unit dir level)
	> 
	> Though the PWG profile may allow  only 1), both have to be allowed  
	> looking from the point of 1212 (and any protocols).


	We may also need to look at the problem of how to encode multiple
	layers of protocols needed to access a function.


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

From gleclair at agentz.com  Wed May 27 18:57:17 1998
From: gleclair at agentz.com (Greg LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> May 1394 PWG Definitions
Message-ID: <199805261738.KAA08753@hpsdlgj1.sdd.hp.com>

Greg,


I think you may be touching on a couple of points here that tie into 
what we want to put into Config ROM and the location - in a Unit dir 
or in the 'Function' branch.


Some clarifications though:
"Equating *_SW_VERSION with a monolithic driver "
	- 1212 states 'I/O driver software'


"all other layers would have to be queried using the identified driver"
	- Or assumed based on other info in the Config ROM - just using R/W transactions


"And this makes sense when we remember that 1212 is a Control and Status REGISTER
Architecture.  Now we're trying to encode things well beyond the register layer."
	- See page 15, Section 2.1 - item d. Are we out of scope?


ISSUES:
1. Function is something which doesn't consistently map to existing 1212 structure (Y/N)
	- If yes, what is the 1212 structure?
	- If no, what should the structure be in 1212r (FDS?)


2. How much function info SHALL be required in the Config ROM for an implementation.
	- Fixed for all device classes
	- Common subset with vendor or organization unique extensions.


Comments?




Regards,


Greg LeClair








-----Original Message-----
From:	Greg Shue [SMTP:gregs@sdd.hp.com]
Sent:	Tuesday, May 26, 1998 10:11 AM
To:	Atsushi Nakamura
Cc:	p1394@pwg.org
Subject:	Re: P1394> May 1394 PWG Definitions




Ats wrote:
> I do not intend to take this up as a problem, but I feel 1394 protocols
> (current actual usage) do not equate units with functions, but as
> protocols. (ex. AV/C unit, SBP-2 unit, etc.)
> Under this circumstances and understanding, equating units to drivers seemed
> to fit. 


The big struggle I have with current 1212 definitions is that
they do equate *_SW_VERSION with a monolithic driver (where *
 could be either Module, Node, or Unit), and they don't provide a
way of encoding arbitrary number of layers of drivers into the
Config ROM.  Under this idea, all other layers would have to
be queried using the identified driver.  And this makes sense
when we remember that 1212 is a Control and Status REGISTER
Architecture.  Now we're trying to encode things well beyond
the register layer.  :-)


> Greg said : 
> >I think we need to expand the idea of function : unit on a 1:1 ratio
> 
> True. Another point is 
> 1) function : unit on a 1:n ratio......1 function using/supported by one or more protocols
>                                                                                                 (unit dir level)
> 2) function : unit on a n:1 ratio......one or more functions supported by 1 protocol.
>                                                                                                 (unit dir level)
> 
> Though the PWG profile may allow  only 1), both have to be allowed  
> looking from the point of 1212 (and any protocols).


We may also need to look at the problem of how to encode multiple
layers of protocols needed to access a function.



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


From gleclair at agentz.com  Wed May 27 18:32:32 1998
From: gleclair at agentz.com (Greg LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> May 1394 PWG Definitions
Message-ID: <199805261738.KAA08753@hpsdlgj1.sdd.hp.com>

So...


AN> Your comments seems to say function==unit==protocols. 


Well, actually I was trying to get across the fact that function did not 
directly equate to a unit. 


My 2nd try at "function" (and brevity) : 
Function - A capability of the node which is accessed by one or more units.




Regards,
Greg




-----Original Message-----
From:	Atsushi Nakamura [SMTP:atsnaka@bsd.canon.co.jp]
Sent:	Sunday, May 24, 1998 7:48 PM
To:	'ALAN_BERKEMA@HP-Roseville-om2.om.hp.com'; Greg LeClair
Cc:	Peter Johansson; '1394 PWG'
Subject:	RE: P1394> May 1394 PWG Definitions




I had thought that units were equated to drivers from the discussions
in Virginia and it sounded good to me. (Sorry if I misunderstood) 


Greg said : 


>We equated a function to a unit directory. We called it a 'Unit' to equate 
>it to the 1212 unit definition.


but Greg ALSO said : 


>A printer (Function) may be implemented with one or more protocols (Units) 


[Greg LeClair]  Your comments seems to say function==unit==protocols. 
 
No personal offense. In fact, you stated one of my initial concerns when I saw 
the 1212 definition of units for the first time, and how 1394 uses it. I felt some
inconsistency with the 1212 definition of units, and actual usage.
I do not intend to take this up as a problem, but I feel 1394 protocols
(current actual usage) do not equate units with functions, but as
protocols. (ex. AV/C unit, SBP-2 unit, etc.)
Under this circumstances and understanding, equating units to drivers seemed
to fit. 



--
Anyway, I think the following comments will make sense either way.
(units==drivers and units==functions)


Greg said : 
>I think we need to expand the idea of function : unit on a 1:1 ratio


True. Another point is 
1) function : unit on a 1:n ratio......1 function using/supported by one or more protocols
                                                                                                (unit dir level)
2) function : unit on a n:1 ratio......one or more functions supported by 1 protocol.
                                                                                                (unit dir level)


Though the PWG profile may allow  only 1), both have to be allowed  
looking from the point of 1212 (and any protocols).




So...
My 2nd try at "function" : 
'The higher level capability of the Module / node which is accessed by
one or more units, e.g., mass storage, CD-ROM or printer. 
A function is usually a collection of services that are user identifiable.
A function can be accessed by multiple units, and multiple functions can 
be accessed by one unit.'

--


The "function_class entry" of  FDS will represent :
an (physical) instance model of a function




Ats


-----Original Message-----


>I think we need to expand the idea of function == unit on a 1:1 ratio
>
>More like function == unit on a 1:n ratio
>
>Isn't this where we came up with the term Function in the beginning?
>
>A physical device (functional unit) or portion thereof (MFP case)
>that uses one or more protocols (unit dir[s] level)
>and has a 'unit architecture' which is represented in 
>Configuration ROM by one or more Unit Directory entries
>which contain one or more service entry points.
>
>GregL
>
>
>-----Original Message-----
>From: ALAN_BERKEMA@HP-Roseville-om2.om.hp.com [SMTP:ALAN_BERKEMA@HP-Roseville-om2.om.hp.com]
>Sent: Friday, May 22, 1998 2:04 PM
>To: gleclair@agentz.com
>Cc: ALAN_BERKEMA@HP-Roseville-om2.om.hp.com; atsnaka@bsd.canon.co.jp; p1394@pwg.org
>Subject: RE: P1394> May 1394 PWG Definitions
>
>     Sounds to me like Greg is starting to zone in on what a function is.
>
>     Only part that does not quit gel is that since a function can be made up of 
>     one or more units then do we differ from the 1212 function == unit view?
>
>     Alan
>
>______________________________ Reply Separator _________________________________
>Subject: RE: P1394> May 1394 PWG Definitions
>Author:  Non-HP-gleclair (gleclair@agentz.com) at HP-Roseville,uugw3
>Date:    5/22/98 9:15 AM
>
>
>We equated a function to a unit directory. We called it a 'Unit' to equate 
>it to the 1212 unit definition.
>     
>If we need to include function from the point of view of 1212r - (based on 
>what we've been discussing)
>     
>A printer (Function) may be implemented with one or more protocols (Units) 
>which may allow access to one or more services (LUNs)
>     
>Therefore, the definition of function would seem to be
>'The higher level capability of the Module / device which is accessed by 
>one of the Units. A singular function may be supported by more than one 
>Unit.'
>     
>Comments?
>     
>Greg
>     
>     
>     
>-----Original Message-----
>From:   ALAN_BERKEMA@HP-Roseville-om2.om.hp.com 
>[SMTP:ALAN_BERKEMA@HP-Roseville-om2.om.hp.com] 
>Sent:   Friday, May 22, 1998 8:23 AM
>To:     atsnaka@bsd.canon.co.jp
>Cc:     ALAN_BERKEMA@HP-Roseville-om2.om.hp.com; p1394@pwg.org 
>Subject:        RE: P1394> May 1394 PWG Definitions
>     
>I am still unclear about the definition of a function vs unit & service.
>     
>I do believe that since the PWG has found 1212 to be normative the 1212 
>definition and the PWG definition should serve the same purpose.
>     
>     Alan
>     
>     
>______________________________ Reply Separator 
>_________________________________
>Subject: RE: P1394> May 1394 PWG Definitions
>Author:  Non-HP-atsnaka (atsnaka@bsd.canon.co.jp) at HP-Roseville,mimegw3 
>Date:    5/22/98 12:14 AM
>     
>     
>First of all,
>The defintion of "function" is for p1212r FDS purposes.
>We may not even have to define "function" for the PWG profile, but it is 
>needed
> for FDS.
>I apologize if I should of done this in the 1212 reflector.
>     
>Alan said;
>>
>>The definition of a function seems to indicate that a function is a unit. 
>>
>     
>It CAN be considered that way in a ceratin implementation, but we CONNOT 
>say that is the ONLY way we have to see it.
> (Especially in the case of FDS, where we have to start thinking
>about other protocols.)
>At one point in the discussison, Brian had mentioned that some people may 
>consider a service as a function, and visa-versa. I agree to this idea, and 
>I gu
>ess
>we are not allowed to give an answer (restriction) to the relationship 
>between a
>function and a  unit.
>We agreed a unit corresponds to a driver (in the case of the PWG profile). 
>If so, the relationship of a driver to a function is implementation 
>specific.
>     
>The only restrictions I think I can make for "function" are :
>     
>1) A part of the unit architecture (not meaning a part of the unit, but 
>meaning
>    a part of this architecture i.e. part of a node, module, or whatever)
>2) A collection(meaning 1 or more) of services 
>3) User identifiable
>     
>I cannot think of more resrtictions to add and still make the definition 
>consist
>ant
>within 1212
>     
>ats
>     
>>
>>by Atsushi Nakamura
>>----
>>My shot at definition of "function":
>>A function is part of the unit architecture and is an instance of a device 
>>model, e.g.,   mass storage, CD-ROM or printer. A function is usually a 
>>collection of services that are user identifiable.
>>-----
>>
>>The definition of a function seems to indicate that a function is a unit. 
>>
>     
>     
>
>
>
>


From gleclair at agentz.com  Wed May 27 19:34:18 1998
From: gleclair at agentz.com (Greg LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> 1212 Issues - was May 1394 PWG Definitions
Message-ID: <199805261738.KAA08753@hpsdlgj1.sdd.hp.com>

Others that have been involved in revisions work please comment.....


My understanding is that current 1212 definitions are an issue. See if the following applies:


Changes to Config ROM may be limited to new keys and or structures. 
Is this what you meant by "revise how config ROM is structured"?


And yes, there is legacy within 1212. The existing spec, it's inclusion as 
a reference in other specs and bus standards......


The compliance terminology on new items is an issue.


Regards,
Greg




-----Original Message-----
From:	Jeff Schnitzer [SMTP:jds@underscore.com]
Sent:	Wednesday, May 27, 1998 6:34 AM
To:	p1394@pwg.org
Subject:	RE: P1394> May 1394 PWG Definitions


From: "Turner, Randy" <rturner@sharplabs.com>
To: "'p1394@pwg.org'" <p1394@pwg.org>
Subject: RE: P1394> May 1394 PWG Definitions
Date: Tue, 26 May 1998 10:29:44 -0700




I was assuming that "current 1212 definitions" would not be an issue,
and that p1212r would take our requirements into account and revise how
config ROM is structured? With the almost non-existent 1394 product
base, I'm also assuming there are no legacy 1212 issues do deal with.


Randy


	-----Original Message-----
	From:	Greg Shue [SMTP:gregs@sdd.hp.com]
	Sent:	Tuesday, May 26, 1998 10:11 AM
	To:	atsnaka@bsd.canon.co.jp
	Cc:	p1394@pwg.org
	Subject:	Re: P1394> May 1394 PWG Definitions




	Ats wrote:
	> I do not intend to take this up as a problem, but I feel 1394 protocols
	> (current actual usage) do not equate units with functions, but as
	> protocols. (ex. AV/C unit, SBP-2 unit, etc.)
	> Under this circumstances and understanding, equating units to drivers seemed
	> to fit. 


	The big struggle I have with current 1212 definitions is that
	they do equate *_SW_VERSION with a monolithic driver (where *
	could be either Module, Node, or Unit), and they don't provide a
	way of encoding arbitrary number of layers of drivers into the
	Config ROM.  Under this idea, all other layers would have to
	be queried using the identified driver.  And this makes sense
	when we remember that 1212 is a Control and Status REGISTER
	Architecture.  Now we're trying to encode things well beyond
	the register layer.  :-)


	> Greg said : 
	> >I think we need to expand the idea of function : unit on a 1:1 ratio
	> 
	> True. Another point is 
	> 1) function : unit on a 1:n ratio......1 function using/supported by one or more protocols
	>               (unit dir level)
	> 2) function : unit on a n:1 ratio......one or more functions supported by 1 protocol.
	>               (unit dir level)
	> 
	> Though the PWG profile may allow  only 1), both have to be allowed  
	> looking from the point of 1212 (and any protocols).


	We may also need to look at the problem of how to encode multiple
	layers of protocols needed to access a function.


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

From rturner at sharplabs.com  Wed May 27 20:20:50 1998
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:51 2009
Subject: P1394> 1212 Issues - was May 1394 PWG Definitions
Message-ID: <199805261738.KAA08753@hpsdlgj1.sdd.hp.com>

See my comments below...






Randy


	-----Original Message-----
	From:	Greg LeClair [SMTP:gleclair@agentz.com]
	Sent:	Wednesday, May 27, 1998 4:34 PM
	To:	p1394@pwg.org
	Subject:	P1394> 1212 Issues - was May 1394 PWG
Definitions 


	Others that have been involved in revisions work please
comment.....


	My understanding is that current 1212 definitions are an issue.
See if the following applies:


	Changes to Config ROM may be limited to new keys and or
structures. 
	Is this what you meant by "revise how config ROM is structured"?


	Yes. But limiting changes to "structures" is not very limiting.
Our original proposal including the addition of a "function" directory
is just such a structure addition.


	And yes, there is legacy within 1212. The existing spec, it's
inclusion as 
	a reference in other specs and bus standards......


I was referring to "legacy" in the case of "legacy" SBP-2
implementations in shipping devices that would be used as "targets".


I think 1212R is just extending 1212 to cover other requirements that
have come up since original publication. Whatever "R" does should be
backwards compatible with the original 1212. Of course, I may be wrong
about this.




	The compliance terminology on new items is an issue.


	Regards,
	Greg




	-----Original Message-----
	From:	Jeff Schnitzer [SMTP:jds@underscore.com]
	Sent:	Wednesday, May 27, 1998 6:34 AM
	To:	p1394@pwg.org
	Subject:	RE: P1394> May 1394 PWG Definitions


	From: "Turner, Randy" <rturner@sharplabs.com>
	To: "'p1394@pwg.org'" <p1394@pwg.org>
	Subject: RE: P1394> May 1394 PWG Definitions
	Date: Tue, 26 May 1998 10:29:44 -0700




	I was assuming that "current 1212 definitions" would not be an
issue,
	and that p1212r would take our requirements into account and
revise how
	config ROM is structured? With the almost non-existent 1394
product
	base, I'm also assuming there are no legacy 1212 issues do deal
with.


	Randy


		-----Original Message-----
		From:	Greg Shue [SMTP:gregs@sdd.hp.com]
		Sent:	Tuesday, May 26, 1998 10:11 AM
		To:	atsnaka@bsd.canon.co.jp
		Cc:	p1394@pwg.org
		Subject:	Re: P1394> May 1394 PWG Definitions




		Ats wrote:
		> I do not intend to take this up as a problem, but I
feel 1394 protocols
		> (current actual usage) do not equate units with
functions, but as
		> protocols. (ex. AV/C unit, SBP-2 unit, etc.)
		> Under this circumstances and understanding, equating
units to drivers seemed
		> to fit. 


		The big struggle I have with current 1212 definitions is
that
		they do equate *_SW_VERSION with a monolithic driver
(where *
		could be either Module, Node, or Unit), and they don't
provide a
		way of encoding arbitrary number of layers of drivers
into the
		Config ROM.  Under this idea, all other layers would
have to
		be queried using the identified driver.  And this makes
sense
		when we remember that 1212 is a Control and Status
REGISTER
		Architecture.  Now we're trying to encode things well
beyond
		the register layer.  :-)


		> Greg said : 
		> >I think we need to expand the idea of function : unit
on a 1:1 ratio
		> 
		> True. Another point is 
		> 1) function : unit on a 1:n ratio......1 function
using/supported by one or more protocols
		>               (unit dir level)
		> 2) function : unit on a n:1 ratio......one or more
functions supported by 1 protocol.
		>               (unit dir level)
		> 
		> Though the PWG profile may allow  only 1), both have
to be allowed  
		> looking from the point of 1212 (and any protocols).


		We may also need to look at the problem of how to encode
multiple
		layers of protocols needed to access a function.


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

From gleclair at agentz.com  Thu May 28 01:03:49 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> 1212 Issues - was May 1394 PWG Definitions
Message-ID: <199805261738.KAA08753@hpsdlgj1.sdd.hp.com>

Okay. I understand your comments. 


In terms of change / addition to structure - the issues are key 
definitions in 1212r and a registry for the function class values. 




Cheers,
Greg










-----Original Message-----
From:	Turner, Randy [SMTP:rturner@sharplabs.com]
Sent:	Wednesday, May 27, 1998 5:21 PM
To:	p1394@pwg.org
Subject:	RE: P1394> 1212 Issues - was May 1394 PWG Definitions 




See my comments below...






Randy


	-----Original Message-----
	From:	Greg LeClair [SMTP:gleclair@agentz.com]
	Sent:	Wednesday, May 27, 1998 4:34 PM
	To:	p1394@pwg.org
	Subject:	P1394> 1212 Issues - was May 1394 PWG
Definitions 


	Others that have been involved in revisions work please
comment.....


	My understanding is that current 1212 definitions are an issue.
See if the following applies:


	Changes to Config ROM may be limited to new keys and or
structures. 
	Is this what you meant by "revise how config ROM is structured"?


	Yes. But limiting changes to "structures" is not very limiting.
Our original proposal including the addition of a "function" directory
is just such a structure addition.


	And yes, there is legacy within 1212. The existing spec, it's
inclusion as 
	a reference in other specs and bus standards......


I was referring to "legacy" in the case of "legacy" SBP-2
implementations in shipping devices that would be used as "targets".


I think 1212R is just extending 1212 to cover other requirements that
have come up since original publication. Whatever "R" does should be
backwards compatible with the original 1212. Of course, I may be wrong
about this.




	The compliance terminology on new items is an issue.


	Regards,
	Greg




	-----Original Message-----
	From:	Jeff Schnitzer [SMTP:jds@underscore.com]
	Sent:	Wednesday, May 27, 1998 6:34 AM
	To:	p1394@pwg.org
	Subject:	RE: P1394> May 1394 PWG Definitions


	From: "Turner, Randy" <rturner@sharplabs.com>
	To: "'p1394@pwg.org'" <p1394@pwg.org>
	Subject: RE: P1394> May 1394 PWG Definitions
	Date: Tue, 26 May 1998 10:29:44 -0700




	I was assuming that "current 1212 definitions" would not be an
issue,
	and that p1212r would take our requirements into account and
revise how
	config ROM is structured? With the almost non-existent 1394
product
	base, I'm also assuming there are no legacy 1212 issues do deal
with.


	Randy


		-----Original Message-----
		From:	Greg Shue [SMTP:gregs@sdd.hp.com]
		Sent:	Tuesday, May 26, 1998 10:11 AM
		To:	atsnaka@bsd.canon.co.jp
		Cc:	p1394@pwg.org
		Subject:	Re: P1394> May 1394 PWG Definitions




		Ats wrote:
		> I do not intend to take this up as a problem, but I
feel 1394 protocols
		> (current actual usage) do not equate units with
functions, but as
		> protocols. (ex. AV/C unit, SBP-2 unit, etc.)
		> Under this circumstances and understanding, equating
units to drivers seemed
		> to fit. 


		The big struggle I have with current 1212 definitions is
that
		they do equate *_SW_VERSION with a monolithic driver
(where *
		could be either Module, Node, or Unit), and they don't
provide a
		way of encoding arbitrary number of layers of drivers
into the
		Config ROM.  Under this idea, all other layers would
have to
		be queried using the identified driver.  And this makes
sense
		when we remember that 1212 is a Control and Status
REGISTER
		Architecture.  Now we're trying to encode things well
beyond
		the register layer.  :-)


		> Greg said : 
		> >I think we need to expand the idea of function : unit
on a 1:1 ratio
		> 
		> True. Another point is 
		> 1) function : unit on a 1:n ratio......1 function
using/supported by one or more protocols
		>               (unit dir level)
		> 2) function : unit on a n:1 ratio......one or more
functions supported by 1 protocol.
		>               (unit dir level)
		> 
		> Though the PWG profile may allow  only 1), both have
to be allowed  
		> looking from the point of 1212 (and any protocols).


		We may also need to look at the problem of how to encode
multiple
		layers of protocols needed to access a function.


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

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Thu Jun  4 13:18:28 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:51 2009
Subject: P1394> HAVi and PWG-C
Message-ID: <H0000d930f6ca1a6@MHS>

     Anyone form the PWG-C have any thoughts on the HAVi announcement?
     Cover of EE times May 25 1998.
     
     How does it fit with DPP?
     
     It looks to me like it is mainly the API for AV/C over IEC 61883 
     (FCP). Is the SWG2 planning on working with HAVi? How does it fit in?
     
     At first I thought it was another new transport?
     
     Can look at the spec at.
     http://www.hitachi.co.jp/cgi-bin/HAVi/
     
     Thanks,
     Alan

From gleclair at agentz.com  Thu Jun  4 20:35:02 1998
From: gleclair at agentz.com (Greg LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> HAVi and PWG-C
Message-ID: <H0000d930f6ca1a6@MHS>

Alan,


I get the following:
Forbidden
You don't have permission to access /cgi-bin/HAVi/ on this server.


Is there some magic?


Greg






-----Original Message-----
From:	ALAN_BERKEMA@HP-Roseville-om2.om.hp.com [SMTP:ALAN_BERKEMA@HP-Roseville-om2.om.hp.com]
Sent:	Thursday, June 04, 1998 10:18 AM
To:	p1394@pwg.org; pp1394@cpdc.canon.co.jp
Subject:	P1394> HAVi and PWG-C


     Anyone form the PWG-C have any thoughts on the HAVi announcement?
     Cover of EE times May 25 1998.
     
     How does it fit with DPP?
     
     It looks to me like it is mainly the API for AV/C over IEC 61883 
     (FCP). Is the SWG2 planning on working with HAVi? How does it fit in?
     
     At first I thought it was another new transport?
     
     Can look at the spec at.
     http://www.hitachi.co.jp/cgi-bin/HAVi/
     
     Thanks,
     Alan

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Fri Jun  5 11:16:02 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:51 2009
Subject: P1394> HAVi and PWG-C
In-Reply-To: <01BD8FDF.E94C1B80.gleclair@agentz.com>
Message-ID: <H0000d930f6e1d6c@MHS>

begin 777 1.txt
M4F5C96EV960Z(&9R;VT@<&%L<F5L,RYH<"YC;VT@*'!A;')E;#,N:'`N8V]M
M(%LQ-2XX,2XQ.#0N,3!=*2!B>2!V96YU<RYR;W-E+FAP+F-O;2!W:71H($53
M3510("@X+C<N,2\X+C<N,R!425,@-2XP($]P96YM86EL*2!I9"!204$P-3DU
M-R!F;W(@/$%,04Y?0D522T5-04!(4"U2;W-E=FEL;&4M;VTR+F]M+FAP+F-O
M;3X[(%1H=2P@-"!*=6X@,3DY."`Q-SHT-SHT,B`M,#<P,"`H4$14*0I296-E
M:79E9#H@9G)O;2!P<F]X>3,N8F$N8F5S="YC;VT@*')O;W1`<')O>'DS+F)A
M+F)E<W0N8V]M(%LR,#8N,3@T+C$S.2XQ-%TI"@EB>2!P86QR96PS+FAP+F-O
M;2`H."XX+C4O."XX+C5T:7,I('=I=&@@15--5%`@:60@4D%!,3,R.#,*"69O
M<B`\04Q!3E]"15)+14U!0$A0+5)O<V5V:6QL92UO;3(N;VTN:'`N8V]M/CL@
M5&AU+"`T($IU;B`Q.3DX(#$W.C0W.C0R("TP-S`P("A01%0I"E)E8V5I=F5D
M.B!F<F]M(&)O;G-A:2YE<F,N97!S;VXN8V]M("AG;&5C;&%I<BYV:7`N8F5S
M="YC;VT@6S(P-2XQ-#DN,38X+C(Q.%TI(&)Y('!R;WAY,RYB82YB97-T+F-O
M;2`H."XX+C@O."XX+D)%4U0I('=I=&@@4TU44"!I9"!204$R.#DR.3L@5&AU
M+"`T($IU;B`Q.3DX(#$W.C0P.C4P("TP-S`P("A01%0I"E)E8V5I=F5D.B!B
M>2!L;V-A;&AO<W0@=VET:"!-:6-R;W-O9G0@34%023L@5&AU+"`T($IU;B`Q
M.3DX(#$W.C0P.C0Y("TP-S`P"DUE<W-A9V4M240Z(#PP,4)$.$9$1BY%.31#
M,4(X,"YG;&5C;&%I<D!A9V5N='HN8V]M/@I&<F]M.B!'<F5G($QE0VQA:7(@
M/&=L96-L86ER0&%G96YT>BYC;VT^"E)E<&QY+51O.B`B9VQE8VQA:7)`86=E
M;G1Z+F-O;2(@/&=L96-L86ER0&%G96YT>BYC;VT^"E1O.B`B)T%,04Y?0D52
M2T5-04!(4"U2;W-E=FEL;&4M;VTR+F]M+FAP+F-O;2<B"@D@/$%,04Y?0D52
M2T5-04!(4"U2;W-E=FEL;&4M;VTR+F]M+FAP+F-O;3XL"B`@("`@("`@(G`Q
M,SDT0'!W9RYO<F<B"@D@/'`Q,SDT0'!W9RYO<F<^+`H@("`@("`@(")P<#$S
M.31`8W!D8RYC86YO;BYC;RYJ<"(-"@D@/'!P,3,Y-$!C<&1C+F-A;F]N+F-O
M+FIP/@I3=6)J96-T.B!213H@4#$S.30^($A!5FD@86YD(%!71RU#"D1A=&4Z
M(%1H=2P@-"!*=6X@,3DY."`Q-SHS-3HP,B`M,#<P,`I/<F=A;FEZ871I;VXZ
M($%G96YT6B`M(%=O<FQD=VED92!!9V5N=',*6"U-86EL97(Z($UI8W)O<V]F
M="!);G1E<FYE="!%+6UA:6PO34%022`M(#@N,"XP+C0R,3$*16YC;V1I;F<Z
)(#,T(%1%6%0*
`
end


     


Sorry about that.


try 


http://www.hitachi.co.jp/Prod/HAVi/


and then fill out the short form to download pdf.


Alan
______________________________ Reply Separator _________________________________
Subject: RE: P1394> HAVi and PWG-C
Author:  Non-HP-gleclair (gleclair@agentz.com) at HP-Roseville,uugw3
Date:    6/4/98 5:35 PM




     
Alan,
     
I get the following:
Forbidden
You don't have permission to access /cgi-bin/HAVi/ on this server.
     
Is there some magic?
     
Greg
     
     
     
-----Original Message-----
From:   ALAN_BERKEMA@HP-Roseville-om2.om.hp.com [SMTP:ALAN_BERKEMA@HP-Roseville-
om2.om.hp.com]
Sent:   Thursday, June 04, 1998 10:18 AM
To:     p1394@pwg.org; pp1394@cpdc.canon.co.jp 
Subject:        P1394> HAVi and PWG-C
     
     Anyone form the PWG-C have any thoughts on the HAVi announcement? 
     Cover of EE times May 25 1998.
     
     How does it fit with DPP?
     
     It looks to me like it is mainly the API for AV/C over IEC 61883 
     (FCP). Is the SWG2 planning on working with HAVi? How does it fit in?
     
     At first I thought it was another new transport?
     
     Can look at the spec at.
     http://www.hitachi.co.jp/cgi-bin/HAVi/
     
     Thanks,
     Alan

From gleclair at agentz.com  Fri Jun 19 14:55:19 1998
From: gleclair at agentz.com (Gregory A. LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Web Site updated
Message-ID: <H0000d930f6e1d6c@MHS>

All of the content sent to me (minutes, presentations, papers, etc.) from the VA /DC meeting is now on-line.


New items:
A. Rev. 0.4 of the profile has been posted
	- Config ROM section is currently being completed so pardon the missing section 7
B. Transport Command Set Proposal Rev 0c was posted.


Please let me know if anything is in error, missing or not available.


Thanks,
Greg

From jeff at underscore.com  Tue Jun 23 10:50:52 1998
From: jeff at underscore.com (Jeff Schnitzer)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Please ignore this test message.
Message-ID: <H0000d930f6e1d6c@MHS>

Please ignore this test message.


  This message is being posted to verify that PWG mailing lists 
  are public, per Keith Moore's mandate. 


  Note that the Majordomo "who" command remains disabled.  


/Jeff Schnitzer
 <majordomo-owner@pwg.org>


---------------------------------------------------------------
Jeffrey D. Schnitzer      |   Email:  jds@underscore.com 
Underscore, Inc.          |   Voice:  (603) 889-7000
41-C Sagamore Park Rd     |     Fax:  (603) 889-2699   
Hudson, NH  03051-4915    |     Web:  http://www.underscore.com
---------------------------------------------------------------






>To: wg-chairs@apps.ietf.org
>Subject: mailing lists that don't allow outside posts
>cc: moore@cs.utk.edu
>From: Keith Moore <moore@cs.utk.edu>
>Date: Fri, 19 Jun 1998 13:23:39 PDT
>
>It's come to my attention that some of the WG mailing lists don't
>allow posts from people who aren't on the list.
>
>This is not an acceptable policy for IETF WG lists.  It's important to 
>allow people who aren't subscribed to the list to make suggestions 
>or ask questions.  It's also important to allow cross-postings 
>between lists where a single topic is of interest to multiple
>working groups.  Finally, it unfairly penalizes against those 
>who use subaddresses.
>
>There are other ways of effectively blocking spam besides 
>blocking postings from non-subscribers.
>
>Lists that do this need to be fixed asap.
>
>Keith
>

From bob at sismicro.com  Tue Jun 30 15:29:57 1998
From: bob at sismicro.com (Robert Morford)
Date: Wed May  6 14:00:51 2009
Subject: P1394> SBP-2 Logins
Message-ID: <35993CB5.32F9B8ED@sismicro.com>

In revision 0.40 of the PWG 1394 profile, section 24 (Login),
it states that Microsoft has implemented their SBP-2 driver
to login at power-up and not logout until shutdown.  According
to my notes, Microsoft indicated that they are set up to
do this for disk, but that it wasn't necessary for printers.


Does anyone else have information that supports or 
contradicts this statement in the profile? 



-- 
Bob Morford (bob@sismicro.com)
SIS Microelectronics, Inc.
A Subsidiary of Aspec Technology, Inc.
1831 Lefthand Cir., Suite #E
Longmont, CO 80501
303-776-1667 x226


From gregs at sdd.hp.com  Tue Jun 30 15:51:08 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:51 2009
Subject: P1394> SBP-2 Logins
In-Reply-To: <35993CB5.32F9B8ED@sismicro.com>
Message-ID: <199806301951.MAA28022@hpsdlgj1.sdd.hp.com>

> In revision 0.40 of the PWG 1394 profile, section 24 (Login),
> it states that Microsoft has implemented their SBP-2 driver
> to login at power-up and not logout until shutdown.  According
> to my notes, Microsoft indicated that they are set up to
> do this for disk, but that it wasn't necessary for printers.
> 
> Does anyone else have information that supports or 
> contradicts this statement in the profile? 


I think the statement in the profile is out-of-date.


What I recall is essentially the same as your notes.
The Microsoft driver does a login at powerup for disk devices.


It will do dynamic login/logout for printers as needed.
I **think** I was told that they will login when the print
queue for the device becomes non-empty, and they will logout
when the queue becomes empty.


I don't know which policy they will use for scanners.
I hope they will not follow the disk paradigm.


> -- 
> Bob Morford (bob@sismicro.com)



-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------


From hitoshis at MICROSOFT.com  Tue Jun 30 17:26:18 1998
From: hitoshis at MICROSOFT.com (Hitoshi Sekine)
Date: Wed May  6 14:00:51 2009
Subject: P1394> SBP-2 Logins
Message-ID: <199806301951.MAA28022@hpsdlgj1.sdd.hp.com>

Yes, we will log out when never we do not use the device so long as the
device returns device_type 02 or 03 (Printer or Scanner).


Hitoshi Sekine
Program Manager, Windows Operating Systems Group
Microsoft Corporation


One Microsoft Way
Redmond, WA 98-52-6399
hitoshis@microsoft.com
Tel 425-936-1729
Fax 425-936-7329




-----Original Message-----
From: Greg Shue [mailto:gregs@sdd.hp.com]
Sent: Tuesday, June 30, 1998 12:51 PM
To: bob@sismicro.com
Cc: p1394@pwg.org
Subject: Re: P1394> SBP-2 Logins




> In revision 0.40 of the PWG 1394 profile, section 24 (Login),
> it states that Microsoft has implemented their SBP-2 driver
> to login at power-up and not logout until shutdown.  According
> to my notes, Microsoft indicated that they are set up to
> do this for disk, but that it wasn't necessary for printers.
> 
> Does anyone else have information that supports or 
> contradicts this statement in the profile? 


I think the statement in the profile is out-of-date.


What I recall is essentially the same as your notes.
The Microsoft driver does a login at powerup for disk devices.


It will do dynamic login/logout for printers as needed.
I **think** I was told that they will login when the print
queue for the device becomes non-empty, and they will logout
when the queue becomes empty.


I don't know which policy they will use for scanners.
I hope they will not follow the disk paradigm.


> -- 
> Bob Morford (bob@sismicro.com)



-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------


From gleclair at agentz.com  Thu Jul  2 12:42:13 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Config ROM doc posted - Web Site update
Message-ID: <01BDA59D.B53A7E80.gleclair@agentz.com>

Hi all.

The web site was just updated with the config ROM proposal.

If it's acceptable, then Alan can merge it into the spec after Monterey.

Cheers,

Greg LeClair



From gleclair at agentz.com  Thu Jul  2 12:50:02 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Agenda for Monterey
Message-ID: <01BDA59E.C94E2740.gleclair@agentz.com>


Following is current idea for an agenda in Monterey. 

	1. OUI issue - How to publish the profile

	2. Transport Command Set proposal review

	3. Configuration ROM proposal review

	4. Profile review - turn those pages......

Other suggestions / comments welcome.

Have a great 4th everyone! See you in Monterey.

Regards,
Greg LeClair


From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Thu Jul  2 13:34:22 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Agenda for Monterey
In-Reply-To: <01BDA59E.C94E2740.gleclair@agentz.com>
Message-ID: <H0000d930f932694@MHS>

begin 777 1.txt
M4F5C96EV960Z(&9R;VT@<&%L<F5L,2YH<"YC;VT@*'!A;')E;#$N:'`N8V]M
M(%LQ-2XX,2XQ-C@N,3!=*2!B>2!V96YU<RYR;W-E+FAP+F-O;2!W:71H($53
M3510("@X+C<N,2\X+C<N,R!425,@-2XP($]P96YM86EL*2!I9"!*04$P,#DU
M."!F;W(@/&%L86Y?8F5R:V5M84!H<"UR;W-E=FEL;&4M;VTR+F]M+FAP+F-O
M;3X[(%1H=2P@,B!*=6P@,3DY."`P.3HU-#HT-"`M,#<P,"`H4$14*0I296-E
M:79E9#H@9G)O;2!L:7-T<RYU;F1E<G-C;W)E+F-O;2`H=7-C;W)E+3$N;78N
M8V]M(%LQ.3DN,3(U+C@U+C,P72D*"6)Y('!A;')E;#$N:'`N8V]M("@X+C@N
M-B\X+C@N-71I<RD@=VET:"!%4TU44"!I9"!*04$R,C4Q.3L*"51H=2P@,B!*
M=6P@,3DY."`P.3HU-#HS."`M,#<P,"`H4$14*0I296-E:79E9#H@9G)O;2!L
M;V-A;&AO<W0@*&1A96UO;D!L;V-A;&AO<W0I(&)Y(&QI<W1S+G5N9&5R<V-O
M<F4N8V]M("@X+C<N-2\X+C<N,RD@=VET:"!33510(&ED($U!03(W.3,Q.R!4
M:'4L(#(@2G5L(#$Y.3@@,3(Z-30Z,S$@+3`T,#`@*$5$5"D*4F5C96EV960Z
M(&)Y('!W9RYO<F<@*&)U;&M?;6%I;&5R('8Q+C4I.R!4:'4L(#(@2G5L(#$Y
M.3@@,3(Z-3,Z,C@@+3`T,#`*4F5C96EV960Z("AF<F]M(&1A96UO;D!L;V-A
M;&AO<W0I(&)Y(&QI<W1S+G5N9&5R<V-O<F4N8V]M("@X+C<N-2\X+C<N,RD@
M:60@34%!,C<W.#0@9F]R('`Q,SDT+6]U=&=O:6YG.R!4:'4L(#(@2G5L(#$Y
M.3@@,3(Z-3,Z,#0@+3`T,#`@*$5$5"D*365S<V%G92U)1#H@/#`Q0D1!-3E%
M+D,Y-$4R-S0P+F=L96-L86ER0&%G96YT>BYC;VT^"D9R;VTZ($=R96=O<GD@
M3&5#;&%I<B`\9VQE8VQA:7)`86=E;G1Z+F-O;3X*4F5P;'DM5&\Z(")G;&5C
M;&%I<D!A9V5N='HN8V]M(B`\9VQE8VQA:7)`86=E;G1Z+F-O;3X*5&\Z("(G
M,3,Y-"!05T<G(B`\<#$S.31`<'=G+F]R9SX*4W5B:F5C=#H@4#$S.30^($%G
M96YD82!F;W(@36]N=&5R97D*1&%T93H@5&AU+"`R($IU;"`Q.3DX(#`Y.C4P
M.C`R("TP-S`P"D]R9V%N:7IA=&EO;CH@2F%Y1V5E($-O;6UU;FEC871I;VYS
M"E@M36%I;&5R.B!-:6-R;W-O9G0@26YT97)N970@12UM86EL+TU!4$D@+2`X
M+C`N,"XT,C$Q"D5N8V]D:6YG.B`Q-R!415A4"E-E;F1E<CH@<#$S.30M;W=N
+97)`<'=G+F]R9PIN
`
end

     See 4.1 - 4.5
     
     Alan


______________________________ Reply Separator _________________________________
Subject: P1394> Agenda for Monterey
Author:  Non-HP-gleclair (gleclair@agentz.com) at HP-Roseville,uugw3
Date:    7/2/98 9:50 AM


     
Following is current idea for an agenda in Monterey. 
     
        1. OUI issue - How to publish the profile
     
        2. Transport Command Set proposal review
     
        3. Configuration ROM proposal review
     
        4. Profile review - turn those pages......
        
          4.1) Rev 0.40 is changed to approach what we decided at the May PWG. 
          4.2) We need to discuss error recovery.
          4.3) Need a statement which defines the behavior if a target has 
          communication and it is configured for unidirectional (in the opposite 
          direction) or the appropriate ORB is not found in bi-directional?
          4.4) Need to discuss the issues list. Some have been resolved. Should 
          we remove them from the doc or state the resolution for a running 
          history?
          4.5) Definition of function is one of the latest I saw go by and needs 
          discussion.

Other suggestions / comments welcome.

Have a great 4th everyone! See you in Monterey.

Regards,
Greg LeClair

From atsnaka at bsd.canon.co.jp  Fri Jul  3 06:33:07 1998
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Config ROM doc posted - Web Site update
In-Reply-To: <01BDA59D.B53A7E80.gleclair@agentz.com>
Message-ID: <199807031018.TAA06408@bsdmail.bsd.canon.co.jp>


Hi,

Few comments on the config ROM document.

1) 7.2.5 Instance Directory
     - The key type/key value concatination for function_class is planned to be 19h, not 18h

2) 9.2 OUI
    - The function_class values are (planned to be ) defined by IEEE p1212r (section 7.2.5), so
       function_class value is not a OUI value.

Below is just an opinion.

3) 7.1.5 Unit directory
      - It says,"Compliant devices shall implement at least one unit directory in the format...."
         An informative sentence on what one unit direcotry stands for would help readers.
        Something like, "One unit directory will represent one target compliant with this profile." 

Thanks.

Ats


At 09:42 98/07/02 -0700, Gregory LeClair wrote:
> Hi all.
> 
> The web site was just updated with the config ROM proposal.
> 
> If it's acceptable, then Alan can merge it into the spec after Monterey.
> 
> Cheers,
> 
> Greg LeClair
> 
> 
> 
> 

-----------------------------------------
Atsushi Nakamura
-----------------------------------------

BJ Technology Development 22,
Canon Inc.

53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211

tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------

From gleclair at agentz.com  Mon Jul  6 02:57:05 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Config ROM doc posted - Web Site update
Message-ID: <01BDA8A7.B6F116A0@gleclair.vip.best.com>


>Ats Nakamura wrote:

>1) 7.2.5 Instance Directory
>    - The key type/key value concatination for function_class is planned to be 19h, not 18h

I'll fix this one.

>2) 9.2 OUI
>    - The function_class values are (planned to be ) defined by IEEE p1212r (section 7.2.5), so
>       function_class value is not a OUI value.

I think this issue gets back to whether there is a function class listing in 1212r. TBD


>Below is just an opinion.
>
>3) 7.1.5 Unit directory
>      - It says,"Compliant devices shall implement at least one unit directory in the format...."
>         An informative sentence on what one unit direcotry stands for would help readers.
>        Something like, "One unit directory will represent one target compliant with this profile." 

Agreed. I think we need to add something a little more concrete on the ConfigROM structure.


Cheers,
Greg L.


From jfuller at MICROSOFT.com  Mon Jul 13 13:28:55 1998
From: jfuller at MICROSOFT.com (John Nels Fuller)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Ways to do parameter setup
Message-ID: <FD8F41F04D35D111899600805F19A16C0B3D9A80@red-msg-48.dns.microsoft.com>

Hi everyone,

I talked to George C. about the three possible ways we were considering for
setting connection parameters:

1.	Using command-set dependant management commands.  There is no way
for the class driver to cause the SBP-2 driver to send these, so I guess
they are out.

2.	Using additional registers in the command agent register block.
There is no way for the class driver to discover these addresses or to
deliver requests directly to the 1394 bus driver, so again no luck.

3.	Using commands in the normal command stream.  This will work (as we
knew in Monterey), so we'll have to figure out a way to ensure that the in
and out queues are both idle when they are issued (but we really needed to
do that for 1 & 2 as well).

_____________________
John Nels Fuller
Software Design Engineer, Windows NT
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (425) 703-3863
Fax: (425) 93 MSFAX


From gregs at sdd.hp.com  Mon Jul 13 19:41:13 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Ways to do parameter setup
In-Reply-To: <FD8F41F04D35D111899600805F19A16C0B3D9A80@red-msg-48.dns.microsoft.com> from "John Nels Fuller" at Jul 13, 98 10:28:55 am
Message-ID: <199807132341.QAA18133@hpsdlgj1.sdd.hp.com>

> 
> Hi everyone,
> 
> I talked to George C. about the three possible ways we were considering for
> setting connection parameters:
> 
> 1.	Using command-set dependant management commands.  There is no way
> for the class driver to cause the SBP-2 driver to send these, so I guess
> they are out.

Too bad.

> 2.	Using additional registers in the command agent register block.
> There is no way for the class driver to discover these addresses or to
> deliver requests directly to the 1394 bus driver, so again no luck.

Oh well.

> 3.	Using commands in the normal command stream.  This will work (as we
> knew in Monterey), so we'll have to figure out a way to ensure that the in
> and out queues are both idle when they are issued (but we really needed to
> do that for 1 & 2 as well).

Any progress on getting the Device Type to be dependent on Command_Set?


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From ewa at apple.com  Mon Jul 13 21:40:03 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Ways to do parameter setup
Message-ID: <B1D00555-1E00B@17.219.108.14>

Since I have not been participating, I want to be careful not to
criticize.  But I agree with Greg - it seems like good SBP-2
services should not get in the way of natural communication with
a device.  It sounds like Windows' services make some assumptions
or simplifications that may be too limiting.

In Mac OS, the SBP-2 services are merged with the basic 1394
services.  SBP-2 is not a separate layer that hides 1394; instead
SBP-2 services are available alongside basic 1394 services.  So a
driver can use efficient SBP-2 transfers, while still directly
accessing a device through 1394 (if it wants to).  Maybe this is
also true in Windows, but from the restrictions John mentioned,
it sounds like there may be room for improvement.

It would be a shame to define awkward or inefficient peripheral
protocols just because of software limitataions in an OS.  Software
can always be fixed, while poor protocols seem to have long lives.

--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.      408-974-8187
--------------------------------------

>> Hi everyone,
>> 
>> I talked to George C. about the three possible ways we were considering
for
>> setting connection parameters:
>> 
>> 1.	Using command-set dependant management commands.  There is no way
>> for the class driver to cause the SBP-2 driver to send these, so I guess
>> they are out.
>
>Too bad.
>
>> 2.	Using additional registers in the command agent register block.
>> There is no way for the class driver to discover these addresses or to
>> deliver requests directly to the 1394 bus driver, so again no luck.
>
>Oh well.
>
>> 3.	Using commands in the normal command stream.  This will work (as we
>> knew in Monterey), so we'll have to figure out a way to ensure that the
in
>> and out queues are both idle when they are issued (but we really needed
to
>> do that for 1 & 2 as well).
>
>Any progress on getting the Device Type to be dependent on Command_Set?
>
>
>-- 
>Greg Shue
>Hewlett-Packard Company
>All-in-One Division			        gregs@sdd.hp.com
>----------------------------------------------------------------





From georgioc at microsoft.com  Mon Jul 13 21:56:59 1998
From: georgioc at microsoft.com (George Chrysanthakopoulos)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Ways to do parameter setup
Message-ID: <5BF896CAFE8DD111812400805F1991F705440FEA@red-msg-08.dns.microsoft.com>

?
now i dont know how secure MacOS is but we really dont like to give access
to raw devices up to ANY service/user up in user mode or even higer layer
drivers.  I

in any case, as john said, having control commands in the command stream is
a perfectly good way to do it. Defining bunch of more registers and bloating
the core transport sounds like a bad design, not the other way around.

we do allow passthrough to a device and the lower sbp2 driver can whack the
device directly using our 1394 api. However we dont expose that device
specific functionality up to our class driver. They dont need to know hacky
methods of configuring the device.

We layer:
command set class driver
Transports
Bus specific drivers
hw specific drivers


thanx
g

> -----Original Message-----
> From:	Eric Anderson [SMTP:ewa@apple.com]
> Sent:	Monday, July 13, 1998 6:40 PM
> To:	p1394@pwg.org
> Cc:	George Chrysanthakopoulos; John Nels Fuller; Greg Shue
> Subject:	Re: P1394> Ways to do parameter setup
> 
> Since I have not been participating, I want to be careful not to
> criticize.  But I agree with Greg - it seems like good SBP-2
> services should not get in the way of natural communication with
> a device.  It sounds like Windows' services make some assumptions
> or simplifications that may be too limiting.
> 
> In Mac OS, the SBP-2 services are merged with the basic 1394
> services.  SBP-2 is not a separate layer that hides 1394; instead
> SBP-2 services are available alongside basic 1394 services.  So a
> driver can use efficient SBP-2 transfers, while still directly
> accessing a device through 1394 (if it wants to).  Maybe this is
> also true in Windows, but from the restrictions John mentioned,
> it sounds like there may be room for improvement.
> 
> It would be a shame to define awkward or inefficient peripheral
> protocols just because of software limitataions in an OS.  Software
> can always be fixed, while poor protocols seem to have long lives.
> 
> --------------------------------------
> Eric Anderson            ewa@apple.com
> Apple Computer, Inc.      408-974-8187
> --------------------------------------
> 
> >> Hi everyone,
> >> 
> >> I talked to George C. about the three possible ways we were considering
> for
> >> setting connection parameters:
> >> 
> >> 1.	Using command-set dependant management commands.  There is no way
> >> for the class driver to cause the SBP-2 driver to send these, so I
> guess
> >> they are out.
> >
> >Too bad.
> >
> >> 2.	Using additional registers in the command agent register block.
> >> There is no way for the class driver to discover these addresses or to
> >> deliver requests directly to the 1394 bus driver, so again no luck.
> >
> >Oh well.
> >
> >> 3.	Using commands in the normal command stream.  This will work (as we
> >> knew in Monterey), so we'll have to figure out a way to ensure that the
> in
> >> and out queues are both idle when they are issued (but we really needed
> to
> >> do that for 1 & 2 as well).
> >
> >Any progress on getting the Device Type to be dependent on Command_Set?
> >
> >
> >-- 
> >Greg Shue
> >Hewlett-Packard Company
> >All-in-One Division			        gregs@sdd.hp.com
> >----------------------------------------------------------------
> 
> 
> 

From georgioc at microsoft.com  Mon Jul 13 21:59:42 1998
From: georgioc at microsoft.com (George Chrysanthakopoulos)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Ways to do parameter setup
Message-ID: <5BF896CAFE8DD111812400805F1991F705440FEB@red-msg-08.dns.microsoft.com>

once again, pritning should come to terms with the fact that if use the core
sbp2 protocol correctly(even if it means being alittle bit creative without
resorting in bloating with abuncg of regs) it provides enough for you to
work with and create great 1394 implementations.

Device type is command set specifc.  we need to see hw. 

thanx
g

> -----Original Message-----
> From:	Greg Shue [SMTP:gregs@sdd.hp.com]
> Sent:	Monday, July 13, 1998 4:41 PM
> To:	John Nels Fuller
> Cc:	p1394@pwg.org; George Chrysanthakopoulos
> Subject:	Re: P1394> Ways to do parameter setup
> 
> > 
> > Hi everyone,
> > 
> > I talked to George C. about the three possible ways we were considering
> for
> > setting connection parameters:
> > 
> > 1.	Using command-set dependant management commands.  There is no way
> > for the class driver to cause the SBP-2 driver to send these, so I guess
> > they are out.
> 
> Too bad.
> 
> > 2.	Using additional registers in the command agent register block.
> > There is no way for the class driver to discover these addresses or to
> > deliver requests directly to the 1394 bus driver, so again no luck.
> 
> Oh well.
> 
> > 3.	Using commands in the normal command stream.  This will work (as we
> > knew in Monterey), so we'll have to figure out a way to ensure that the
> in
> > and out queues are both idle when they are issued (but we really needed
> to
> > do that for 1 & 2 as well).
> 
> Any progress on getting the Device Type to be dependent on Command_Set?
> 
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------

From gregs at sdd.hp.com  Tue Jul 14 11:30:19 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Ways to do parameter setup
In-Reply-To: <5BF896CAFE8DD111812400805F1991F705440FEB@red-msg-08.dns.microsoft.com> from "George Chrysanthakopoulos" at Jul 13, 98 06:59:42 pm
Message-ID: <199807141530.IAA20246@hpsdlgj1.sdd.hp.com>


So the PWG command set device_type == PRINTER doesn't have to match
the value used by SCSI, right?

Thanks!  That was always annoying.

I didn't think you would need hardware to verify that change.
It seems easy enough to mock up an SBP-2 unit directory on
another PC node.

- GregS

> once again, pritning should come to terms with the fact that if use the core
> sbp2 protocol correctly(even if it means being alittle bit creative without
> resorting in bloating with abuncg of regs) it provides enough for you to
> work with and create great 1394 implementations.
> 
> Device type is command set specifc.  we need to see hw. 
> 
> thanx
> g


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From georgioc at microsoft.com  Tue Jul 14 13:42:43 1998
From: georgioc at microsoft.com (George Chrysanthakopoulos)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Ways to do parameter setup
Message-ID: <5BF896CAFE8DD111812400805F1991F705440FF6@red-msg-08.dns.microsoft.com>

we need hw to start making 1394 printing real instead of just talking about
it.
I also need a spec that sets the new device types according to a a NEW
command set which i have yet to see.
thanx
g

-----Original Message-----
From: Greg Shue [mailto:gregs@sdd.hp.com]
Sent: Tuesday, July 14, 1998 8:30 AM
To: George Chrysanthakopoulos
Cc: p1394@pwg.org
Subject: Re: P1394> Ways to do parameter setup



So the PWG command set device_type == PRINTER doesn't have to match
the value used by SCSI, right?

Thanks!  That was always annoying.

I didn't think you would need hardware to verify that change.
It seems easy enough to mock up an SBP-2 unit directory on
another PC node.

- GregS

> once again, pritning should come to terms with the fact that if use the
core
> sbp2 protocol correctly(even if it means being alittle bit creative
without
> resorting in bloating with abuncg of regs) it provides enough for you to
> work with and create great 1394 implementations.
> 
> Device type is command set specifc.  we need to see hw. 
> 
> thanx
> g


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From gregs at sdd.hp.com  Mon Jul 20 13:05:11 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Revised PWG1394 Cmd Set
Message-ID: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>


Grettings all,

As I have thought about many of the issues and simplifications
discussed at the July PWG 1394 meeting, I have tried to create
an overview of the resulting command set.  Before I start modifying
the Command Set proposal, I would like to hear any concerns you have
with the revisions.  The overview follows.  Please respond with 
any feedback before Friday 7/24/98.  I will try to have the
revised Command Set proposal ready by 8/5/98.  (I cannot have
it ready a full 2 weeks before the August meeting.)  Thank you
for your feedback.


PWG SBP-2-based Transport Command Set
7/20/98

With:
  - the restrictions imposed by the Microsoft SBP-2 implementation
  - the desire from Randy Turner (Sharp) for Open & Close commands
  - the removal of Vendor-specific extension mechanisms
  - the relabeling of commands with more descriptive names

the command set transforms into:

  TRANSPORT_STATUS   {GET_PARAMETER w/ all params tags}

                     Only valid on T2I data queue, only valid
                     when in an Unopened Connection state.

  TRANSPORT_OPEN     {SET PARAMETER LIST w/ all settable parameters}

                     Contains all "Negotiated" parameter values.
                     Only valid on I2T data queue, only valid
                     when in an Unopened Connection state.

  TRANSPORT_CLOSE    {SET PARAMETER LSIT w/ only Mode parameter}

                     Closed direction inferred from queue_id bit.
                     Valid on both queues. Invalid only in the
                     UnOpened Connection state.

  TRANSPORT_I2T_DATA {FETCH_DATA}

                     Valid only on I2T data queue.  Valid only
                     in the Opened Connection state.  Valid only
                     while the queue is open.

  TRANSPORT_T2I_DATA {STORE_DATA}

                     Valid only on T2I data queue.  Valid only
                     in the Opened Connection state.  Valid only
                     while the queue is open.

the Command Set Model of Use becomes:

   Login event ---->    UnOpened Conn  [ TRANSPORT_STATUS is OK
			|                TRANSPORT_OPEN is OK
			|                All other cmds is ERROR ]
 _______________________|
 |
 +-- TRANSPORT_OPEN ->  Opened Conn    [ TRANSPORT_STATUS is ERROR
                        |   ^ ^          TRANSPORT_CLOSE is OK
                        |   | |          TRANSPORT_I2T_DATA is OK if
                        |   | |            I2T direction is Open
                        |   | |          TRANSPORT_T2I_DATA is OK if
                        |   | |            T2I direction is Open
			|   | |          TRANSPORT_OPEN is ERROR
 _______________________|   | |
 |||                        | |
 ||+- TRANSPORT_CLOSE (I2T) + |
 ||    && T2I still open      |
 ||                           |
 |+-- TRANSPORT_CLOSE (T2I) --+
 |     && I2T still open
 |
 +- TRANSPORT_CLOSE -> Closed Conn     [ TRANSPORT_STATUS is ERROR
     | I2T & T2I closed                  TRANSPORT_CLOSE is OK
     |                                   TRANSPORT_I2T_DATA is ERROR
     |                                   TRANSPORT_T2I_DATA is ERROR
     +---> Logout                        TRANSPORT_OPEN is ERROR

The variables associated with TRANSPORT_STATUS become:

  A)  MAX_TASK_SET_SIZE  (16 bits unsigned int,
                                  2 is minimum;
                                  2^14-1 is maximum)
  B)  MAX_I2T_DATA_SIZE  (31 bits unsigned int)
  C)  MAX_T2I_DATA_SIZE  (31 bits unsigned int)
  D)  STREAM_COMPLETION  ( 8 bits unsigned int)
  E)  CONNECTION_STATE   ( 2 bits unsigned int
                                  0 => I2T CLOSED, T2I CLOSED;
                                  1 => I2T OPEN,   T2I CLOSED;
                                  2 => I2T CLOSED, T2I OPEN;
                                  3 => I2T OPEN,   T2I OPEN;)

The target needs to communicate the following specific events
to the initiator even in the case that no commands are queued.

  - UNIT ATTENTION: logical unit was reset outside of this Login

  - Target has closed a communication direction and will reject
     further TRANSPORT_?2?_DATA commands for that direction.
     When all directions are closed, then target is should
     Logout ASAP.  (The target shall only successfully execute
     TRANSPORT_STATUS commands.)

  Since an initiator can not leave a TRANSPORT_T2I_DATA command
  enqueued when the T2I direction is closed, this data must be
  communicated via the Unsolicited Status mechanism.  Also, since
  an Initiator may not even exist on the bus (due to a transient
  link interruption) when either of these events happens, they
  must be buffered.


Now, error recovery for when a target detects an ACK Timeout on a
Status FIFO write requires some special considerations.  When
this condition happens the initiator and target may be
out-of-sync with each other, and the SBP-2 protocol does not
provide a mechanism for the initiator to determine that the
condition exists.  The problem breaks down to two issues:

  Initiator Detection:
    Because this condition is expected to happen _extremely_
    infrequently, it is expected that a Bus Reset mechanism
    is a reasonable way of forcing the initiator to resynchronize
    with the target.

  Recovery:
    To recover from this condition, the target needs to infer
    whether or not the initiator received the completion notification(s).

      If the initiator did, the target may release the resources
      or take the appropriate action assocaited with the command(s).

      If the initiator did not, the target must determine whether
      or not the same command (sequence, and associated data) is
      restored to the execution queue.

	If the same sequence is not restored to the front of the
        queue, then the target should ignore all previous commands
        and re-execute them.

	If the same sequence is restored, then the target need
	not reprocess the entire command and data block.  It
	simply needs to know where it left off within the
	transfers.

    This makes it reasonable to employ a command tag, used to
    uniquely identify each previously active command within the
    implicilty aborted task set, and new commands which were not
    in the previously active task set.

    Unfortunately, SBP-2 requires targets to support the ABORT TASK
    function, and the process described for aborting tasks causes
    previously valid commands to be turned into Dummy ORBs.  This
    effectively removes the command tag from the ORB, so the
    queue's Execution Agent no longer sees command tags as
    sequential even if they were assigned sequentially.

      It may be reasonable for a target to enforce seeing
      sequential command tags in order to recover from this
      situation.  If the queue's Execution Agent completed
      all commands in that queue with a status of "ABORTED -
      UNEXPECTED COMMAND TAG VALUE", then the initiator has
      a chance to recover from the situation.  This also means
      that an ABORT TASK function causes all successive commands
      on the associated queue to be aborted without affecting
      the other queue.
      
    This brings us to the following policies:

      A)  A target shall enforce sequential command tag values.
      B)  Initial command tag values shall be established by the
            first command placed on each queue.
      C)  ABORT TASK shall indirectly cause the rest of the
            command queue to be aborted without affecting
            the other command queue.
      D)  Initiators shall retire a command tag until
            it receives a successful completion notification
            for a following command on the associated queue.
            Once that following successful notification has
            been received, the command tag may be reused.
      E)  Targets shall invalidate a command tag when
            the completion notification for the associated
            ORB has been succesfully acknowledged.

    These policies allow the target to use the algorithm below
    to recover synchronization:

      If the target is not in a missing status FIFO ACK error
      recovery situation, it shall examine the command at the
      head of the queue and:

        process it if it is either the first command enqueued
        on this queue since Login, or has a command tag immediately
        following the one of the last successfully completed command.

        otherwise, abort it.

      If the target is in a missing status FIFO ACK error
      recovery situation, it shall examine the command at the
      head of the queue and:

	If the command tag matches the one of the unacknowledged
	command, it shall make sure the command is processed and
	resend the completion notification.

	Else if the command tag follows the one of the
	unacknowledged command, it shall ASSUME the completion
	notification was successfully received by the initiator
	and that the ACK transmission was lost.  The pending
	command shall be implicilty acknowledged by the new
	command, and completed by the target.

        Else the target shall abort it.
-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From fumiona at venus.dtinet.or.jp  Thu Jul 23 09:09:46 1998
From: fumiona at venus.dtinet.or.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Revised PWG1394 Cmd Set
In-Reply-To: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
References: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
Message-ID: <98072322090601.AKG5A71@smtp.venus.dti.ne.jp>

Dear Greg,

1. Is a "command tag" same as a "transaction number" ?

2. Do you really believe a target device can fail to 
   receive an ack-packet?

3. I would like to suggest three commands listed below;
	TRANSPORT_I2T_ABORT
	TRANSPORT_T2I_ABORT
	TRANSPORT_ORB_RELEASE

3.1. TRANSPORT_I2T_ABORT
	An initiator requests a target to stop ORB fetching, 
	and solicits the target to reply STATUS block when
	the last ORB had been executed.

3.2. TRANSPORT_T2I_ABORT
	A target requests an initiator to stop appending new
	ORBs on outstanding linked list. The initiator may
	invoke "close" command when it received STATUS bock
	associated with the last ORB.

3.3. TRANSPORT_ORB_RELEASE
	A target request an initiator to release specified ORB
	without completion STATUS block.

Fumio Nagasaka
>
>Grettings all,
>
>As I have thought about many of the issues and simplifications
>discussed at the July PWG 1394 meeting, I have tried to create
>an overview of the resulting command set.  Before I start modifying
>the Command Set proposal, I would like to hear any concerns you have
>with the revisions.  The overview follows.  Please respond with 
>any feedback before Friday 7/24/98.  I will try to have the
>revised Command Set proposal ready by 8/5/98.  (I cannot have
>it ready a full 2 weeks before the August meeting.)  Thank you
>for your feedback.
>
>
>PWG SBP-2-based Transport Command Set
>7/20/98
>
>With:
>  - the restrictions imposed by the Microsoft SBP-2 implementation
>  - the desire from Randy Turner (Sharp) for Open & Close commands
>  - the removal of Vendor-specific extension mechanisms
>  - the relabeling of commands with more descriptive names
>
>the command set transforms into:
>
>  TRANSPORT_STATUS   {GET_PARAMETER w/ all params tags}
>
>                     Only valid on T2I data queue, only valid
>                     when in an Unopened Connection state.
>
>  TRANSPORT_OPEN     {SET PARAMETER LIST w/ all settable parameters}
>
>                     Contains all "Negotiated" parameter values.
>                     Only valid on I2T data queue, only valid
>                     when in an Unopened Connection state.
>
>  TRANSPORT_CLOSE    {SET PARAMETER LSIT w/ only Mode parameter}
>
>                     Closed direction inferred from queue_id bit.
>                     Valid on both queues. Invalid only in the
>                     UnOpened Connection state.
>
>  TRANSPORT_I2T_DATA {FETCH_DATA}
>
>                     Valid only on I2T data queue.  Valid only
>                     in the Opened Connection state.  Valid only
>                     while the queue is open.
>
>  TRANSPORT_T2I_DATA {STORE_DATA}
>
>                     Valid only on T2I data queue.  Valid only
>                     in the Opened Connection state.  Valid only
>                     while the queue is open.
>
>the Command Set Model of Use becomes:
>
>   Login event ---->    UnOpened Conn  [ TRANSPORT_STATUS is OK
>			|                TRANSPORT_OPEN is OK
>			|                All other cmds is ERROR ]
> _______________________|
> |
> +-- TRANSPORT_OPEN ->  Opened Conn    [ TRANSPORT_STATUS is ERROR
>                        |   ^ ^          TRANSPORT_CLOSE is OK
>                        |   | |          TRANSPORT_I2T_DATA is OK if
>                        |   | |            I2T direction is Open
>                        |   | |          TRANSPORT_T2I_DATA is OK if
>                        |   | |            T2I direction is Open
>			|   | |          TRANSPORT_OPEN is ERROR
> _______________________|   | |
> |||                        | |
> ||+- TRANSPORT_CLOSE (I2T) + |
> ||    && T2I still open      |
> ||                           |
> |+-- TRANSPORT_CLOSE (T2I) --+
> |     && I2T still open
> |
> +- TRANSPORT_CLOSE -> Closed Conn     [ TRANSPORT_STATUS is ERROR
>     | I2T & T2I closed                  TRANSPORT_CLOSE is OK
>     |                                   TRANSPORT_I2T_DATA is ERROR
>     |                                   TRANSPORT_T2I_DATA is ERROR
>     +---> Logout                        TRANSPORT_OPEN is ERROR
>
>The variables associated with TRANSPORT_STATUS become:
>
>  A)  MAX_TASK_SET_SIZE  (16 bits unsigned int,
>                                  2 is minimum;
>                                  2^14-1 is maximum)
>  B)  MAX_I2T_DATA_SIZE  (31 bits unsigned int)
>  C)  MAX_T2I_DATA_SIZE  (31 bits unsigned int)
>  D)  STREAM_COMPLETION  ( 8 bits unsigned int)
>  E)  CONNECTION_STATE   ( 2 bits unsigned int
>                                  0 => I2T CLOSED, T2I CLOSED;
>                                  1 => I2T OPEN,   T2I CLOSED;
>                                  2 => I2T CLOSED, T2I OPEN;
>                                  3 => I2T OPEN,   T2I OPEN;)
>
>The target needs to communicate the following specific events
>to the initiator even in the case that no commands are queued.
>
>  - UNIT ATTENTION: logical unit was reset outside of this Login
>
>  - Target has closed a communication direction and will reject
>     further TRANSPORT_?2?_DATA commands for that direction.
>     When all directions are closed, then target is should
>     Logout ASAP.  (The target shall only successfully execute
>     TRANSPORT_STATUS commands.)
>
>  Since an initiator can not leave a TRANSPORT_T2I_DATA command
>  enqueued when the T2I direction is closed, this data must be
>  communicated via the Unsolicited Status mechanism.  Also, since
>  an Initiator may not even exist on the bus (due to a transient
>  link interruption) when either of these events happens, they
>  must be buffered.
>
>
>Now, error recovery for when a target detects an ACK Timeout on a
>Status FIFO write requires some special considerations.  When
>this condition happens the initiator and target may be
>out-of-sync with each other, and the SBP-2 protocol does not
>provide a mechanism for the initiator to determine that the
>condition exists.  The problem breaks down to two issues:
>
>  Initiator Detection:
>    Because this condition is expected to happen _extremely_
>    infrequently, it is expected that a Bus Reset mechanism
>    is a reasonable way of forcing the initiator to resynchronize
>    with the target.
>
>  Recovery:
>    To recover from this condition, the target needs to infer
>    whether or not the initiator received the completion notification(s).
>
>      If the initiator did, the target may release the resources
>      or take the appropriate action assocaited with the command(s).
>
>      If the initiator did not, the target must determine whether
>      or not the same command (sequence, and associated data) is
>      restored to the execution queue.
>
>	If the same sequence is not restored to the front of the
>        queue, then the target should ignore all previous commands
>        and re-execute them.
>
>	If the same sequence is restored, then the target need
>	not reprocess the entire command and data block.  It
>	simply needs to know where it left off within the
>	transfers.
>
>    This makes it reasonable to employ a command tag, used to
>    uniquely identify each previously active command within the
>    implicilty aborted task set, and new commands which were not
>    in the previously active task set.
>
>    Unfortunately, SBP-2 requires targets to support the ABORT TASK
>    function, and the process described for aborting tasks causes
>    previously valid commands to be turned into Dummy ORBs.  This
>    effectively removes the command tag from the ORB, so the
>    queue's Execution Agent no longer sees command tags as
>    sequential even if they were assigned sequentially.
>
>      It may be reasonable for a target to enforce seeing
>      sequential command tags in order to recover from this
>      situation.  If the queue's Execution Agent completed
>      all commands in that queue with a status of "ABORTED -
>      UNEXPECTED COMMAND TAG VALUE", then the initiator has
>      a chance to recover from the situation.  This also means
>      that an ABORT TASK function causes all successive commands
>      on the associated queue to be aborted without affecting
>      the other queue.
>      
>    This brings us to the following policies:
>
>      A)  A target shall enforce sequential command tag values.
>      B)  Initial command tag values shall be established by the
>            first command placed on each queue.
>      C)  ABORT TASK shall indirectly cause the rest of the
>            command queue to be aborted without affecting
>            the other command queue.
>      D)  Initiators shall retire a command tag until
>            it receives a successful completion notification
>            for a following command on the associated queue.
>            Once that following successful notification has
>            been received, the command tag may be reused.
>      E)  Targets shall invalidate a command tag when
>            the completion notification for the associated
>            ORB has been succesfully acknowledged.
>
>    These policies allow the target to use the algorithm below
>    to recover synchronization:
>
>      If the target is not in a missing status FIFO ACK error
>      recovery situation, it shall examine the command at the
>      head of the queue and:
>
>        process it if it is either the first command enqueued
>        on this queue since Login, or has a command tag immediately
>        following the one of the last successfully completed command.
>
>        otherwise, abort it.
>
>      If the target is in a missing status FIFO ACK error
>      recovery situation, it shall examine the command at the
>      head of the queue and:
>
>	If the command tag matches the one of the unacknowledged
>	command, it shall make sure the command is processed and
>	resend the completion notification.
>
>	Else if the command tag follows the one of the
>	unacknowledged command, it shall ASSUME the completion
>	notification was successfully received by the initiator
>	and that the ACK transmission was lost.  The pending
>	command shall be implicilty acknowledged by the new
>	command, and completed by the target.
>
>        Else the target shall abort it.
>-- 
>Greg Shue
>Hewlett-Packard Company
>All-in-One Division			        gregs@sdd.hp.com
>----------------------------------------------------------------
>

---
Fumio Nagasaka
EPSON Software Deveopment Lab., Inc.
voice: +81 268 25-4111

From shimura at pure.cpdc.canon.co.jp  Fri Jul 24 11:34:11 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:51 2009
Subject: P1394> MAX_?2?_DATA_SIZE(Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
References: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
Message-ID: <199807241534.AAA23522@origin.pure.cpdc.canon.co.jp>


>   B)  MAX_I2T_DATA_SIZE  (31 bits unsigned int)
>   C)  MAX_T2I_DATA_SIZE  (31 bits unsigned int)

It is still not clear for me what is specified for initiator and/or
target by these parameters.

Size of the "buffer" referred by data_descriptor field of an ORB will
be determined along with requesting client of the initiator. Once the
ORB is appended to task list, access right to the "buffer" is granted
to the target, and the "buffer" looks like (remote) receiving/sending
buffer of the target. The target can access any part of the "buffer"
within the address range of the "buffer" in arbitrary size unit the
target wants to handle.

I think the size of the "buffer" referred by the ORB and the size
unit that target processes the "buffer" are independent of each other.

Could you explain why these parameters need to go across the wire?

Akihiro Shimura

On Mon, 20 Jul 1998 10:05:11 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:

> 
> Grettings all,
> 
> As I have thought about many of the issues and simplifications
> discussed at the July PWG 1394 meeting, I have tried to create
> an overview of the resulting command set.  Before I start modifying
> the Command Set proposal, I would like to hear any concerns you have
> with the revisions.  The overview follows.  Please respond with 
> any feedback before Friday 7/24/98.  I will try to have the
> revised Command Set proposal ready by 8/5/98.  (I cannot have
> it ready a full 2 weeks before the August meeting.)  Thank you
> for your feedback.
> 
> 
> PWG SBP-2-based Transport Command Set
> 7/20/98
> 
> With:
>   - the restrictions imposed by the Microsoft SBP-2 implementation
>   - the desire from Randy Turner (Sharp) for Open & Close commands
>   - the removal of Vendor-specific extension mechanisms
>   - the relabeling of commands with more descriptive names
> 
> the command set transforms into:
> 
>   TRANSPORT_STATUS   {GET_PARAMETER w/ all params tags}
> 
>                      Only valid on T2I data queue, only valid
>                      when in an Unopened Connection state.
> 
>   TRANSPORT_OPEN     {SET PARAMETER LIST w/ all settable parameters}
> 
>                      Contains all "Negotiated" parameter values.
>                      Only valid on I2T data queue, only valid
>                      when in an Unopened Connection state.
> 
>   TRANSPORT_CLOSE    {SET PARAMETER LSIT w/ only Mode parameter}
> 
>                      Closed direction inferred from queue_id bit.
>                      Valid on both queues. Invalid only in the
>                      UnOpened Connection state.
> 
>   TRANSPORT_I2T_DATA {FETCH_DATA}
> 
>                      Valid only on I2T data queue.  Valid only
>                      in the Opened Connection state.  Valid only
>                      while the queue is open.
> 
>   TRANSPORT_T2I_DATA {STORE_DATA}
> 
>                      Valid only on T2I data queue.  Valid only
>                      in the Opened Connection state.  Valid only
>                      while the queue is open.
> 
> the Command Set Model of Use becomes:
> 
>    Login event ---->    UnOpened Conn  [ TRANSPORT_STATUS is OK
> 			|                TRANSPORT_OPEN is OK
> 			|                All other cmds is ERROR ]
>  _______________________|
>  |
>  +-- TRANSPORT_OPEN ->  Opened Conn    [ TRANSPORT_STATUS is ERROR
>                         |   ^ ^          TRANSPORT_CLOSE is OK
>                         |   | |          TRANSPORT_I2T_DATA is OK if
>                         |   | |            I2T direction is Open
>                         |   | |          TRANSPORT_T2I_DATA is OK if
>                         |   | |            T2I direction is Open
> 			|   | |          TRANSPORT_OPEN is ERROR
>  _______________________|   | |
>  |||                        | |
>  ||+- TRANSPORT_CLOSE (I2T) + |
>  ||    && T2I still open      |
>  ||                           |
>  |+-- TRANSPORT_CLOSE (T2I) --+
>  |     && I2T still open
>  |
>  +- TRANSPORT_CLOSE -> Closed Conn     [ TRANSPORT_STATUS is ERROR
>      | I2T & T2I closed                  TRANSPORT_CLOSE is OK
>      |                                   TRANSPORT_I2T_DATA is ERROR
>      |                                   TRANSPORT_T2I_DATA is ERROR
>      +---> Logout                        TRANSPORT_OPEN is ERROR
> 
> The variables associated with TRANSPORT_STATUS become:
> 
>   A)  MAX_TASK_SET_SIZE  (16 bits unsigned int,
>                                   2 is minimum;
>                                   2^14-1 is maximum)
>   B)  MAX_I2T_DATA_SIZE  (31 bits unsigned int)
>   C)  MAX_T2I_DATA_SIZE  (31 bits unsigned int)
>   D)  STREAM_COMPLETION  ( 8 bits unsigned int)
>   E)  CONNECTION_STATE   ( 2 bits unsigned int
>                                   0 => I2T CLOSED, T2I CLOSED;
>                                   1 => I2T OPEN,   T2I CLOSED;
>                                   2 => I2T CLOSED, T2I OPEN;
>                                   3 => I2T OPEN,   T2I OPEN;)
> 
> The target needs to communicate the following specific events
> to the initiator even in the case that no commands are queued.
> 
>   - UNIT ATTENTION: logical unit was reset outside of this Login
> 
>   - Target has closed a communication direction and will reject
>      further TRANSPORT_?2?_DATA commands for that direction.
>      When all directions are closed, then target is should
>      Logout ASAP.  (The target shall only successfully execute
>      TRANSPORT_STATUS commands.)
> 
>   Since an initiator can not leave a TRANSPORT_T2I_DATA command
>   enqueued when the T2I direction is closed, this data must be
>   communicated via the Unsolicited Status mechanism.  Also, since
>   an Initiator may not even exist on the bus (due to a transient
>   link interruption) when either of these events happens, they
>   must be buffered.
> 
> 
> Now, error recovery for when a target detects an ACK Timeout on a
> Status FIFO write requires some special considerations.  When
> this condition happens the initiator and target may be
> out-of-sync with each other, and the SBP-2 protocol does not
> provide a mechanism for the initiator to determine that the
> condition exists.  The problem breaks down to two issues:
> 
>   Initiator Detection:
>     Because this condition is expected to happen _extremely_
>     infrequently, it is expected that a Bus Reset mechanism
>     is a reasonable way of forcing the initiator to resynchronize
>     with the target.
> 
>   Recovery:
>     To recover from this condition, the target needs to infer
>     whether or not the initiator received the completion notification(s).
> 
>       If the initiator did, the target may release the resources
>       or take the appropriate action assocaited with the command(s).
> 
>       If the initiator did not, the target must determine whether
>       or not the same command (sequence, and associated data) is
>       restored to the execution queue.
> 
> 	If the same sequence is not restored to the front of the
>         queue, then the target should ignore all previous commands
>         and re-execute them.
> 
> 	If the same sequence is restored, then the target need
> 	not reprocess the entire command and data block.  It
> 	simply needs to know where it left off within the
> 	transfers.
> 
>     This makes it reasonable to employ a command tag, used to
>     uniquely identify each previously active command within the
>     implicilty aborted task set, and new commands which were not
>     in the previously active task set.
> 
>     Unfortunately, SBP-2 requires targets to support the ABORT TASK
>     function, and the process described for aborting tasks causes
>     previously valid commands to be turned into Dummy ORBs.  This
>     effectively removes the command tag from the ORB, so the
>     queue's Execution Agent no longer sees command tags as
>     sequential even if they were assigned sequentially.
> 
>       It may be reasonable for a target to enforce seeing
>       sequential command tags in order to recover from this
>       situation.  If the queue's Execution Agent completed
>       all commands in that queue with a status of "ABORTED -
>       UNEXPECTED COMMAND TAG VALUE", then the initiator has
>       a chance to recover from the situation.  This also means
>       that an ABORT TASK function causes all successive commands
>       on the associated queue to be aborted without affecting
>       the other queue.
>       
>     This brings us to the following policies:
> 
>       A)  A target shall enforce sequential command tag values.
>       B)  Initial command tag values shall be established by the
>             first command placed on each queue.
>       C)  ABORT TASK shall indirectly cause the rest of the
>             command queue to be aborted without affecting
>             the other command queue.
>       D)  Initiators shall retire a command tag until
>             it receives a successful completion notification
>             for a following command on the associated queue.
>             Once that following successful notification has
>             been received, the command tag may be reused.
>       E)  Targets shall invalidate a command tag when
>             the completion notification for the associated
>             ORB has been succesfully acknowledged.
> 
>     These policies allow the target to use the algorithm below
>     to recover synchronization:
> 
>       If the target is not in a missing status FIFO ACK error
>       recovery situation, it shall examine the command at the
>       head of the queue and:
> 
>         process it if it is either the first command enqueued
>         on this queue since Login, or has a command tag immediately
>         following the one of the last successfully completed command.
> 
>         otherwise, abort it.
> 
>       If the target is in a missing status FIFO ACK error
>       recovery situation, it shall examine the command at the
>       head of the queue and:
> 
> 	If the command tag matches the one of the unacknowledged
> 	command, it shall make sure the command is processed and
> 	resend the completion notification.
> 
> 	Else if the command tag follows the one of the
> 	unacknowledged command, it shall ASSUME the completion
> 	notification was successfully received by the initiator
> 	and that the ACK transmission was lost.  The pending
> 	command shall be implicilty acknowledged by the new
> 	command, and completed by the target.
> 
>         Else the target shall abort it.
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------
> 

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

From shimura at pure.cpdc.canon.co.jp  Fri Jul 24 11:51:09 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:51 2009
Subject: P1394> CONNECTION_STATE(Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
References: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
Message-ID: <199807241551.AAA23539@origin.pure.cpdc.canon.co.jp>


>   E)  CONNECTION_STATE   ( 2 bits unsigned int

I do not think it is necessary for the initiator to control connection
of each direction separately at transport level.

I suppose the initiator can do it by not issuing either
TRANSPORT_I2T_DATA or TRANSPORT_T2I_DATA command, while
uni-directional target may want to declare its capability.

Because we are providing bi-directional transport, I think, whether
clients use it as uni-directional or bi-directional is up to the
clients.

Any suggestions?

Akihiro Shimura

On Mon, 20 Jul 1998 10:05:11 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:

> 
> Grettings all,
> 
> As I have thought about many of the issues and simplifications
> discussed at the July PWG 1394 meeting, I have tried to create
> an overview of the resulting command set.  Before I start modifying
> the Command Set proposal, I would like to hear any concerns you have
> with the revisions.  The overview follows.  Please respond with 
> any feedback before Friday 7/24/98.  I will try to have the
> revised Command Set proposal ready by 8/5/98.  (I cannot have
> it ready a full 2 weeks before the August meeting.)  Thank you
> for your feedback.
> 
> 
> PWG SBP-2-based Transport Command Set
> 7/20/98
> 
> With:
>   - the restrictions imposed by the Microsoft SBP-2 implementation
>   - the desire from Randy Turner (Sharp) for Open & Close commands
>   - the removal of Vendor-specific extension mechanisms
>   - the relabeling of commands with more descriptive names
> 
> the command set transforms into:
> 
>   TRANSPORT_STATUS   {GET_PARAMETER w/ all params tags}
> 
>                      Only valid on T2I data queue, only valid
>                      when in an Unopened Connection state.
> 
>   TRANSPORT_OPEN     {SET PARAMETER LIST w/ all settable parameters}
> 
>                      Contains all "Negotiated" parameter values.
>                      Only valid on I2T data queue, only valid
>                      when in an Unopened Connection state.
> 
>   TRANSPORT_CLOSE    {SET PARAMETER LSIT w/ only Mode parameter}
> 
>                      Closed direction inferred from queue_id bit.
>                      Valid on both queues. Invalid only in the
>                      UnOpened Connection state.
> 
>   TRANSPORT_I2T_DATA {FETCH_DATA}
> 
>                      Valid only on I2T data queue.  Valid only
>                      in the Opened Connection state.  Valid only
>                      while the queue is open.
> 
>   TRANSPORT_T2I_DATA {STORE_DATA}
> 
>                      Valid only on T2I data queue.  Valid only
>                      in the Opened Connection state.  Valid only
>                      while the queue is open.
> 
> the Command Set Model of Use becomes:
> 
>    Login event ---->    UnOpened Conn  [ TRANSPORT_STATUS is OK
> 			|                TRANSPORT_OPEN is OK
> 			|                All other cmds is ERROR ]
>  _______________________|
>  |
>  +-- TRANSPORT_OPEN ->  Opened Conn    [ TRANSPORT_STATUS is ERROR
>                         |   ^ ^          TRANSPORT_CLOSE is OK
>                         |   | |          TRANSPORT_I2T_DATA is OK if
>                         |   | |            I2T direction is Open
>                         |   | |          TRANSPORT_T2I_DATA is OK if
>                         |   | |            T2I direction is Open
> 			|   | |          TRANSPORT_OPEN is ERROR
>  _______________________|   | |
>  |||                        | |
>  ||+- TRANSPORT_CLOSE (I2T) + |
>  ||    && T2I still open      |
>  ||                           |
>  |+-- TRANSPORT_CLOSE (T2I) --+
>  |     && I2T still open
>  |
>  +- TRANSPORT_CLOSE -> Closed Conn     [ TRANSPORT_STATUS is ERROR
>      | I2T & T2I closed                  TRANSPORT_CLOSE is OK
>      |                                   TRANSPORT_I2T_DATA is ERROR
>      |                                   TRANSPORT_T2I_DATA is ERROR
>      +---> Logout                        TRANSPORT_OPEN is ERROR
> 
> The variables associated with TRANSPORT_STATUS become:
> 
>   A)  MAX_TASK_SET_SIZE  (16 bits unsigned int,
>                                   2 is minimum;
>                                   2^14-1 is maximum)
>   B)  MAX_I2T_DATA_SIZE  (31 bits unsigned int)
>   C)  MAX_T2I_DATA_SIZE  (31 bits unsigned int)
>   D)  STREAM_COMPLETION  ( 8 bits unsigned int)
>   E)  CONNECTION_STATE   ( 2 bits unsigned int
>                                   0 => I2T CLOSED, T2I CLOSED;
>                                   1 => I2T OPEN,   T2I CLOSED;
>                                   2 => I2T CLOSED, T2I OPEN;
>                                   3 => I2T OPEN,   T2I OPEN;)
> 
> The target needs to communicate the following specific events
> to the initiator even in the case that no commands are queued.
> 
>   - UNIT ATTENTION: logical unit was reset outside of this Login
> 
>   - Target has closed a communication direction and will reject
>      further TRANSPORT_?2?_DATA commands for that direction.
>      When all directions are closed, then target is should
>      Logout ASAP.  (The target shall only successfully execute
>      TRANSPORT_STATUS commands.)
> 
>   Since an initiator can not leave a TRANSPORT_T2I_DATA command
>   enqueued when the T2I direction is closed, this data must be
>   communicated via the Unsolicited Status mechanism.  Also, since
>   an Initiator may not even exist on the bus (due to a transient
>   link interruption) when either of these events happens, they
>   must be buffered.
> 
> 
> Now, error recovery for when a target detects an ACK Timeout on a
> Status FIFO write requires some special considerations.  When
> this condition happens the initiator and target may be
> out-of-sync with each other, and the SBP-2 protocol does not
> provide a mechanism for the initiator to determine that the
> condition exists.  The problem breaks down to two issues:
> 
>   Initiator Detection:
>     Because this condition is expected to happen _extremely_
>     infrequently, it is expected that a Bus Reset mechanism
>     is a reasonable way of forcing the initiator to resynchronize
>     with the target.
> 
>   Recovery:
>     To recover from this condition, the target needs to infer
>     whether or not the initiator received the completion notification(s).
> 
>       If the initiator did, the target may release the resources
>       or take the appropriate action assocaited with the command(s).
> 
>       If the initiator did not, the target must determine whether
>       or not the same command (sequence, and associated data) is
>       restored to the execution queue.
> 
> 	If the same sequence is not restored to the front of the
>         queue, then the target should ignore all previous commands
>         and re-execute them.
> 
> 	If the same sequence is restored, then the target need
> 	not reprocess the entire command and data block.  It
> 	simply needs to know where it left off within the
> 	transfers.
> 
>     This makes it reasonable to employ a command tag, used to
>     uniquely identify each previously active command within the
>     implicilty aborted task set, and new commands which were not
>     in the previously active task set.
> 
>     Unfortunately, SBP-2 requires targets to support the ABORT TASK
>     function, and the process described for aborting tasks causes
>     previously valid commands to be turned into Dummy ORBs.  This
>     effectively removes the command tag from the ORB, so the
>     queue's Execution Agent no longer sees command tags as
>     sequential even if they were assigned sequentially.
> 
>       It may be reasonable for a target to enforce seeing
>       sequential command tags in order to recover from this
>       situation.  If the queue's Execution Agent completed
>       all commands in that queue with a status of "ABORTED -
>       UNEXPECTED COMMAND TAG VALUE", then the initiator has
>       a chance to recover from the situation.  This also means
>       that an ABORT TASK function causes all successive commands
>       on the associated queue to be aborted without affecting
>       the other queue.
>       
>     This brings us to the following policies:
> 
>       A)  A target shall enforce sequential command tag values.
>       B)  Initial command tag values shall be established by the
>             first command placed on each queue.
>       C)  ABORT TASK shall indirectly cause the rest of the
>             command queue to be aborted without affecting
>             the other command queue.
>       D)  Initiators shall retire a command tag until
>             it receives a successful completion notification
>             for a following command on the associated queue.
>             Once that following successful notification has
>             been received, the command tag may be reused.
>       E)  Targets shall invalidate a command tag when
>             the completion notification for the associated
>             ORB has been succesfully acknowledged.
> 
>     These policies allow the target to use the algorithm below
>     to recover synchronization:
> 
>       If the target is not in a missing status FIFO ACK error
>       recovery situation, it shall examine the command at the
>       head of the queue and:
> 
>         process it if it is either the first command enqueued
>         on this queue since Login, or has a command tag immediately
>         following the one of the last successfully completed command.
> 
>         otherwise, abort it.
> 
>       If the target is in a missing status FIFO ACK error
>       recovery situation, it shall examine the command at the
>       head of the queue and:
> 
> 	If the command tag matches the one of the unacknowledged
> 	command, it shall make sure the command is processed and
> 	resend the completion notification.
> 
> 	Else if the command tag follows the one of the
> 	unacknowledged command, it shall ASSUME the completion
> 	notification was successfully received by the initiator
> 	and that the ACK transmission was lost.  The pending
> 	command shall be implicilty acknowledged by the new
> 	command, and completed by the target.
> 
>         Else the target shall abort it.
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------
> 

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

From gregs at sdd.hp.com  Fri Jul 24 12:32:52 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:51 2009
Subject: P1394> MAX_?2?_DATA_SIZE(Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807241534.AAA23522@origin.pure.cpdc.canon.co.jp> from "Akihiro Shimura" at Jul 25, 98 00:34:11 am
Message-ID: <199807241632.JAA15696@hpsdlgj1.sdd.hp.com>


It was acknowledged at the July meeting that these parameters
do NOT need to go across the wire in order to have a functioning
protocol.

A strong desire was expressed to have these parameters go
across the wire in order for initiator and target to more
effeciently use their respective memory resources.  These
are there as a concession to that desire.

MAX_I2T_DATA_SIZE indicates the maximum amount of
target-to-initiator data the target can buffer and retransmit for
this connection across an 

  MAX_T2I_DATA_SIZE is the maximum amount of target-to-initiator
  data the target will buffer and retransmit across this
  connection if the Task is implicilty or explicitly aborted
  (e.g.  Bus Reset or TASK SET ABORT).  Any memory allocated by
  the initiator beyond this amount is wasted, since it will never
  be used.  Similarly, if an initiator only provides memory
  buffers much smaller than those indicated by the target, the
  target may be able to manage it's internal memory more
  effeciently.

  MAX_I2T_DATA_SIZE is there for symmetry.

Greg Shue, HP

Akihiro Shimura wrote:

> >   B)  MAX_I2T_DATA_SIZE  (31 bits unsigned int)
> >   C)  MAX_T2I_DATA_SIZE  (31 bits unsigned int)
> 
> It is still not clear for me what is specified for initiator and/or
> target by these parameters.
> 
> Size of the "buffer" referred by data_descriptor field of an ORB will
> be determined along with requesting client of the initiator. Once the
> ORB is appended to task list, access right to the "buffer" is granted
> to the target, and the "buffer" looks like (remote) receiving/sending
> buffer of the target. The target can access any part of the "buffer"
> within the address range of the "buffer" in arbitrary size unit the
> target wants to handle.
> 
> I think the size of the "buffer" referred by the ORB and the size
> unit that target processes the "buffer" are independent of each other.
> 
> Could you explain why these parameters need to go across the wire?
> 
> Akihiro Shimura


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From gregs at sdd.hp.com  Fri Jul 24 13:07:25 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:51 2009
Subject: P1394> CONNECTION_STATE(Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807241551.AAA23539@origin.pure.cpdc.canon.co.jp> from "Akihiro Shimura" at Jul 25, 98 00:51:09 am
Message-ID: <199807241707.KAA15733@hpsdlgj1.sdd.hp.com>


As I thought about your observation, the only case which might
need CONNECTION_STATE is when the connection is opened
unidirecitonally.  I suppose unidirectional communication could
be determined from the MAX_I2T_DATA_SIZE and MAX_T2I_DATA_SIZE
parameters.  We need one or the other for this case.

If this is the only case, then I'll remove CONNECTION_STATE
and keep both MAX_I2T_DATA_SIZE and MAX_T2I_DATA_SIZE.

Can anyone else think of a case where the message or stream
transport needs to go from bi- to uni-directional before closing?
If so, respond before 8/3/98 or else I'll remove it from the
command set proposal.

- Greg Shue, HP

Akihiro Shimura wrote:

> 
> >   E)  CONNECTION_STATE   ( 2 bits unsigned int
> 
> I do not think it is necessary for the initiator to control connection
> of each direction separately at transport level.
> 
> I suppose the initiator can do it by not issuing either
> TRANSPORT_I2T_DATA or TRANSPORT_T2I_DATA command, while
> uni-directional target may want to declare its capability.
> 
> Because we are providing bi-directional transport, I think, whether
> clients use it as uni-directional or bi-directional is up to the
> clients.
> 
> Any suggestions?


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From bob at sismicro.com  Fri Jul 24 13:36:11 1998
From: bob at sismicro.com (Robert Morford)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Revised PWG1394 Cmd Set
References: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
Message-ID: <35B8C60B.1C04D19B@sismicro.com>

Greg Shue wrote:
>
> The target needs to communicate the following specific events
> to the initiator even in the case that no commands are queued.
> 
>   - UNIT ATTENTION: logical unit was reset outside of this Login
> 
>   - Target has closed a communication direction and will reject
>      further TRANSPORT_?2?_DATA commands for that direction.
>      When all directions are closed, then target is should
>      Logout ASAP.  (The target shall only successfully execute
>      TRANSPORT_STATUS commands.)

Does this statement imply that the initiator doesn't need to
do a logout if it does both TRANSPORT_CLOSE(I2T) and (T2I)?
Perhaps you could reword "then target is should Logout ASAP"
to "Initiator should Logout ASAP" (since there are no other
valid actions).

-- 
Bob Morford (bob@sismicro.com)
SIS Microelectronics, Inc.
A Subsidiary of Aspec Technology, Inc.
1831 Lefthand Cir., Suite #E
Longmont, CO 80501
303-776-1667 x226

From gregs at sdd.hp.com  Fri Jul 24 13:45:38 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Revised PWG1394 Cmd Set
In-Reply-To: <98072322090601.AKG5A71@smtp.venus.dti.ne.jp> from "Fumio Nagasaka" at Jul 23, 98 10:09:46 pm
Message-ID: <199807241745.KAA15773@hpsdlgj1.sdd.hp.com>


Fumio Nagasaka wrote:
> 
> 1. Is a "command tag" same as a "transaction number" ?

It's the same idea, but at a different scope.  As I was
working out the draft I knew we needed to uniquely identfy
each command, no matter what sequence it arrived in.  These
didn't degrade to being sequential until parameters could
only be read before openning a connection.

(Otherwise we may end up with the problem of needing to
read a parameter to do error recovery before we can continue.
The command to read a parameter gets put into the command
stream before continuing the previously aborted commands.
Does this command get the first sequence number expected
by the target and associated with a previously queued command,
or does it get a tag which may be out-of-sequence?)

> 2. Do you really believe a target device can fail to 
>    receive an ack-packet?

Yes.  Do I really believe that a target device can fail to
receive an ack-packet without receiving a bus reset?  Yes,
but it's _extremely_ unlikely unless it's during product
development.  In that case, all bets are off.  :-)

> 3. I would like to suggest three commands listed below;
> 	TRANSPORT_I2T_ABORT
> 	TRANSPORT_T2I_ABORT
> 	TRANSPORT_ORB_RELEASE
> 
> 3.1. TRANSPORT_I2T_ABORT
> 	An initiator requests a target to stop ORB fetching, 
> 	and solicits the target to reply STATUS block when
> 	the last ORB had been executed.

I probably don't understand this one.

  Since we're using the UNORDERED model, all the ORBs on the
  task list have been fetched by the target as soon as they
  are placed on it.  There is no point to issuing this command.

  This command would really need to be issued as a vendor-specific
  Management Agent command, since it needs to be executed
  asynchronously to the two ordered execution queues or
  else a third queue needs to be defined.

  Using the ABORT TASK management function defined by SBP-2
  beginning with the last task in the queue will do the same
  thing if you want a queue-specific function.  

I don't think this provides any additional usefulness and
significantly changes the device model.  What am I missing?

> 
> 3.2. TRANSPORT_T2I_ABORT
> 	A target requests an initiator to stop appending new
> 	ORBs on outstanding linked list. The initiator may
> 	invoke "close" command when it received STATUS bock
> 	associated with the last ORB.

I don't understand this one either.

  A target knows what is the last ORB on the queue when the
  target's transport client gives the appropriate indication.

  We can make a target capable of indicating a direction close
  synchronous with a TRANSPORT_T2I_DATA completion.  All subsequent
  TRANSPORT_T2I_DATA commands are completed with a status of
  connection closed.

I don't see the need for this command either.  Can you explain
this one better?

> 3.3. TRANSPORT_ORB_RELEASE
> 	A target request an initiator to release specified ORB
> 	without completion STATUS block.

"I don't understand this one either."

  This command would really need to be issued as a vendor-specific
  Management Agent command, since it needs to be executed
  asynchronously to the two ordered execution queues or
  else a third queue needs to be defined.

  This sounds identical to ABORT TASK.

What am I missing?

I don't want to re-invent and re-implement SBP-2.  The goal is
to supplement it as little as possible.

-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From gregs at sdd.hp.com  Fri Jul 24 13:48:24 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Revised PWG1394 Cmd Set
In-Reply-To: <35B8C60B.1C04D19B@sismicro.com> from "Robert Morford" at Jul 24, 98 10:36:11 am
Message-ID: <199807241748.KAA15785@hpsdlgj1.sdd.hp.com>

> 
> Greg Shue wrote:
> >
> > The target needs to communicate the following specific events
> > to the initiator even in the case that no commands are queued.
> > 
> >   - UNIT ATTENTION: logical unit was reset outside of this Login
> > 
> >   - Target has closed a communication direction and will reject
> >      further TRANSPORT_?2?_DATA commands for that direction.
> >      When all directions are closed, then target is should
> >      Logout ASAP.  (The target shall only successfully execute
> >      TRANSPORT_STATUS commands.)
> 
> Does this statement imply that the initiator doesn't need to
> do a logout if it does both TRANSPORT_CLOSE(I2T) and (T2I)?
> Perhaps you could reword "then target is should Logout ASAP"
> to "Initiator should Logout ASAP" (since there are no other
> valid actions).

Hmm, did I say this was a "rough" draft?
If not, I should have.  Good catch.  Thanks.  :-)

> -- 
> Bob Morford (bob@sismicro.com)
> SIS Microelectronics, Inc.
> A Subsidiary of Aspec Technology, Inc.
> 1831 Lefthand Cir., Suite #E
> Longmont, CO 80501
> 303-776-1667 x226


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From bob at sismicro.com  Fri Jul 24 17:03:29 1998
From: bob at sismicro.com (Robert Morford)
Date: Wed May  6 14:00:51 2009
Subject: STREAM_COMPLETION (Was Re: P1394> Revised PWG1394 Cmd Set)
References: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
Message-ID: <35B8F6A1.8DE24F2D@sismicro.com>

Greg Shue wrote:
>
> The variables associated with TRANSPORT_STATUS become:
> 
>   A)  MAX_TASK_SET_SIZE  (16 bits unsigned int,
>                                   2 is minimum;
>                                   2^14-1 is maximum)
>   B)  MAX_I2T_DATA_SIZE  (31 bits unsigned int)
>   C)  MAX_T2I_DATA_SIZE  (31 bits unsigned int)
>   D)  STREAM_COMPLETION  ( 8 bits unsigned int)
>   E)  CONNECTION_STATE   ( 2 bits unsigned int
>                                   0 => I2T CLOSED, T2I CLOSED;
>                                   1 => I2T OPEN,   T2I CLOSED;
>                                   2 => I2T CLOSED, T2I OPEN;
>                                   3 => I2T OPEN,   T2I OPEN;)

Greg -

You didn't discuss the STREAM_COMPLETION variable in your
"Revised PWG1394 CMD Set note, although I'm guessing it's 
related to the question I raised (and my subsequent action 
item) about whether there needs to be some negotiation over 
strategies for pre-maturely completing stream-oriented ORBs. 
(See page 8 of PWG 1394 Transport Command Set Proposal Rev. 
0c:  TO BE DETERMINED - When else should a target complete 
this command? (e.g. "Flush" requested from target's 
transport client; the target can no longer retain the data 
for retransmission).)

The Store Data Command Response status block provides
a field called "residue".  The Command Set Proposal
indicates that the meaning of "residue" depends upon
whether "message-based communication" is being used
or "stream-based communication" is being used between
host and device.  As I understand it, "message-based
communication" implies that the initiator knows when
the target has data to send, but doesn't necessarily
know the length of the data.  For the target, the
size of the data is reasonably predicable.  "Stream-based 
communication" allows more initiation on the part of
the target, so that the initiator must post a Store
Data ORB, to support the possibility that the target
will have data to transfer.

I think the question to be answered is whether there needs
to be negotiation between target and initiator (or maybe
just information from target to initiator) over when, under 
stream-based comm., the target is allowed to complete the 
Store Data Orb.  As I thought about this, the only reasons
that I identified for termination were application 
related.  And the application (transport client in the
device) seemed to have it's own good reason.

So, what was the intent for the STREAM_COMPLETION
variable?  Is there something I'm missing related
to the early completion of Store Data Commands
for stream-based communication?

-- 
Bob Morford (bob@sismicro.com)
SIS Microelectronics, Inc.
A Subsidiary of Aspec Technology, Inc.
1831 Lefthand Cir., Suite #E
Longmont, CO 80501
303-776-1667 x226

From shimura at pure.cpdc.canon.co.jp  Mon Jul 27 09:59:14 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:51 2009
Subject: P1394> MAX_?2?_DATA_SIZE(Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807241632.JAA15696@hpsdlgj1.sdd.hp.com>
References: <199807241534.AAA23522@origin.pure.cpdc.canon.co.jp> <199807241632.JAA15696@hpsdlgj1.sdd.hp.com>
Message-ID: <199807271359.WAA19952@origin.pure.cpdc.canon.co.jp>


On Fri, 24 Jul 1998 09:32:52 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:

> It was acknowledged at the July meeting that these parameters
> do NOT need to go across the wire in order to have a functioning
> protocol.
> 
> A strong desire was expressed to have these parameters go
> across the wire in order for initiator and target to more
> effeciently use their respective memory resources.  These
> are there as a concession to that desire.

So, these two parameters do not specify the transport behavior itself
and are only referenced by client application of the initiator, right?

If so, your descriptions seem to me to be misleading.
I feel the descriptions of these parameters sound like followings,
though I am still not sure these descriptions make sense.

  MAX_I2T_DATA_SIZE indicates the maximum amount of
  initiator-to-target data the client of target is willing to receive
  in one buffer. This parameter does not limit buffer size itself,
  and may be reported to the client of initiator.
  If this value is zero, target shall reject TRANSPORT_I2T_DATA
  command.

  MAX_T2I_DATA_SIZE indicates the maximum amount of
  target-to-initiator data the client of target is willing to send in
  one buffer. This parameter does not limit buffer size itself, and
  may be reported to the client of initiator.
  If this value is zero, target shall reject TRANSPORT_T2I_DATA
  command.

>   MAX_T2I_DATA_SIZE is the maximum amount of target-to-initiator
>   data the target will buffer and retransmit across this
>   connection if the Task is implicilty or explicitly aborted
>   (e.g.  Bus Reset or TASK SET ABORT).  Any memory allocated by

>From the error recovery model we discussed, above value may be
smaller than the size of buffer pointed by the ORB, and may minimally
be payload size of block transaction.

>   the initiator beyond this amount is wasted, since it will never
>   be used.  Similarly, if an initiator only provides memory
>   buffers much smaller than those indicated by the target, the
>   target may be able to manage it's internal memory more
>   effeciently.

On the other hand, above statement implies the size of buffer pointed
by the ORB itself.

So, this description seems to me to be conflicting.

I may be still missing something. Any suggestion?

Akihiro Shimura

>   MAX_I2T_DATA_SIZE is there for symmetry.
> 
> Greg Shue, HP
> 
> Akihiro Shimura wrote:
> 
> > >   B)  MAX_I2T_DATA_SIZE  (31 bits unsigned int)
> > >   C)  MAX_T2I_DATA_SIZE  (31 bits unsigned int)
> > 
> > It is still not clear for me what is specified for initiator and/or
> > target by these parameters.
> > 
> > Size of the "buffer" referred by data_descriptor field of an ORB will
> > be determined along with requesting client of the initiator. Once the
> > ORB is appended to task list, access right to the "buffer" is granted
> > to the target, and the "buffer" looks like (remote) receiving/sending
> > buffer of the target. The target can access any part of the "buffer"
> > within the address range of the "buffer" in arbitrary size unit the
> > target wants to handle.
> > 
> > I think the size of the "buffer" referred by the ORB and the size
> > unit that target processes the "buffer" are independent of each other.
> > 
> > Could you explain why these parameters need to go across the wire?
> > 
> > Akihiro Shimura
> 
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------
> 

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.


From shimura at pure.cpdc.canon.co.jp  Mon Jul 27 10:01:05 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:51 2009
Subject: P1394> Recovery (Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
References: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
Message-ID: <199807271401.XAA19959@origin.pure.cpdc.canon.co.jp>


On Mon, 20 Jul 1998 10:05:11 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:
(snip)
>   Recovery:
(snip)
>     Unfortunately, SBP-2 requires targets to support the ABORT TASK
>     function, and the process described for aborting tasks causes
>     previously valid commands to be turned into Dummy ORBs.  This
>     effectively removes the command tag from the ORB, so the
>     queue's Execution Agent no longer sees command tags as
>     sequential even if they were assigned sequentially.

As far as I understand, in Monterey, we have discussed to make the
range of sequence identifier fairly larger than the range of
MAX_TASK_SET_SIZE to make it possible for target to determine, from
the sign of distance between two sequence identifiers (target is
expecting and specified by initiator), whether initiator is
synchronized, behind by missing packet or ahead by Abort Task.

The fairly large range of sequence identifier may not be enough for
the target to handle the gap between sequence identifiers caused by
Abort Task because the gap may infinitely grow.

The initiator is already limiting the number of ORB's not to exceed
maximum reorderable number.
By making this condition a little severe, I think we can avoid
unrecoverable situation without retry interaction between initiator
and target.

The descriptive condition will be as follows;

  The initiator limits 
    the number of ORB's not to exceed maximum reorderable number,
    "AND"
    to append the ORB that has sequence identifier target can identify
    as ahead from last completed one.
  "OR"
  If there is no outstanding ORB for the queue, the initiator appends
  ORB that has sequence identifier adjusted to the next number of last
  completed one.

The conditional expression will be as follows;

  IF ((Number of outstanding ORB for the queue)
      <= (MAX_TASK_SET_SIZE - n))
     AND
     ((((appending sequence id)-(last completed sequence id)) MOD (2^m))
      < (2^(m-1)))
  THEN append ORB with (appending sequence id)
  ELSE
  IF ((Number of outstanding ORB for the queue) = 0)
  THEN adjust (appending sequence id) to (last completed sequence
  id) + 1 and append ORB, 

  where "n" is room for another queue, and "m" is number of bit of
  sequence id.
  
If the target finds initiator is ahead, target can simply update
recorded identifier with the new value specified by the initiator.

So, I do not think the following policy (and so on) is necessary.

>       A)  A target shall enforce sequential command tag values.

Am I missing something?

Akihiro Shimura
--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.


From gregs at sdd.hp.com  Mon Jul 27 11:48:56 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:52 2009
Subject: STREAM_COMPLETION (Was Re: P1394> Revised PWG1394 Cmd Set)
In-Reply-To: <35B8F6A1.8DE24F2D@sismicro.com> from "Robert Morford" at Jul 24, 98 02:03:29 pm
Message-ID: <199807271548.IAA22002@hpsdlgj1.sdd.hp.com>


> Greg -
> 
> You didn't discuss the STREAM_COMPLETION variable in your
> "Revised PWG1394 CMD Set note, although I'm guessing it's 
> related to the question I raised (and my subsequent action 
> item) about whether there needs to be some negotiation over 
> strategies for pre-maturely completing stream-oriented ORBs. 
> (See page 8 of PWG 1394 Transport Command Set Proposal Rev. 
> 0c:  TO BE DETERMINED - When else should a target complete 
> this command? (e.g. "Flush" requested from target's 
> transport client; the target can no longer retain the data 
> for retransmission).)

You are correct.  I didn't.  It should be in a final draft.


> host and device.  As I understand it, "message-based
> communication" implies that the initiator knows when
> the target has data to send, but doesn't necessarily
> know the length of the data.

The model we have been using is that a message is a
bounded set of data to be transferred within one ORB.
It is to be transferred as a composite whole, and may
be transferred at any time.  The idea is best described
as a "reliable point-to-point datagram service".  So the
receiver doesn't know when a message will come or how
long it is.  It just knows the maximum length of any single
message, and that the whole message will be transferred
within one ORB.  The size of the message is limited by
primarily by the command set used, and otherwise limited
by the packet negotiation size (if the command set takes
care of de/fragmentation).

> "Stream-based 
> communication" allows more initiation on the part of
> the target, so that the initiator must post a Store
> Data ORB, to support the possibility that the target
> will have data to transfer.

A STORE DATA (or TRANSPORT_I2T_DATA) ORB will have to
be posted whether it's a message or stream connection.
It's the only means to move data from the Target to the
Initiator.  :-)

> I think the question to be answered is whether there needs
> to be negotiation between target and initiator (or maybe
> just information from target to initiator) over when, under 
> stream-based comm., the target is allowed to complete the 
> Store Data Orb.  As I thought about this, the only reasons
> that I identified for termination were application 
> related.  And the application (transport client in the
> device) seemed to have it's own good reason.

This is the essence of the issue.  In Stream-based communication,
a target could complete an ORB:

  as soon as _any_ data is available (possibly wasting bus
    bandwidth)

  only when it must (full or target internally blocked because
    output must be sent before proceeding).

  or anywhere in between.

> So, what was the intent for the STREAM_COMPLETION
> variable?  Is there something I'm missing related
> to the early completion of Store Data Commands
> for stream-based communication?

If commands are completed immediately, then extra bus
bandwidth is consumed for having to requeue additional
ORBs.

Does this help?

> -- 
> Bob Morford (bob@sismicro.com)
> SIS Microelectronics, Inc.
> A Subsidiary of Aspec Technology, Inc.
> 1831 Lefthand Cir., Suite #E
> Longmont, CO 80501
> 303-776-1667 x226
> 


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From bob at sismicro.com  Mon Jul 27 12:05:44 1998
From: bob at sismicro.com (Robert Morford)
Date: Wed May  6 14:00:52 2009
Subject: STREAM_COMPLETION (Was Re: P1394> Revised PWG1394 Cmd Set)
References: <199807271548.IAA22002@hpsdlgj1.sdd.hp.com>
Message-ID: <35BCA558.D2B7FC2@sismicro.com>

Greg Shue wrote:
>
> > I think the question to be answered is whether there needs
> > to be negotiation between target and initiator (or maybe
> > just information from target to initiator) over when, under
> > stream-based comm., the target is allowed to complete the
> > Store Data Orb.  As I thought about this, the only reasons
> > that I identified for termination were application
> > related.  And the application (transport client in the
> > device) seemed to have it's own good reason.
> 
> This is the essence of the issue.  In Stream-based communication,
> a target could complete an ORB:
> 
>   as soon as _any_ data is available (possibly wasting bus
>     bandwidth)
> 
>   only when it must (full or target internally blocked because
>     output must be sent before proceeding).
> 
>   or anywhere in between.

It seems that the second case must be determined by the application 
(transport client).  If you allow the application to decide, then
is there really any point in negotiation?

Was this the point of "STREAM_COMPLETION" or did you have something
else in mind?

-- 
Bob Morford (bob@sismicro.com)
SIS Microelectronics, Inc.
A Subsidiary of Aspec Technology, Inc.
1831 Lefthand Cir., Suite #E
Longmont, CO 80501
303-776-1667 x226

From gregs at sdd.hp.com  Mon Jul 27 12:26:16 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:52 2009
Subject: P1394> MAX_?2?_DATA_SIZE(Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807271359.WAA19952@origin.pure.cpdc.canon.co.jp> from "Akihiro Shimura" at Jul 27, 98 10:59:14 pm
Message-ID: <199807271626.JAA22234@hpsdlgj1.sdd.hp.com>

> 
> 
> On Fri, 24 Jul 1998 09:32:52 -0700 (PDT)
> Greg Shue <gregs@sdd.hp.com> wrote:
> 
> > It was acknowledged at the July meeting that these parameters
> > do NOT need to go across the wire in order to have a functioning
> > protocol.
> > 
> > A strong desire was expressed to have these parameters go
> > across the wire in order for initiator and target to more
> > effeciently use their respective memory resources.  These
> > are there as a concession to that desire.
> 
> So, these two parameters do not specify the transport behavior itself
> and are only referenced by client application of the initiator, right?

Perhaps the better description is that these parameters _clarify_
transport behavior.  They communicate how the data can/will be moved
across the wire.  This information can be used by both the target
and intiator protocol drivers in order to more efficiently manage
it's own resources.  If this information was not communicated,
the behavior of information transfer across the wire would still
be the same, but much more memory may be reserved for buffering than
is ever used.

> I feel the descriptions of these parameters sound like followings,
> though I am still not sure these descriptions make sense.
> 
>   MAX_I2T_DATA_SIZE indicates the maximum amount of
>   initiator-to-target data the client of target is willing to receive
>   in one buffer. This parameter does not limit buffer size itself,
>   and may be reported to the client of initiator.
>   If this value is zero, target shall reject TRANSPORT_I2T_DATA
>   command.
> 
>   MAX_T2I_DATA_SIZE indicates the maximum amount of
>   target-to-initiator data the client of target is willing to send in
>   one buffer. This parameter does not limit buffer size itself, and
>   may be reported to the client of initiator.
>   If this value is zero, target shall reject TRANSPORT_T2I_DATA
>   command.

Essentially, you are correct.  These parameters only make sense
when you start to consider memory usage optimizations on both intiator
and target ends.  Without these numbers (other than for zero/non-zero
values), memory could be very unequally allocated by each end.

> >   MAX_T2I_DATA_SIZE is the maximum amount of target-to-initiator
> >   data the target will buffer and retransmit across this
> >   connection if the Task is implicilty or explicitly aborted
> >   (e.g.  Bus Reset or TASK SET ABORT).  Any memory allocated by
> 
> >From the error recovery model we discussed, above value may be
> smaller than the size of buffer pointed by the ORB, and may minimally
> be payload size of block transaction.

I don't think that an SBP-2 target can require that the same
physical memory be tied to a requeued TRANSPORT_T2I_DATA ORB.
So a target must assume that the memory does NOT contain any
previously written data, and so must rewrite the entire valid
contents.  The size of the acutal data being transported may
always be less than the indicated MAX_T2I_DATA_SIZE (unless
the max size is 1 Byte!).  The actual minimum valid data size
is 1 byte.  It still takes a 1 quadlet transaction.

> On the other hand, above statement implies the size of buffer pointed
> by the ORB itself.

Yes, the MAX size is the maximum size of the buffer pointed to
by the ORB itself.

> So, this description seems to me to be conflicting.
> 
> I may be still missing something. Any suggestion?

Yes, can someone else try to describe this?  Unfortunately, I am
as confused with your misunderstandings as you are with my
descriptions!

> Akihiro Shimura


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From gregs at sdd.hp.com  Mon Jul 27 13:13:31 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Recovery (Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807271401.XAA19959@origin.pure.cpdc.canon.co.jp> from "Akihiro Shimura" at Jul 27, 98 11:01:05 pm
Message-ID: <199807271713.KAA22270@hpsdlgj1.sdd.hp.com>


Akihiro Shimura wrote:

> The initiator is already limiting the number of ORB's not to exceed
> maximum reorderable number.

(... number of ORBs in the active task set...)

> By making this condition a little severe, I think we can avoid
> unrecoverable situation without retry interaction between initiator
> and target.
> 
> The descriptive condition will be as follows;
> 
>   The initiator limits 
>     the number of ORB's not to exceed maximum reorderable number,
>     "AND"
>     to append the ORB that has sequence identifier target can identify
>     as ahead from last completed one.
>   "OR"
>   If there is no outstanding ORB for the queue, the initiator appends
>   ORB that has sequence identifier adjusted to the next number of last
>   completed one.
> 
> The conditional expression will be as follows;
> 
>   IF ((Number of outstanding ORB for the queue)
>       <= (MAX_TASK_SET_SIZE - n))

(... the first part is always true!)

>      AND
>      ((((appending sequence id)-(last completed sequence id)) MOD (2^m))
>       < (2^(m-1)))
>   THEN append ORB with (appending sequence id)
>   ELSE
>   IF ((Number of outstanding ORB for the queue) = 0)
>   THEN adjust (appending sequence id) to (last completed sequence
>   id) + 1 and append ORB, 
> 
>   where "n" is room for another queue, and "m" is number of bit of
>   sequence id.

Unfortunately, the target isn't going to always recieve
sequence numbers which are monotonically increasing.  This is
the consequence of an ABORT_TASK applied to the middle of
a queue.  The "sequence number" space has suddenly become
sparse!

Suddenly a sequence number space >> MAX_TASK_SET_SIZE doesn't
guarantee that we can detect order in an error recovery
situation.  Both ends may differ as to where they believe the
"last completed sequence number" is!

> If the target finds initiator is ahead, target can simply update
> recorded identifier with the new value specified by the initiator.
>
> Am I missing something?

I think so.  Start aborting single tasks from the middle of a
queue and watch what happens to the "sequence numbers" from the
target's perspective.

SBP-2 requires the support of ABORT TASK.

-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From gregs at sdd.hp.com  Mon Jul 27 13:27:32 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:52 2009
Subject: STREAM_COMPLETION (Was Re: P1394> Revised PWG1394 Cmd Set)
In-Reply-To: <35BCA558.D2B7FC2@sismicro.com> from "Robert Morford" at Jul 27, 98 09:05:44 am
Message-ID: <199807271727.KAA22290@hpsdlgj1.sdd.hp.com>

Bob Morford (bob@sismicro.com) wrote:

> Greg Shue wrote:
> >
> > > I think the question to be answered is whether there needs
> > > to be negotiation between target and initiator (or maybe
> > > just information from target to initiator) over when, under
> > > stream-based comm., the target is allowed to complete the
> > > Store Data Orb.  As I thought about this, the only reasons
> > > that I identified for termination were application
> > > related.  And the application (transport client in the
> > > device) seemed to have it's own good reason.
> > 
> > This is the essence of the issue.  In Stream-based communication,
> > a target could complete an ORB:
> > 
> >   as soon as _any_ data is available (possibly wasting bus
> >     bandwidth)
> > 
> >   only when it must (full or target internally blocked because
> >     output must be sent before proceeding).
> > 
> >   or anywhere in between.
> 
> It seems that the second case must be determined by the application 
> (transport client).  If you allow the application to decide, then
> is there really any point in negotiation?
> 
> Was this the point of "STREAM_COMPLETION" or did you have something
> else in mind?

The point was some policy needed to be defined to have consistent
implementations.  I just couldn't make the call on my own about
where that responsibility lies or what the policy should be.
If the policy becomes that the target will pass along as much
data as it can as quickly as it can it may be sufficient.  (Though
we could end up with many small transactions rather than a few large
ones when data trickles out.)

As long as you can get people to agree on something, it's probably
fine with me.  :-)


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From shimura at pure.cpdc.canon.co.jp  Mon Jul 27 18:49:16 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Recovery (Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807271713.KAA22270@hpsdlgj1.sdd.hp.com>
References: <199807271401.XAA19959@origin.pure.cpdc.canon.co.jp> <199807271713.KAA22270@hpsdlgj1.sdd.hp.com>
Message-ID: <199807272249.HAA20510@origin.pure.cpdc.canon.co.jp>

See comment below,

On Mon, 27 Jul 1998 10:13:31 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:

> Akihiro Shimura wrote:
> 
> > The initiator is already limiting the number of ORB's not to exceed
> > maximum reorderable number.
> 
> (... number of ORBs in the active task set...)
> 
> > By making this condition a little severe, I think we can avoid
> > unrecoverable situation without retry interaction between initiator
> > and target.
> > 
> > The descriptive condition will be as follows;
> > 
> >   The initiator limits 
> >     the number of ORB's not to exceed maximum reorderable number,
> >     "AND"
> >     to append the ORB that has sequence identifier target can identify
> >     as ahead from last completed one.
> >   "OR"
> >   If there is no outstanding ORB for the queue, the initiator appends
> >   ORB that has sequence identifier adjusted to the next number of last
> >   completed one.
> > 
> > The conditional expression will be as follows;
> > 
> >   IF ((Number of outstanding ORB for the queue)
> >       <= (MAX_TASK_SET_SIZE - n))
> 
> (... the first part is always true!)

The initiator is responsible to make the first part true. The
condition represents the way initiator decides to append ORB or not.

> >      AND
> >      ((((appending sequence id)-(last completed sequence id)) MOD (2^m))
> >       < (2^(m-1)))
> >   THEN append ORB with (appending sequence id)
> >   ELSE
> >   IF ((Number of outstanding ORB for the queue) = 0)
> >   THEN adjust (appending sequence id) to (last completed sequence
> >   id) + 1 and append ORB, 
> > 
> >   where "n" is room for another queue, and "m" is number of bit of
> >   sequence id.
> 
> Unfortunately, the target isn't going to always recieve
> sequence numbers which are monotonically increasing.  This is
> the consequence of an ABORT_TASK applied to the middle of
> a queue.  The "sequence number" space has suddenly become
> sparse!

Above condition
> >      ((((appending sequence id)-(last completed sequence id)) MOD (2^m))
> >       < (2^(m-1)))
prevents the sequence number distance to become "too" apart for the
target to distinguish the initiator is ahead or behind.

> Suddenly a sequence number space >> MAX_TASK_SET_SIZE doesn't
> guarantee that we can detect order in an error recovery
> situation.  Both ends may differ as to where they believe the
> "last completed sequence number" is!

The "last completed sequence number" means the number the
"initiator" is recognizing.
Because (a sequence number space >> MAX_TASK_SET_SIZE) does not
guarantee successful detection, additional condition is necessary
to safely append ORB.

The distance between "last completed sequence id(that initiator is
recognizing)" and "appending sequence id(initiator is going to
append ORB with this id)" is always greater than the distance
between "the sequence id target derives from ORB" and "the sequence
id target is expecting to derive".
This makes target detect ahead or behind successfully.

> > If the target finds initiator is ahead, target can simply update
> > recorded identifier with the new value specified by the initiator.
> >
> > Am I missing something?
> 
> I think so.  Start aborting single tasks from the middle of a
> queue and watch what happens to the "sequence numbers" from the
> target's perspective.

>From this observation, I have made additional condition.

> 
> SBP-2 requires the support of ABORT TASK.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------
> 

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

From fumiona at venus.dtinet.or.jp  Mon Jul 27 20:26:16 1998
From: fumiona at venus.dtinet.or.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Revised PWG1394 Cmd Set
In-Reply-To: <199807241745.KAA15773@hpsdlgj1.sdd.hp.com>
References: <199807241745.KAA15773@hpsdlgj1.sdd.hp.com>
Message-ID: <98072809243001.AKG35F1@smtp.venus.dti.ne.jp>

Greg Shue wrote:
>
>Fumio Nagasaka wrote:
>
>> 3.1. TRANSPORT_I2T_ABORT
>> 	An initiator requests a target to stop ORB fetching, 
>> 	and solicits the target to reply STATUS block when
>> 	the last ORB had been executed.
>
>I probably don't understand this one.
>
>  Since we're using the UNORDERED model, all the ORBs on the
>  task list have been fetched by the target as soon as they
>  are placed on it.  There is no point to issuing this command.
>
>  This command would really need to be issued as a vendor-specific
>  Management Agent command, since it needs to be executed
>  asynchronously to the two ordered execution queues or
>  else a third queue needs to be defined.
>
>  Using the ABORT TASK management function defined by SBP-2
>  beginning with the last task in the queue will do the same
>  thing if you want a queue-specific function.  
>
>I don't think this provides any additional usefulness and
>significantly changes the device model.  What am I missing?
>
You are missing one point;
Let me come back to your first note.

Greg Shue wrote:

GS>
GS>Now, error recovery for when a target detects an ACK Timeout on a
GS>Status FIFO write requires some special considerations.  When
GS>this condition happens the initiator and target may be
GS>out-of-sync with each other, and the SBP-2 protocol does not
GS>provide a mechanism for the initiator to determine that the
GS>condition exists.  The problem breaks down to two issues:

SBP-2 protocol *does* provide a mechanism to show this status.
An AGENT_STATE register has two bit to describe status.

In this case "SBP-2 Specification Rev.4" is saying, the fetch agent
shall transition to state DEAD. See page 62 "Transition Any:F5".
The only way to recover from this state, the initiator need to
write data on AGENT_RESET register.

Your scenario cause an impression that the target device shall
be responsible for recovery. However, SBP-2 specification requires
the initiator to be responsible in this case.

SBP-2>State F5: Dead. The dead state is a unique state that preserves fetch agent information in the
SBP-2>AGENT_STATE and ORB_POINTER registers. Writes to any fetch agent register except AGENT_RESET
SBP-2>shall have no effect while in state F5.

After AGENT_RESET the initiator need to inquire what is the
last ORB consumed by the target. In my idea, the initiator
shall invoke TRANSPORT_I2T_ABORT command to receive reply
from the target.

---
Fumio Nagasaka
EPSON Software Deveopment Lab., Inc.
voice: +81 268 25-4111

From shimura at pure.cpdc.canon.co.jp  Tue Jul 28 10:06:29 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Recovery (Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807272249.HAA20510@origin.pure.cpdc.canon.co.jp>
References: <199807271713.KAA22270@hpsdlgj1.sdd.hp.com> <199807272249.HAA20510@origin.pure.cpdc.canon.co.jp>
Message-ID: <199807281406.XAA29403@origin.pure.cpdc.canon.co.jp>


I forgot to describe the accurate condition "target" detects whether
the initiator is ahead, synchronized or behind.

Target uses the following condition;

  Put DistT = 
    ((sequence id specified in ORB)-(expecting sequence id)) mod (2^m)

  IF ((DistT) >= (2^(m-1)) THEN initiator is behind
  ELSE IF (0<DistT<(2^(m-1)) THEN initiator is ahead
  ELSE initiator is synchronized


Following figure shows the relationship between each sequence id.

"Initiator"    (last completed)          (going to append)
                v(S1)                     v(S2)
                |                         |

"Target"             (expecting)     (specified in ORB)  
                      v(S3)          v(S4)
                      |              |
                      |<--------da------->|
                |   | |
"Target(ahead)"    (specified in ORB)  
                    v(S4)
                  ->| |<- db
                  
S1-S4 represents the sequence IDs.

By the initiator's condition, (S2-S1) mod (2^m) < (2^(m-1)).
Because the initiator is recognizing that S1 is completed, 
0 < (S3-S1) mod (2^m) < (2^(m-1)).
Thus, the distance "da" in above figure, (S2-S3) mod (2^m) < 2^(m-1).
So, target recognizes S2 as ahead.

If the initiator is behind, S4 will be between S1 and S3 as show
above "Target(ahead)".
Because (S3-S4) mod (2^m) < (2^(m-1)), the distance "db" in above
figure, (S4-S3) mod (2^m) >= (2^(m-1)).
So, target recognizes S4 as behind.

I think this method makes target free from reporting "ABORTED" status
and makes initiator free from taking recovery actions due to the
identifier gap.

Akihiro Shimura

On Tue, 28 Jul 1998 07:49:16 +0900 (JST)
Akihiro Shimura <shimura@pure.cpdc.canon.co.jp> wrote:

> See comment below,
> 
> On Mon, 27 Jul 1998 10:13:31 -0700 (PDT)
> Greg Shue <gregs@sdd.hp.com> wrote:
> 
> > Akihiro Shimura wrote:
> > 
> > > The initiator is already limiting the number of ORB's not to exceed
> > > maximum reorderable number.
> > 
> > (... number of ORBs in the active task set...)
> > 
> > > By making this condition a little severe, I think we can avoid
> > > unrecoverable situation without retry interaction between initiator
> > > and target.
> > > 
> > > The descriptive condition will be as follows;
> > > 
> > >   The initiator limits 
> > >     the number of ORB's not to exceed maximum reorderable number,
> > >     "AND"
> > >     to append the ORB that has sequence identifier target can identify
> > >     as ahead from last completed one.
> > >   "OR"
> > >   If there is no outstanding ORB for the queue, the initiator appends
> > >   ORB that has sequence identifier adjusted to the next number of last
> > >   completed one.
> > > 
> > > The conditional expression will be as follows;
> > > 
> > >   IF ((Number of outstanding ORB for the queue)
> > >       <= (MAX_TASK_SET_SIZE - n))
> > 
> > (... the first part is always true!)
> 
> The initiator is responsible to make the first part true. The
> condition represents the way initiator decides to append ORB or not.
> 
> > >      AND
> > >      ((((appending sequence id)-(last completed sequence id)) MOD (2^m))
> > >       < (2^(m-1)))
> > >   THEN append ORB with (appending sequence id)
> > >   ELSE
> > >   IF ((Number of outstanding ORB for the queue) = 0)
> > >   THEN adjust (appending sequence id) to (last completed sequence
> > >   id) + 1 and append ORB, 
> > > 
> > >   where "n" is room for another queue, and "m" is number of bit of
> > >   sequence id.
> > 
> > Unfortunately, the target isn't going to always recieve
> > sequence numbers which are monotonically increasing.  This is
> > the consequence of an ABORT_TASK applied to the middle of
> > a queue.  The "sequence number" space has suddenly become
> > sparse!
> 
> Above condition
> > >      ((((appending sequence id)-(last completed sequence id)) MOD (2^m))
> > >       < (2^(m-1)))
> prevents the sequence number distance to become "too" apart for the
> target to distinguish the initiator is ahead or behind.
> 
> > Suddenly a sequence number space >> MAX_TASK_SET_SIZE doesn't
> > guarantee that we can detect order in an error recovery
> > situation.  Both ends may differ as to where they believe the
> > "last completed sequence number" is!
> 
> The "last completed sequence number" means the number the
> "initiator" is recognizing.
> Because (a sequence number space >> MAX_TASK_SET_SIZE) does not
> guarantee successful detection, additional condition is necessary
> to safely append ORB.
> 
> The distance between "last completed sequence id(that initiator is
> recognizing)" and "appending sequence id(initiator is going to
> append ORB with this id)" is always greater than the distance
> between "the sequence id target derives from ORB" and "the sequence
> id target is expecting to derive".
> This makes target detect ahead or behind successfully.
> 
> > > If the target finds initiator is ahead, target can simply update
> > > recorded identifier with the new value specified by the initiator.
> > >
> > > Am I missing something?
> > 
> > I think so.  Start aborting single tasks from the middle of a
> > queue and watch what happens to the "sequence numbers" from the
> > target's perspective.
> 
> >From this observation, I have made additional condition.
> 
> > 
> > SBP-2 requires the support of ABORT TASK.
> > 
> > -- 
> > Greg Shue
> > Hewlett-Packard Company
> > All-in-One Division			        gregs@sdd.hp.com
> > ----------------------------------------------------------------
> > 
> 
> --
>  Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
>  Office Imaging System Promotion Project
>  CANON INC.
> 

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

From list at listme.com  Thu Jul 30 03:45:26 1998
From: list at listme.com (list@listme.com)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Your Search Engine Listing
Message-ID: <199807300745.DAA18823@listme.com>

To: p1394@pwg.org 

     Is your site listed with the top search engines?  ListMe will 
     list you with 50 search engines and indexes for $90. 
     Satisfaction guaranteed! 

Search engines are the only way most people have to find internet sites.
But if your site is not listed, no one will find it.

ListMe will submit your site for listing in the top 50 search engines for $90.

Here's how it works:

1.  Complete and return the form below.

2.  We'll post your site to 50 search engines within two business days, and 
we'll send you a submission report when we're finished.

3.  Pay nothing now.  We'll send you an invoice after we've completed the posting.
Your satisfaction is guaranteed!

These are permanent listings.  The $90 is a one-time fee.

WHICH SEARCH ENGINES?

Here's the list:

Infoseek, Lycos, Excite, Alta Vista,  Galaxy, HotBot, Magellan, Open 
Text Web Index, Web Crawler, BizWeb, New Riders WWW Yellow Pages, 
YelloWWWeb, True North, Northern Light, LinkMonster, The Weekly Bookmark, 
Seven Wonders, Jayde Online Directory, Starting Point, Web 100, Web Walker, 
New Page List, PeekABoo, One World Plaza, PageHost A-Z, Net-Announce, 
Project Cool, Where2Go, World Wide Business Yellow Pages, Sserv, 
Wow! Web Wonders!, WWW Worm, JumpCity, The Galactic Galaxy, TurnPike, 
Unlock:The Information Exchange, Your WebScout, Manufacturers Information 
Network, Net Happenings, Net Mall, Web World  Internet Directory, 
InfoSpace, BC Internet, BizCardz Business Directory, Scrub The Web,  
WebVenture, Hotlist, What's New, WhatUSeek, JumpLink, Linkcentre Directory. 

ORDER FORM (or use our convenient on-line order form at "www.listme.com")

Hit the REPLY button on your e-mail program and fill out the following information.
 (This information will be posted to the search engines/indexes):


Contact name: 
Company Name:
Address:
City:              State/Prov:     Zip/Postal Code: 
Telephone: 
Fax: 
Email address: 

Contact e-mail address (in case we have questions about this order): 

URL:  http://
Site Title: 
Description (250 characters): 

Key words (250 characters, in descending order of importance):

If  billing a different address, please complete the following:

Addressee: 
Company Name:
Address:
City:              State/Prov:     Zip/Postal Code: 
Telephone: 
Fax: 
Email address: 

TERMS

Terms are net 15 days from date of invoice.

______________________________________________________________________
ListMe, Inc.
1127 High Ridge Road - Suite 184
Stamford CT 06905
Phone: (203) 326-8519
Fax:   (203) 322-4505
E-mail: list@listme.com
URL: www.listme.com

From shimura at pure.cpdc.canon.co.jp  Fri Jul 31 01:20:20 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:52 2009
Subject: P1394> MAX_?2?_DATA_SIZE(Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807271626.JAA22234@hpsdlgj1.sdd.hp.com>
References: <199807271359.WAA19952@origin.pure.cpdc.canon.co.jp> <199807271626.JAA22234@hpsdlgj1.sdd.hp.com>
Message-ID: <199807310520.OAA09352@origin.pure.cpdc.canon.co.jp>


Thank you for the explanation.

I am now a little clear on this topic (, I hope).

Originally, it was very questionable for me that the target must
resend the "entire" buffer though the target is sending data over
very reliable (acknowledged) 1394 transactions.

If the initiator can keep the contents of buffer, the target only
needs to resend outstanding transaction(s).
I thought this avoids redundant re-transmission on the wire while
allowing utilization of buffer beyond the target resource.

Whether the initiator keeps the contents of buffer or not depends on
the underlying implementation on the initiator (i.e. interpretation
on the buffer's "direction" bit set to one).

So I would like to propose an enhancement to the recovery model based
on the "MAX_T2I_DATA_SIZE" to take advantage of shared memory model
while keeping independence of implementations.

The enhancement is based on negotiated MAX_T2I_DATA_SIZE reflecting
initiator's preference.

The definition of MAX_T2I_DATA_SIZE will look like following;

  MAX_T2I_DATA_SIZE provided by the target indicates the maximum unit
  of target-to-initiator data the target can guarantee to hold and
  re-send in case of recovering requeued TRANSPORT_T2I_DATA command.
  Initiator may set this parameter value smaller than the value
  provided by the target. The value zero specified by the initiator
  indicates that the target needs not to guarantee to hold and
  re-send data beyond 1394 transaction.
  Target shall guarantee to hold and re-send data up to this
  (negotiated) parameter size.
  Responsibility to hold the contents of buffer beyond this parameter
  size belongs to the initiator.
  The initiator shall avoid to issue TRANSPORT_T2I_DATA command which
  has associated buffer larger than this parameter in case that the
  buffer contents may not be held.
 
Though this enhancement will not be optimal in the spirit of shared
memory model, I think almost the same result will be derived by this
enhancement.

Ueda-san from Canon will make a presentation on this enhancement at
upcoming Toronto meeting.

BTW, MAX_I2T_DATA_SIZE parameter seems not to be useful at all for
both ends, and should be gone. Any objections?

Akihiro Shimura

On Mon, 27 Jul 1998 09:26:16 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:

> > On Fri, 24 Jul 1998 09:32:52 -0700 (PDT)
> > Greg Shue <gregs@sdd.hp.com> wrote:
> > 
> > > It was acknowledged at the July meeting that these parameters
> > > do NOT need to go across the wire in order to have a functioning
> > > protocol.
> > > 
> > > A strong desire was expressed to have these parameters go
> > > across the wire in order for initiator and target to more
> > > effeciently use their respective memory resources.  These
> > > are there as a concession to that desire.
> > 
> > So, these two parameters do not specify the transport behavior itself
> > and are only referenced by client application of the initiator, right?
> 
> Perhaps the better description is that these parameters _clarify_
> transport behavior.  They communicate how the data can/will be moved
> across the wire.  This information can be used by both the target
> and intiator protocol drivers in order to more efficiently manage
> it's own resources.  If this information was not communicated,
> the behavior of information transfer across the wire would still
> be the same, but much more memory may be reserved for buffering than
> is ever used.
> 
> > I feel the descriptions of these parameters sound like followings,
> > though I am still not sure these descriptions make sense.
> > 
> >   MAX_I2T_DATA_SIZE indicates the maximum amount of
> >   initiator-to-target data the client of target is willing to receive
> >   in one buffer. This parameter does not limit buffer size itself,
> >   and may be reported to the client of initiator.
> >   If this value is zero, target shall reject TRANSPORT_I2T_DATA
> >   command.
> > 
> >   MAX_T2I_DATA_SIZE indicates the maximum amount of
> >   target-to-initiator data the client of target is willing to send in
> >   one buffer. This parameter does not limit buffer size itself, and
> >   may be reported to the client of initiator.
> >   If this value is zero, target shall reject TRANSPORT_T2I_DATA
> >   command.
> 
> Essentially, you are correct.  These parameters only make sense
> when you start to consider memory usage optimizations on both intiator
> and target ends.  Without these numbers (other than for zero/non-zero
> values), memory could be very unequally allocated by each end.
> 
> > >   MAX_T2I_DATA_SIZE is the maximum amount of target-to-initiator
> > >   data the target will buffer and retransmit across this
> > >   connection if the Task is implicilty or explicitly aborted
> > >   (e.g.  Bus Reset or TASK SET ABORT).  Any memory allocated by
> > 
> > >From the error recovery model we discussed, above value may be
> > smaller than the size of buffer pointed by the ORB, and may minimally
> > be payload size of block transaction.
> 
> I don't think that an SBP-2 target can require that the same
> physical memory be tied to a requeued TRANSPORT_T2I_DATA ORB.
> So a target must assume that the memory does NOT contain any
> previously written data, and so must rewrite the entire valid
> contents.  The size of the acutal data being transported may
> always be less than the indicated MAX_T2I_DATA_SIZE (unless
> the max size is 1 Byte!).  The actual minimum valid data size
> is 1 byte.  It still takes a 1 quadlet transaction.
> 
> > On the other hand, above statement implies the size of buffer pointed
> > by the ORB itself.
> 
> Yes, the MAX size is the maximum size of the buffer pointed to
> by the ORB itself.
> 
> > So, this description seems to me to be conflicting.
> > 
> > I may be still missing something. Any suggestion?
> 
> Yes, can someone else try to describe this?  Unfortunately, I am
> as confused with your misunderstandings as you are with my
> descriptions!
> 
> > Akihiro Shimura
> 
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------
> 

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

From shimura at pure.cpdc.canon.co.jp  Fri Jul 31 01:29:27 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:52 2009
Subject: STREAM_COMPLETION (Was Re: P1394> Revised PWG1394 Cmd Set)
In-Reply-To: <199807271727.KAA22290@hpsdlgj1.sdd.hp.com>
References: <35BCA558.D2B7FC2@sismicro.com> <199807271727.KAA22290@hpsdlgj1.sdd.hp.com>
Message-ID: <199807310529.OAA09515@origin.pure.cpdc.canon.co.jp>


> > >   as soon as _any_ data is available (possibly wasting bus
> > >     bandwidth)

Because transport does not have any knowledge about stream boundary,
I think transport should not have its own completion policy beyond
the flow control, and should follow the client's policy.

For a target, it will be straightforward to follow the client's early
completion request by issuing early completion status to the
initiator.

On the other hand, I think we need some consideration in case of
client's early completion request on the initiator side.
Because SBP-2 works with message queuing (linked list of ORBs) and
initiator does not have knowledge of the place where the target is
executing, the early completion will not be able to be handled within
the initiator, and early completion request needs to go across the
wire to the target.

My concern here is that if we can use "ABORT TASK" management
function for this purpose or we need "TERMINATE TASK" management
function which has gone from the latest SBP-2 specification.

Is there any suggestion?

Akihiro Shimura

On Mon, 27 Jul 1998 10:27:32 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:

> Bob Morford (bob@sismicro.com) wrote:
> 
> > Greg Shue wrote:
> > >
> > > > I think the question to be answered is whether there needs
> > > > to be negotiation between target and initiator (or maybe
> > > > just information from target to initiator) over when, under
> > > > stream-based comm., the target is allowed to complete the
> > > > Store Data Orb.  As I thought about this, the only reasons
> > > > that I identified for termination were application
> > > > related.  And the application (transport client in the
> > > > device) seemed to have it's own good reason.
> > > 
> > > This is the essence of the issue.  In Stream-based communication,
> > > a target could complete an ORB:
> > > 
> > >   as soon as _any_ data is available (possibly wasting bus
> > >     bandwidth)
> > > 
> > >   only when it must (full or target internally blocked because
> > >     output must be sent before proceeding).
> > > 
> > >   or anywhere in between.
> > 
> > It seems that the second case must be determined by the application 
> > (transport client).  If you allow the application to decide, then
> > is there really any point in negotiation?
> > 
> > Was this the point of "STREAM_COMPLETION" or did you have something
> > else in mind?
> 
> The point was some policy needed to be defined to have consistent
> implementations.  I just couldn't make the call on my own about
> where that responsibility lies or what the policy should be.
> If the policy becomes that the target will pass along as much
> data as it can as quickly as it can it may be sufficient.  (Though
> we could end up with many small transactions rather than a few large
> ones when data trickles out.)
> 
> As long as you can get people to agree on something, it's probably
> fine with me.  :-)
> 
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------
> 

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

From shimura at pure.cpdc.canon.co.jp  Fri Jul 31 01:41:26 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:52 2009
Subject: P1394> ABORTED - UNEXPECTED ... (Was Re: Revised PWG1394 Cmd Set)
In-Reply-To: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
References: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com>
Message-ID: <199807310541.OAA09620@origin.pure.cpdc.canon.co.jp>


On Mon, 20 Jul 1998 10:05:11 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:
(snip)
>       It may be reasonable for a target to enforce seeing
>       sequential command tags in order to recover from this
>       situation.  If the queue's Execution Agent completed
>       all commands in that queue with a status of "ABORTED -
>       UNEXPECTED COMMAND TAG VALUE", then the initiator has
>       a chance to recover from the situation.  This also means
>       that an ABORT TASK function causes all successive commands
>       on the associated queue to be aborted without affecting
>       the other queue.

I have a question about actions taken by the initiator.

I suppose that if the target's agent finds this situation, target
enters from 'execute' state to 'abort all subsequent commands' state
(in order not to execute the commands still not fetched).
The initiator will wait until target aborts all subsequent commands
destined to the queue.
(Target may be executing commands destined to another queue at this
moment.)

After all subsequent commands are aborted, the initiator will requeue
aborted commands with properly assigned sequence ids. 
I think, initiator "needs to" restore target's agent state to
'execute' without affecting the execution of another queue at this
point.

How does target find the initiator recovered from the
situation? (I may be misunderstanding the process.)

In the model I described in previous mails, the initiator does not
take recovery action at all.

Because descriptive explanation may make it hard to be well
understood, I am preparing some slides for explanation.

Ueda-san from Canon will make a presentation for this alternative
model at upcoming Toronto meeting.

Akihiro Shimura
--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

From gregs at sdd.hp.com  Tue Aug  4 22:20:16 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Revised PWG1394 Cmd Set
In-Reply-To: <98072809243001.AKG35F1@smtp.venus.dti.ne.jp> from "Fumio Nagasaka" at Jul 28, 98 09:26:16 am
Message-ID: <199808050220.TAA28805@hpsdlgj1.sdd.hp.com>


Fumio Nagasaka wrote:
> 
> Greg Shue wrote:
> >
> >Fumio Nagasaka wrote:
> >
> >> 3.1. TRANSPORT_I2T_ABORT
> >> 	An initiator requests a target to stop ORB fetching, 
> >> 	and solicits the target to reply STATUS block when
> >> 	the last ORB had been executed.
> >
> >I probably don't understand this one.
> >
> >  Since we're using the UNORDERED model, all the ORBs on the
> >  task list have been fetched by the target as soon as they
> >  are placed on it.  There is no point to issuing this command.
> >
> >  This command would really need to be issued as a vendor-specific
> >  Management Agent command, since it needs to be executed
> >  asynchronously to the two ordered execution queues or
> >  else a third queue needs to be defined.
> >
> >  Using the ABORT TASK management function defined by SBP-2
> >  beginning with the last task in the queue will do the same
> >  thing if you want a queue-specific function.  
> >
> >I don't think this provides any additional usefulness and
> >significantly changes the device model.  What am I missing?
> >
> You are missing one point;
> Let me come back to your first note.
> 
> Greg Shue wrote:
> 
> GS>
> GS>Now, error recovery for when a target detects an ACK Timeout on a
> GS>Status FIFO write requires some special considerations.  When
> GS>this condition happens the initiator and target may be
> GS>out-of-sync with each other, and the SBP-2 protocol does not
> GS>provide a mechanism for the initiator to determine that the
> GS>condition exists.  The problem breaks down to two issues:
> 
> SBP-2 protocol *does* provide a mechanism to show this status.
> An AGENT_STATE register has two bit to describe status.
> 
> In this case "SBP-2 Specification Rev.4" is saying, the fetch agent
> shall transition to state DEAD. See page 62 "Transition Any:F5".
> The only way to recover from this state, the initiator need to
> write data on AGENT_RESET register.

Good point, but that status requires the intiator go look for it.
How will the initiator know to go look for it?

Here's another one for consideration:

  Since a fetch agent may be processing transactions for multiple
  Tasks simultaneously (since split-transactions), which ORB is
  the ORB_POINTER supposed to reference?  And when is it set?
  SPB-2 Rev 4 doesn't say.  It really is written to a sequential
  execution model.

  SBP-2 Rev 4, p 62 also says (just above State F5:)  The fetch
  agent __may__ also be instructed to transition to the dead
  state as a result of an error in command execution detection by
  the device server.

If the SBP-2 target driver provides a hook to transition the
fetch agent to the DEAD state at any point in time, and if the
ORB_POINTER value is provided in that interface, then we might be
able to use the ORB_POINTER register.  Unfortunately, I'm not
sure if this functionality is a requirement.

> Your scenario cause an impression that the target device shall
> be responsible for recovery. However, SBP-2 specification requires
> the initiator to be responsible in this case.

I don't see it as the target is responsible for _recovery_, but
it is responsible for _detection_ and _indication_.  A Bus Reset
by itself doesn't recover from the situation, it just indicates
that something is drastically wrong.

The problem we have is how to get the initiator to take any sort
of recovery action.  SBP-2 expects that this will be detected by
some mechanism independent of the 'target' module.  The expected
mechanism is a timeout.  At the May PWG 1394 meeting (?), another
mechanism of Bus Reset was suggested.

Any other suggestions?

-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From Nagasaka.Fumio at exc.epson.co.jp  Tue Aug  4 23:34:19 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Revised PWG1394 Cmd Set
Message-ID: <01376112D7AFD011911E0020AF70BEC51163C0@cpuex1.ued.epson.co.jp>

Greg Shue wrote:

	GS> The problem we have is how to get the initiator to take any sort
	GS> of recovery action.  SBP-2 expects that this will be detected by
	GS> some mechanism independent of the 'target' module.  The expected
	GS> mechanism is a timeout.  At the May PWG 1394 meeting (?),
another
	GS> mechanism of Bus Reset was suggested.

The Annex E of SBP-2 Specification Rev.4 is describing;

<<<
E.4 Status FIFO write request
When the target detects a missing acknowledgement after a write to an
initiator?s status FIFO, it should
take no error recovery actions. Any target resources allocated to the ORB
should be released by the
target. The initiator is expected to discover the error by means of a
higher-level mechanism, such as a
command time-out and to initiate appropriate error recovery. The nature of
the error recovery undertaken
by the initiator likely depends whether or not the target processes ORB?s
and returns their status in order,
but in any event is beyond the scope of this description.
>>>

I was missing this section when I sent previous e-mail.
In my idea, a print spooler in the initiator shall detect time out.
Then this initiator shall write AGENT_RESET register or RESET_START
register. Writing RESET_START register will cause the target
same effect as "power reset". In addition to, in this case,...

SBP-2 E.4 >Any target resources allocated to the ORB should be released by
thetarget.

...so, ORB_POINTER is unusable to examine the last ORB which
was consumed. Thus this initiator shall ask the target to report the last
ORB
address utilizing higher level command sounds like "TRANSPORT_I2T_ABORT".

-------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp

> -----Original Message-----
> From:	Greg Shue [SMTP:gregs@sdd.hp.com]
> Sent:	Wednesday, August 05, 1998 11:20 AM
> To:	Nagasaka Fumio
> Cc:	p1394@pwg.org
> Subject:	Re: P1394> Revised PWG1394 Cmd Set
> 
> 
> Fumio Nagasaka wrote:
> > 
> > Greg Shue wrote:
> > >
> > >Fumio Nagasaka wrote:
> > >
> > >> 3.1. TRANSPORT_I2T_ABORT
> > >> 	An initiator requests a target to stop ORB fetching, 
> > >> 	and solicits the target to reply STATUS block when
> > >> 	the last ORB had been executed.
> > >
> > >I probably don't understand this one.
> > >
> > >  Since we're using the UNORDERED model, all the ORBs on the
> > >  task list have been fetched by the target as soon as they
> > >  are placed on it.  There is no point to issuing this command.
> > >
> > >  This command would really need to be issued as a vendor-specific
> > >  Management Agent command, since it needs to be executed
> > >  asynchronously to the two ordered execution queues or
> > >  else a third queue needs to be defined.
> > >
> > >  Using the ABORT TASK management function defined by SBP-2
> > >  beginning with the last task in the queue will do the same
> > >  thing if you want a queue-specific function.  
> > >
> > >I don't think this provides any additional usefulness and
> > >significantly changes the device model.  What am I missing?
> > >
> > You are missing one point;
> > Let me come back to your first note.
> > 
> > Greg Shue wrote:
> > 
> > GS>
> > GS>Now, error recovery for when a target detects an ACK Timeout on a
> > GS>Status FIFO write requires some special considerations.  When
> > GS>this condition happens the initiator and target may be
> > GS>out-of-sync with each other, and the SBP-2 protocol does not
> > GS>provide a mechanism for the initiator to determine that the
> > GS>condition exists.  The problem breaks down to two issues:
> > 
> > SBP-2 protocol *does* provide a mechanism to show this status.
> > An AGENT_STATE register has two bit to describe status.
> > 
> > In this case "SBP-2 Specification Rev.4" is saying, the fetch agent
> > shall transition to state DEAD. See page 62 "Transition Any:F5".
> > The only way to recover from this state, the initiator need to
> > write data on AGENT_RESET register.
> 
> Good point, but that status requires the intiator go look for it.
> How will the initiator know to go look for it?
> 
> Here's another one for consideration:
> 
>   Since a fetch agent may be processing transactions for multiple
>   Tasks simultaneously (since split-transactions), which ORB is
>   the ORB_POINTER supposed to reference?  And when is it set?
>   SPB-2 Rev 4 doesn't say.  It really is written to a sequential
>   execution model.
> 
>   SBP-2 Rev 4, p 62 also says (just above State F5:)  The fetch
>   agent __may__ also be instructed to transition to the dead
>   state as a result of an error in command execution detection by
>   the device server.
> 
> If the SBP-2 target driver provides a hook to transition the
> fetch agent to the DEAD state at any point in time, and if the
> ORB_POINTER value is provided in that interface, then we might be
> able to use the ORB_POINTER register.  Unfortunately, I'm not
> sure if this functionality is a requirement.
> 
> > Your scenario cause an impression that the target device shall
> > be responsible for recovery. However, SBP-2 specification requires
> > the initiator to be responsible in this case.
> 
> I don't see it as the target is responsible for _recovery_, but
> it is responsible for _detection_ and _indication_.  A Bus Reset
> by itself doesn't recover from the situation, it just indicates
> that something is drastically wrong.
> 
> The problem we have is how to get the initiator to take any sort
> of recovery action.  SBP-2 expects that this will be detected by
> some mechanism independent of the 'target' module.  The expected
> mechanism is a timeout.  At the May PWG 1394 meeting (?), another
> mechanism of Bus Reset was suggested.
> 
> Any other suggestions?
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------

From gregs at sdd.hp.com  Wed Aug  5 17:18:31 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Revised PWG1394 Cmd Set
In-Reply-To: <01376112D7AFD011911E0020AF70BEC51163C0@cpuex1.ued.epson.co.jp> from "Nagasaka Fumio" at Aug 5, 98 12:34:19 pm
Message-ID: <199808052118.OAA00831@hpsdlgj1.sdd.hp.com>


Fumio Nagasaka wrote:
> In my idea, a print spooler in the initiator shall detect time out.

That's fine if the initiator's transport client is a print spooler,
but what about other higher layer apps such as:
   a Status/Event Monitor?
   a file transfer protocol?
   a scanning app?

We're working on a generic protocol.  I don't want to impose any
more requirements on the application than does TCP.  TCP itself
takes care of timeout/lost link detection.  I think this protocol
should also.  Once detection by the initiator's protocol driver is
taken care of, then recovery is easy.  Have we now ended up with
a case where the initiator's side needs to poll for FETCH_AGENT status
or do we let the node hosting the target side generate a Bus Reset?

> SBP-2 E.4 >Any target resources allocated to the ORB should be released by
> thetarget.
> 
> ...so, ORB_POINTER is unusable to examine the last ORB which
> was consumed. Thus this initiator shall ask the target to report the last
> ORB
> address utilizing higher level command sounds like "TRANSPORT_I2T_ABORT".

I don't think so.  The ORB_POINTER register can still point to
the offending ORB.  The ORB itself can no longer be referenced
by the target.  Since it is in the initiator's memory space, the
initiator can still examine it.

-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From Nagasaka.Fumio at exc.epson.co.jp  Wed Aug  5 22:14:34 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Revised PWG1394 Cmd Set
Message-ID: <01376112D7AFD011911E0020AF70BEC51163D8@cpuex1.ued.epson.co.jp>

	Fumio Nagasaka wrote:
> In my idea, a print spooler in the initiator shall detect time out.

OK, forget my brain damaged idea. But still we don?t have cool answers.
Any session layer beyond SBP-2 can detect this error. Then what shall we do?
Examining ORB_POINTR requires an initiator to do effort as same as
issuing a transport command. Doesn?t it?

--------------------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to  <mailto:nagasaka.fumio@exc.epson.co.jp> nagasaka.fumio@exc.epson.
co.jp

	-----Original Message-----
	From:	Greg Shue [SMTP:gregs@sdd.hp.com]
	Sent:	Thursday, August 06, 1998 6:19 AM
	To:	Nagasaka Fumio
	Cc:	p1394@pwg.org
	Subject:	Re: P1394> Revised PWG1394 Cmd Set


	Fumio Nagasaka wrote:
	> In my idea, a print spooler in the initiator shall detect time
out.

	That's fine if the initiator's transport client is a print spooler,
	but what about other higher layer apps such as:
	   a Status/Event Monitor?
	   a file transfer protocol?
	   a scanning app?

	We're working on a generic protocol.  I don't want to impose any
	more requirements on the application than does TCP.  TCP itself
	takes care of timeout/lost link detection.  I think this protocol
	should also.  Once detection by the initiator's protocol driver is
	taken care of, then recovery is easy.  Have we now ended up with
	a case where the initiator's side needs to poll for FETCH_AGENT
status
	or do we let the node hosting the target side generate a Bus Reset?

	> SBP-2 E.4 >Any target resources allocated to the ORB should be
released by
	> thetarget.
	> 
	> ...so, ORB_POINTER is unusable to examine the last ORB which
	> was consumed. Thus this initiator shall ask the target to report
the last
	> ORB
	> address utilizing higher level command sounds like
"TRANSPORT_I2T_ABORT".

	I don't think so.  The ORB_POINTER register can still point to
	the offending ORB.  The ORB itself can no longer be referenced
	by the target.  Since it is in the initiator's memory space, the
	initiator can still examine it.

	-- 
	Greg Shue
	Hewlett-Packard Company
	All-in-One Division			        gregs@sdd.hp.com
	----------------------------------------------------------------

From gregs at sdd.hp.com  Thu Aug  6 12:45:09 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Revised PWG1394 Cmd Set
In-Reply-To: <01376112D7AFD011911E0020AF70BEC51163D8@cpuex1.ued.epson.co.jp> from "Nagasaka Fumio" at Aug 6, 98 11:14:34 am
Message-ID: <199808061645.JAA06132@hpsdlgj1.sdd.hp.com>


Fumio Nagasaka wrote:
> > In my idea, a print spooler in the initiator shall detect time out.
> 
> OK, forget my brain damaged idea. But still we don$B!G(Jt have cool answers.
> Any session layer beyond SBP-2 can detect this error. Then what shall we do?
> Examining ORB_POINTR requires an initiator to do effort as same as
> issuing a transport command. Doesn$B!G(Jt it?

I wouldn't call it "brain damaged", just focused on a narrow
application space.  :-)

Issuing a transport command is much more intrusive to the system
than examining the AGENT_STATE and ORB_POINTER registers, because
it now requires it's own sequence number, and it can't be put on
the queue until the condition is corrected!

So, just for review:

  - Any identified errors other than a lost Ack on a status FIFO write
    either have a retry alogrithm described in SBP-2, or cause
    a status FIFO write to report the error.

  - All identified errors cause the Fetch Engine to transition to
    the DEAD state, and cause the entire task set to be cleared.

  - Because we are dealing with parallel-execution rather than
    just out-of-order, we must clarify what value ends up in the
    ORB_POINTER register when the Fetch Engine is in the DEAD state.

  ? The process used by an initiator to recover when it finds
    the Fetch Engine in the DEAD state without a cause written to
    the status FIFO is to construct a linked list of the pending
    ORBs and queue it up on the Task List.

  - Because the PWG Transport Requirements identify the transport as
    "reliable" and "Connection-oriented" and the undocumented transport
    model is TCP, the following options come to mind:

      1) The stall detection could be left up to the Transport
	 Client.  Any clients which do not provide this detection
	 (via a timeout) would get hung in this condition until
	 something caused a Bus Reset.

      2) The stall detection could be handled by the initiating
	 node's PWG protocol layer.  It could either be done by:
           - a timeout (negotiated reconnect interval?) on target
             activity, causing the initiator to look at the
             AGENT_STATE register.
           - the target's node generating a Bus Reset
           - ???

I believe strongly that this detection should NOT be forced on
the Transport Client or above.  I also believe that human
intervention must not be required to recover from this condition.
Any target inactivity detection must occur within a
target-dependent timeout, because different functions and
technologies have different constraints.  (e.g.  ink jet dry
times, scanner bulb color stability, media sitting over fusers.)

Can somebody model or better yet measure the frequency of this error?
If it really is extreemely low, then let's just let the target
node generate a Bus Reset.  Otherwise let's put in a heart-beat
write to the Status FIFO using Unsolicited Status.

I think we need to choose one at the next meeting and be done
with it.  We're only looking for a solution for the first
revision of this protocol.

-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From shimura at pure.cpdc.canon.co.jp  Fri Aug  7 06:14:31 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Revised PWG1394 Cmd Set
In-Reply-To: <199808061645.JAA06132@hpsdlgj1.sdd.hp.com>
References: <01376112D7AFD011911E0020AF70BEC51163D8@cpuex1.ued.epson.co.jp> <199808061645.JAA06132@hpsdlgj1.sdd.hp.com>
Message-ID: <199808071014.TAA01352@origin.pure.cpdc.canon.co.jp>

Greg,

I think reading AGENT_STATE register (may be periodically) is very
similar to heart-beat, isn't it?

Because the error is (accidentally) occurred during the
communication between only two nodes, I think bus reset may be too
sacrificed for entire bus as a first recovery step.

Am I missing something?

Akihiro Shimura

On Thu, 6 Aug 1998 09:45:09 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:

> 
> Fumio Nagasaka wrote:
> > > In my idea, a print spooler in the initiator shall detect time out.
> > 
> > OK, forget my brain damaged idea. But still we don?t have cool answers.
> > Any session layer beyond SBP-2 can detect this error. Then what shall we do?
> > Examining ORB_POINTR requires an initiator to do effort as same as
> > issuing a transport command. Doesn?t it?
> 
> I wouldn't call it "brain damaged", just focused on a narrow
> application space.  :-)
> 
> Issuing a transport command is much more intrusive to the system
> than examining the AGENT_STATE and ORB_POINTER registers, because
> it now requires it's own sequence number, and it can't be put on
> the queue until the condition is corrected!
> 
> So, just for review:
> 
>   - Any identified errors other than a lost Ack on a status FIFO write
>     either have a retry alogrithm described in SBP-2, or cause
>     a status FIFO write to report the error.
> 
>   - All identified errors cause the Fetch Engine to transition to
>     the DEAD state, and cause the entire task set to be cleared.
> 
>   - Because we are dealing with parallel-execution rather than
>     just out-of-order, we must clarify what value ends up in the
>     ORB_POINTER register when the Fetch Engine is in the DEAD state.
> 
>   ? The process used by an initiator to recover when it finds
>     the Fetch Engine in the DEAD state without a cause written to
>     the status FIFO is to construct a linked list of the pending
>     ORBs and queue it up on the Task List.
> 
>   - Because the PWG Transport Requirements identify the transport as
>     "reliable" and "Connection-oriented" and the undocumented transport
>     model is TCP, the following options come to mind:
> 
>       1) The stall detection could be left up to the Transport
> 	 Client.  Any clients which do not provide this detection
> 	 (via a timeout) would get hung in this condition until
> 	 something caused a Bus Reset.
> 
>       2) The stall detection could be handled by the initiating
> 	 node's PWG protocol layer.  It could either be done by:
>            - a timeout (negotiated reconnect interval?) on target
>              activity, causing the initiator to look at the
>              AGENT_STATE register.
>            - the target's node generating a Bus Reset
>            - ???
> 
> I believe strongly that this detection should NOT be forced on
> the Transport Client or above.  I also believe that human
> intervention must not be required to recover from this condition.
> Any target inactivity detection must occur within a
> target-dependent timeout, because different functions and
> technologies have different constraints.  (e.g.  ink jet dry
> times, scanner bulb color stability, media sitting over fusers.)
> 
> Can somebody model or better yet measure the frequency of this error?
> If it really is extreemely low, then let's just let the target
> node generate a Bus Reset.  Otherwise let's put in a heart-beat
> write to the Status FIFO using Unsolicited Status.
> 
> I think we need to choose one at the next meeting and be done
> with it.  We're only looking for a solution for the first
> revision of this protocol.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------
> 

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

From gleclair at agentz.com  Tue Aug 11 03:17:10 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Web site update
Message-ID: <01BDC4BD.626E49E0.gleclair@agentz.com>




The latest update to the command set proposal has been posted to the web site.

http://www.pwg.org/p1394/

SBP-2 Transport Command Set Proposal - Rev. 0d [Shue]
ftp://ftp.pwg.org/pub/pwg/p1394/mtg081798/pwgcmd0d.pdf

I think this is on the top of the list for agenda items in Toronto.

Any other topics people would like to add to the agenda?

Please advise.

Thanks,
Greg




From shimura at pure.cpdc.canon.co.jp  Tue Aug 11 21:02:16 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Document for Error Recovery supporting GAP (Was Re: ABORTED - UNEXPECTED ...)
In-Reply-To: <199807310541.OAA09620@origin.pure.cpdc.canon.co.jp>
References: <199807201705.KAA25407@hpsdlgj1.sdd.hp.com> <199807310541.OAA09620@origin.pure.cpdc.canon.co.jp>
Message-ID: <199808120102.KAA02877@origin.pure.cpdc.canon.co.jp>

Hello, All,

I have made a model and example document for the error recovery
model supporting abort task gap.

Though new command set proposal contains similar descriptions, I
feel yet another explanation especially for a corner case may help
understanding.

Because I will not be able to attend Toronto meeting, Ueda-san from
Canon will explain the model.

Please find attached document.

Regards,

Akihiro Shimura

On Fri, 31 Jul 1998 14:41:26 +0900 (JST)
Akihiro Shimura <shimura@pure.cpdc.canon.co.jp> wrote:

> Because descriptive explanation may make it hard to be well
> understood, I am preparing some slides for explanation.
> 
> Ueda-san from Canon will make a presentation for this alternative
> model at upcoming Toronto meeting.

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: SeqIdGap.pdf
Type: application/octet-stream
Size: 29910 bytes
Desc: not available
Url : http://www.pwg.org/archives/p1394/attachments/19980812/b2073913/SeqIdGap-0001.obj
From gregs at sdd.hp.com  Tue Aug 11 21:16:22 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Document for Error Recovery supporting GAP (Was Re: ABORTED - UNEXPECTED ...)
In-Reply-To: <199808120102.KAA02877@origin.pure.cpdc.canon.co.jp> from "Akihiro Shimura" at Aug 12, 98 10:02:16 am
Message-ID: <199808120116.SAA06911@hpsdlgj1.sdd.hp.com>



I'm sorry to find out that you won't be at the next meeting.
Thank you for the additional document and presentation.
I am depending on them to fill out the error recovery
portion of the command set proposal.

> Hello, All,
> 
> I have made a model and example document for the error recovery
> model supporting abort task gap.
> 
> Though new command set proposal contains similar descriptions, I
> feel yet another explanation especially for a corner case may help
> understanding.
> 
> Because I will not be able to attend Toronto meeting, Ueda-san from
> Canon will explain the model.
> 
> Please find attached document.
> 
> Regards,
> 
> Akihiro Shimura


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From gleclair at agentz.com  Thu Aug 13 02:38:54 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:52 2009
Subject: FW: P1394> Web site update - alternate location
Message-ID: <01BDC64A.5F191200.gleclair@agentz.com>

Sorry if you have not been able to get the Command set doc from the PWG web server.

I placed a copy of the file in a temporary location on an alternate server.

The URL is: http://www.agentz.com/1394pwg/pwgcmd0d.pdf

Please let me know if you have problems.

Greg



-----Original Message-----
From:	Gregory LeClair [SMTP:gleclair@agentz.com]
Sent:	Tuesday, August 11, 1998 12:17 AM
To:	'1394 PWG'
Subject:	P1394> Web site update




The latest update to the command set proposal has been posted to the web site.

http://www.pwg.org/p1394/

SBP-2 Transport Command Set Proposal - Rev. 0d [Shue]
ftp://ftp.pwg.org/pub/pwg/p1394/mtg081798/pwgcmd0d.pdf

I think this is on the top of the list for agenda items in Toronto.

Any other topics people would like to add to the agenda?

Please advise.

Thanks,
Greg




From shimura at pure.cpdc.canon.co.jp  Thu Aug 13 06:01:03 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:52 2009
Subject: P1394> T2I Recovery Enhancement Proposal Document (Was Re: MAX_?2?_DATA_SIZE)
In-Reply-To: <199807310520.OAA09352@origin.pure.cpdc.canon.co.jp>
References: <199807271626.JAA22234@hpsdlgj1.sdd.hp.com> <199807310520.OAA09352@origin.pure.cpdc.canon.co.jp>
Message-ID: <199808131001.TAA28640@origin.pure.cpdc.canon.co.jp>

Hello, All,

I've made a recovery enhancement proposal document for
TRANSPORT_T2I_DATA command and its parameter to clarify the model.
This document also contains brief example usage.

Ueda-san from Canon will explain this model at Toronto meeting on
my behalf, too.

Please find attached document.

Regards,

Akihiro Shimura

On Fri, 31 Jul 1998 14:20:20 +0900 (JST)
Akihiro Shimura <shimura@pure.cpdc.canon.co.jp> wrote:

> Thank you for the explanation.
> 
> I am now a little clear on this topic (, I hope).
> 
> Originally, it was very questionable for me that the target must
> resend the "entire" buffer though the target is sending data over
> very reliable (acknowledged) 1394 transactions.
> 
> If the initiator can keep the contents of buffer, the target only
> needs to resend outstanding transaction(s).
> I thought this avoids redundant re-transmission on the wire while
> allowing utilization of buffer beyond the target resource.
> 
> Whether the initiator keeps the contents of buffer or not depends on
> the underlying implementation on the initiator (i.e. interpretation
> on the buffer's "direction" bit set to one).
> 
> So I would like to propose an enhancement to the recovery model based
> on the "MAX_T2I_DATA_SIZE" to take advantage of shared memory model
> while keeping independence of implementations.
> 
> The enhancement is based on negotiated MAX_T2I_DATA_SIZE reflecting
> initiator's preference.
> 
> The definition of MAX_T2I_DATA_SIZE will look like following;
> 
>   MAX_T2I_DATA_SIZE provided by the target indicates the maximum unit
>   of target-to-initiator data the target can guarantee to hold and
>   re-send in case of recovering requeued TRANSPORT_T2I_DATA command.
>   Initiator may set this parameter value smaller than the value
>   provided by the target. The value zero specified by the initiator
>   indicates that the target needs not to guarantee to hold and
>   re-send data beyond 1394 transaction.
>   Target shall guarantee to hold and re-send data up to this
>   (negotiated) parameter size.
>   Responsibility to hold the contents of buffer beyond this parameter
>   size belongs to the initiator.
>   The initiator shall avoid to issue TRANSPORT_T2I_DATA command which
>   has associated buffer larger than this parameter in case that the
>   buffer contents may not be held.
>  
> Though this enhancement will not be optimal in the spirit of shared
> memory model, I think almost the same result will be derived by this
> enhancement.
> 
> Ueda-san from Canon will make a presentation on this enhancement at
> upcoming Toronto meeting.
> 
> BTW, MAX_I2T_DATA_SIZE parameter seems not to be useful at all for
> both ends, and should be gone. Any objections?
> 
> Akihiro Shimura

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: MaxT2Isz.pdf
Type: application/octet-stream
Size: 8678 bytes
Desc: not available
Url : http://www.pwg.org/archives/p1394/attachments/19980813/31f55746/MaxT2Isz-0001.obj
From fumiona at venus.dti.ne.jp  Tue Sep  1 12:15:55 1998
From: fumiona at venus.dti.ne.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:52 2009
Subject: P1394> 1394 Timers?
In-Reply-To: <H0000d930fdb0c80@MHS>
References: <H0000d930fdb0c80@MHS>
Message-ID: <199809011610.BAA03465@smtp1.dti.ne.jp>

Hanging read ORB release timer;

When an initiator assume a target will reply 500 bytes,
but the target device only replies 300 bytes, then this
input ORB will not be completed. The initiator is waiting
for 200 bytes as rest of the contents. If we do not have
any timer to detect this situation and if the transport
layer software does not resolve hanging ORB to avoid input
pipe stalling, a higher level client software need to solve
this problem.

One possible solution for the problem is that the transport
software of the target fills padding data (null data) when
this timer over runs, and the target force to complete this
input ORB, and also the target shall reply the valid length
of data in the input buffer.

However I do not feel that we need to define this timer.

Because I prefer to design a predictable transport like CBT.
If we choose a CBT style solution, the target may ask the
initiator to provide credit to receive data from the target.
Then the target sends a packet which contains length field
of valid data length and real data itself.  Thus I believe
timer design depends upon whether we can define predictable
transport or not. Actually IEEE 1284.4 does not require to
have this sort of timer, because it does not need to assume
a communication pipe to be stalled.

Fumio

Alan wrote:
>August 25, 1998
>
>This is a call for discussion on Timers for the 1394 Image Profile.
>At the last meeting we attempted to address this issue and only identified 3 
>timers. Are there others we missed? Please submit comments and suggestions.
>
>1) Reconnect Timer - This one is taken care of by SBP-2 as part of the Login 
>process.
>
>2) Management ORB Timer - When the Initiator writes a Management ORB address to 
>the Management Agent Register, how long should it wait for a response to be 
>written to the management ORBs status fifo? How is the timeout value determined 
>and communicated?
>
>3) Abort Task Set Timer - An Abort Task Set may issued by an Initiator in 
>response to Target Inactivity. How is the timeout value determined and 
>communicated?
>
>Any other timers that we did not include at the last meeting?
>
>
>

---
Fumio Nagasaka
EPSON Software Deveopment Lab., Inc.
voice: +81 268 25-4111

From fumiona at venus.dti.ne.jp  Wed Sep  2 11:41:51 1998
From: fumiona at venus.dti.ne.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:52 2009
Subject: [PP1394:00315] Re: P1394> 1394 Timers?
In-Reply-To: <199809011657.JAA04024@hpsdlgj1.sdd.hp.com>
References: <199809011657.JAA04024@hpsdlgj1.sdd.hp.com>
Message-ID: <199809021536.AAA28437@smtp1.dti.ne.jp>

Thank you Greg,

>Incidently, this transport should already be as predictable as
>1284.4.

This is the answer I was waiting for.
If 1394 PWG transport is as predictable as 1284.4,
then we shall remove descriptions which are describing
two queues model in 1394 PWG profile. Because these
descriptions are implementation issue and beyond the
specification. In addition to this, if our transport
is as predictable as 1284.4, then why do we need to describe
something about two queues model. The forward direction
(I to T) transaction and the reverse direction (T to I)
transaction will not be stalled. If so, we do not need
to assume a target to have two independent queues.

Also 1394 PWG profile describes in "1. Scope".
(reformatted)
>This document specifies the communications profile and device
>communications command set for imaging devices attached to
>the IEEE 1394 High Speed Serial Bus.

>SBP-2 provides multiple, concurrent, independent connections
>which do not preclude concurrent operation of other protocol
>stacks; is data, application, and OS independent In order
>to meet the requirements for imaging devices, SBP-2 must be
>supplemented by a device profile, which specifies:

>Information supplemental to the IEEE 1394 and SBP-2
>specifications are provided in this document.
> * a policy to be used for maintaining device access across
>   "transient" link interruptions
> * a model of use for maintaining guaranteed, in-order data
>   deliver across "transient" link interruptions
> *a command set which supports
>      * independent, bi-directional, half-duplex communication
>      * data tagging of an associated data payload
>      * ability for either end of a connection to close the
>        connection at any time

The current command set does not meet the scope of 1394
PWG profile. Because the command set does not allow for
either end of a connection to close the connection at
any time. Also the current command set does not describe
the way to support multiple host connectivity. Actually
when a host A is printing to a target B utilizing LUN #1,
then the other host C cannot login to receive status of
the target B. Or the fetch agent of the target B shall
implement multiple login capability to allow the host C
to login to receive status, while the host A is printing.

I felt only two commands;
   - TRANSPORT_I2T_DATA
   - TRANSPORT_T2I_DATA
is required to develop data link layer for printing. And
any OS vender may use IEEE P1284.4 or MLC 3.x over this
data link layer to make a predictable multiple logical
channel supportive transport layer. I beleive 1284.4 is
beyond the specification of 1394 PWG command set. But 1394
PWG cannot forbid any OS vender to use 1284.4 over the data
link layer defined by 1394 PWG. Why do we need to define
something quite new from scratch? IEEE P1284.4 is one of
the excellent result from our PWG and it is very new.

I had experienced my proposal 1284.4 over SBP-2 was
eliminated through 1394 PWG discussion. Thus I realized
we need to define something better than 1284.4. However
for me, current commands set seems to be more poor than
1284.4.

                  |  1284.4      |  1394 PWG cmd set  |
------------------|--------------|--------------------|
Multiple Logical  |     YES      |         NO         |
   channels       |              | or YES/w LUNs      |
open/close from   |     YES      |         NO         |
     both peer    |              |                    |
predicatble       |     YES      |         YES        |
API for WinSock2  |     YES      |         NO         |
standardization   | 99% ALREADY  |       NOT YET      |
Multi Host support|      NO      |         NO         |
                  |or YES/w LUNs | or YES/w LUNs      |
------------------------------------------------------|

The chair man shall drive our discussion to clear pros/cons
of these idea;
1) something already existing over SBP-2 as data link
2) new command set now we are discussing over SBP-2

And 1394 PWG profile shall clear the method to support
multiple hosts connectivity. Design for the timer is
less priority. We will be able to define timer
requirements later, when we've got a real model of
transaction.

I don't feel my opinion bring us several month back to
the confusion. If the current model is not suitable for
current protocol driver provided in existing consumer PC OS,
we need to pay great effort to develop new device drivers.
And these effort will easily take several months to write,
to test and to debug new software. May be, my job becomes
more busy as code developer. :-) Thus we shall choose better
way to ship real products into the market.


Greg wrote:
>
>Fumio!  Are you serious about this timer?  You know as well as I
>do that:
>
>  - There is no need for the target to send all the data
>    requested by the initiator before completing the request,
>    since the _residual_ field will indicate the difference.
>    Padding bytes are not necessary.
>
>(and as discussed at the August meeting and a bit on the
>reflector(?))
>  - The target is at liberty to complete the ORB at it's
>    own discretion.  Since there is no reason for the
>    transport to hold it open for long periods of time
>    after it has moved some data, it should complete it
>    soon after moving all the data which was pending.
>
>This means there is no _need_ for a hanging read ORB timeout at
>the transport layer.  If one happened to be used, then it would
>need to be sensitive to the expected completion time of an ORB.
>Since the transport specifies a hanging TRANSPORT_T2I_DATA ORB to
>exist at all times, this ORB may not be completed for hours.  If
>this is a problem with current SBP-2 implementations, then we
>need to raise that issue.
>
>Incidently, this transport should already be as predictable as
>1284.4.
>
>If an initiator-side application is expecting "500" bytes to be
>returned by the target, and wishes to maintain a timeout for that
>transfer, then this is beyond the scope of the transport.
>
>- Greg Shue, HP
>
>Fumio wrote:
>> Hanging read ORB release timer;
>> 
>> When an initiator assume a target will reply 500 bytes,
>> but the target device only replies 300 bytes, then this
>> input ORB will not be completed. The initiator is waiting
>> for 200 bytes as rest of the contents. If we do not have
>> any timer to detect this situation and if the transport
>> layer software does not resolve hanging ORB to avoid input
>> pipe stalling, a higher level client software need to solve
>> this problem.
>> 
>> One possible solution for the problem is that the transport
>> software of the target fills padding data (null data) when
>> this timer over runs, and the target force to complete this
>> input ORB, and also the target shall reply the valid length
>> of data in the input buffer.
>> 
>> However I do not feel that we need to define this timer.
>> 
>> Because I prefer to design a predictable transport like CBT.
>> If we choose a CBT style solution, the target may ask the
>> initiator to provide credit to receive data from the target.
>> Then the target sends a packet which contains length field
>> of valid data length and real data itself.  Thus I believe
>> timer design depends upon whether we can define predictable
>> transport or not. Actually IEEE 1284.4 does not require to
>> have this sort of timer, because it does not need to assume
>> a communication pipe to be stalled.
>> 
>> Fumio
>> 
>> Alan wrote:
>> >August 25, 1998
>> >
>> >This is a call for discussion on Timers for the 1394 Image Profile.
>> >At the last meeting we attempted to address this issue and only identified 3 
>> >timers. Are there others we missed? Please submit comments and suggestions.
>> >
>> >1) Reconnect Timer - This one is taken care of by SBP-2 as part of the Login 
>> >process.
>> >
>> >2) Management ORB Timer - When the Initiator writes a Management ORB address to 
>> >the Management Agent Register, how long should it wait for a response to be 
>> >written to the management ORBs status fifo? How is the timeout value determined 
>> >and communicated?
>> >
>> >3) Abort Task Set Timer - An Abort Task Set may issued by an Initiator in 
>> >response to Target Inactivity. How is the timeout value determined and 
>> >communicated?
>> >
>> >Any other timers that we did not include at the last meeting?
>> >
>> >
>> >
>> 
>> ---
>> Fumio Nagasaka
>> EPSON Software Deveopment Lab., Inc.
>> voice: +81 268 25-4111
>> 
>
>
>-- 
>Greg Shue
>Hewlett-Packard Company
>All-in-One Division			        gregs@sdd.hp.com
>----------------------------------------------------------------
>

---
Fumio Nagasaka
EPSON Software Deveopment Lab., Inc.
voice: +81 268 25-4111

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Wed Sep  2 11:51:32 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:52 2009
Subject: P1394> November PWG Meeting
Message-ID: <H0000d930fe74147@MHS>

Hello PWG Members,

I have started planning our Meetings in November.

Unfortunately the meeting space in Phoenix was limited and the one Hotel 
that did have rooms, was not willing to accommodate our billing process.

The good news is that I was able to secure space at the Tucson Marriott 
University Park in Tucson Arizona (still in the southwest near Phoenix and 
closer to Nogales).
http://www.marriott.com/marriott/TUSUP/

Also it seems that the southwest is popular in November, I think a lot of folks 
like to get away from the Snow, so we would do well to make reservations early.

I should have more details in the next week or two.
Feel free to ping now if you want, with the usual information

Name:
Meetings you will attend:
If staying at the Marriott: Arrival & Departure Date

Regards,
Alan



From fumiona at venus.dti.ne.jp  Wed Sep  2 21:54:46 1998
From: fumiona at venus.dti.ne.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:52 2009
Subject: [PP1394:00329] Re: P1394> 1394 Timers?
In-Reply-To: <199809021710.KAA24412@hpsdlgj1.sdd.hp.com>
References: <199809021710.KAA24412@hpsdlgj1.sdd.hp.com>
Message-ID: <199809030149.KAA24771@smtp1.dti.ne.jp>

At first, my proposal 1284.4 over SBP-2 was eliminated by
voting in this January. Thus I will not suggest same idea
again. In February meeting I actually realized my idea was
bad and I stopped to say 1284.4 over SBP-2. So I did other
effort to edit WhitePaper to show existing 1394 driver
structure in a consumer PC OS. And 1284.4 design discussed
in different PWG group is obviously beyond the 1394 PWG
command set specification.

I am just saying one existing transport design seems to be
better than current 1394 PWG commands set. We need to do
more effort. If someone improve the design and persuade me
to realize 1394 command set is better, I willingly agree
with the idea. If not, my idea is the 1394 PWG command set
shall be a data link layer to be utilized with other
transport command set.

For example, usb printing class design seems to be providing
something convenient data link layer which is flexible to
meet higher protocol layer. I am not sure whether someone
had developed already, but may be someone can apply 1284.4
over usb printing class. Usb printing class design is
providing two bi-directional communication queue, bulk-in,
bulk-out and default pipe. And one bi-directional queue is
applicable for data session and the other is applicable for
transport control. One bi-directional communication pipe may
be enough to meet 1284.4. But in this thread, I have no
urge to say something about usb, thus I will stop to say more
about usb in here. I prefer 1394 :-)

Greg Shue wrote:
>Let's look at some other characteristics:
>  effecient:            LESS                |  MUCH MORE
>  -> Bus Utilization:  low to moderate      |  high
>                       (credit pkts aren't) |
>  -> Max size transfer:  64KBytes           | 2 GBytes - 1

I agree with you, but 64kB is max_length of one packet
delivered from a peer to the other peer. The title "Max size
transfer" may cause misunderstanding for someone who are
subscribing our reflector without knowledge about 1284.4.

>  -> Max amt of data
>     queuable:           as much memory as     max (negotiated) size
>                         allocated by device   transfer * MAX_TASK_SET_SIZE - 1

Ok, if you say "queeable", the max size queuable in memory
cannot exceed max size of memory allocated by Operating System.
Thus your description is misleading the discussion.
Our scanner OS will not allocate 2 GB for queuable memory
space. :-) This is just a specification writing technique.

>                         for that connection
>  -> Processing overhead: MUCH MORE         | LESS

Agreed. Thank you! good pont.

>
>  Defined SBP-2           No                | Yes
>  command set

This is one benefit of 1284.4. IEEE P1284.4 is pure transport.
I mean 1284.4 is abstracted from any data link layer and it
does not have any dependency for data link design. If you
want to say your commands have some dependency for SBP-2
in words "defined SBP-2 command set", I feel it is better
to develop command set which does not have any dependency on
data link layer. We are defining transport layer.

>1284.4 is insufficient by itself as a data link.
>Without a description of an SBP-2 command set,
>target device model, Config ROM description,
>and model of use, you have an incomplete solution.

Let's clear the points;
I'm not saying I would like to use 1284.4 over SBP-2.
This idea was eliminated in February. I am saying that we
shall develop something better than 1284.4 to utilize
SBP-2, or something just a data link layer which is
applicable for transport protocol. But in later case
each vendor need to choose or develop higher layer to
apply this data link. Thus I prefer first idea. We shall
develop something more effective than 1284.4 to utilize
SBP-2. May be Greg is thinking current command set
is better thna aother, but I am thinking we need to pay
more effort to exceed even 1284.4.

>
>Fumio Nagasaka wrote:
>> >Incidently, this transport should already be as predictable as
>> >1284.4.
>> 
>> This is the answer I was waiting for.
>> If 1394 PWG transport is as predictable as 1284.4,
>> then we shall remove descriptions which are describing
>> two queues model in 1394 PWG profile. Because these
>> descriptions are implementation issue and beyond the
>> specification. In addition to this, if our transport
>> is as predictable as 1284.4, then why do we need to describe
>> something about two queues model. The forward direction
>> (I to T) transaction and the reverse direction (T to I)
>> transaction will not be stalled. If so, we do not need
>> to assume a target to have two independent queues.
>
>The services provided by the command set are the same as provided by a
>1284.4 connection.  Separate logins provide separate channels.
>The big question in my mind is how many services and instances
>are combined in one UNIT.  There is at least one path forward
>simply by defining each service instance is a separate unit.
>There may be other reasonable options.
>
>As far as predictability of the transport goes, you must not have
>done much debugging of 1284.4 communications.  The exact sequence
>of packets going across the wire is not predictable.  Neither is
>the sequence if IP packets going to an Ethernet node.
>
>The reason for providing the "two queues" descriptions on the command
>set is because we must describe how to use SBP-2 and what the contents
>of the CDB mean.  Removing the description of "two queues" from
>the profile is equivalent to removing the concept of "credit"
>from 1284.4.
>
>The "two queues" is a conceptual description.  There is nothing
>that requires that an implementation actually maintains two
>distinct queues.  It could do it using a single linked list
>and searching through the list each time.  It just must behave
>as though it were maintaining two distinct queues.  This description
>is what gives it some degree of predictability.
>
>As far as "stalling" goes, the I2T direction and T2I direction
>could be stalled simply by the initiator not providing ORBs.
>What is prevented is that the data flow will not be blocked by
>_other_ communication.
>
>> The current command set does not meet the scope of 1394
>> PWG profile. Because the command set does not allow for
>> either end of a connection to close the connection at
>> any time.
>
>The command set by itself could never meet the scope of the
>profile.  If it did, it would be the entire profile.
>
>In the command set, the concept of a "closed connection" is
>distinct from a "Logout".  The transport client within the target
>can "close" a connection (or either direction of a connection) at
>any time.  When an ORB is queued for a "closed" direction, that
>status is returned in the completion notification of the ORB.
>
>> Also the current command set does not describe
>> the way to support multiple host connectivity.
>
>That is beyond the scope of the command set.  The command set
>describes how to manage one connection.  Multi-host connectivity
>may be (and should be) addressed elsewhere in the profile.
>
>> Actually
>> when a host A is printing to a target B utilizing LUN #1,
>> then the other host C cannot login to receive status of
>> the target B. Or the fetch agent of the target B shall
>> implement multiple login capability to allow the host C
>> to login to receive status, while the host A is printing.
>
>This is beyond the scope of the command set.  Your example is
>true if the "status" service is done as a separate LUN instead of
>a separate service found in a different Unit directory.
>
>Also, I'd recommend using LUN #0 since it must be supported.  :-)
>
>> I felt only two commands;
>>    - TRANSPORT_I2T_DATA
>>    - TRANSPORT_T2I_DATA
>> is required to develop data link layer for printing. And
>> any OS vender may use IEEE P1284.4 or MLC 3.x over this
>> data link layer to make a predictable multiple logical
>> channel supportive transport layer.
>
>I would not recommend you using MLC 3.x for anything.  Using
>P1284.4 is an option, and we discussed this in the PWG many, many
>months ago and _voted_ against going that direction.  If you'd
>like to do independent work and present a written proposal at the
>next meeting, please feel free to, but that issue has been
>addressed.
>
>> I had experienced my proposal 1284.4 over SBP-2 was
>> eliminated through 1394 PWG discussion. Thus I realized
>> we need to define something better than 1284.4. However
>> for me, current commands set seems to be more poor than
>> 1284.4.
>> 
>>                   |  1284.4      |  1394 PWG cmd set  |
>> ------------------|--------------|--------------------|
>> Multiple Logical  |     YES      |         NO         |
>>    channels       |              | or YES/w LUNs      |
>
>And yes with multiple Units!
>
>> open/close from   |     YES      |         NO         |
>>      both peer    |              |                    |
>See above comment, the answer is YES for PWG, to exactly
>the same degree that it would be for 1284.4 over ??? over SBP-2.
>
>> predicatble       |     YES      |         YES        |
>> API for WinSock2  |     YES      |         NO         |
>When was this a transport requirement?
>
>> standardization   | 99% ALREADY  |       NOT YET      |
>OK, show me the standard document.
>
>> Multi Host support|      NO      |         NO         |
>>                   |or YES/w LUNs | or YES/w LUNs      |
>> ------------------------------------------------------|
>
>Let's look at some other characteristics:
>  effecient:            LESS                |  MUCH MORE
>  -> Bus Utilization:  low to moderate      |  high
>                       (credit pkts aren't) |
>  -> Max size transfer:  64KBytes           | 2 GBytes - 1
>  -> Max amt of data
>     queuable:           as much memory as     max (negotiated) size
>                         allocated by device   transfer * MAX_TASK_SET_SIZE - 1
>                         for that connection
>  -> Processing overhead: MUCH MORE         | LESS
>
>  Defined SBP-2           No                | Yes
>  command set
>
>> The chair man shall drive our discussion to clear pros/cons
>> of these idea;
>> 1) something already existing over SBP-2 as data link
>> 2) new command set now we are discussing over SBP-2
>
>I doubt the chair would re-open a closed issue without
>a written complete proposal.
>
>1284.4 is insufficient by itself as a data link.
>Without a description of an SBP-2 command set,
>target device model, Config ROM description,
>and model of use, you have an incomplete solution.
>
>> And 1394 PWG profile shall clear the method to support
>> multiple hosts connectivity. Design for the timer is
>> less priority. We will be able to define timer
>> requirements later, when we've got a real model of
>> transaction.
>
>We already have a real model of transaction.
>I haven't heard any other complaints about it.
>
>-- 
>Greg Shue
>Hewlett-Packard Company
>All-in-One Division			        gregs@sdd.hp.com
>----------------------------------------------------------------
>

---
Fumio Nagasaka
EPSON Software Deveopment Lab., Inc.
voice: +81 268 25-4111

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Thu Sep  3 17:20:37 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:52 2009
Subject: [PP1394:00331] Re: P1394> 1394 Timers?
In-Reply-To: <199809031635.JAA25392@hpsdlgj1.sdd.hp.com>
Message-ID: <H0000d930fe97ab5@MHS>

A non-text attachment was scrubbed...
Name: 1.txt
Type: application/octet-stream
Size: 2013 bytes
Desc: not available
Url : http://www.pwg.org/archives/p1394/attachments/19980903/e7f0d54e/1-0001.obj
-------------- next part --------------
     
Wow! I am lost in the drift of this whole thread?

Does any of this still actually address timers?

Can someone summarize the salient points in a new topic?

Is there anything actionable for the profile?

Help....

Alan

______________________________ Reply Separator _________________________________
Subject: Re: [PP1394:00331] Re: P1394> 1394 Timers?
Author:  gregs-at-sdd (gregs@sdd.hp.com) at HP-Roseville,mimegw3
Date:    9/3/98 9:36 AM


Fumio Nagasaka wrote:
> I am just saying one existing transport design seems to be 
> better than current 1394 PWG commands set. We need to do
> more effort. If someone improve the design and persuade me 
> to realize 1394 command set is better, I willingly agree
> with the idea. If not, my idea is the 1394 PWG command set 
> shall be a data link layer to be utilized with other
> transport command set.
     
When looking at a total solution, I don't see how the combination 
of (1284.4 + <data link cmd set> + SBP-2 + 1394) is "better"
than what we have currently defined.  The <data link cmd set> 
would be slightly simpler than our current proposal, but
it requires much more complexity to do 1284.4.  We'll end 
up with a much more efficient and lighter weight protocol.
     
> Greg Shue wrote:
> >  -> Max amt of data
> >     queuable:           as much memory as     max (negotiated) size
> >                         allocated by device   transfer * MAX_TASK_SET_SIZE -
 1
> 
> Ok, if you say "queeable", the max size queuable in memory
> cannot exceed max size of memory allocated by Operating System. 
> Thus your description is misleading the discussion.
> Our scanner OS will not allocate 2 GB for queuable memory 
> space. :-) This is just a specification writing technique.
     
In the case of SBP-2, the maximum size queuable on the Task List 
cannot exceed the max size of memory allocated by the initiator's 
operating system.  These are PCs with potentially lots of memory. 
In the case of 1284.4, the maximum size which can be transferred 
without having to issue credit is limited to the smallest amount 
dedicated at either end of the cable.  For the same configuration, 
would you rather have a 2 MB total limit or a 32 KB total limit?
     
> >
> >  Defined SBP-2           No                | Yes 
> >  command set
> 
> This is one benefit of 1284.4. IEEE P1284.4 is pure transport. 
> I mean 1284.4 is abstracted from any data link layer and it
> does not have any dependency for data link design. If you 
> want to say your commands have some dependency for SBP-2 
> in words "defined SBP-2 command set", I feel it is better
> to develop command set which does not have any dependency on 
> data link layer. We are defining transport layer.
     
Nope, we are defining a complete stack up through the transport 
layer.  This means we must also define the "data link" layer and 
how to glue them together.  Without an SBP-2 command set, there 
is no SBP-2 based solution.
     
> Let's clear the points;
> I'm not saying I would like to use 1284.4 over SBP-2.
> This idea was eliminated in February. I am saying that we 
> shall develop something better than 1284.4 to utilize
> SBP-2, or something just a data link layer which is 
> applicable for transport protocol. But in later case
> each vendor need to choose or develop higher layer to
> apply this data link. Thus I prefer first idea. We shall 
> develop something more effective than 1284.4 to utilize 
> SBP-2. May be Greg is thinking current command set
> is better thna aother, but I am thinking we need to pay 
> more effort to exceed even 1284.4.
     
I'll agree with the first option.  And I think we are already 
doing that.  Specifically, what do you think needs to be improved 
or addressed?
     
The second option is counter-productive.  We're trying to 
come up with standards here.
     
-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division                             gregs@sdd.hp.com 
----------------------------------------------------------------
From atsnaka at bsd.canon.co.jp  Thu Sep  3 20:18:30 1998
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:52 2009
Subject: [PP1394:00331] Re: P1394> 1394 Timers?
In-Reply-To: <199809031635.JAA25392@hpsdlgj1.sdd.hp.com>
References: <199809030149.KAA24771@smtp1.dti.ne.jp>
Message-ID: <4.0.1-J.19980904091453.00f1ad90@172.20.108.5>

While I was ctching up with the thread, 
I noticed that this is going out ONLY on the PWG-C reflector,
not p1394@pwg.org.

Is there something wrong with the PWG reflector (or my mailer) ?????

Ats

At 01:36 98/09/04 +0900, Greg Shue wrote:
> Fumio Nagasaka wrote:
> > I am just saying one existing transport design seems to be
> > better than current 1394 PWG commands set. We need to do
> > more effort. If someone improve the design and persuade me
> > to realize 1394 command set is better, I willingly agree
> > with the idea. If not, my idea is the 1394 PWG command set
> > shall be a data link layer to be utilized with other
> > transport command set.
> 
> When looking at a total solution, I don't see how the combination
> of (1284.4 + <data link cmd set> + SBP-2 + 1394) is "better"
> than what we have currently defined.  The <data link cmd set>
> would be slightly simpler than our current proposal, but
> it requires much more complexity to do 1284.4.  We'll end
> up with a much more efficient and lighter weight protocol.
> 
> > Greg Shue wrote:
> > >  -> Max amt of data
> > >     queuable:           as much memory as     max (negotiated) size
> > >                         allocated by device   transfer * MAX_TASK_SET_SIZE - 1
> > 
> > Ok, if you say "queeable", the max size queuable in memory
> > cannot exceed max size of memory allocated by Operating System.
> > Thus your description is misleading the discussion.
> > Our scanner OS will not allocate 2 GB for queuable memory
> > space. :-) This is just a specification writing technique.
> 
> In the case of SBP-2, the maximum size queuable on the Task List
> cannot exceed the max size of memory allocated by the initiator's
> operating system.  These are PCs with potentially lots of memory.
> In the case of 1284.4, the maximum size which can be transferred
> without having to issue credit is limited to the smallest amount
> dedicated at either end of the cable.  For the same configuration,
> would you rather have a 2 MB total limit or a 32 KB total limit?
> 
> > >
> > >  Defined SBP-2           No                | Yes
> > >  command set
> > 
> > This is one benefit of 1284.4. IEEE P1284.4 is pure transport.
> > I mean 1284.4 is abstracted from any data link layer and it
> > does not have any dependency for data link design. If you
> > want to say your commands have some dependency for SBP-2
> > in words "defined SBP-2 command set", I feel it is better
> > to develop command set which does not have any dependency on
> > data link layer. We are defining transport layer.
> 
> Nope, we are defining a complete stack up through the transport
> layer.  This means we must also define the "data link" layer and
> how to glue them together.  Without an SBP-2 command set, there
> is no SBP-2 based solution.
> 
> > Let's clear the points;
> > I'm not saying I would like to use 1284.4 over SBP-2.
> > This idea was eliminated in February. I am saying that we
> > shall develop something better than 1284.4 to utilize
> > SBP-2, or something just a data link layer which is
> > applicable for transport protocol. But in later case
> > each vendor need to choose or develop higher layer to
> > apply this data link. Thus I prefer first idea. We shall
> > develop something more effective than 1284.4 to utilize
> > SBP-2. May be Greg is thinking current command set
> > is better thna aother, but I am thinking we need to pay
> > more effort to exceed even 1284.4.
> 
> I'll agree with the first option.  And I think we are already
> doing that.  Specifically, what do you think needs to be improved
> or addressed?
> 
> The second option is counter-productive.  We're trying to
> come up with standards here.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------
>  
-----------------------------------------
Atsushi Nakamura
-----------------------------------------

BJ Technology Development 22,
Canon Inc.

53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211

tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------

From don at lexmark.com  Fri Sep  4 07:38:28 1998
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Test
Message-ID: <199809041139.AA03562@interlock2.lexmark.com>

I am testing the PWG's 1394 printing reflector..... please ignore.

Don



From gregs at sdd.hp.com  Wed Sep  2 13:47:16 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:52 2009
Subject: P1394> TARGET RESET & Unit/LU/Profile interactions
Message-ID: <199809021747.KAA25581@hpsdlgj1.sdd.hp.com>


Hi all,

At the end of the last meeting I agreed to raise the following
issue on the reflector...

One of the areas still requiring clarification is the mapping
of transport and target transport clients into SBP-2 Units and
Logical Units.  This is an area where the SCSI roots of SBP-2
have really impacted our efforts.

 - Looking at the draft SCSI-3 ARCHITECTURE MODEL -2 (SAM-2) rev
   0.3, I find that "Each SCSI-3 protocol standard shall specify
   the response to a target reset event including the conditions
   under which a target hard reset shall be executed.

 - Looking at SBP-2, rev 4, we find TARGET RESET affects all
   logged-in initiators (to any logical unit within the Unit).

Some questions which need to be answered are:

 a) How is TARGET RESET used by drivers n commercial operating
    systems?  (Both non-embedded and embedded?)
    
 b) Can we define how broadly (or narrowly) the TARGET RESET event
    affects a device using our transport?

    If so, how should it be defined?

    If not, does this mean that we must use one Unit directory
    for each possible instance of a service?

Ideas, anyone?



-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From fumiona at venus.dti.ne.jp  Mon Sep  7 11:08:46 1998
From: fumiona at venus.dti.ne.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:52 2009
Subject: [PP1394:00335] Re: P1394> 1394 Timers?
In-Reply-To: <199809040134.SAA12880@hpsdlgj1.sdd.hp.com>
References: <199809040134.SAA12880@hpsdlgj1.sdd.hp.com>
Message-ID: <199809071503.AAA21383@coral.ocn.ne.jp>

Thank you Greg, for your good summarizing,

Alan, Randy I was sorry may be you are confused as I
did not separate these two thread.

1. Timer issue
Greg explained the 1394 PWG transport is predictable
as same as CBT (Credit Based Transport). Thus I understood
a timer to detect a hanging read ORB is not required.
However the T to I transaction will easily be stalled
when the initiator does not provide any input ORBs.

Greg Shue:
> As far as "stalling" goes, the I2T direction and T2I direction
> could be stalled simply by the initiator not providing ORBs.
> What is prevented is that the data flow will not be blocked by
> _other_ communication.

Thus we at 1394 PWG shall describe a method to force an
initiator to provides ORBs without utilizing unsolicited
status from the target. Because some operating system does
not support this functionality.

2. Transport requirements

Greg Shue:
> I suggested that he create a written alternate proposal for the
> next PWG meeting, so that his concerns get raised.

Yes, I will.

Greg Shue and Fumio Nagasaka:
fn> gs>
fn> gs>  Defined SBP-2           No                | Yes
fn> gs>  command set
fn> 
fn> This is one benefit of 1284.4. IEEE P1284.4 is pure transport.
fn> I mean 1284.4 is abstracted from any data link layer and it
fn> does not have any dependency for data link design. If you
fn> want to say your commands have some dependency for SBP-2
fn> in words "defined SBP-2 command set", I feel it is better
fn> to develop command set which does not have any dependency on
fn> data link layer. We are defining transport layer.

gs>
gs> Nope, we are defining a complete stack up through the transport
gs> layer.  This means we must also define the "data link" layer and
gs> how to glue them together.  Without an SBP-2 command set, there
gs> is no SBP-2 based solution.

When we are defining a data link layer which is applicable
for other transport protocol,  then may be open/close/move
data I2T or move data T 2I/ are enough  functions  in this
layer. However if you say we are defining "a complete stack
up through the transport layer", then we shall provide
services to ease a session layer to find or to use facilities
provided in the 1394 PWG peripherals. So we shall provide
some higher service capability and functions abstracted
from SBP-2 transaction.

To give a simple example, "Universal Serial Bus (USB) Device
Class Definition for Printing Device" is defining two
interesting "Class Specific Requests" GET_DEVICE_ID and
GET_PORT_STATUS. The first request makes it easy for the
session layer to get 1284 PnP ID from a printer. The later
request fakes the session layer as if the transport is
providing a conventional 8 bit printer port. Actually
these requests are really usable for a PortMonitor developer
who is working for some existing PC OS(s).

A SBP-2/1394 PWG supportive printer provides 1284 PnP ID in a
configuration ROM. So a higher level protocol driver
may read textual descriptor from the configuration ROM.
But this method has a strong dependency for 1394 bus
system. If the transport layer protocol driver has a
function which reports 1284 PnP ID to higher level
protocol driver, the higher level protocol driver would
be abstracted from 1394 Bus system. And the printer
driver developer will be able to write a common session
layer program which covers both USB and SBP-2.

Still 40% of my mind is wondering these description
shown above seems to be inconsistent. Because still
I am not sure what Greg is saying as "a complete stack
up through the transport layer". It seems to be very
big scope. We shall just design a transport layer.



Greg Shue:
>
>> I agree. I'm lost too. I thought my previous email got lost....
>> 
>> Randy
>
>Welcome to topic drift ...
>
>The topic was timeouts.  No one has come up with any other ones
>than those listed by Alan, so no additional action items exist
>for the draft.
>
>In the course of discussion, Fumio expressed his concern that
>the current proposal is no better (or possibly even worse)
>than a 1284.4-based solution.  He also thought that we were
>defining a transport layer, rather than a transport stack.
>
>I suggested that he create a written alternate proposal for the
>next PWG meeting, so that his concerns get raised.
>
>
>-- 
>Greg Shue
>Hewlett-Packard Company
>All-in-One Division			        gregs@sdd.hp.com
>----------------------------------------------------------------
>

---
Fumio Nagasaka
EPSON Software Deveopment Lab., Inc.
voice: +81 268 25-4111

From hitoshis at MICROSOFT.com  Tue Sep  8 01:46:09 1998
From: hitoshis at MICROSOFT.com (Hitoshi Sekine)
Date: Wed May  6 14:00:52 2009
Subject: P1394> FW: Profile 24. Login
Message-ID: <FD8F41F04D35D111899600805F19A16C0642FC7D@RED-MSG-48>

> This statement is no longer true in NT5 as long as the device returns
> device_type 2 or 3.
> 
> 24 Login
> Microsoft has implemented their SBP-2 driver to do a login on power up and
> not logout until the PC is shut down. Though this is provided for within
> the SBP-2 specification, it requires devices, which may be shared among
> multiple PCs to support multiple logins to a single service, even if the
> different PCs cannot simultaneously use the service.
> 
> Can imaging devices (which want to take advantage of the shared nature of
> 1394) tolerate the resource requirements to operate on a multiple
> Microsoft O/S host configuration? 
> 
Thanks,
Hitoshi

From gregs at sdd.hp.com  Tue Sep  8 12:33:49 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:52 2009
Subject: P1394> PWG Profile Scope (was 1394 Timers?)
In-Reply-To: <199809071503.AAA21383@coral.ocn.ne.jp> from "Fumio Nagasaka" at Sep 8, 98 00:12:13 am
Message-ID: <199809081633.JAA18693@hpsdlgj1.sdd.hp.com>

Fumio Nagasaka:
> Thus we at 1394 PWG shall describe a method to force an
> initiator to provides ORBs without utilizing unsolicited
> status from the target. Because some operating system does
> not support this functionality.

We did.  We said it was required by the spec.  Any driver
which does not supply an outstanding TRANSPORT_T2I_DATA command
on an open (T2I) queue is non-compliant.

> 2. Transport requirements
> 
> Greg Shue:
> > I suggested that he create a written alternate proposal for the
> > next PWG meeting, so that his concerns get raised.
> 
> Yes, I will.
> 
> Greg Shue and Fumio Nagasaka:
> fn> gs>
> fn> gs>  Defined SBP-2           No                | Yes
> fn> gs>  command set
> fn> 
> fn> This is one benefit of 1284.4. IEEE P1284.4 is pure transport.
> fn> I mean 1284.4 is abstracted from any data link layer and it
> fn> does not have any dependency for data link design. If you
> fn> want to say your commands have some dependency for SBP-2
> fn> in words "defined SBP-2 command set", I feel it is better
> fn> to develop command set which does not have any dependency on
> fn> data link layer. We are defining transport layer.
> 
> gs>
> gs> Nope, we are defining a complete stack up through the transport
> gs> layer.  This means we must also define the "data link" layer and
> gs> how to glue them together.  Without an SBP-2 command set, there
> gs> is no SBP-2 based solution.
> 
> When we are defining a data link layer which is applicable
> for other transport protocol,  then may be open/close/move
> data I2T or move data T 2I/ are enough  functions  in this
> layer. However if you say we are defining "a complete stack
> up through the transport layer", then we shall provide
> services to ease a session layer to find or to use facilities
> provided in the 1394 PWG peripherals. So we shall provide
> some higher service capability and functions abstracted
> from SBP-2 transaction.

Or provide it in Config ROM.  Nothing says that it must be
done on top of SBP-2.

> A SBP-2/1394 PWG supportive printer provides 1284 PnP ID in a
> configuration ROM. So a higher level protocol driver
> may read textual descriptor from the configuration ROM.
> But this method has a strong dependency for 1394 bus
> system...

So does a 1284 negotiation for Device ID.
So does whatever process is necessary to extract the Device ID
from USB.  The "strong dependency" of the method is not
a reasonable argument.


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From don at lexmark.com  Mon Sep 14 15:26:47 1998
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Mailing Lists
Message-ID: <199809141927.AA13984@interlock2.lexmark.com>

The mailing lists are back up and running.  Just to test everything out, I have
sent this mail to ALL the mailing lists.  If you get this mail on one list and
not on another you think you should be on then I suggest you resubscribe by
sending e-mail to:

majordomo@pwg.org

with the body of the note containing

subscribe <list-name>

when <list-name> is the name of the list you wish to subscribe to.  You can
include multiple subscriptions in the same note.

Thanks for your patience during this transfer.

**********************************************
* Don Wright                 don@lexmark.com *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************




From gregs at sdd.hp.com  Mon Sep 14 16:13:46 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:52 2009
Subject: P1394> TARGET RESET & Unit/LU/Profile interactions
Message-ID: <199809142013.NAA18566@hpsdlgj1.sdd.hp.com>

Hi all,

At the end of the last meeting I agreed to raise the following
issue on the reflector...

One of the areas still requiring clarification is the mapping
of transport and target transport clients into SBP-2 Units and
Logical Units.  This is an area where the SCSI roots of SBP-2
have really impacted our efforts.

 - Looking at the draft SCSI-3 ARCHITECTURE MODEL -2 (SAM-2) rev
   0.3, I find that "Each SCSI-3 protocol standard shall specify
   the response to a target reset event including the conditions
   under which a target hard reset shall be executed.

 - Looking at SBP-2, rev 4, we find TARGET RESET affects all
   logged-in initiators (to any logical unit within the Unit).

Some questions which need to be answered are:

 a) How is TARGET RESET used by drivers n commercial operating
    systems?  (Both non-embedded and embedded?)
    
 b) Can we define how broadly (or narrowly) the TARGET RESET event
    affects a device using our transport?

    If so, how should it be defined?

    If not, does this mean that we must use one Unit directory
    for each possible instance of a service?

Ideas, anyone?



-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From gregs at sdd.hp.com  Mon Sep 14 18:01:36 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:52 2009
Subject: P1394> TARGET RESET & Unit/LU/Profile interactions
In-Reply-To: <35FD80BB.6A92296C@sharplabs.com> from "Randy Turner" at Sep 14, 98 01:46:52 pm
Message-ID: <199809142201.PAA18639@hpsdlgj1.sdd.hp.com>



"Should" doesn't matter, since the behavior of TARGET RESET is defined
by SBP-2, Rev 4, in section 10.4.4.  The problem is we are stuck with
the defined behavior.

- Greg S.

Randy Turner wrote:
> 
> Shouldn't a target reset from a particular initiator abort all existing login sessions that have been established from the initiator
> of the target reset to the target itself. Note I'm implying that other login sessions from other initiators would not be affected.
> Note this is our OWN transport semantics and might not apply to any other transport currently in use. The original logical unit and
> config information would not be changed (if it's ok to make that assumption).
> 


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From gregs at sdd.hp.com  Tue Sep 15 12:06:00 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:52 2009
Subject: P1394> TARGET RESET & Unit/LU/Profile interactions
In-Reply-To: <199809150508.WAA23993@mail.pacifier.com> from "Randy Turner" at Sep 14, 98 10:05:01 pm
Message-ID: <199809151606.JAA20589@hpsdlgj1.sdd.hp.com>


Discussions about how to map between units & logical units and
functions & services & service instances given this interaction,
and any other issues related to this behavior that I haven't
noted.  I was primarily raising awareness of the issue.

GregS

> 
> 
> If SBP-2 mandates what we do with a target reset, then I'm not sure what
> you are asking for in your original mail...(?)
> 
> Randy


-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Tue Sep 15 16:04:57 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:52 2009
Subject: P1394> 1394 PWG Spec rev 0.52
Message-ID: <H0000d930ff86d7e@MHS>

     Hello,
     
     The latest spec is out on the web. 
     
     I did the major edits, added the command set, and updated 
     the issues list.
     
     I did not finish all of the minor edits.
     
     I expect that we will review the spec and issues in Savannah.
     
     Also did not add config ROM.
     
     Get the spec now at ftp://www.pwg.org/pub/pwg-in
     
     regards,
     Alan


From gleclair at agentz.com  Mon Sep 21 12:55:13 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Additional proposal posted
Message-ID: <01BDE545.EDA416E0.gleclair@agentz.com>

Fumio Nagasaka has written a proposal for the 1394 PWG transport command set.

The PDF file has been uploaded at:

ftp://ftp.pwg.org/pub/pwg/p1394/mtg092898/proposal-cmd-1a.pdf


This is proposed after reviewing new profile (Rev. 0.52). It addresses 
some points in the current proposal. Thus it is also a proposal for the 
1394 PWG command set.


Regards,
Greg


From gleclair at agentz.com  Mon Sep 21 14:27:24 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Proposal Issue
Message-ID: <01BDE552.CEFE6760.gleclair@agentz.com>

I've received notice that some people have had problems with the 
proposal recieved from Nagasaka-san.

I'll work with him to repost a fixed version.

Regards,
Greg


From gleclair at best.com  Sun Sep 27 21:06:12 1998
From: gleclair at best.com (Gregory LeClair)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Agenda and Meeting start time
Message-ID: <01BDEA41.88B85EC0@gleclair.vip.best.com>

Agenda for Savannah Meeting:

1. Administrivia (Wright)
2. Presentation for command set proposal (Nagasaka) 
3. Profile 0.52 review (Berkema) 
4. Config ROM Issues (LeClair) 
	- PWG OUI
	- IEEE 1212 Status

Meeting Start Time:
My departure has been delayed. I will be in Savannah at approximately 
10 - 10:30 AM on Monday. Please start the meeting at your convenience.


Greg


 

From gleclair at best.com  Sun Sep 27 20:55:53 1998
From: gleclair at best.com (Gregory LeClair)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Updated copy of proposal posted
Message-ID: <01BDEA41.86A0C960@gleclair.vip.best.com>

An updated copy of the proposal by Fumio Nagasaka has been uploaded.

The PDF file has been uploaded at:

ftp://ftp.pwg.org/pub/pwg/p1394/mtg092898/proposal-cmd-1a.pdf


This is proposed after reviewing new profile (Rev. 0.52). It addresses 
some points in the current proposal. Thus it is also a proposal for the 
1394 PWG command set.


Regards,
Greg


From gleclair at best.com  Mon Sep 28 17:36:12 1998
From: gleclair at best.com (Gregory LeClair)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Meeting Minutes from Monterey - July
Message-ID: <01BDEAED.64FEA280@gleclair.vip.best.com>

===============================================


Meeting Attendees

Takashi Isoda	Canon
Osamu Hirata	Canon
Akihiro Shimura	Canon
Lee Farrell	Canon Information Systems
Greg LeClair 	Epson   (1394 PWG Chairman)
Fumio Nagasaka	Seiko Epson 
Atsushi Uchino	Seiko Epson
Brian Batchelder	Hewlett Packard
Alan Berkema	Hewlett Packard
Scott Bonar	Hewlett Packard
Eric Clement	Hewlett Packard
Laurie Lasslo	Hewlett Packard
Greg Shue	Hewlett Packard
Kwang Kim	Hitachi
Yuji Sasaki	Japan Computer Industry
Brian Nagy	Kodak
Jerry Thrasher	Lexmark
Don Wright	Lexmark
John Fuller	Microsoft
Frank Zhao	Panasonic
Randy Turner	Sharp
Bob Morford	SIS Microelectronics
Anthony Fung	ST Micro Electronics
Peter Groz	ST Micro Electronics
Harry Hvostov	ST Micro Electronics


Administrivia

Don Wright gave the next PWG meeting details:
August 17-21
Toronto Marriott at Eaton Centre 
525 Bay Street
Toronto, Ontario, Canada M5G 2L2
$175CN (about $120 US)
Registration deadline is July 24, 1998

Future PWG weekly schedules will be as follows:
  1394 PWG on Monday and Tuesday
  MIB meetings on Tuesday evening (if needed)
  PWG Plenary meetings on Wednesday morning
  IPP on Wednesday afternoon and Thursday morning
  SDP on Thursday afternoon
  UPD on Friday

Greg LeClair presented the 1394 PWG meeting goals and proposed agenda
topics:
  OUI Issues
  Transport Command Set
  Config ROM Review
  Profile Review
  Updates


OUI Issues

Greg LeClair asked if we need to have an OUI for the 1394 PWG Profile?

The group did not resolve this issue, but a few attendees suggested that
the IEEE 1212 group should maintain the list of Function Classes. Greg
said that this topic was raised at the previous 1212 meeting, but no
conclusion was reached at that meeting. Further discussions were
deferred.


Error Recovery Model

Isoda-san gave a presentation on his ideas for supporting error
recovery. His main requirements are that the Initiator shall keep the
contents of the data buffers associated with the ORBs in the linked
list, and maintain the correspondence of the data buffers to a Sequence
Identifier. The Target must guarantee that it does not execute any data
or command twice.

Greg Shue asked if the proposal addresses both writing from the
Initiator as well as writing from the Target. Isoda-san suggested that
it does address both, but he is more confident about the Initiator
writing recovery.

Isoda-san claims that we should maintain a Sequence Id for the ORBs. As
part of the proposal, he explained that it is not necessary for every
ORB to have a status notification sent. It is adequate to send status
for a subset of the ORBs. Specifically, if a Sequence Id can be a
maximum of 2n-1, it is necessary to have at least one status sent for
every group of n ORBs that have been sent since the previous status.

He showed that, based on the requeuing of ORBs, the Target can determine
if the Initiator has received the most recently sent status block. He
also said that if a Sequence Id is not used, the Target cannot determine
if the Initiator has received the status block or not.

A few people commented that the idea of a "sliding window" of ORB
sequences was a good one. 

During discussion of the proposal, Randy Turner said that he believes we
should keep negotiation of buffer size. 

Brian Batchelder asked if anyone could evaluate the benefit (in terms of
performance efficiency) gained by reducing the number of notification
status blocks sent. The only comment was that "it really depends on the
size of the data buffers."


Transport Command Set

Greg Shue referenced his proposal document, PWG 1394 Transport Command
Set Proposal Revision 0c. (This document is available at
ftp://ftp.pwg.org/pub/pwg/p1394/mtg070698/pwgcmd0c.pdf.) He provided a
quick overview of the document and each of the open issues including
those items in the document that are identified as "to be determined."
The major discussion items and any conclusions reached are given below.
(The discussions were not sequential as the paragraphs below might
imply.)

[NOTE:	Greg LeClair captured additional issues that were raised. His
list should be included in the minutes.]


Queues

Should the usage of each queue be specified (e.g. Read and Write) or
left arbitrary? Should we allow a vendor to extend the number of queues
within a single Login? 

Brian Batchelder suggested that if an implementer would like to extend
the number of queues, it should be accomplished by additional Logins. He
suggests that we should limit a given Login to a (simple) bi-directional
communication "pipe." (The idea of two independent queues was originally
proposed because SBP-2 doesn't inherently support this capability.)

The group agreed to limit the number of queues to 2; one for
Initiator-to-Target transfer and one for Target-to-Initiator transfer.
It is intended that the group will focus on providing the equivalent of
a bi-directional transport.

Should we eliminate the queue (q) bit, and just use the direction (d)
bit only? Is it a reasonable assumption that the direction is equivalent
to the queue id? It was decided that this issue is dependent on error
recovery, and it was deferred. 


Notification

There was a long discussion about the problems that can occur if a
status notification (or its acknowledgment) can be lost. There was also
some doubt expressed about the frequency of this condition ever
happening. If it is an extremely unlikely event, perhaps it is better to
simplify the recovery process as much as possible. 

Should we set the notify bit to one (1) for every ORB? Do we need to
always notify completion of every ORB? Greg Shue points out that we are
using the unordered model of the SBP-2 specification. A direct
implication of this is that every ORB must have completion notification.
A "well-partitioned," layered SBP-2 driver does not have sufficient
knowledge about the ORBs in the queue when using an unordered model. If
the driver did have this knowledge (by examining the q bit, for
example), it would be considered "munging" (combining) the different
layers.

After looking at the latest SBP-2 specification, this issue is not
(apparently) explicitly addressed. There is no clear statement that says
the Initiator must set the notify bit when using the unordered model.
Greg Shue would like to make an explicit statement about this in the PWG
Profile document. He identified three possible alternatives:
  1. Require an Initiator to set the notify bit on every ORB
  2. Require the Target to always give completion notification
  3. Allow for the possibility of "monolithic" (multi-layered)
SBP-drivers to be implemented without saying anything additional beyond
what is already specified in the SBP-2 specification 

After more discussion, the group agreed that the PWG Profile document
would not make any additional, explicit statements on this issue other
than to follow the SBP-2 specification.


Extensibility

To what degree should we provide extensibility? Do we really need to
support a mechanism for vendor-specific transport commands? 

As stated above, the group agreed to limit the number of queues to 2.
The number of queues is not extensible.

Shimura-san suggested that vendor-specific commands could be useful as a
method to fix bugs. Most of the other attendees felt that this was not a
good enough reason to include support for vendor-specific commands. It
was suggested that vendor feature differentiation could (and should?) be
achieved at higher levels. 

The group agreed that a Command OUI is not necessary (at least for this
version of the Profile.) No vendor-specific commands or parameters will
be supported. Any extensions will only be possible through the PWG
standards group by revision of the document. 


Parameters

When can parameters be set and/or changed? 

Because the SBP-2 Login is not extensible, Randy Turner suggests that
the PWG Profile should include a Login Response, followed by an exchange
of additional parameters. He also pointed out that both the Target and
the Initiator should know each other's capabilities -- at least to help
resource allocation efficiency. It was suggested that the commands Get
Param and Set Param List should be executed before data transfer,
similar to a "connect" process. This suggestion was later expanded to an
Open command that could establish other items that would be necessary
for managing a connection. 

ACTION:  Randy volunteered to write up an example that would explain
this concept.


Error Recovery 

Should we include a Sequence Id for the ORBs? What is the scope of the
sequence number?

After a fairly brief discussion, the group agreed to use a Sequence Id
for error recovery purposes.

Brian Batchelder noted that the Target should not process more than 2n
ORBs ahead of the last ORB for which the Target received an
acknowledgment of completion status from the Initiator (where 'n' is the
bit width of the Sequence Id.) Otherwise, it is possible that the Target
could lose track of the error recovery information provided by the
Sequence Id.

A long discussion occurred about pre-fetching ORBs and the reliability
of ORB pointers after a bus reset.

Greg Shue noted that the group needs to define a unit attention status
model. However, he suggested that the topic is probably too large to
adequately address at this meeting. It was suggested that the topic be
discussed via e-mail.

A few individuals discussed the processes involved in error recovery,
based on the assumptions of the proposal given by Isoda-san. After the
discussion, John Fuller proposed that the Sequence Id should be eight
bits wide. Nagasaka-san wanted it to be 16 bits wide. After discussing
the need to have the Sequence Id be sufficiently larger than the Maximum
Task Set, the group agreed to 16 bits for the Sequence Id and 14 bits
for the Maximum Task Set size. 

What should be the initial value for the Sequence Id? Greg Shue
suggested that the initial value could be inferred based on the first
ORB on each queue after a Login or an abort task. Randy preferred that
some "initial process" be defined to ensure a specific value for the
first Sequence Id. The topic was deferred for discussion via e-mail.

John Fuller noted that the ORB Sequence Ids might have "gaps," because
of the use of Abort Task and Abort Task Set commands. This caused people
to wonder if it is necessary to generate a notification for each ORB to
handle error recovery properly. However, it was decided that Greg Shue
(and others) would spend time after the meeting to examine this question
more closely. 

ACTION:  Greg will attempt to write up a statement for discussion via
e-mail.

Randy is concerned that without a timeout value (for an ORB completion
notification), there is no way a host can know the lifetime of an ORB.
How long should an Initiator keep an ORB allocated? The group suggested
that if the Initiator wants to free the resources associated with an ORB
before the completion notification has been received, an abort task
command should be issued.

What should the timeouts be for the following items?
  abort task
  abort task set
  logical unit reset
  Target reset

The discussion of timeout values was deferred.


Open/Close Connection

Several items were put into a category of "connection meta-data" that
should be communicated and established. The items include:
  initial values for Sequence Id numbers 
  connection type
  completion policy
  maximum record size

How can a Target close a connection (i.e. unsolicited status)?

This entire topic was deferred for e-mail discussion.


Other Deferred Topics/Issues/Questions

The following items were raised during the discussions, but not directly
resolved:
  When should a Target complete the Store Data Command Response? 
  Does it make sense to use the names "Store Data" and "Fetch Data" for
commands? 
  Would it be better to just have a single "Transfer" command, with the
direction (d) bit used to indicate which way the data should be
transferred?
  Should the q bit be placed in the status block?
  Should we keep the Max Data Size Per Fetch ORB parameter?
  Should we keep the Max Data Size Per Store ORB parameter?
  What should happen to Fetch Data and Store Data commands that are in
or added to the active task set when a data flow direction is disabled?
  Maybe we could put "last acknowledged Sequence Id" in each status
block? 
  Perhaps we should add some attributes and features to the Unit
Directory? This might be a mechanism (for example) to communicate the
maximum buffer size of the Target.


Summary of Commands Discussions

Greg Shue attempted to summarize the decisions reached:
  2 queues only
  No vendor-unique extensions (for this revision)
    no CMD_OUI 
    no Parameter_OUI
  Provide only equivalent bi-directional transport
    MSG (packet) 
    Stream
  Error recovery
    16 bit increasing Sequence Ids
    14 bit size for Max Task Set
 

Remaining issues and assignments for write-ups:

  sequence # [Greg Shue]
    seeding, abort task, interactions
    notify bits and gaps in sequence
  Open/Close CMDs [Randy Turner and Greg Shue]
    parameters and encodings
    negotiated buffer sizes
    mode and completion policy [Bob Morford]
    management agent CMD support
  How will Target initiate close (unsolicited status)?
  How to communicate/clear UNIT ATTENTION?
  Timeouts [Alan Berkema]
  Is queue implied by direction bit?
  What initiates error recovery on Microsoft stack? What steps are
taken? [John Fuller]


Config ROM Review

Because Greg LeClair could not be present the second day of the meeting,
Alan Berkema attempted to lead a discussion of the CSR and Config ROM
document. (This document is available at
ftp://ftp.pwg.org/pub/pwg/p1394/mtg070698/pwg_cfgrom.pdf.) However, it
did not seem that many people read the document.  There was very little
discussion.


Imaging Device Profile Review

Alan Berkema decided that the Profile document will continue to contain
Issues and their resolutions. (This document is available at
ftp://ftp.pwg.org/pub/pwg/p1394/mtg070698/pwg_cfgrom.pdf.)

Meeting adjourned.

From gleclair at best.com  Mon Sep 28 17:36:18 1998
From: gleclair at best.com (Gregory LeClair)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Meeting Minutes from Toronto - August
Message-ID: <01BDEAED.6C85D1E0@gleclair.vip.best.com>

                                  1394 PWG Minutes
                                 August 17-18, 1998
       1.
             Shigeru Ueda   Canon
             Osamu Hirata   Canon (CBM)
             Jim Schwerin   Canon (CBM)
             Lee Farrell    Canon Information
                            Systems
             Greg LeClair*  Epson
             Kazuo Nomura   Epson
             Brian          Hewlett Packard
             Batchelder
             Alan Berkema   Hewlett Packard
             Scott Bonar    Hewlett Packard
             Greg Shue      Hewlett Packard
             Jerry Thrasher Lexmark
             Don Wright     Lexmark
             Anthony Fung   ST Microelectronics
             Harry Hvostov  ST Microelectronics

       Don Wright provided the details for the next PWG meeting:
            Savannah Marriott Riverfront
            Savannah, GA 31401
            100 General McIntosh Blvd.
            Savannah, GA
            912 233-7722
            September 28-October 2
            $165 room rate

       He announced the draft meeting schedule for 1999, indicating that it
       would be discussed further at the PWG Plenary meeting on Wednesday:
            .  Jan 18-22 Maui (Joint PWG/PWG-C)
               Jan 27-29 1394TA Maui
            .  Mar 1-5   Miami
            .  Apr 12-16 New Orleans
                                              Apr. 4-9  Comdex Tokyo
            .  May 24-28 Philadelphia
                                              May 11-14 WWW8 Toronto
                                              May 10-11 W3C AC Meeting
                                              May 31-Jun 4  N+I Tokyo
                                              Jun 22-24 PC-Expo NYC
            .  Jul 5-9   Copenhagen, Denmark (other European site?)
                                              Jul 12-16 IETF Oslo
                                              Jul 14-16 Comdex Canada
            .  Aug 16-20 Alaska
            .  Sep 27-Oct 1                   Denver
            .  Nov 2-6   San Juan, Puerto Rico
                                              Nov 8-12 IETF Wash DC
                                              Nov 15-19 Comdex
            .  Dec 13-17 Los Angeles
       1394 PWG Meeting, August 17-18, 1998

       Greg LeClair presented the proposed agenda topics:
            .  GAP Control
            .  Recovery
            .  Command Set
            .  Open Profile Issues

       3.
       Ueda-san presented a few slides on the _gap control_ method used to
       maintain coordination and recovery of command processing between the
       Initiator and Target.

       He believes that the _enforced sequential command tag_ approach is
       inefficient for command set recovery, because there can be overhead
       introduced even in normal operation situations. To avoid the
       inefficiency two rules are proposed:
            .  Target determines whether the command is ahead or behind
               current position based on the sign of the distance between
               them.
            .  Initiator is responsible to keep the actual sequence of tasks
               in the task list to be recognized correctly by the target.

       Shimura-san has distributed a description of the proposal via e-mail.

       Ueda provided example cases illustrating different situations that may
       occur in an error recovery situation.

       There was some discussion about the process of aborting a task by using
       a _dummy orb_. Greg Shue explained the Abort Task Set management
       function. He feels that the Abort Task command can possibly cause
       problems. The issue about aborting a task is that there is no guarantee
       that the Initiator will actually respond to the Abort Task request.

       Greg Shue asked Ueda-san what the _normal condition_ would be that
       would cause inefficient operation. Ueda gave the example of a paper-jam
       or out-of-paper condition. After a bit of discussion, there is still
       unresolved disagreement about how frequently this situation will really
       occur_and therefore how much efficiency is really gained by the
       proposal.

       ISSUE: Once a Target's fetch agent has transitioned to a dead state,
       how long will it wait for an Initiator to do error recovery before it
       takes action on its own? How long do we stay in a dead state? This
       issue is currently felt to be beyond the scope of the specification
       because it is application specific. If it needs to be resolved at a
       higher level, we may need to provide a mechanism to achieve it.

       4.
	Recovery

       Ueda-san also gave a presentation on the Error recovery model used in
       Canon's SHPT proposal. A few optimization methods were proposed:
            .  use same physical memory for application buffers and transport
               buffers
            .  use same size buffer as 1394 transaction for error recovery




       1394 PWG Meeting, August 17-18, 1998

            .  sender can directly write data to buffer in receiver specifying
               the 1394 address

       For error recovery, the Initiator must keep the contents of the data
       buffers associated with the ORBs in the linked list, and the Target
       must guarantee not to execute any data and command twice. [The slide in
       Ueda's presentation was missing the word _not_.]

       The Initiator must guarantee that the contents of the data buffer will
       not change over a Bus Reset.

       Ueda proposes that a special value of 0 for Max_T2I_DATA_SIZE should
       indicate that the Target does not need to guarantee to hold and re-send
       data. (The Initiator will guarantee to maintain the contents over a Bus
       Reset.)

       Greg Shue pointed out that the value of zero is already used to
       indicate that no data will be transferred in that direction. He
       suggested that another (new) parameter could be defined to indicate the
       capability proposed by Ueda.

       Greg agreed that the capability to indicate to a Target that the
       Initiator will retain the data contents of a data block and its
       Sequence ID over a Bus Reset was a reasonable feature. However,
       discussion of the method for indicating this feature was deferred until
       the Command Set topic was addressed.

       Much discussion occurred about whether the contents of the page-tables
       for the buffer could be relied upon after a Bus Reset. Generally,
       people feel that the Target should re-read the page table (in case the
       pointers to the data contents have changed.)

       5.Command Set

       Greg Shue has issued revision 0d of the PWG 1394 Transport Command Set
       Proposal. He led the group in a page-by-page review of the latest
       revision, asking for comments.

       Ueda-san commented that the Open and Close Transport commands are not
       symmetrical. The Transport_Open command is issued for both queues, but
       the Transport_Close is issued for only one queue at a time. Greg
       explained that the reason for this was to allow the Initiator to
       indicate that no more writing to the write queue will occur, but
       reading will continue on the read queue.

       The group discussed whether or not Greg's reason was a valid situation.
       After not being able to identify a specific situation to justify the
       capability, the group agreed to change the Transport_Close to apply to
       both queues. However, Greg noted that once a Close is done to both
       queues, there is nothing that can be done next_except a Logout.
       Therefore, he suggests that the Transport_Close command is redundant to
       the Logout command. (Although unsolicited status could be generated
       before a Logout, it was not felt that this was a reasonable event.)
       If Transport_Close is eliminated (because it is redundant to Logout),
       this would also create an asymmetrical situation for Transport_Open.


       The Get_Transport_Capabilities command was discussed. Brian noted that
       when a Target responds with certain transport capabilities, it must
       reserve those capabilities for the duration of that Login.

       Greg LeClair suggested that we should keep the Close command to allow
       some kind of acknowledgment of the Close command. Using Logout does not
       provide any chance for a reply.

       After much discussion about the above issues, no consensus was reached,
       and the topic was deferred.

       ISSUES:
            .  Should we have a Transport_Close command of any type_either
               applicable to a single queue or both queues?
            .  What behavior should occur after a Close and after/during an
               Open?
            .  If we eliminate the Transport Close command, should the Open
               command be renamed?

       ISSUE: What should be done about the following case? An initiator opens
       a connection, carries on a conversation, closes both queues for
       communication, and then does a TARGET RESET? Presumably, this would
       allow another TRANSPORT_OPEN to be issued without having the initiator
       Logout, though it would affect all other initiators logged in to that
       target by generating a UNIT ATTENTION condition. Because we must
       support TARGET RESET to be SBP-2 compliant, this situation must be
       supported as well.

       ISSUE: Should we support ABORT TASK?

       Greg Shue points out that the Target has the option to ignore the ABORT
       TASK command_once it has fetched the ORB.

       Greg LeClair claims that if an Initiator Aborts a task, it must Abort
       all the remaining ORBs in that queue, and must resubmit them with the
       same sequence IDs.

       ISSUE: What do we do if the Target responds to an Abort Task with _I
       completed the ORB_ (instead of acknowledging it as a Dummy ORB?) This
       condition might cause the Target to process data that shouldn't have
       been. This can cause problems for a printer data stream.

       CONCLUSION: The PWG Profile will state that the client SHALL NOT issue
       an Abort Task (because we cannot guarantee the execution of an Abort
       Task request, and this might cause unpredictable behavior.) [It was
       also noted that Microsoft does not support the Abort Task capability.]
       Greg LeClair suggests that any desire to abort a large print job should
       be handled at a higher level_perhaps on a job cancel basis.

       ISSUE: Abort Task Set is used by a _soon-to-be_ commercially available
       O/S in response to a timeout condition. The group needs to examine and
       understand what the condition details are.

       The group agreed to add a new parameter to indicate that the Initiator
       will maintain data buffer content integrity across Bus Resets (to
       address the proposal made by Ueda-san earlier.)

       1394 PWG Meeting, August 17-18, 1998
       ISSUE: The Profile document should include an explicit statement on the
       padding order and the placement of data bytes less than a full quadlet
       (e.g. a diagram showing a five-byte data value.)
       MOTION: At the end of the page-by-page review, Alan Berkema made a
       motion to include the latest revision of the Command Set document into
       the Profile document. Greg Shue seconded the motion.
       Ueda-san requested that additional evaluation and changes to the
       Command Set information should still be possible. Greg LeClair (and
       others) agreed that comments and changes are still possible, but that
       the motion is primarily a convenience to the Profile editor_and an
       acknowledgment that the Command Set information is _relatively stable_.

       VOTE: The motion passed unanimously. Alan Berkema will incorporate the
       material into the next revision of the Profile document.

       ISSUE: How do we pass down Sockets implementation information into the
       Command Set? No resolution was reached on this issue.

       6. Config ROM Review and IEEE 1212r
       Greg LeClair briefly reviewed the latest activity in 1212r and
       referenced his CSR and Config ROM proposal that is posted.

       According to Greg, the FDS proposal and other discovery concepts have
       been _stabilized_ at the Bath meeting last month. (Greg noted that this
       doesn't necessarily mean that it can't become unstable in the future.)
       The group believes that there should be a class registry monitored and
       maintained by the 1212r group.

       Next meetings for 1212r are planned for September 9-10 in Chicago and
       October 15-16 in Maui.

       Alan Berkema asked if the Config ROM document is ready to be included
       into the Profile document. The group decided that we should wait until
       the document is updated to reflect the most recent 1212r activity and
       reviewed by the group.

       7. PWG Profile Document

       Alan Berkema led the group in a _page-by-page_ review of the latest
       Profile document.

       It was suggested that a re-write of the Purpose section be considered
       and proposed on the e-mail reflector for review. A few individuals felt
       that the current description is not as accurate as it could be. There
       was a question on how specific we should be in terms of addressing
       specific device classes. Should we really attempt to address all
       imaging devices_or consider separate documents for each device class?
       It was suggested that the current document be considered as a sample
       _template_ for other imaging devices_but that it focus only on the
       printer class.


       1394 PWG Meeting, August 17-18, 1998

       The definition of Queue should be changed to reflect a sequence of
       ORBs_not just a collection.

       The Config ROM block diagram (Figure 2) should be updated for accuracy.
       It was noted that Section 7 will eventually be replaced by Greg
       LeClair's document on Config ROM. The group then reviewed the Config
       ROM document contents, identifying several edits that Greg will include
       in the next revision.

       There was a long discussion about the section on Device Discovery (in
       the Config ROM document.) A concern was raised about whether a Bus
       Reset should be generated every time the device configuration changes_
       and a corresponding change to the values of the Config ROM is possible.
       (This could certainly lead to excessive bandwidth problems.) It was
       suggested that the Profile document should inform an implementor that
       any change in the Config ROM values shall not be made until the next
       Bus Reset. However, it should be worded in such a manner that does not
       encourage Bus Resets unnecessarily.

       Section 9 of the Profile document will be re-worded so that it does not
       say every command will have the ORB notify bit set to zero. Not every
       ORB needs to have its notify bit set.

       Sections 10 and 11 will get replaced by the Command Set description
       content.

       Figure 4 in Section 11.2 _ There was some concern that the diagram
       might be confusing because it has too much detail. Isoda-san was
       volunteered to change his _Whole Model_ diagram into an editable Word
       format or PowerPoint format. The group would like the diagram replaced
       by a sequence of (four?) drawings_each one showing a progression of
       detail in the communication flow between the client and server:
       client/server, 1394 PWG, _SBP-2 cloud_, and _SBP-2 details.

       Section 11.3 will be removed.

       It was suggested that Section 12 should include a reference to
       maintaining _fairness_ of access when supporting multiple Logins.

       Sections 13, 15, 18, 19, 20, and 21 will be replaced/superseded by the
       Command Set description content.

       The list of Issues contained in the Profile document (Sections 23-27)
       were very briefly reviewed and evaluated.

       The group decided that Unsolicited Status Register service will not be
       provided to a higher layer. Therefore no policy is needed.

       The Profile document will include a list of timers that should be
       defined. The discussions identified three timers:  Reconnect timer,
       Management Command response timer, and the timer used by the Initiator
       to issue an Abort Task Set due to Target inactivity. Alan will start a
       discussion via e-mail to identify any other timers that might be
       necessary.

       ACTION: Brian volunteered to write up a description clarifying the
       differences between datagram- and datastream-based services.

       1394 PWG Meeting, August 17-18, 1998

       ACTION: Alan said that he will update and issue a new version of the
       Profile by September 10.

       ACTION: Greg LeClair will maintain a prioritized _List of Active
       Issues_ for tracking and reference within the group.

       ISSUE: The Profile document should include an explicit statement on the
       padding order and the placement of data bytes less than a full quadlet
       (e.g. a diagram showing a five-byte data value.)

       8. Greg Shue believes that we are ready to (begin to) create a set of
       scenarios for testing interoperability. It was suggested that we should
       plan to discuss possible scenarios at the next meeting.

       Greg LeClair asked if any companies might be ready with a prototype for
       interoperability testing before December. Epson, HP, and Canon all
       indicated that they might have something.

	9. OUI Issues

       Greg LeClair discussed the issue of Organizationally Unique Identifiers
       (OUI):
            .  Do we need to have an OUI for the 1394 PWG Profile?
               . Cmd_Set_Spec_ID in the Unit Directory
               . possibly needed for `Printer' value of the Function_Class
                 entry in Instance Directory (formerly FDS)
               . useful as a Spec_ID for other locations
            .  Options:
               . select a standards body and get a RAC assigned OUI
               . buy OUI as 1394 PWG
                 _  maintenance and administration problems?

       Greg asked: _Would the individual companies represented at the 1394 PWG
       group be willing to contribute $$$ to pay for an OUI?_ If the group
       does buy one, how will it (and sub-identifiers) be administered,
       maintained, and managed?

       It was suggested that we obtain an OUI from the 1394 TA. However, they
       will not give one out until we have a completed document_and we agree
       to abide by their by-laws.

       MOTION: Brian Batchelder made a motion that the 1394 PWG members
       request that the PWG organization purchase an Organizationally Unique
       Identifier (OUI) from the IEEE RAC. This OUI will be maintained and
       administered by that organization.

      VOTE: The motion passed unanimously.

       Meeting adjourned.

From brianb at vcd.hp.com  Wed Oct 14 10:35:39 1998
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Length of Meetings
Message-ID: <4.0.1.19981013113416.00e1df10@popmail1.vcd.hp.com>

I am concerned with the shift to one day meetings for the 1394 PWG effort.  We used up all of two days at the last meeting with what I thought were mostly important presentations and discussions.  Those discussions caused an evolution in my understanding of our challenges and solutions.  We still have open issues.  Further work is required.  Due to the nature of our "real" jobs, most work seems to occur during the meetings.  I don't see that we can move to 1 day at this time, and still be able to quickly reach a viable standard.  I propose that we return to 2 day meetings and keep them focused on the remaining issues so that we can finish as soon as possible.  Besides, I JUST LOVE the Marriott...

Brian

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227


From harryl at us.ibm.com  Wed Oct 14 12:33:11 1998
From: harryl at us.ibm.com (Harry Lewis)
Date: Wed May  6 14:00:52 2009
Subject: P1394> 2-Days
Message-ID: <5030100027145711000002L012*@MHS>

oops...

I don't mind future adjustments (proposed by Brian) but have already
arranged for Novenber meeting with MIBs and IPP starting Tuesday.
I prefer sticking with the currently posted agenda for Tucson.

Harry Lewis - IBM Printing Systems

From gleclair at agentz.com  Wed Oct 14 17:18:13 1998
From: gleclair at agentz.com (Greg LeClair)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Length of Meetings
Message-ID: <01BDF77F.410CB120.gleclair@agentz.com>

We can take a vote in Tucson to see if we think we'll need two days in the 
future.
My feeling is that 1 day is adequate for tasks of the working group at this 
time.

Detail level work can occur offline from the main working group meeting and 
be brought
back to the main group.

My .02 worth.

If you have a strong opinion one way or another, please let me know before 
the Tucson meeting.

NOTE: No change is planned to the date or duration of the Tucson meeting 
posted by the PWG Chair.

Regards,
Greg



-----Original Message-----
From:	Brian Batchelder [SMTP:brianb@vcd.hp.com]
Sent:	Wednesday, October 14, 1998 7:36 AM
To:	1394 PWG
Subject:	P1394> Length of Meetings

I am concerned with the shift to one day meetings for the 1394 PWG effort. 
 We used up all of two days at the last meeting with what I thought were 
mostly important presentations and discussions.  Those discussions caused 
an evolution in my understanding of our challenges and solutions.  We still 
have open issues.  Further work is required.  Due to the nature of our 
"real" jobs, most work seems to occur during the meetings.  I don't see 
that we can move to 1 day at this time, and still be able to quickly reach 
a viable standard.  I propose that we return to 2 day meetings and keep 
them focused on the remaining issues so that we can finish as soon as 
possible.  Besides, I JUST LOVE the Marriott...

Brian

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227


From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Wed Oct 14 17:36:17 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:52 2009
Subject: P1394> 2-Days
In-Reply-To: <5030100027145711000002L012@MHS>
Message-ID: <H0000d931023d0b9@MHS>

A non-text attachment was scrubbed...
Name: 1.txt
Type: application/octet-stream
Size: 938 bytes
Desc: not available
Url : http://www.pwg.org/archives/p1394/attachments/19981014/e6f39ee5/1-0001.obj
-------------- next part --------------
     I think Tuscon is a done deal. 
     San Diego should be open to discussion.
     
     I finally have a critical mass of pings, I would hate to ask folks to 
     ping again :)
     
     regards,
     Alan


______________________________ Reply Separator _________________________________
Subject: P1394> 2-Days
Author:  Non-HP-harryl (harryl@us.ibm.com) at HP-Roseville,mimegw3
Date:    10/14/98 9:33 AM


oops...
     
I don't mind future adjustments (proposed by Brian) but have already 
arranged for Novenber meeting with MIBs and IPP starting Tuesday.
I prefer sticking with the currently posted agenda for Tucson.
     
Harry Lewis - IBM Printing Systems
From Nagasaka.Fumio at exc.epson.co.jp  Fri Oct 16 07:57:16 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:52 2009
Subject: P1394> connection for Function or Service
Message-ID: <01376112D7AFD011911E0020AF70BEC51C0FB9@cpuex1.ued.epson.co.jp>

In Savannah meeting, Brain opened SPI discussion, and it was really
productive. I would like to confirm some open issue. Actually I
would like to start e-mail discussion thread. Because as Brian 
pointed in this reflector, meeting schedule is too short (only one day),
thus I felt e-mail discussion would be helpful to clear what is
required for current profile Rev.0.52.

An UnitDir is assumed as the entity of a function, a function (ex.
a printer, or a scanner, ) may have several services, for example
job control, printing, status monitoring and finisher control.
A "Function" is an abstracted software entity of a real device.
A "Service" is an abstracted software model of an executable
instance.

                                        [Services]
UnitDir == Function (printer) -----|
                                   |-----Job Control
                                   |-----Status Monitoring
                                   |-----Printing
                                   |-----Finisher
                                   |
                                   
We've discussed three ideas listed below;
(1) an initiator logins to the function.
(2) an initiator logins to each service.
(3) hybrid solution of (1) and (2).

If we choose (2), naturally each service shall be associated
with a LUN and the initiator shall specify the selected LUN in
parameter of "login".

If we choose (1), a function shall be assumed as one LUN.
The initiator shall specify this LUN at login, and this LUN
shall provide multiplexing to support several services.

I have no urge to describe (3). This idea seems to be too
complicated for me.

Second idea is neat. And current profile (0.52) is applicable
for this model. However I am not sure whether existing PC OS
is supporting PnP of this architecture.

UnitDir ---|-- LUN
           |-- LUN
           |-- LUN
           |-- ...

Also I don't think current PC OS is supporting dynamic adding
of LUNs. Thus it is difficult to add service entity on demand.

The first idea is not neat, but may be supported even under
existing PC OS.

UnitDir ----- LUN
UnitDir ----- LUN
...

However, each service requires a multiplexed connection and
each connection requires flow control and send/receive queues.

My proposal suggested in the last meeting was describing
multiplexing, but it does not have description for flow control
of each logical channels. So my question is, shall we choose
second idea? or does anyone have better idea for (3) option?
Or is there new idea??
Thank you,
---
--------------------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to  <mailto:nagasaka.fumio@exc.epson.co.jp> nagasaka.fumio@exc.epson.
co.jp

From gregs at sdd.hp.com  Fri Oct 16 11:39:43 1998
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:52 2009
Subject: P1394> connection for Function or Service
In-Reply-To: <01376112D7AFD011911E0020AF70BEC51C0FB9@cpuex1.ued.epson.co.jp> from "Nagasaka Fumio" at Oct 16, 98 08:57:16 pm
Message-ID: <199810161539.IAA08801@hpsdlgj1.sdd.hp.com>

> However, each service requires a multiplexed connection and
> each connection requires flow control and send/receive queues.

Whether we multiplex connections over a login or have separate
logins, each service is accessed over a connection, and each
connection requires flow control and send/receive queues.
This is a non-issue in the decision.

A larger issue with "current PC OS" implementation may be how
many outstanding requests can be supported at once by the SBP-2
driver.

-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From hitoshis at MICROSOFT.com  Fri Oct 16 14:55:37 1998
From: hitoshis at MICROSOFT.com (Hitoshi Sekine)
Date: Wed May  6 14:00:52 2009
Subject: P1394> connection for Function or Service
Message-ID: <FD8F41F04D35D111899600805F19A16C0642FEB7@RED-MSG-48>

> A larger issue with "current PC OS" implementation may be how
> many outstanding requests can be supported at once by the SBP-2
> driver.

I agree that it is a large issue with the implementation.  But, it is not
clear to me that the SBP-2 is required to handle multiple logins or
connections.  Who cases multiple connections per a single login?  I think we
should be able to handle multiple connection on a single login or multiple
logins.  These implementations are very different.

Thanks,
Hitoshi

-----Original Message-----
From: Greg Shue [mailto:gregs@sdd.hp.com]
Sent: Friday, October 16, 1998 8:40 AM
To: Nagasaka.Fumio@exc.epson.co.jp
Cc: p1394@pwg.org
Subject: Re: P1394> connection for Function or Service


> However, each service requires a multiplexed connection and
> each connection requires flow control and send/receive queues.

Whether we multiplex connections over a login or have separate
logins, each service is accessed over a connection, and each
connection requires flow control and send/receive queues.
This is a non-issue in the decision.

A larger issue with "current PC OS" implementation may be how
many outstanding requests can be supported at once by the SBP-2
driver.

-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------

From Nagasaka.Fumio at exc.epson.co.jp  Fri Oct 16 21:38:52 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:52 2009
Subject: P1394> connection for Function or Service
Message-ID: <01376112D7AFD011911E0020AF70BEC51C0FBA@cpuex1.ued.epson.co.jp>

	Greg Shue wrote:
	>Whether we multiplex connections over a login or have separate
	>logins, each service is accessed over a connection, and each
	>connection requires flow control and send/receive queues.
	>This is a non-issue in the decision.

	Agreed. The profile 0.52 is describing TRANSPORT_CAPABILITIES
	command to ease to support flow control. Right? However when
	we choose ?multiplex connections over a login?, then can we use
	same method? If not, do you prefer connections over multiple LUNs?

	Greg Shue wrote:
	>A larger issue with "current PC OS" implementation may be how
	>many outstanding requests can be supported at once by the SBP-2
	>driver.

	Please write some more,,, as I could not figure out what are
	?outstanding requests? on PC OS platform. Are you saying how many
	outstanding ORBs can be supported at once over multiple LUUs?

Thank you,
Fumio Nagasaka

> -----Original Message-----
> From:	Greg Shue [SMTP:gregs@sdd.hp.com]
> Sent:	Saturday, October 17, 1998 12:40 AM
> To:	Nagasaka Fumio
> Cc:	p1394@pwg.org
> Subject:	Re: P1394> connection for Function or Service
> 
> > However, each service requires a multiplexed connection and
> > each connection requires flow control and send/receive queues.
> 
> Whether we multiplex connections over a login or have separate
> logins, each service is accessed over a connection, and each
> connection requires flow control and send/receive queues.
> This is a non-issue in the decision.
> 
> A larger issue with "current PC OS" implementation may be how
> many outstanding requests can be supported at once by the SBP-2
> driver.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------

From Nagasaka.Fumio at exc.epson.co.jp  Fri Oct 16 21:39:39 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:52 2009
Subject: FW: P1394> connection for Function or Service
Message-ID: <01376112D7AFD011911E0020AF70BEC51C0FBB@cpuex1.ued.epson.co.jp>

> Hi Hitoshi,
> 
> My question is;
> If 1394 PWG chooses ?connections over multiple LUNs?, does new PC OS
> support device-enumeration which has a configuration ROM shown below?
> 
> UnitDir --->[ LUN0, LUN1, LUN2, ?]
> 
> And may our driver invoke ?Login(s)? to each LUN separately?
> 
> Thank you,
> --------------------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
> 
> -----Original Message-----
> From:	Hitoshi Sekine [SMTP:hitoshis@MICROSOFT.com]
> Sent:	Saturday, October 17, 1998 3:56 AM
> To:	'Greg Shue'; Nagasaka Fumio
> Cc:	p1394@pwg.org
> Subject:	RE: P1394> connection for Function or Service
> 
> > A larger issue with "current PC OS" implementation may be how
> > many outstanding requests can be supported at once by the SBP-2
> > driver.
> 
> I agree that it is a large issue with the implementation.  But, it is not
> clear to me that the SBP-2 is required to handle multiple logins or
> connections.  Who cases multiple connections per a single login?  I think
> we
> should be able to handle multiple connection on a single login or multiple
> logins.  These implementations are very different.
> 
> Thanks,
> Hitoshi
> 
> -----Original Message-----
> From: Greg Shue [mailto:gregs@sdd.hp.com]
> Sent: Friday, October 16, 1998 8:40 AM
> To: Nagasaka.Fumio@exc.epson.co.jp
> Cc: p1394@pwg.org
> Subject: Re: P1394> connection for Function or Service
> 
> 
> > However, each service requires a multiplexed connection and
> > each connection requires flow control and send/receive queues.
> 
> Whether we multiplex connections over a login or have separate
> logins, each service is accessed over a connection, and each
> connection requires flow control and send/receive queues.
> This is a non-issue in the decision.
> 
> A larger issue with "current PC OS" implementation may be how
> many outstanding requests can be supported at once by the SBP-2
> driver.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------

From Nagasaka.Fumio at exc.epson.co.jp  Fri Oct 16 21:40:19 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:52 2009
Subject: FW: P1394> connection for Function or Service
Message-ID: <01376112D7AFD011911E0020AF70BEC51C0FBC@cpuex1.ued.epson.co.jp>

> Hi Eric,
> 
> If 1394 PWG chooses ?connections over multiple LUNs?, does new Mac OS
> support device discovery which has a configuration ROM shown below?
> 
> UnitDir --->[ LUN0, LUN1, LUN2, ?]
> 
> And may our driver invoke ?Login(s)? to each LUN separately?
> Does Mac OS register each LUN as a separated entity in the name registry?
> Thank you,
> --------------------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
> 
> -----Original Message-----
> From:	Hitoshi Sekine [SMTP:hitoshis@MICROSOFT.com]
> Sent:	Saturday, October 17, 1998 3:56 AM
> To:	'Greg Shue'; Nagasaka Fumio
> Cc:	p1394@pwg.org
> Subject:	RE: P1394> connection for Function or Service
> 
> > A larger issue with "current PC OS" implementation may be how
> > many outstanding requests can be supported at once by the SBP-2
> > driver.
> 
> I agree that it is a large issue with the implementation.  But, it is not
> clear to me that the SBP-2 is required to handle multiple logins or
> connections.  Who cases multiple connections per a single login?  I think
> we
> should be able to handle multiple connection on a single login or multiple
> logins.  These implementations are very different.
> 
> Thanks,
> Hitoshi
> 
> -----Original Message-----
> From: Greg Shue [mailto:gregs@sdd.hp.com]
> Sent: Friday, October 16, 1998 8:40 AM
> To: Nagasaka.Fumio@exc.epson.co.jp
> Cc: p1394@pwg.org
> Subject: Re: P1394> connection for Function or Service
> 
> 
> > However, each service requires a multiplexed connection and
> > each connection requires flow control and send/receive queues.
> 
> Whether we multiplex connections over a login or have separate
> logins, each service is accessed over a connection, and each
> connection requires flow control and send/receive queues.
> This is a non-issue in the decision.
> 
> A larger issue with "current PC OS" implementation may be how
> many outstanding requests can be supported at once by the SBP-2
> driver.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------

From Nagasaka.Fumio at exc.epson.co.jp  Fri Oct 16 22:19:03 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:52 2009
Subject: P1394> connection for Function or Service
Message-ID: <01376112D7AFD011911E0020AF70BEC51C0FBD@cpuex1.ued.epson.co.jp>

Hi Eric,

If 1394 PWG chooses ?connections over multiple LUNs?, does new Mac OS
support device discovery which has a configuration ROM shown below?

UnitDir --->[ LUN0, LUN1, LUN2, ?]

And may our driver invoke ?Login(s)? to each LUN separately?
Does Mac OS register each LUN as a separated entity in the name registry?
Thank you,
--------------------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp

> -----Original Message-----
> From:	Hitoshi Sekine [SMTP:hitoshis@MICROSOFT.com]
> Sent:	Saturday, October 17, 1998 3:56 AM
> To:	'Greg Shue'; Nagasaka Fumio
> Cc:	p1394@pwg.org
> Subject:	RE: P1394> connection for Function or Service
> 
> > A larger issue with "current PC OS" implementation may be how
> > many outstanding requests can be supported at once by the SBP-2
> > driver.
> 
> I agree that it is a large issue with the implementation.  But, it is not
> clear to me that the SBP-2 is required to handle multiple logins or
> connections.  Who cases multiple connections per a single login?  I think
> we
> should be able to handle multiple connection on a single login or multiple
> logins.  These implementations are very different.
> 
> Thanks,
> Hitoshi
> 
> -----Original Message-----
> From: Greg Shue [mailto:gregs@sdd.hp.com]
> Sent: Friday, October 16, 1998 8:40 AM
> To: Nagasaka.Fumio@exc.epson.co.jp
> Cc: p1394@pwg.org
> Subject: Re: P1394> connection for Function or Service
> 
> 
> > However, each service requires a multiplexed connection and
> > each connection requires flow control and send/receive queues.
> 
> Whether we multiplex connections over a login or have separate
> logins, each service is accessed over a connection, and each
> connection requires flow control and send/receive queues.
> This is a non-issue in the decision.
> 
> A larger issue with "current PC OS" implementation may be how
> many outstanding requests can be supported at once by the SBP-2
> driver.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------

From Nagasaka.Fumio at exc.epson.co.jp  Fri Oct 16 22:19:41 1998
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:52 2009
Subject: P1394> connection for Function or Service
Message-ID: <01376112D7AFD011911E0020AF70BEC51C0FBE@cpuex1.ued.epson.co.jp>

Hi Hitoshi,

My question is;
If 1394 PWG chooses ?connections over multiple LUNs?, does new PC OS
support device-enumeration which has a configuration ROM shown below?

UnitDir --->[ LUN0, LUN1, LUN2, ?]

And may our driver invoke ?Login(s)? to each LUN separately?

Thank you,
--------------------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp

> -----Original Message-----
> From:	Hitoshi Sekine [SMTP:hitoshis@MICROSOFT.com]
> Sent:	Saturday, October 17, 1998 3:56 AM
> To:	'Greg Shue'; Nagasaka Fumio
> Cc:	p1394@pwg.org
> Subject:	RE: P1394> connection for Function or Service
> 
> > A larger issue with "current PC OS" implementation may be how
> > many outstanding requests can be supported at once by the SBP-2
> > driver.
> 
> I agree that it is a large issue with the implementation.  But, it is not
> clear to me that the SBP-2 is required to handle multiple logins or
> connections.  Who cases multiple connections per a single login?  I think
> we
> should be able to handle multiple connection on a single login or multiple
> logins.  These implementations are very different.
> 
> Thanks,
> Hitoshi
> 
> -----Original Message-----
> From: Greg Shue [mailto:gregs@sdd.hp.com]
> Sent: Friday, October 16, 1998 8:40 AM
> To: Nagasaka.Fumio@exc.epson.co.jp
> Cc: p1394@pwg.org
> Subject: Re: P1394> connection for Function or Service
> 
> 
> > However, each service requires a multiplexed connection and
> > each connection requires flow control and send/receive queues.
> 
> Whether we multiplex connections over a login or have separate
> logins, each service is accessed over a connection, and each
> connection requires flow control and send/receive queues.
> This is a non-issue in the decision.
> 
> A larger issue with "current PC OS" implementation may be how
> many outstanding requests can be supported at once by the SBP-2
> driver.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------

From hitoshis at MICROSOFT.com  Fri Oct 16 22:37:41 1998
From: hitoshis at MICROSOFT.com (Hitoshi Sekine)
Date: Wed May  6 14:00:52 2009
Subject: P1394> connection for Function or Service
Message-ID: <FD8F41F04D35D111899600805F19A16C0642FEC6@RED-MSG-48>

Fumio,

I think it should work on any OS so.  Please send the kind of printer to me.

Thanks,
Hitoshi

-----Original Message-----
From: Nagasaka Fumio [mailto:Nagasaka.Fumio@exc.epson.co.jp]
Sent: Friday, October 16, 1998 7:20 PM
To: Hitoshi Sekine
Cc: p1394@pwg.org; 'Greg Shue'
Subject: RE: P1394> connection for Function or Service


Hi Hitoshi,

My question is;
If 1394 PWG chooses $B!H(Jconnections over multiple LUNs$B!I(J, does new PC OS
support device-enumeration which has a configuration ROM shown below?

UnitDir --->[ LUN0, LUN1, LUN2, $B!D(J]

And may our driver invoke $B!H(JLogin(s)$B!I(J to each LUN separately?

Thank you,
--------------------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp

> -----Original Message-----
> From:	Hitoshi Sekine [SMTP:hitoshis@MICROSOFT.com]
> Sent:	Saturday, October 17, 1998 3:56 AM
> To:	'Greg Shue'; Nagasaka Fumio
> Cc:	p1394@pwg.org
> Subject:	RE: P1394> connection for Function or Service
> 
> > A larger issue with "current PC OS" implementation may be how
> > many outstanding requests can be supported at once by the SBP-2
> > driver.
> 
> I agree that it is a large issue with the implementation.  But, it is not
> clear to me that the SBP-2 is required to handle multiple logins or
> connections.  Who cases multiple connections per a single login?  I think
> we
> should be able to handle multiple connection on a single login or multiple
> logins.  These implementations are very different.
> 
> Thanks,
> Hitoshi
> 
> -----Original Message-----
> From: Greg Shue [mailto:gregs@sdd.hp.com]
> Sent: Friday, October 16, 1998 8:40 AM
> To: Nagasaka.Fumio@exc.epson.co.jp
> Cc: p1394@pwg.org
> Subject: Re: P1394> connection for Function or Service
> 
> 
> > However, each service requires a multiplexed connection and
> > each connection requires flow control and send/receive queues.
> 
> Whether we multiplex connections over a login or have separate
> logins, each service is accessed over a connection, and each
> connection requires flow control and send/receive queues.
> This is a non-issue in the decision.
> 
> A larger issue with "current PC OS" implementation may be how
> many outstanding requests can be supported at once by the SBP-2
> driver.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs@sdd.hp.com
> ----------------------------------------------------------------

From ewa at apple.com  Sat Oct 17 18:25:53 1998
From: ewa at apple.com (Eric Anderson)
Date: Wed May  6 14:00:52 2009
Subject: FW: P1394> connection for Function or Service
Message-ID: <B24E699D-33640@17.216.20.64>

Hi everyone,

Mac OS allows any number of LUNs per device.  We will create an
entry in the "Name Registry" for each LUN and we will try to load
a driver for each LUN.

But, it is not required to use one driver per LUN.  If you like, a
single driver can control multiple LUNs.

There is no limit to the number of LUNs, number of Logins, or the
number of active ORBs that one driver can use (other than system
memory size limits, and SBP-2 rules such as one Login per LUN per
node).

I would like to suggest that multi-LUN devices in which the LUNs have
different tasks (such as status, control, data, etc.) related to the
same common goal (such as printing) should make the LUN's somehow
different.  This will help us to load the right driver for the right
LUN.  For example, each LUN could have a different device_type in
the Logical_Unit_Number entry (7.4.11 or 7.5.4).  Or you could even
use different Command Set Revisions or Spec IDs for each LUN,
depending
on what you think the best way to distinguish the functions is.  Mac
OS is very flexible - it can match drivers based on any of these LUN
criteria.  Even if you only want to use one driver for all the LUNs in
your device, it will be easier for us to find them for you if you make
them look different in one of these ways.

--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.      408-974-8187
--------------------------------------

>> Hi Eric,
>> 
>> If 1394 PWG chooses ?gconnections over multiple LUNs?h, does
new Mac OS
>> support device discovery which has a configuration ROM shown below?
>> 
>> UnitDir --->[ LUN0, LUN1, LUN2, ?c]
>> 
>> And may our driver invoke ?gLogin(s)?h to each LUN separately?
>> Does Mac OS register each LUN as a separated entity in the name
registry?
>> Thank you,
>> --------------------------------------------
>> Fumio Nagasaka
>> Epson Software Development Laboratory Inc.
>> Tel +81 268 25 4111,  Fax +81 268 25 4627
>> E-mail to nagasaka.fumio@exc.epson.co.jp
>> 
>> -----Original Message-----
>> From:	Hitoshi Sekine [SMTP:hitoshis@MICROSOFT.com]
>> Sent:	Saturday, October 17, 1998 3:56 AM
>> To:	'Greg Shue'; Nagasaka Fumio
>> Cc:	p1394@pwg.org
>> Subject:	RE: P1394> connection for Function or Service
>> 
>> > A larger issue with "current PC OS" implementation may be how
>> > many outstanding requests can be supported at once by the SBP-2
>> > driver.
>> 
>> I agree that it is a large issue with the implementation.  But, it
is not
>> clear to me that the SBP-2 is required to handle multiple logins or
>> connections.  Who cases multiple connections per a single login?  I
think
>> we
>> should be able to handle multiple connection on a single login or
multiple
>> logins.  These implementations are very different.
>> 
>> Thanks,
>> Hitoshi
>> 
>> -----Original Message-----
>> From: Greg Shue [mailto:gregs@sdd.hp.com]
>> Sent: Friday, October 16, 1998 8:40 AM
>> To: Nagasaka.Fumio@exc.epson.co.jp
>> Cc: p1394@pwg.org
>> Subject: Re: P1394> connection for Function or Service
>> 
>> 
>> > However, each service requires a multiplexed connection and
>> > each connection requires flow control and send/receive queues.
>> 
>> Whether we multiplex connections over a login or have separate
>> logins, each service is accessed over a connection, and each
>> connection requires flow control and send/receive queues.
>> This is a non-issue in the decision.
>> 
>> A larger issue with "current PC OS" implementation may be how
>> many outstanding requests can be supported at once by the SBP-2
>> driver.
>> 
>> -- 
>> Greg Shue
>> Hewlett-Packard Company
>> All-in-One Division			        gregs@sdd.hp.com
>> ----------------------------------------------------------------






From gleclair at agentz.com  Thu Oct 29 18:14:24 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Agenda for Tucson
Message-ID: <01BE034E.D0DE13E0.gleclair@agentz.com>

I currently have two presentations scheduled for the 1394 PWG meeting 
in Tucson.

1. 1394 Node Model - Alan Berkema
2. 1394 PWG Service Discovery - Greg LeClair
3. Profile / ConfigROM issue discussion. - Berkema / LeClair

If you have materials you would like to present, please let me know the following
ASAP:
- Subject
- Speaker
- Date to expect presentation to be posted.

NOTE: We will be meeting on Monday ONLY in Tucson.

Regards,

Greg LeClair
1394 PWG Chair
greg@erc.epson.com



From gleclair at agentz.com  Thu Oct 29 18:18:08 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Web Site Updated: 10/29/98
Message-ID: <01BE034F.563583C0.gleclair@agentz.com>

I just updated the web site for the first time since it was transferred.

Updates were for information from Monterey, Toronto, and Savannah
- Minutes posted
- Presentations posted

Two new presentations posted for Tucson meeting. See the proposals page:
http://www.pwg.org/p1394/proposal.htm

Regards,
Greg



From lstein at fapo.com  Fri Oct 30 12:41:19 1998
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:52 2009
Subject: P1394> December PWG  Meeting Notice
Message-ID: <4.1.19981030093305.00ab6340@pop3.fapo.com>

Hello,

This is the advance meeting notice for the December 14-18 meetings of the PWG
in San Diego, CA. 

Where:  Downtown Marriott Suites
                701 A Street
                SD, CA 92101

Reservations:   1-800-962-1367

Cutoff Date:    Monday, November 30th

Rate:           $175.00 plus tax        

Group Name:     PWG or Warp Nine Engineering

The expected meeting charge will be $30-$40 per meeting day.

Please make your reservations as soon as possible.

Don Wright will be posting, on the PWG web site, the information for the
January meeting in Maui, and the April meeting in New Orleans.

Thanks,
Larry


***************************************************************
Larry A. Stein                  Phone: (619)292-2742
President                               Fax:    (619)292-8020
Warp Nine Engineering           Web:    http://www.fapo.com
*************************************************************** 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/p1394/attachments/19981030/43a4ec17/attachment-0001.html
From gleclair at agentz.com  Fri Oct 30 13:10:50 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Correction - PWG Site Update
Message-ID: <01BE0565.23188D80.gleclair@agentz.com>

Sorry, 

I didn't transfer the mtg110998 directory.

It's now in place.

Regards,
Greg


From brianb at vcd.hp.com  Wed Nov 11 13:34:39 1998
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:52 2009
Subject: P1394> 1212r Meeting with Joint PWG/PWG-C Meeting
Message-ID: <4.1.19981111102356.00a42340@popmail1.vcd.hp.com>

1394PWG & PWG-C Members,

The IEEE 1212r working group is considering holding a working meeting in between the January joint PWG/PWG-C meeting and the January 1394TA meeting.  The intent of the meeting is to review 1212r progress with the PWG, PWG-C and 1394TA, and to advance the work in progress.  We are looking for interest in such a meeting.

The joint PWG/PWG-C meeting is January 18-22.  The 1394PWG meeting is January 21-22.  The 1394TA meeting is the following week, January 27-29.  Both meetings are being held on Maui.  The 1212r meeting would be a 1 to 1-1/2 day meeting on January 25 and/or 26.  This would allow PWG/PWG-C attendees to stay the weekend and meet with 1212r.  It would also allow 1394TA attendees to come a couple of days early and meet with 1212r.

How many 1394PWG & PWG-C members would be interested in attending this meeting?

Brian Batchelder
Chair, IEEE 1212r
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From shimura at pure.cpdc.canon.co.jp  Tue Dec  8 08:11:14 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:52 2009
Subject: P1394> New command proposal for variable MAX_TASK_SET_SIZE
Message-ID: <199812081311.WAA08871@eva-00.pure.cpdc.canon.co.jp>

Hello, all,

At the last meeting, there was a discussion on the definitions of
"queue" and "connection", but I suppose there was little discussion
on "MAX_TASK_SET_SIZE" parameter along with these new definitions.

From shimura at pure.cpdc.canon.co.jp  Tue Dec  8 08:23:12 1998
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:52 2009
Subject: P1394> New command proposal for variable MAX_TASK_SET_SIZE (Resent)
Message-ID: <199812081323.WAA08929@eva-00.pure.cpdc.canon.co.jp>

Hello, all,

I'm re-sending this message because mail delivery system seems to
misunderstand the period at the beginning of line as end of message.
I'm sorry for duplicated messages.

At the last meeting, there was a discussion on the definitions of
"queue" and "connection", but I suppose there was little discussion
on "MAX_TASK_SET_SIZE" parameter along with these new definitions.

I think there are several problems with current "MAX_TASK_SET_SIZE"
definition, that is fixed value during a login, when combined with
new "queue" and "connection" definitions because number of queues
covered by this parameter during login is not static anymore.

I've attached short document that describes problems and proposes a
solution.

Please find attached document.

I would like to discuss this issue on this list and at upcoming San
Diego meeting.

Are there any suggestions and/or comments?

Akihiro Shimura

--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging System Promotion Project
 CANON INC.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: VarMaxT1.pdf
Type: application/octet-stream
Size: 12642 bytes
Desc: not available
Url : http://www.pwg.org/archives/p1394/attachments/19981208/454772df/VarMaxT1-0001.obj
From vvenkat at teil.soft.net  Wed Dec  9 09:08:40 1998
From: vvenkat at teil.soft.net (Venkatesh V)
Date: Wed May  6 14:00:52 2009
Subject: P1394> Config ROM in 1394!!!(IP over 1394)
References: <199812081323.WAA08929@eva-00.pure.cpdc.canon.co.jp>
Message-ID: <366E8468.512ACCF0@teil.soft.net>

Hi,

While reading through the draft of "IP over 1394", I
came across a register called NETWORK_CHANNELS register
.. but the draft doesnot specify where this is to be 
located ?? Is it part of Config ROM .. I mean unit space ??

Could anybody throw some light on this!!!

Thanx 
Venkatesh.

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Wed Dec  9 17:39:11 1998
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:53 2009
Subject: P1394> 1394 Model & Command Set Proposal
Message-ID: <H0000d9310721fd8@MHS>

     1394 PWG & PWG-C Members,
     
     Please carefully review the attached document and bring a copy to San 
     Diego.
     
     It has evolved somewhat from Tuscon. Actually it has changed to allow 
     Targets to open connections. I believe it still captures the spirit of 
     what we discussed in Tuscon.
     
     I am looking forward to discussing this next week.
     
     I also ftp'd it to pwg-in as pwgpr4x.pdf on the web.
     Don, please move to the right place. (Remove pwgpr43.pdf it is a bogus 
     file transferred as ASCII)
     
     regards,
     Alan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pwgpr43.pdf
Type: application/pdf
Size: 112616 bytes
Desc: not available
Url : http://www.pwg.org/archives/p1394/attachments/19981209/86cd7cb7/pwgpr43-0001.pdf
From jfuller at MICROSOFT.com  Fri Dec 11 14:12:31 1998
From: jfuller at MICROSOFT.com (John Nels Fuller)
Date: Wed May  6 14:00:53 2009
Subject: P1394> Config ROM in 1394!!!(IP over 1394)
Message-ID: <FD8F41F04D35D111899600805F19A16C08B1FD52@RED-MSG-48>

Hello,

NETWORK_CHANNELS is defined in IEEE P1394a, the current draft of which is
available on ftp://ftp.symbios.com/pub/standards/io/1394/P1394a.
_____________________ 
John Nels Fuller 
Program Manager, Windows 2000 
Microsoft Corporation 
One Microsoft Way 
Redmond, WA   98052-6399 
Voice: (425) 703-3863 
Fax: (425) 93 MSFAX 


-----Original Message-----
From: Venkatesh V [mailto:vvenkat@teil.soft.net]
Sent: Wednesday, December 09, 1998 6:09 AM
To: p1394@pwg.org
Subject: P1394> Config ROM in 1394!!!(IP over 1394)


Hi,

While reading through the draft of "IP over 1394", I
came across a register called NETWORK_CHANNELS register
.. but the draft doesnot specify where this is to be 
located ?? Is it part of Config ROM .. I mean unit space ??

Could anybody throw some light on this!!!

Thanx 
Venkatesh.

From gleclair at agentz.com  Sun Dec 13 15:15:23 1998
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:53 2009
Subject: P1394> AGENDA for DEC 14-15 at San Diego,CA
Message-ID: <01BE2692.4D668E40@gleclair.vip.best.com>

1394 PWG Meeting Agenda
December 14-15, 1998
     
1. Meeting Agenda
2. Old Business
      New Proposals
	- Command for variable MAX_TASK_SET_SIZE - Shimura
	- 1394 Model & Command Set - Berkema
      Updates
	- Profile
		- Bridges
	- Config ROM
		- 1212 - Instances, keywords
		- OUI - waiting for RAC reply
3. New Business
      Topics:
      Discussion
4. Plan
      Action Items




From brianb at vcd.hp.com  Thu Dec 17 23:48:12 1998
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:53 2009
Subject: P1394> December 1212r Minutes
Message-ID: <4.1.19981214120217.009c0100@popmail1.vcd.hp.com>

Attached you will find the December 1212r minutes.  

(Greg, could you please post them to the web-site?  Thanks.)

Brian 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/p1394/attachments/19981217/fb87ac58/1212r981209-0001.html
-------------- next part --------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder                            | Hewlett-Packard   
Connectivity Standards Architect            | 1115 SE 164th Ave. 
DeskJet Printers                            | Vancouver, WA  98684 
Phone: (360) 212-4107 | Fax: (360) 212-4227 | mailto:brianb@vcd.hp.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From atsnaka at bsd.canon.co.jp  Thu Dec 24 19:20:25 1998
From: atsnaka at bsd.canon.co.jp (Atsushi Nakamura)
Date: Wed May  6 14:00:53 2009
Subject: P1394> target initiating a Login in a non-logged in situation
Message-ID: <001e01be2f9c$5eb3d500$776a14ac@atsnaka01ii.bsd.canon.co.jp>

In San Diego, we talked about Print(Scan) trigger Solutions for a target initiating a Login 
in a non-loggged-in situation. Though we summariazed that using the 1212 messaging
mechanism was a good idea (and I agree), I have a question ;

How does the target find the SBP-2 initiator in the first place ?

As far as I know, there is no configuration ROM definition for a SBP-2 initiator.
How can a device (target) discover a SBP-2 initator device within the 1394 topology ?

Am I missing a point ?

Ats

p.s. Happy Holidays !

-----------------------------------------
Atsushi Nakamura
-----------------------------------------
BJ Technology Development 22,
Canon Inc.

53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211
tel: +81-3-44-733-6111(ext.5593)
     +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------


From atsnaka at bsd.canon.co.jp  Thu Dec 24 19:45:03 1998
From: atsnaka at bsd.canon.co.jp (Atsushi Nakamura)
Date: Wed May  6 14:00:53 2009
Subject: P1394> P1212r instance directory keywords
Message-ID: <002201be2f9f$cfea58e0$776a14ac@atsnaka01ii.bsd.canon.co.jp>

About P1212r instance directory(FDS) keywords, 

The PWG-C previously proposed several "function_classes"
to the 1212 group, before the keyword concept came out.

Tweaking them to fit the "keyword" format ('a'-'z', '0'-'9', and '-' , no spaces)
I would like to propose the following keywords to the Architecture WG 
through the DSI-WG, as a proposal from the PWG-C.

scanner
printer
fax
disk
storage
camera
modem
display
copy

video
still-image

Comments are welcome !

Ats

-----------------------------------------
Atsushi Nakamura
-----------------------------------------
BJ Technology Development 22,
Canon Inc.

53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211
tel: +81-3-44-733-6111(ext.5593)
     +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------


