Subject: P1394> September Meeting Minutes

From: "gregory leclair" <[email-masked]>
Date: Tue, 23 Sep 97 09:40:56 PDT

Attached are the September meeting minutes. They have also been posted 
     to the PWG website on the documents page.

     Greg LeClair

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

          1394 Printer Working Group
          Atlanta Meeting - 9/15 & 9/16
          
     Attendees:
     Don Wright                 Lexmark / PWG Chair
     Greg LeClair               Epson / 1394PWG/1212 Task Group Chair
     Larry Stein                        Warp 9 / 1394PWG Secretary
     Brian Batchelder           HP / 1394 PWG Editor
     Fumio Nagasaka             Seiko Epson     
     Yoshinori Murakami Epson
     Atsushi Nakamura           Canon
     Osamu Hirata               Canon
     Shigeru Ueda               Canon
     Akihiro Shimura            Canon
     Brian Nagy                 Kodak
     Jerry Thrasher             Lexmark
     Greg Shue                  HP
     Alan Berkema               HP
     Lee Farrell                        Canon
     Randy Turner               Sharp
     
          Agenda
          
          I. Introductions
               
          II. Next meetings:
          Boulder/Denver 10/27 & 10/28
          Los Angeles 12/1 & 12/2
          Hawaii (January - TBD)
          
          III. Meeting Plan:
             FDS 
                     - Presentations
                     - Discussion
             Transport 
                     - Presentations
                     - Discussion
             Documents
                     - Sub-working group(s) on 9/16 afternoon & 9/17 all 
     day
          
          IV. How to bring closure and issue results
             FDS proposal (PWG & PWG-C)
             SBP-2 based printer definition (PWG)
             FCP based printer definition (PWG-C)
             IP/1394 based printer definition (TBD)
          
     Meeting called to order at 8:38 by PWG chair Don Wright.
     $42 per day meeting charge.
     
     I. Introductions
               
     II. Next meetings:
          Boulder/Denver 10/27 & 10/28
     
     Boulderado Hotel
     2115 13th St.
     Boulder, CO 80302
     Ph. 303-442-4344
     Reservations 1-800-433-4344
     $104 standard
     $114 Deluxe
     
     The October meeting could not be moved because the meeting contracts 
     have already been completed.
     
          Los Angeles 12/1 & 12/2
     
     1998 Schedule:
          Hawaii (January - TBD)
     Jan 19-23 or 26-30
     
     (Schedule proposal to be posted separately. - GL)
          
     Don Wright asked Greg LeClair to approach 1394 TA Steering Committee 
     if future meetings could be arranged +/- 1 week to allow attendance by 
     members from PWG-C at both meetings.
     
     1394PWG meeting started here.  
     Greg LeClair - Chair
     
     III. Meeting Plan:
     
     Ats Nakamura, Canon made presentation on the PWG-C.
     PWG-C met in September.  The FDS will be a PWG-C proposal to PWG. The 
     PWG-C expects to present the Direct Printing Proposal at the DSI 
     working group at the 1394TA. Target date for 1st draft is October. 
     
     III.A.        FDS  
                     - Presentations
                     - Discussion
     
     Please refer to spec posted on the pwg web site: FDS05.PDF
     
     "How do we find a printer in a multi-device topology?"
     We don't want to utilize a specific protocol just to find a function 
     in a topology. Other proposals include:
             SDD - Self Describing Devices (Sony proposal)
     
                     Add key "mode_unit_id" to 1212 structure.
     
     We should define what we mean by "Independent" functions as used in 
     the 'function_class' key.
     
     The 1394PWG will seed the initial function_class keys.  The list will 
     be extensible and maintained by the IEEE RAC.  The initial list will 
     include:
             printer
             scanner
             fax
             multi-function
     
     Motion made by Larry Stein to adopt the FDS Ver. 0.5 specification as 
     the basis for Function Discovery for 1394PWG. This will become Version 
     0.1 of the PWG1394 Function Discovery specification.  
     This includes:
             - New root entry for FDS support
             - Point to directory of function descriptor.
             - Configuration change flag
             - Function_List definition and contents
             - Function_Description definition and contents
             
     Seconded by Randy Turner, passed without objection.
     
     Open issues for fds05 include:
             - Exact number of keys
             - Exact format of keys and fields
             - Driver info block
             - Does a suitable global registry exist?
             - Do we make the registry extensible?
             - Do we make the registry bus dependent?
             - Do we seed the registry with certain functional classes?
             
     Plug and Play (Microsoft PnP spec for 1394) requires a separate unit 
     directory for each function.  This is different than the current 
     implementation for SBP2 and AV/C protocols.
     
     End of day 1.
     
     Day 2
     Meeting called to order at 8:45AM
     
     III.B Transport
                - Presentations
     
     III.B.1        Greg Shue -- Parallel Port Replacement Protocol 
     Requirements
     Outline of services that are provided on a parallel port that may need 
     to be provided on a 1394 system. This may be used as a set of 
     requirements with which to measure transport protocol options.
     
     Required services to emulate connectivity of the parallel port:
             Connection Oriented
                     Access Control
             Reliable
                     Guaranteed Data Delivery
                     Flow Control
                     Error Detection
                     Error Correction/Recovery
             In Order Data Delivery
             Service Discovery
     
     Direct Print Protocol requirements as defined by PWG-C for thin layer:
     (R is a requirement as determined by 1394PWG, W is a want)
     R        1- Symmetrical Connection
                     Peer to peer start of connection
     R        2- "Real Time" Processing
                     Unsolicited Status indication
     R        3- Multi-channel
                     Independent channels for Command and Data, for example
     W        4- Dynamic allocation of memory
                     Full usage of 1394 memory model
                     (not like FCP with fixed window location and size)
     R        5- Flow control of Command
                     push
             6- Flow control of data
     R                push
     R                pull
     W                ISO
     R        7- Negotiation
                     memory allocation
                     data flow
                     other parameters
     R        8- Packet Segmentation
     R        9- Error Recovery
                     reconnect
                     timeout
     Low priority items:
             10- Compatibility with FCP/AVC
                     not a requirement to be FCP
             11- Multilogin
                     multiple host
             12- Multicast
                     host to multiple ports/devices
     
     OSI(ish) Model for 1394PWG
     APP
     Session
     Transport
             peer to peer
             full usage of memory bus model
             Negotiable transfer sizes to maximize use of MTU (Maximum 
     Transfer Unit)
             Flow Control
             Negotiation
             Service Discovery
     Datalink
             CSR interface at device specific location
             Flow control
             CSR access negotiation
             Transient Connection Disruption Tolerance
             Node update - routing to transport
     Transaction
             Read-Write lock
     Phy

     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
     Believe that #3, Prioritize logins, is the best solution
     This will implement a Primary host login but allow for other hosts to 
     login.  Additional hosts will login as Secondary priority hosts.
     Latest Epson proposal is available on the PWG website.  
     
     III.B.3         Akihiro Shimura - Canon
     HPT  High Performance Transport
     HPT is a Command set layer on top of SBP2 that adds the functionality 
     of the required transport.
             Full duplex communication
                     Queuing model
                     Request based Flow Control
                     3 command, 2 status
                             data transfer
                             read request, requested read
                             direct status, direct status response
             Primitive device control/status
                     4 command, 3 status
                             Acquire, Release, Abdicate device response
                             Basic device status
             Logical Channel
                     2 command, 2 status
                             Open, Close channel
     
     HPT Objectives
             High performance with low overhead
             Bi-directional data transport
             Multiple service channels
             Application independence
             Backward compatibility with bus environment support
             Self configurable (like 1284.4 open channel), no prior setup 
     required
     
     Please review specification at 
     ftp://ftp.tokyoweb.or.jp/pwgc1394/pub/proposals/canon/HPT03E.pdf and 
     it is also available on the 1394 PWG web site.

     III.B.4        Alan Berkema -- Hewlett-Packard
     FCP or SBP2 versus Printing Protocol Requirements
     SBP2
             Not true bi-directional communication
             Bi-directional extensions complicated and troubled
             ORB fetching considered "heavy protocol"
     
     FCP
             No access control
             Fixed communication address
             Does not extend to multiple devices
     
     Proposal        DFA -- "Data FIFO Address Protocol"
     Create an Inbound and Outbound Queue on each of the initiator and 
     target
             Both sides push data into the peer's data fifo
     Login and Login Response
             Provides access control
             Facilitates connection to multiple devices
             Allows simple reconnection
             Provides for unsolicited status
     Limited Loginless status through query logins
     Need data FIFO address exchange mechanism
     
     Pros
             Borrowed from IP1394
             Sort of FCP like
             Bi-direction communication
             Efficient 1394 unified block write transactions
             simple, easy to explain
             command set independent
             easily add higher layer protocols
             Logins do not add that much weight to FCP
             Extensible to multiple devices
     cons
             Does not take advantage of 1394 shared memory
             Do packets need additional header info
             Does not address flow control                        
     
     Could use this as a datalink layer for a 1284.4 transport client.

     III.B.5        Review of requirements for Thick Transport Protocol 
     stack (TP/DL/PHY)
     
     Requirements:
     1.  Connection Oriented
             Open and close and connection to a service.
             A connection between two endpoints
             A service is above the transport.
             One connection cannot block another
     2.  Reliable
             Data is received correctly and in order of transmission
     3.  Byte steam and Buffer interface to the application
     4.  Service Discovery
             Provides directory of services available to the transport.
             Provides query support
     5.  Multiple Logical Channels
             Allows multiple and independent connections to a device or 
     between different devices
     6.  Bi-directional data transfer
     7.  Peer to Peer
             Either end may open or close a connection
     8.  Application independent
     9.  Does not preclude concurrent operation of other protocol stacks
     10. Transient link interruptions are transparent
     
     Wants:
     1. Connectionless support
     2. Multi-casting
     3. Bus Independent transport
     4. Data Tagging (Out of Band)
     
     Clarifications
     Connections:
             peer to peer (open/close/data) from either end
             bi-directional
             1:1 relationship between endpoints
             Reliable

     III.C Documents
           - Sub-working group for FDS will meet on 9/17.
        - See following comments from 9/17 meeting:

     IV. How to bring closure and issue results
             FDS proposal (PWG & PWG-C)
             SBP-2 based printer definition (PWG)
             FCP based printer definition (PWG-C)
             IP/1394 based printer definition (TBD)
     
     Discussion on above topics was raised by Greg LeClair. Don Wright 
     proposed that the discussion on requirements be formalized and each 
     proposal submitter explain if requirements were met by their proposal.
     
     Plan accepted and reflected below in Action items.
     
     V. Action Items
     1. FDS sub-group to meet on 9/17 and begin revising FDS doc.
        (Nakamura, Nagasaka, Murakami, Thrasher, LeClair)
     2. Requirements doc to be published ASAP
        (Shue, Batchelder)
     3. Comparison of Proposals to Requirements doc to be published at 
        least 1 week prior to Boulder meeting for consideration by WG. 
        Comparison and updated proposals should be sent to Greg LeClair 
        for posting by 10/20.
        (All proposal submitters)

     Sub-working group meeting on FDS - 9/17.
     
     Goal of meeting today:
     Put document into public hands
     - Items in questions that need addressing:
       - Key value 18h - ConfigROM dynamic nature????
       - Establish rule of usage - boundary conditions
       - Configuration_state change -> Configuration register
        - forcing it to Random number may preclude use by a 
          vendor as a '1 of  n' configuration value 
        - Consider allocating space and recommending usage. 
                - Exact value is vendor dependent.
     
     Nagasaka asked question if we really need FDS as it is defined
        - Reason: existing mechanism - re-read ConfigROM
        - GL this is non-deterministic, 
                - Configuration change identifier tells us if ROM is 
     changed
        - Global point of view 
                - Config_Identifier is just for FDS or global for ConfigROM 
     
     Document Action Items:
     
     Title suggestions
     Terminology:
     Greg will draft explanation for forward.
     - Big picture List of function and Unit identifier
     Greg will send Ats a list of terminology changes
     - i.e. we used this - now should be this
     
     Rewrite document to utilize same terminology as IEEE-1212
     - Possibly add new terminology to identify new items (FUNCTION)
     - Change Annex A to informative
     
     Point out contentious issues in the Overview
      - Issues TBD
      - Past discussion history 
        - Issues addressed & resolution (Like SBP-2 spec)
     
     Current issues:
     - scope of configuration identifier (just FDS or entire config ROM )
           - Scope is just FDS or entire Config ROM
           - break value into fields to identify what has changed.
           - Possibly other method, needs investigation.
         
     - Function Class categorization 
           - How is it represented - pair of FUNCTION & UNIT IDENTIFIER
           - Central RAC for all "FUNCTION CLASSES" (IEEE RAC? others)
           - Value for UNIT IDENTIFIER 
        - Pointer to Unit directory or 
        - same as (which Key?) in the Unit directory to identify the "I/O 
     driver software"
         
     - Annex A - Function Unit Info field
           - Usage is TBD
        - 1394 PWG is discussing content such as legacy PNP string.
        - Feedback appreciated
        - Will be made informative at this time.
     
     Nagasaka raised issue of power management for multi-function unit
     - Requires further discussion, decided it did not directly affect FDS 
     and further discussion was postponed.
     
     Meeting closed.

     Submitted by:
             Larry Stein
             Warp Nine Engineering
             [email-masked]
      and 
          Greg LeClair
             EPSON Imaging Technology Center
             [email-masked]