1394 PWG - Issue No.970514-007

1394 PWG - Issue No.970514-007
Back to the Issues Page
ISSUE NO.:970514-007NAME:What should CSR and Config ROM look like for a printer device with a 1394 Interface?STATUS:In Process
RESOLUTION:DATE:TBD
ORIGIN:05/14/97 Meeting in San Diego
DESCRIPTION:Basic question dealing with the model of a 1394 printing device.
DISCUSSIONS:
  • CSR and Config ROM definition provides the Basic Framework for Device and Service Discovery mechanisms. Each device node must meet IEEE 1212 and IEEE 1394 requirements. Therefore, the Config ROM basic structure:
    • 1212 CSR
    • 1394 CSR
    • Details of Printer/Imaging Device Class
      • Device (functional unit)
      • 1284 Device ID
      • -Unit - Unit ID (Printer)
        • Services
      • -Unit - Unit ID (Scanner)
        • Services
    • Sample Device Models to consider
      • D1 - Two functions - separate nodes
        A simple printer and a scanner (separate physical devices) are two separate device nodes. In this example each device node contains one functional Unit. Each Unit will have all of the device node bandwidth.
      • D2 - Two or more functions - single node
        D2- A MFP device comprised of a printer and scanner is a single node with two functional Units. In this example each Unit will share the device node bandwidth.
      • D3 - Two or more functions - single node - multi-protocol
        D3- A MFP may be a single device but may need to operate with one or more protocols simultaneously.
    • Issues to be resolved:
      • A- CSR and Config ROM defines how we identify the device node.
      • B- Device Discovery reads CSR and Config ROM to implement automatic installation options.
      • C- Service Discovery reads CSR and Config ROM to implement protocol selection.
      • D- A device node may contain one or more functional Units.
      • E- IEEE Std. 1284-1994 provides legacy device ID string which is used by the existing Printer Class installer code on Windows. This could be an appropriate low-level identifier for 1394.
      • F- What are the minimum requirements that we will define?
    • Update of issue from 6/23/97 Meeting in Nashua
      • 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(Issue: initializing state). Not writable (See IEEE-1212). Actual implementation could be RAM, ROM or Flash as long as it conforms to rules above.
      • Configuration ROM for a "proxy" device.
        • 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.
    • Update of issue from October 27th Meeting in Boulder, CO
      • Device Discovery -> Function Discovery
      • The group walked through a proposed Unit Directory and Function Descriptor Directory content:
        • To define a 1284.4 architecture on top of SBP-2, we would need a RAC assigned ID for 1284.4
          • Left as an open item for chair of 1284.4
        • Function Directory
          • Function Class Pointer (pointer to Unit Directory)
          • Textual Descriptor "Printer", "Scanner, "Fax", "MFP", etc…
        • Unit Directory
          • Unit_spec_id
          • Textual Descriptor "SBP-2", "FCP", etc…
          • Unit_dependent_info (pointer to Function Descriptor Directory)
          • Unit_vendor (proposed key)
          • Textual Descriptor
          • Unit_model_id
          • Textual Descriptor
          • Two new keys were proposed for the Unit Directory:
            • Unit_vendor_id key
            • Unit_model_id key
        • Function Descriptor Directory
          • Function Class Pointer (pointer to Unit Directory)
          • Model Number
        • Suggestion made to include Manufacturer in the Unit Directory.
          • We would take it to 1212 WG.Function Class Pointer (pointer to Unit Directory)
          • Otherwise we could define or own ID string.
          • Left open at this meeting
          • "Appropriate information that should be necessary for interoperability, but not already included in other directories"
        • Issue was raised on how Service_channel assignments would be encoded, if at all.
          • Part of the Function Descriptor Directory would include a list of service channel assignments, using the channel number as the key value. An additional three bytes would point to a text leaf which contained the IANA-registered service string which is assigned to that channel.
        • Recommendation from member of 1212WG and PWG-C that 1394 PWG should come up with list of fucntion classes. No action taken at this meeting.
    • From April 6th, 1998 Meeting in Portland, OR
      • Correct Hierarchy for identifying the PWG solution:
        • Command_Set_Specification_Id
          • standards organization of your choice
        • Command_Set
          • PWG Transport Command Set (TCS)
        • Service - new ROM entry -- TBD
          • LPR
          • TIPSI
          • IPP
          • "Bass-o-matic"
        • Action:
          • How will PWG define its own command set?
    • From May 18th, 1998 Meeting in Crystal City, VA
      • Config ROM
        • Group agreed on the following "NEEDS":
          • General format
          • Bus Information Block with unique EUI-64
          • Root Directory
          • Module_Vendor_ID (and textual descriptor that provides a human readable message that identifies the vendor)
          • SBP-2 Unit Directory
          • At least one Unit Directory
          • LUN 0 with Device type field
          • Unit_Spec_ID = 00609Ih
          • Unit_SW_Version = 010483h
          • Vendor ID, Model ID and textual descriptors (with informative annex that discusses implementation considerations under Windows O/S and adoption of Unicode for internationalization)
          • p1394a enhancements
          • generate bits
          • FDS
        • Issues:
          • It was noted that the textual descriptors should not be used to determine feature capability or behavior.
          • The question of what OUI will be used for the command set Spec ID remains as an unresolved issue.
    • From July 6th, 1998 Meeting in Monterey, CA
      • Config ROM
        • Draft spec posted. No comments expressed on reflector or in minutes.
          • It was noted that the textual descriptors should not be used to determine feature capability or behavior.
          • The question of what OUI will be used for the command set Spec ID remains as an unresolved issue.
      • OUI Issues
        • Chair suggested we need to procure an OUI for the 1394 PWG Command set. No resolution.
        • Suggestion that IEEE 1212 group should maintain the list of Function Classes. (not really relevant to OUI)
        • Further discussions were deferred.
    • From August 17th, 1998 Meeting in Toronto
      • Config ROM Draft
        • Draft spec was reviewed.
          • Discussion about the section on Device Discovery
          • Should a Bus Reset be generated every time the device configuration changes and a corresponding change to the values of the Config ROM is possible.
        • Config ROM Issues
          • What cases would cause sufficient level of Config ROM change to warrant a Bus Reset?
          • Group feels that a class registry monitored and maintained by the 1212r group. Issue is how to maintain after that group is finished.
          • Group decided that we should wait until the Config ROM document is updated to reflect the most recent 1212r activity and reviewed by the group before it is included into the profile.
      • OUI Issues
        • Chair discussed the issue of Organizationally Unique Identifiers (OUI):
          • Need for a OUI to complete 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?
          • Issue:
            • Would the 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?
            • Suggestion to obtain an OUI from the 1394 TA, however, we get back to organizational issue on ownership of spec and complying weith their by-laws.
          • Summary:
            • Motion made, seconded and passed unanimously to ask the PWG members to purchase and OUI from the IEEE RAC.
            • The chair volunteered to write up a proposal
            • Proposal was accepted at the PWG plenary on Wednesday, August 19th, 1998.
    • From September 28th, 1998 Meeting in Savannah, GA
      • Config ROM Draft and OUI Issues
      • Summary: Were not addressed at this meeting
    • From November 9th, 1998 Meeting in Tucson, AZ
      • Config ROM Issues:
        • 1212r WG is trying to define function classes.
        • A suggestion is to use Keywords that best describe the product or function.
        • The 1394 PWG may have some recommended keywords to use which describe common devices.
    • From December 14th, 1998 Meeting in San Diego, CA
      • Config ROM Issues:
        • 1212r is leaning towards keywords which provides a description of the device function. These keywords would not require registration. This returns us the similar situtation of the 1284 Device ID string where popular demand dictated the "common" keywords used by most implementations.
        • 1394 PWG needs to provide a list of what keywords would apply to devices considered by this group. Group developed the following list as a brainstorming exercise.
          • printer
          • fax
          • mfp
          • color
          • sbp-2
          • photo
          • laser
          • ink
          • inkjet
          • thermal
          • dye-sub
          • pcl
        • Summary:
          • The following 1212 Keywords were identified for Functions
            • Printer
            • Scanner
            • FAX
          • The following 1212 Keywords were identified for Attributes
            • Color
            • Laser
            • Inkjet
        • Issues:
          • Question as to whether we provide keywords for functions or attributes of services? Or both?
          • Should these go into the feature directory?
    • Update of issue from January 21st, 1998 Meeting in Maui, HI
      • Config ROM Document Review: CFGROM02b.pdf
      • (Note document was revised based on comments received during the meeting and posted as: CFGROM03a.pdf)
        • Summary:
          • General opinion was the document was moving in the right direction.
          • Suggestion to not repeat what is in other specs unless we are adding or changing something.
          • Currently document contains two examples.
          • Suggestion was to include samples for concrete devices (printer, scanner, printer / scanner MFP and an SBP-2 / DPP printer).
        • Service Discovery:
          • Proposal to use the Keyword Leaf defined in 1212r as a container for the service names supported by the node.
        • Issues:
          • Changes noted will be rolled into a new version.
          • Noted that we need to ask p1212r to change the ASCII encoding for Keyword Leaf to uppercase characters to match IANA standard.
    • Update of issue from March 1st, 1999 Meeting in Miami, FL
      • No comments received before or during meeting.
Back to the Top of the Page
Back to the Issues Page / Back to the Top of the Page

Go To 1394 Home

If you would like to contribute any input, contact Greg LeClair.
Last modified May.18.1999.