Hello PWG members and PWG-C members,
A mistake was found in the body of the minutes I sent you before.
Please change it to the file attached in this mail.
------------------------------------
(The mistake in the section 4.5.3.)
Nagasaka-san demonstrated a hot plug and play of a modified Epson printer.
It showed the Macintosh registering a "Firefly" printer driver.
-- (Correct description) Nagasaka-san demonstrated a hot plug and play of a modified Epson printer. It showed the Macintosh registering a "FireWire" printer driver. ------------------------------------(Also, it still seems to remain some troubles with opening the file. So , I converted it to text file.)
Best Regards, Nobuhiro Ohnishi
--=====================_866649155==_ Content-Type: text/plain; charset="ISO-2022-JP" Content-Disposition: attachment; filename="970611-12min-cor.txt"
IEEE1394 PWG-C MEETING MINUTES
1 Date: June 11-12, 1997 2 Place: Microsoft Japan Sasazuka Office Apple Japan Hatsudai Office (sub meetings on June 12) 3 Meeting Attendees Name Company (11-Jun 12-Jun) Toru Takano Adaptec Japan Ltd. (∨∨) Stephen N. Zilles Adobe Systems Incorporated(∨∨) Junji Iwane Apple Japan Inc. (∨∨) Kiyotaka Ohara Brother Industries,ltd. (∨∨) Akihiro Shimura Canon Inc.(∨∨) Kouji Fukunaga Canon Inc.(-∨) Atsushi Nakamura Canon Inc.(∨∨) Naohisa Suzuki Canon Inc. (∨-) Nobuhiko Shinoda Canon Inc.(∨∨) Nobuhiro Ohnishi Canon Inc.(∨∨) Shigeru Ueda Canon Inc. (∨∨) Takashi Isoda Canon Inc. (∨∨) Lee Farrell Canon Information Systems (∨∨) Kyouichi Ohno CASIO Electoronics Manufacturing Co.,Ltd.(∨-) Yoshinori Murakami Epson Imaging Technology Center (∨∨) Fumio Nagasaka Epson Software Development Laboratory(∨∨) Tanizaki Masanori Epson TP System Design (∨∨) Fumihiro Funazaki Fuji Photo Film Co., Ltd.(∨∨) Mikio Watanabe Fuji Photo Film Co., Ltd.(∨∨) Kazuhiro HiRATA Fuji Xerox Co.,Ltd.(∨∨) Tatsuya Matsumoto Fuji Xerox Co.,Ltd.(∨∨) Akira Karasudani Fujitsu Labs. I/O Systems Lab. (∨∨) Yasuhiko Nakano Fujitsu Labs. I/O Systems Lab. (∨-) Yoshiyuki Okada Fujitsu Labs. I/O Systems Lab. (∨-) Alan Berkema Hewlett-Packard Company (∨∨) Brian Batchelder Hewlett-Packard Company (∨∨) Richard Andrade Intel Corporation(∨∨) Kazushige Harada Kobe Steel, Ltd.(∨-) Shigeo Tochino Kobe Steel, Ltd.(∨-) Shoji Akashita Kobe Steel, Ltd.(∨-) Hiromi Jyoshita Kyusyu Matsushita Electric (∨-) Don Write Lexmark International, Inc.(∨∨) Takahiko Nankou Matsushita Electric Industrial Co.,Ltd. (∨∨) Yasuo Nishiwaki Matsushita Electric Industrial Co.,Ltd. (∨∨) Kiyonori Sekiguchi Matsushita Graphic Communication Systems, Inc. (∨∨) Keisuke Tsuchida Microsoft Co., Ltd(∨∨) Toshio Shimoaraiso Microsoft Co., Ltd(∨∨) Yasushi Nagao Microsoft Co., Ltd(∨∨) Yasunari Kitagaki Minolta Co., Ltd.(∨∨) Hironori Nagai NEC Corporation (∨-) Mikio Saisu NEC Corporation (∨∨) Kiwamu Sumino Nippon Motorola Ltd.(∨∨) Mitsuhisa Kanaya Ricoh Company, Ltd.(∨∨) Okubo Akinori Ricoh Company, Ltd.(∨∨) Kyoji Marumoto Rohm Co., Ltd. (∨-) Shigemichi Aoki Rohm Co., Ltd. (∨-) Hiroshi Wakai Sharp Corporation(∨∨) Masahiro Ohsawa Sharp Corporation(∨-) Toru Ueda Sharp Corporation(∨∨) Hiromitsu Kurokawa Sony Corporation(∨∨) Makoto Sato Sony Corporation(∨∨) Takashi Kojima Sony Corporation(∨∨) Yorihiko Sakai Sony Corporation(∨∨) Masakazu Kikuchi Syou Engineering(∨-) Danny Mitchell Texas Instruments Incorporated(∨∨) Junichi Komura Texas Instruments Japan Limited (∨∨) Keijiroh Kaneda Texas Instruments Japan Limited (∨∨) Akira Saitoh Toshiba Corporation (∨∨) Noriko Kure Toshiba Corporation (∨∨) Yoshiki Hayakashi Toshiba Corporation (∨-) Katsuhiko Terada Victor Company of Japan, Limited(∨∨) Larry A. Stein Warp Nine Engineering (∨∨) Masanori Gonda YASKAWA Information Systems Co., Ltd. (∨-) Kazuo Nagata Yokogawa Electric Corporation (∨-) Makoto Simizu Yokogawa Electric Corporation (∨-)
4 Detailed Activity The meeting was opened by Shinoda-san. The PWG members from U.S. and the PWG-C members introduced themselves. He presented the proposed agenda topics:
1.General Session: 1-1 Self Introduction 1-2 PWG-C Past Activities Summary PWG-C SC 1-3 PWG Past Activities Summary Larry Stein 1-4 DSI-WG Foundation Announcement SONY 2.Learning Session: 2-1 FCP SONY 2-2 SBP2 T.B.D. 3.Proposals: 3-1 Fuji Photo Film 3-2 EPSON 3-3 Canon 3-4 Sharp 3-5 Hewlett Packard 3-6 SONY 3-7 other companies 4 Misc. 4-1 1394 Analyzer YEW 4-2 Additional presentation if any member has topics without technical proposal drafts, demonstration etc. 4-3 Next day scheduling
New company members (RICOH) were announced. 4.1 PWG-C Past Activities Summary PWG-C SC (slides) A list of the past PWG-C meetings was presented by Shinoda-san. 4.2 PWG Past Activities Summary Larry Stein (slides) Larry gave a summary: ・瘢雹 Formed in Feb 1997, became an IEEE Study Group. Submitting a Project Authorization Request at July MSC meeting ・瘢雹 Put group on track to generate an International Standard ・瘢雹 Hope to become a standard within a year - "fast track" ・瘢雹 Proposed title: "Standard for Device and Service Discovery for Printing on an IEEE Std. 1394 Topology" ・瘢雹 Scope: (see slides) ・瘢雹 Pupose: (see slides) ・瘢雹 Proposed IEEE 1394.x * Will hold meetins jointly with the PWG. * Will coordinate with the 1394TA via Greg LeClair * Coordinate with PWG/C via reflector, joint meetings and open communication ・瘢雹 Next Meetings: * June 23-24 Nashua * August 1 San Jose * August 4-5 Seattle 4.3 DSI-WG Foundation Announcement SONY (slides) Sakai-san announced the formation of the DSI-WG under the 1394TA. Reflector e-mail: "1394-DSI@1394ta.org". Temporary ftp site: "ftp://ftp.canon.co.jp/pub/tmp/1394/printer/" will contain today's presentations. 4.4 Learning Session 4.4.1 Device and Service Discovery - Brian Batchelder, 1394 PWG (slides) ・瘢雹 Module, Node and Unit were defined. (see slides) ・瘢雹 Device Discovery * Mechanism by which a device is discovered and its unit types are determined ・瘢雹 Service Discovery * Mechanism by which a unit's services are discovered ・瘢雹 1394 provices a mechanism to discover devices throu the config ROM ・瘢雹 No standardized mechanism for discovering services in 1394. ・瘢雹 Discoverer should only need to decode info about which it is interested. ・瘢雹 Service discovery should occur at the layer where that service is exposed. Each layer should provide service discovery for the layer above it. ・瘢雹 Conceptual Hierarchy (see slides) * Device Information R Unit Information R Service Information * Device and Unit Info defined through 1394TA/DSI-WG * Service Info defined by service specifier-1394PWG, PWG-C, etc.
There was concern that Brian's use of the term "Unit" should not be confused with the 1394 term, "Unit Directory." 4.4.2 FCP Function Control Protocol Makoto Sato , SONY (slides) ・瘢雹 Provides a simple way to exchange messages * Accessed through uniquely defined address ・瘢雹 Possible to support multiple submits in a FCP unit ・瘢雹 Standard of IEC 61883-1 (to be published) ・瘢雹 WRITE transactions of 1394 Asynchronous communication ・瘢雹 COMMAND and RESPONSE frames are addressed to defined registers ・瘢雹 Transaction depends on a higher layer 4.4.3 SBP-2 Alan Berkema (slides) Alan presented Peter Johansson's slides on Serial Bus Protocol 2 that was given in October at 1394 TA. Peter has indicated some interest in the 1394 PWG activity, and he may attend the meeting in Boston. 4.5 Proposals: 4.5.1 Canon: DDSR and Direct Print Protocol-Nakamura (slides) ・瘢雹 DDSR - Device Discovery and Status Retrieval Protocol * Also called "Basic Framework" * Allows discovery and access to both PC Print Protocol and Direct Print Protocol ・瘢雹 Several Terminology definitions offered: * Device Discovery * Transport * Datalink * Service Discovery ・瘢雹 Usage: 2-step process for discovery: * Step 1: Device information - read node description, and supported function (unit) * Step 2: Unit information - obtain supported "datalinks" for each function (unit) ・瘢雹 Changes from v0.2 "Login" proposal were described * Name changed to "DDSR" * Simpler functions * 2 methods for RAM space access * Configuration ROM defined ・瘢雹 Basic Architecture and Config ROM diagrams (see slides) * Proposed "root leaf" to include Node dependent info-will give device info prior to establishing protocol and accessing service info available in Unit directory ・瘢雹 Remaining Open Issues * Content of Status retrieval? * Which is required minimum-command/response or register read or both? (command/response good for FCP, register read good for SBP-2) There was a short discussion about the possible benefits for command/response. The proposed architecture was described as offering support for FCP devices even if they do not support IEEE 1394.x protocol. ・瘢雹 DPP - Direct Print Protocol * Common protocol for any DPP compliant image source to print to any DPP supporting printer * Simple, expandable ・瘢雹 Defines minimum requirements and expansion rules ・瘢雹 Follows DDSR Protocol ・瘢雹 Basic Architecture diagram (see slides) ・瘢雹 Image Format and Data Flow Model candidates listed * Need to specify minimum mandatory requirements ・瘢雹 Remaining Open Issues * Data Flow model * Image format * Is protocol layering needed? * Is bi-directional data-transport required? * Service Discovery definition ・瘢雹 Slide presentations at "ftp://ftp.canon.co.jp/pub/tmp/1394/printer/" 4.5.2 Fuji Photo Film: IEEE1394 Color Printer Protocol -Watanabe(slides) The following Protocol Proposal was distributed.: ・瘢雹 Host device * Image source devices and PC ・瘢雹 Color Image Printing * Bit map color data * Image file data ・瘢雹 Interoperability ・瘢雹 Device Discovery * ConfigROM (Unit directory) - unit_spec_version - command-set_spec_ID ・瘢雹 Register based control ・瘢雹 Image Format * Raw Image - RGB, YCbCr, Vendor unique color * High level Format - Exif (JPEG) ・瘢雹 Data Format ・瘢雹 Data Flow Model * Asynch Transfer Model - Repeat push Block transaction to dat butffer window - Can simp;ify the control * Isoch Transfer Model ・瘢雹 Issues * Service discovery definition * Minimum Requirements for control, image format, data flow model * Extensions 4.5.3 EPSON: SBP-2 like protocol (demo and slides) Nagasaka-san demonstrated a hot plug and play of a modified Epson printer. It showed the Macintosh registering a FireWire printer driver. He printed a page on the printer, and (part of) a hi-res color image. The demo showed a dialog box providing status information of the print job progress. He showed the source code of the printer driver does not have any flow control. (It uses a hard-coded delay for the device.)
He then gave the proposal presentation: ・瘢雹 Design overview of 1394 printer driver for Macintosh (see slides) ・瘢雹 Example model for the driver stack (see slides) * May wish to use 1284.4 implementation for multiple logical channel support to offer simultaneous monitor info as well as data transfer. ・瘢雹 Wants to convert Push model to Pull model (to reduce flow control communication?) ・瘢雹 Multiple host devices are served on longest waiting time basis. There was a discussion about the possibility of evolving to the point of having the "Thin" and "Thick" transport layers being the same. Brian suggested that whatever the transport is, it would be beneficial to have the Operating System vendors include it as part of their OS product. ・瘢雹 Reconnection Protocol? Who shall maintain reconnection problem? * Application * Bus enumerator * Transport Layer * Data Link Layer It was suggested that the lowest layer should be responsible. Tanizaki-san (Epson) demonstrated Photo PC digital camera direct printing using Epson Inkjet Printer and Digital Camera. The camera should be available next month. Camera photo was taken, camera plugged into printer and image was printed. He explained that the camera itself has the same printer driver as that for Macintosh. 4.5.4 Hewlett Packard: 1284.4 over SBP-2 - Alan Berkema (slides) Alan gave his presentation which was similar to the one given in San Diego at the last 1394 PWG meeting (see slides) ・瘢雹 Issues * Not yet addressed Isochronous * Need bi-directional Login to retrieve status * Need Login resources for each Initiator that can connect to a Target 4.5.5 Sharp: Printer/Still Image Protocol Features for Consumer Devices - Toru Ueda (slides) ・瘢雹 Wide Range of Use * The market of consumer devices with still image handling capability is dramatically increasing ・瘢雹 Wide Range of Devices ・瘢雹 Requirements * Small footprint * Physical Media Independent * Data Format/Command Free * Segmentation/Reassembly of data ・瘢雹 "Image Transfer Protocol" (ITP) * Asynch transaction * Tiny (less than 10 KB) * Only 4 services * Physical Media Independent * Authentication and Negotiation * Segmentation and Reassembly
The ITP over FCP proposal was distributed. The connect sequence and command execution diagrams (see proposal) were briefly reviewed. The Abort sequence diagrams were also very briefly referenced. A question about flow control was raised, and Ueda-san admitted that the proposal does not yet address this issue. 4.5.6 SONY: Interface for Digital Still Image - Takashi Kojima (slides) ・瘢雹 Concepts * Able to connect AV devices * Easy to implement even for consumer devices * Compatibility with other interfaces (USB, IrDA, etc.) * Asynch, Packet-based transport is "better than" Isoch, Register-based transport * Data transport based on FCP is preferred ・瘢雹 Data Transport (Stack Model) diagram (see slides) * FCP command/response transaction * Realize data transport transaction - single comand, single response - split commands - split responses ・瘢雹 Split commands and responses diagrams (see slides) ・瘢雹 Device Discovery - Minimum Requirements * Node Unique ID * Supported transport protocol over 1394 (FCP, SBP2, etc.) * Command_set_ID ・瘢雹 Device Discovery - Unit Dependent Information * Unit Type * Data Format * Data transfer efficiency (capability of device) ・瘢雹 Connection & Reconnection * Controller establishes a connection for data transport with Target by Connection command * Controller manages the connection by Connection ID and Target's Node Unique ID * After a bus reset, Controller can re-establish the connection with Target by Reconnection command An issue was raised that if a device is disconnected, there does not seem to be any way to receive this indication. How does it abort activity? A suggestion was made to discuss this issue in future. 4.5.7 Yokogawa/3A International: Analyzing Data on the 1394 Bus (slides) Makoto Shimizu presented a 1394 Data Analyzer product: ・瘢雹 "Good analysis tools reduce development costs" ・瘢雹 Product listens to 1394 bus traffic and displays packet info ・瘢雹 Identifies existing topology of nodes on the bus ・瘢雹 Can generate Bus Reset ・瘢雹 Set trigger conditions on specific data in header field ・瘢雹 Filter information to match certain transactions 4.5.8 Next day scheduling Before the first day ended, the following agenda was suggested by Shinoda-san: Free Discussion - 1 hour Device/Service Discovery - 2 hours Afternoon Discussion Topics Direct Print Solicitation LM, SM 4.6 Free Discussion, Device/Service Discovery (June 12, 1997) The next morning the group had a discussion on the process of determining "the preferred protocol"-FCB or SBP2. Larry Stein suggested that the 1394.x group was not necessarily interested in choosing one method over the other. He felt that it was more important to focus on defining a method (protocol) to discover the device and then discover its capabilities and agree on its service protocol. He thinks the discovery process should support devices that use either FCB or SBP2.
This comment led to a discussion on the meaning of device discovery, and what information is necessary to provide and different levels of discovery. Brian Batchelder wrote down several ideas: 1) Device Discovery (Node, Module) a. Mfr, model # b. Unique ID 2) Unit Discovery (function) a. Unit class (printer, scanner, camera, etc.) b. Unit attributes (Plug 'n' Play ID, etc.) 3) Service Discovery (Protocol) a. Low-level service discovery - Slim (Thin) + - Thick +- Transport - FCP + - SBP-2 + b. High-level service discovery - Data formats - Status languages
The group discussed exactly what order of the above discovery steps should IEEE 1394.x occur. (The order of 1, 2, 3a was suggested.) Then Nakamura-san led a discussion in which he walked through the possible use of the "root dependent directory" for implementing unit discovery and low-level service discovery. He also showed that current FCP and SBP-2 config ROM definitions will not be conflicted as with the Canon proposal.
Brian asked about the benefit trade-offs of command/response vs. reading registers. However, the discussion was deferred for later.
There was a request for the details (date, location) of an "off-cycle AV/C meeting" of the 1394 TA in which Sony will describe their proposal-which should include device discovery. No details on the meeting were provided, but it was said that they should be provided in a future e-mail. Danny Mitchell thought that it may be June 25 and/or 26 in San Jose. He volunteered to find out and post the details when he gets the information.
Larry Stein then summarized (and gave possible examples of) what had been discussed, and said his opinion. ・瘢雹 "Device" discovery is now really "unit" discovery ・瘢雹 ROM space is used for initial discovery (register access only)
It was also suggested that the root leaves could be expanded to contain additional information about the device/unit capabilities. (Plug 'n' Play ID was given as a possible example.)
The idea was proposed that each "root leaf" contents could be defined by companies that are experts in the areas of the specific device (unit) technology. For example, the PWG could be responsible for defining the contents for "printer units" while other companies would be responsible for "video camera units." It was noted that the root leaf for MFPs may be difficult to agree on content.
A few individuals wondered if the root dependent directory could be implemented in RAM. This question was also deferred.
For decision on the access methods (read transaction vs command and response)Brian suggested that we wait to answer that question until a better understanding of the complexity of the root leaf contents.
Fumio Nagasaka drew a diagram showing the behavior of how a Bus Enumerator currently causes a device driver to be loaded. He was wondering how this process would need to change to support the proposals described above. A few individuals felt that the Bus Enumerator will need to be expanded to recognize and support the 1394.x information.
According to Brian, HP has been suggesting to Microsoft that the 1394 Plug n Play enumerator should enumerate by function, not by device. In the special case of printers, there should also be a "printer enumerator." 4.7 Afternoon Discussion Topics Shinoda-san suggested breaking into three groups for more discussion: ・瘢雹 Device/Service Discovery ・瘢雹 Network Printing ・瘢雹 Direct Print Protocol
Because of time constraints, the individual groups will not be getting together after their break-off sessions. Instead, a summary of their efforts will be reported in the minutes and posted via e-mail.
4.7.1 Device/Service Discovery SUBJECT 1 :"DEVICE DISCOVERY" RELATED TERMINOLOGY ...defined at PWG-C meeting (June 12)
The following terms were (re)defined . 1) Node Discovery mfr,model# of node 1394.x support unique ID (serial number,GUID?) 2) Unit (function) Discovery unit class 3a)Low-level service Discovery availability of lowest layer above 1394 transaction layer-datalink. 3b)High-level service Discovery high -level service information (ex.data formats,languages...)
* It was confirmed that what we had been calling "Device discovery" actually included 1),2),and 3a). * 3b) would be done in each of the (thick and thin) transports. * Part of 1) is already part of the 1394-1995 spec.
SUBJECT 2 :BASIC METHOD AND ARCHITECTURE OF "DEVICE DISCOVERY"
*It was disscused that the current UNIT_DIRECTORYs of the ConfigROM defined by protocols such as FCP and SBP-2 only allows discovery of the protocols first(not the unit functions), and unit discovery would be done using that particular protocol.(The order of discovery would be 1,3,then 2......current method)
*Our "DEVICE DISCOVERY" scheme would make it possible to discover the function units first,then the protocols that each of the units would support. It would be a "short-cut"when discovering unit functions. (The order of discovery would be 1,2,then 3......new method) * This idea above was described by a matrix diagram below
(ITEMS ARE EXAMPLES) PRINTER SCANNER FAX ....(function units) ------+----------+----------+----------+------ SBP-2 YES/NO YES/NO YES/NO ------+----------+----------+----------+------ FCP YES/NO YES/NO YES/NO ------+----------+----------+----------+------ (protocols)
a)The concept of looking at this matrix from the (protocol) side would be the current method.(The order of discovery would be 1,3,then 2) b)The concept of looking at this matrix from the (function unit) side would be the new("Our")method.(The order of discovery would be 1,2,then 3)...both ways will be possible.
*Our "DEVICE DISCOVERY" scheme would be made to have no conflict with existing Config ROM definitions. (ex.Unit_Directories of SBP-2, FCP...)
*Please see the attached diagram for basic architecture.
SUBJECT 3:CONTENTS OF THE"ROOT LEAF"
* The following information will be needed in the ROOT_LEAF of each function unit as minimum. 1)supported datalinks info. and entry pointer 2)unit unique ID(PnP string?)
* There was an opinion on supplying primitive low-level unit status. (ex.: error/no error, unit active/non-active)
SUBJECT 4:DISSCUSION ON THE RANGE OF "DEVICE DISCOVERY"
*There was disscusion that this device discovery is a problem not just for printers, but for all 1394 devices. There was general concensus that the range of this Device Discovery protocol should be for any 1394 devices, and that it should be made that way.(Not printer specific, function -free)
*The printer specific items will be discussed and defined in work on the "thin/thick transport".
* There was even a idea to split the specification (1394.x for device discovery and 1394.y for the "transport") SUBJECT 5:ISSUES,OTHERS
* Categorization of unit "types" Does any suitable (global) registy exist that can be pointed at? Do we make the registery extensible?
* Implemented in ROM or RAM? Is it possible to point directly to RAM space from the Root_Directory of Config.ROM? In case RAM implementation is allowed, some rules for information updating is needed.(info. refresh rules)
* Determine access method 1. register map read ? 2. command/response? ....if all implemented in ROM, register read is only choice. ....will depend on the load it takes to do register reads
* next.... proof of concept: try to actually map fields confirming with IEEE1394,IEC1212 specs. 4.7.2 Network Printing and Direct Printing (The minutes of this sub-meeting will be attached soon.) 4.7.3 Direct Printing Protocol sub-meeting (This sub-meeting was Hosted by Ueda-san, Sharp.) Meeting started at 2:00 p.m. and closed at 5:10pm
1. Functions required for direct printing These functions will be required for direct printing.
1) Service Discovery 2) Transport/Session Protocol Pull/Push?, Iso/Async.? 3) Command Set 4) File Format 5) Color Adjustment
2. Basic policy for direct printing protocols The followings are discussed and decided to define mandatory/recommended protocol. 1) 1394 upper layer protocol (transport/session/application/data format/command set) should work over 1394 and other buses(IrDA, USB etc.) 2) Mandatory(or recommended) protocol suite should be defined to assure direct image printing. By using this mandatory protocol suite, ANY digital still image device can print images by ANY printer directly. 3) Asynchronous transaction model will be used for the mandatory/recommended protocol. 4) Isochronous transaction model will be defined for optional protocol.
In the item 2), protocol suite means a set of protocols including transport/session layer protocol, data format, command set.
----------------------------- |C-1*| C-2, C-3,.. | Command set |____|________________________| |D-1* | D-2, D-3, ... | Data format |______|______________________| |T-1* | T-2, T-3, ... | Transport/Session protocol |_________|___________________| C-n : n-th Command set D-n : n-th Data format T-n : n-th Transport/Session protocol * : mandatory Fig. 1
Figure 1 shows the protocol suites. The command set C-1, data format D-1, transport/session protocol T-1 are mandatory. For optional use, vendor can use any combination of C, D and T. The definitions of C-1, D-1 and T-1 are to be discuss item. To define transport layer protocol, the following items should be considered. [1] Bus reset should be considered during sending packets. [2] Packet over-written should be considered if FCP is hired for low layer protocol.
3. Action Item 1) Make comparison table to compare the benefits of in-bound only transaction model VS. symmetrical transaction model (by Fuji film) 2) Make comparison table to compare the benefits of SBP2 model VS. FCP model. (by Seiko Epson and Sharp)
4. To Be Discuss item 1) What is the mandatory/recommended transport/session protocol? (What is T-1?) 2) What is the mandatory/recommended data format? (What is D-1?) 3) What is the mandatory/recommended command set? (What is C-1?) 4) Color adjustment is mandatory or not? 5) What are the optional protocol suites ? 6) PC printing system and direct printing system need to have the same protocol suite as mandatory or not? 7) Digital still camera(DSC) and printer protocol should be discussed in the same working group or not? 8) Do we need to define which device(DSC or PRT) has instruction panel?
Regarding Item 8), EPSON raised the concern about which device should have a control panel to manipulate DSC, printer and so on under peer-to-peer environment though this kind of issue might not be related to printer protocol. If we leave this issue untouched upon, there would emerge the devices having no keys nor buttons to control the functions for those devices. 5 Future Activity Upcoming PWG-related meetings are scheduled as follows: Jun 23-27 PWG Meeting Nashua, NH Jun 25-26 AV-WG (1394 TA) San Jose, CA Jul 31-Aug 1 1394 TA San Jose, CA Aug 4-5 1394 PWG Meeting Redmond, Washington Aug 6-8 PWG Meetings Redmond, Washington Sep 15-18 PWG Meeting Atlanta, Georgia Oct 27-30 PWG Meeting Denver, Colorado Dec 1-4 PWG Meeting Los Angeles, California
--=====================_866649155==_--