Subject: P1394> EMAIL Poll

From: "Gregory A. LeClair" <[email-masked]>
Date: Mon, 23 Feb 1998 18:35:51 -0800

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 - [email-masked]

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: Atsushi_Nakamura <[email-masked]>
Date: Tue, 24 Feb 1998 12:53:04 +0900

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 

-----------------------------------------

<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):[email-masked]

email(2):[email-masked]

-----------------------------------------

---

From: [email-masked]
Date: Tue, 24 Feb 1998 09:52:29 -0800

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.

     
        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,  

  (   )   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: Greg Shue <[email-masked]>
Date: Tue, 24 Feb 1998 11:00:37 -0800 (PST)

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

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

	  See above comments

	  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			[email-masked]
----------------------------------------------------------------

---

From: Nagasaka Fumio <[email-masked]>
Date: Wed, 25 Feb 1998 21:22:55 +0900 (JST)

On Mon, 23 Feb 1998 18:35:51 -0800
	( 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)__________________

> 	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: Atsushi_Nakamura <[email-masked]>
Date: Thu, 26 Feb 1998 17:59:20 +0900

snip>

I changed the order of the questions around to explain my position; 

FIRST,

  	(   )   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;

 	(   )   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

53 Imai Kami-cho

---

From: Toru Ueda <[email-masked]>
Date: Fri, 27 Feb 98 18:11:19 JST

---- 

The answer is for PC printing. 

Also,  

  (   )   There should be ONLY 1 printing protocol in any case and any
application. 
  ( X )   2 protocols are ACCEPTABLE if necessary for different
situations

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.

> 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)__________________
> 	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: Akihiro Shimura <[email-masked]>
Date: Sat, 28 Feb 1998 00:24:46 +0900 (JST)

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

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.

   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 <[email-masked]>
 To: "[email-masked]" <[email-masked]>, "'1394 PWG'" <[email-masked]>
 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 ([email-masked])
 Office Imaging Products Development Center 3
 CANON INC.