Subject: P1394> 1394PWG Meeting Minutes - June 23-24

From: Brian Batchelder <[email-masked]>
Date: Thu, 26 Jun 1997 15:56:09 -0700

Note: I am posting these for Alan Berkema, who took the minutes at the
meeting.

Brian
-----------------------------------------------------------------------------
June 23 1997

IEEE 1394 Printer Working Group minutes

Future meetings
--------------------
1394 TA Architecture meeting 7/31 San Jose
1394 TA DSI-WG meeting 7/31 San Jose
1394 PWG Meeting 8/4-8/5 Redmond

Japan Summary
-------------------
Several companies presented proposals (see PWG-C minutes).
Overall theme revolved around FCP and SBP-2.
Work accomplished on device discovery resulted in an updated proposal 
presented by Canon at this meeting.

Device Discovery General
---------------------------------
Goal is to discover the device independent of a Protocol.
Should not need to know a specific protocol to enumerate imaging devices
on a 1394 bus.

Canon Device discovery based on work at the PWG-C meeting in Japan
----------------------------------------------------------------------------
Atsushi Nakamura presented. See the Canon proposal on www.pwg.org web site.

Terminology -

Device (node) Discovery
  - mfr. Model# of node
  - 1394.x support
  - unique ID (serial number, GUID)

Unit (function) Discovery
  functional unit class (ex. printer)

Low level Service Discovery
  availability of the lowest layer above the 1394 transaction layer - the
datalink layer

High-level Service Discovery
  command set, image format

Some of the Issues were discussed at length

Nature of IEEE 1212 config ROM. Does it need to be physical ROM.
Conclusion is that it must obey the spirit and intent of a ROM.
  Information is static between bus resets
  Always responds with valid information
  Not writable
Actual implementation could be RAM, ROM or Flash as long as it conforms to
rules above.

Status Retrieval at device discovery level. Consensus seemed to be that
true status retrieval should be at the protocol level. Do we need anything
beyond the device responds to 1394 reads of the config ROM so it must be
alive?  This will probably not be part of p1394.X

Revised some previous discussion of a device acting as a "proxy" for other
devices by providing config ROM information indicating that a device such
as a PC could be a 1394 printer. Proposed calling this a "bridge" function.
Example a PC could state that it was a 1394 printer and bridge the 1394
print job to a standard Parallel port printer.

For Device Discovery
--------------------------
Root Dependent Directory approach vs. Unit Directory approach.

1) Hierarchically the root describes all functions before searching Unit
directories.
2) Unit directories refer to I/O driver software (communication protocols)
and FCP already defines sub functions using FCP.

The Root directory is a bus level concept if we want to add information at
the Root we should take it to the IEEE 1212 committee. The scope of this
effort has a greater global impact on other devices. 

Could also accomplish device discovery with a New Unit Directory.

What approach is architecturally consistent with how devices currently work?

Need to write this up and submit it to the 1394 TA Architecture Working
Group and/or the 1212 committee (or the appropriate persons) in terms of
what we are attempting to accomplish and what is the best way to accomplish
it.

Canon High Performance Transport Concept using Shared Memory Model
------------------------------------------------------------------------------
Shigeru Ueda presented. See the Canon proposal on www.pwg.org  web site.

  Efficient Use of High Bandwidth
    Data Movement Copy Bottleneck
      Wastes CPU power by slow Main Memory Access
      Cache miss by reduced locality of reference in Memory Access
    OS Involvement in all I.O activity
    
  -> Split control headers from data itself
  -> List delivery schedule

   Short summary of the concept is that it will use SBP-2 to move the data.
The 
   details of the command set will be presented in the future.

PAR - Project Authorization Request.

This will be submitted to the Microprocessor Standards Committee (MSC) on
July 14 1997.  The MSC is the standards body that sponsors the IEEE 1284.x,
IEEE 1394, IEEE 1212 and others.

Discussion on whether or not we need to PARs.
1) Broader specification for device discovery that covers a wide range of
devices beyond Imaging Devices and Multi Function Devices.
2) p1394.X printing over IEEE 1394.

June 24 1997

PAR discussion. 

Don Wright presented the first one on device discovery. The title is 
provided below. The textual description will be sent out on the reflector.

	"Standard for node and Unit function discovery for Control and Status 
Register (CSR),  ISO IEC  13213 ANSI/IEEE Std 1212, architecture
implementations on the IEEE Std. 1394-1995 Serial Bus.

Greg LeClair presented the  "P1394.x Printing Protocol" scope and purpose.
The textual description will be sent out on the reflector.

	The standard defines a printing protocol for use on IEEE Std 1394-1995
High Performance Serial Buses.

Requirements for Printing Protocol
-------------------------------------------

Access Control (Login)
	Fair Access
	Does this provide a way to determine how many Logins does a node have
* Issue: does the thin (FCP) protocol require Access Control?

In order delivery of Data
Flow Control
Guaranteed Delivery
	Error Detection
	Correction/Recovery
Multiple Independent (Logical) Channels (Is a single channel Bidirectional?)
PDL, Application and OS Independent
Standard will allow con-current operation of multiple Protocols
_____________________________________________________________

Implementation Goals:
	- Physical Interface Independent
	- Extensible
	- Low System Overhead
	- Backwards Compatible

New Conclusion: If a form of SBP-2 works with a yet to be defined SBP-2
Printer 
Command Descriptor Block (PCDB) we may not have enough effort to submit a
second PAR.  Similarly 1284.4 over SBP-2 may not be a new standard, it
could be a 1394 printing implementation guide or recommended practice
document.

So,
	1394 Printing Effort
		o Discovery
		o Thick - SBP-2 plus new Printer Command Descriptor Blocks.
		o FCP plus AV/C Commands
		o Data Formats

Further,

We concluded that we DO believe we a sufficient effort to submit the Device
function discovery.

We do not currently believe we have enough to submit the "P1394.x Printing
Protocol" PAR.

We will continue by refining a new "Requirements" document using our Scope
and Purpose and the 1284 SIMPLE Document.

Actions:
----------
1) 6/24/97 - Locate the web site or electronic copy of the Disk Boys Command 
Descriptor Block document for SCSI-3
Owner: Greg Leclair
Status: Done
ftp://fission.dt.wdc.com/pub/standards/sbp/incoming/

2) 6/24/97 - 1394 PWG "P1394.x Printing Protocol" Requirements document.
Owner: Brian Batchelder

3) 6/24/97 - Transport research on SBP-2 Printer Command Descriptor Blocks.
Owner: Alan Berkema

4) 6/24/97 - Transport research on SBP-2 Printer Command Descriptor Blocks.
Owner: Alan Berkema

5) 6/24/97 - Transport research on SBP-2 Printer Command Descriptor Blocks 
with respect to Canon proposal.
Owner: Shigeru Ueda

6) 6/24/97 - Discovery PAR
Owner: Greg Leclair

7) 6/24/97 Common Image Data Format
Owner: Atsushi Nakamura, Lee Farrell

8) 6/24/97 Research FCP Implementations, does it meet the PWG requirements
Owner: