From gregory_leclair at erc.epson.com  Tue Jan 14 05:40:22 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:43 2009
Subject: P1394> 1394 Printer Working Group - Albuquerque Meeting Summary
Message-ID: <9700148532.AA853243500@erc.epson.com>

     Minutes of the 1394 PWG meeting: 1-8-'97
     
     
     I'd like to summarize the events of the PWG meeting last week in 
     Albuquerque to all those on the p1394 and 1394-prt-img mailing lists.
     
     For those who attended the Oct. 1394 TA meeting and the subsequent 
     Printer Group Meeting at Adobe on Dec. 6th, there was an open issue of 
     how to support a printing standards effort. The TA wanted to establish 
     a standard as did the Printer Working Group (PWG). The docs from the 
     12/6 meeting are available via anonymous ftp at:
     
                 ftp.pwg.org/pub/pwg/p1394/mtg12696
     
     The Dec. 6th meeting was a way for both groups to get together and 
     figure out how to proceed. As an action item, I agreed to draft a 
     charter that would be reviewed. That draft charter was posted to the 
     pwg@pwg.org, p1394@pwg.org and 1394-prt-img@fireflyinc.com mailing 
     lists. 
     
     Subsequent to that posting, the PWG met last week in Albuquerque. The 
     draft charter was reviewed and found to be quite broad in scope. The 
     PWG asked if the charter could be refined. Since the printing issue is 
     still quite open, I revised the draft with the assistance of others 
     present who where also interested in developing a standard 
     (representatives of HP, EPSON, Warp Nine, Canon and Printronix were 
     present). 
     
     Attendees:
     Brian Batchelder           Hewlett Packard
     Osamu Hirata               Canon, Inc.
     Gregory LeClair            EPSON Research Center
     Fumio Nagasaka             Seiko EPSON
     Ron Norton                 Printronix
     Larry Stein                Warp Nine Engineering
     Satoshi Yamamuro           Canon, Inc.
     
     Note: PWG meeting attendee list is larger. Please refer to 
           the minutes of the PWG meeting. This list is composed 
           of the individuals participating in the 1394 PWG meeting.
       
     I planned on reviewing this charter this week in Houston at the 1394 
     TA meetings. Unfortunately, I was stranded in Dallas by the weather 
     and have since returned to San Jose. Please comment on the proposed 
     charter at the appropriate address.
     
     Keep warm.
     
     Greg LeClair
     1394 Printer Working Group
     
     =================================================================
     
     
     Revised Draft (approved by PWG):
     
     
     ============================Draft Text Appears Below=============
     
     1394 Printer Working Group
     Draft Charter - January 8, 1997
     
     Current status: Proposal of charter for 1394 Printer Working Group
     
     Mailing lists: 
     General Discussion:                p1394@pwg.org
     To Subscribe:                      majordomo@pwg.org 
     Archive:                           ftp.pwg.org/pub/pwg/p1394
     
     Description of Working Group and Goals
     
     Purpose:
     IEEE-1394 High Speed Serial Bus enables new and enhanced printing 
     applications. Standardization of the 1394 printing model(s) grows and 
     extends the printing market and accelerates the adoption of the 
     IEEE-1394 standard interface.
     
     1394 printing applications want to take advantage of the new 
     capabilities of 1394, including: 
     - Multiple Asynchronous and Isochronous streams 
     - Peer to Peer Communication
     - High Bandwidth
     
     Standards for use of these capabilities need to be developed and 
     endorsed for use by 1394 printing devices and other 1394 devices that 
     wish to communicate with them. These standards will enable 
     interoperability between 1394 devices.
     
     Scope:
     The 1394 Printer Working Group will be the focal point for the 
     development and coordination of a comprehensive printing solution for 
     the 1394 I/F.
     
     This project will produce the necessary set of specifications to enable the 
     printing solution. These specifications may include endorsements of 
     existing specifications and new specifications developed under charter from 
     the 1394 Printer Working Group.
     
     Areas of review will include:
     Job Submission
     Printing Models
     Transport protocols
     Link Layers
     Data formats
     Device Management
     Service Discovery
     
     The 1394 Printer Working Group is jointly chartered by the PWG and the 
     1394 TA and is open to anyone interested in contributing to the 
     project. The 1394 PWG will seek the participation of key 
     representatives of the computer and consumer electronics industry.
     
     
     Goals and Milestones:
     
     Oct 96
     First meeting of a proposed Printer Working Group for 1394 Serial bus 
     at Oct. 1394 TA meeting (Redmond, WA)
     
     Dec 96
     First meeting of P1394 Printer Working Group at Adobe Systems in San 
     Jose, CA.
     
     Jan 97
     Review proposed charter for P1394 Group at Albuquerque PWG Meeting 
     (Jan. 8, 1997) (DONE)
     
     Jan 97     
     If agreement can be reached on Working Group Charter, propose an 
     agreed upon charter to 1394 TA Steering Committee in Houston at the 
     1394 TA Meeting (Jan. 13, 1997).
     
     Feb 97     
     First working meeting in conjunction with IEEE 1284.4 working group on 
     Feb. 27th or Feb. 28th to define major tasks. 
     

From lpyoung at lexmark.com  Tue Jan 14 16:44:00 1997
From: lpyoung at lexmark.com (Lloyd Young)
Date: Wed May  6 14:00:43 2009
Subject: P1394> December 6 mtg. info on PWG server
Message-ID: <199701142143.AA21365@interlock.lexmark.com>

I have placed the meeting minutes and presentations that
were available electronically from the December 6 meeting
on the PWG server. The files are located in the 
pub/pwg/p1394/mtg12696 directory.


Lloyd Young                       Phone: (606) 232-5150
Lexmark International Inc.        Fax: (606) 232-6740
740 New Circle Road NW            internet: lpyoung@lexmark.com
Lexington, KY 40511

From lstein at fapo.com  Mon Mar  3 19:18:02 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:43 2009
Subject: P1394> Minutes from Orlando meeting
Message-ID: <3.0.32.19970303161748.006adf08@pop3.fapo.com>

These minutes and the revised charter are available on the PWG
ftp site "ftp://ftp.pwg.org/pub/p1394"
I've posted them as a Word 6 doc and as a PDF file.
-Larry
******************************************************************


1394 PWG Meeting
Feb. 26, 1997
Orlando, Florida


Mailing lists:=20
Web Page:		http://www.pwg.org/p1394
General Discussion:		p1394@pwg.org
To Subscribe:		majordomo@pwg.org=20
Archive:           		ftp://ftp.pwg.org/pub/p1394


Since this meeting started without an official Secretary these minutes were
compiled from notes by Don Wright, Brian Batchelder and Larry Stein.


Larry Stein - Warp Nine Engineering
Alan Bream - HP Roseville
Brian Batchelder- HP Vancouver
Danny Mitchell - TI
Ron Norton - Printronix
Greg LeClair - Epson
Lee Farrell - Canon
Don Wright - Lexmark
Ozay Oktay- Canon
Randy Turner - Sharp




Started at 8:45


Discussion on agenda topics


1)  What kind of organization is this?
=B7 coordination
=B7 SDO affiliation
2)  Officers
3)  Charter


Organization
=B7 Are we affiliated with any SDOs (Standards Development Organizations)?
=B7 How do we coordinate between the US side and the Japan side?
=B7 Let Japan side focus on camera-to-printer payload?
=B7 Let US side deal with DLC/transport part?
=B7 Everyone working on this effort needs to post their proposals to the ftp
server
How do we coordinate with other groups?
1394TA
TA sponsored groups must be chaired by a Steering team member and contain
only TA members.  We want to be more open, so we won=92t be an official TA
sponsored group.  We will coordinate our efforts with the TA, through their
architectural committee.
Japan
In Japan, a group referring to itself as "PWG-J" has formed.  It is made up
of a bunch of companies, including Seiko-Epson, Canon and Sony.  They are
working on solving the same problem we are.  They seem to be a little more
focused on the consumer-device (e.g. camera) to printer connection.  We
talked at length about coordinating our efforts.  It is absolutely critical
to our success.  Some of the options we discussed were:
1)  periodic joint meetings
2)  coordination through the chairmen
3)  cross-membership on the e-mail reflectors
4)  just "making them do it our way" (resoundingly vetoed)
5)  working on the common problems first, to help drive interoperability at
the lowest levels


Charter
We decided that we were trying to avoid the adoption of a multiplicity of
printing models over 1394.  We all remember too painfully how difficult it
was to support printing when each printer did everything differently, and
all apps were DOS apps and they required their own drivers.  In 1394,
without standards, we run the risk of again having all of the printers do
everything differently.  Since all 1394 devices can speak directly to every
other 1394 device, we will have to convince every device to support our
unique model of printing.  Not an easy task, even for the biggest player in
the printing industry.
There was a definite issue of how much we specify?  We decided that we
should specify as little as possible.  We joked that we "wanted to avoid
being creative if at all possible."  We simply meant that we want to
reference existing standards and specifications wherever possible.  Only
where absolutely necessary will we invent anything new.
We are also concerned about the scope of the problem that we are trying to
solve.  One of our first tasks is to work on defining our scope and keeping
it as small as possible.  We need to move quickly, and a tight scope will
enable us to do so.


=B7 Reviewed charter developed at the Albuquerque meeting
Please see "CHARTER.PDF" or "CHARTER.DOC" on ftp site for final draft of
working charter.
=B7 Need to add to the charter a statement about producing a 1394 printing
architectural model document
=B7 How do we deal with the "urgency" of the consumer oriented companies
versus the normal standards process?
=B7 Should we work on the high level model, get that done and then attack th=
e
individual pieces?
=B7 Work to do:
=B7 CSR definitions
=B7 Image formats/PDL formats
=B7 Plug and Play
=B7 Config ROM contents


Charter Scope:
The 1394 Printer Working Group will be the focal point for the development
and coordination of a comprehensive printing solution for the IEEE
Std.1394-1995 interfaces.


This project will produce a specification to define a mechanism for
printing on IEEE Std.1394-1995 compliant links.  This specification will
include existing standards or specification and any new specifications as
necessary.


Areas of review include:
Job Submission
=B7 push
=B7 pull
=B7 remote initiation
Transport and Link protocols
Data Formats
Device Management
Service Discovery
=B7 Config ROM=20
=B7 Plug =91n Play
=B7 Control and Status Registers (CSR)
The 1394 Printer Working Group is chartered by the PWG and coordinates with
the 1394 TA and is open to anyone interested in contributing to the
project.  The 1394 PWG will seek the participation of other industry groups
and key representatives of the computer and consumer electronics industry.


----------
By consensus, the group elected the following officers:


Chair: Greg LeClair - Epson
Secretary: Larry Stein - Warp Nine Engineering
Editor: Brian Batchelder - HP


The group decided to seek status as a study group with the MSC.


This has since been requested of the IEEE MSC chair and approval has been
received.  We are now a study group sponsored by the IEEE MSC.  We have 6
months in order do decide whether or not to seek status as an IEEE working
group.


In order to better understand how printing on 1394 will be used, a set of
scenarios should be developed.


Examples scenarios:


1)  PC to a Printer
2)  Source to a Printer with a PC on the link as well
3)  Source to a Printer without a PC on the link
4)  Multiple printers and/or multiple sources
5)  #4 plus more than 1 PC
6)  Two or more 1394 busses interconnected by bridges


Concepts ---
1)  What does 1394 printing mean? =20
2)  Does it include printing a video stream being sent across the 1394 bus? =
=20
3)  What initiates the print? =20
4)  Is there a print button on the printer than captures a frame out of the
stream and print it? =20
5)  Must the PC or other Source do something special to cause printing to
occur? =20


Should we limit the scope to:


1)  Source initiated print operation - data sent from PC (in a PDL format)
or Camera (image)?
=B7 data pushed from source to printer
=B7 data pulled by printer from source
2)  Sink initiated print operation?
=B7 push
=B7 pull
3) Source/Sink Crossbar
	In general, we want to connect any sink to any source on a 1394 link.
4) The architecture consists of :
	Service Discovery
=B7 Who I am=20
=B7 What I can support
	Job Management
=B7 Connect source to sink
	Job Submission
=B7 Source Initiated
=B7 Sink Initiated
	Transport Type
=B7 Push
=B7 Pull
	Transport Mode
=B7 Isochronous
=B7 Asynchronous
=B7 Multicast


Is the printing service required to simultaneously print to multiple
devices (1 to many)?


How does service discovery work?  Is it really device discovery?
=B7 LDAP
=B7 Srv Loc
=B7 Something else
=B7 How does it interoperate with PnP?
=B7 What are "my" capabilities?


Next Meeting:
	April 2, 1997
	Austin, Texas
	Sponsored by Dazzle


Meeting notice will be posted on this reflector.


-Larry Stein
Secretary


****************************************************************************=
*
Larry A. Stein			Phone: (619)292-2740
Warp Nine Engineering		Fax:	(619)292-8020
					Web: 	http://www.fapo.com
****************************************************************************=
*

From genesis at peter.hd.epson.co.jp  Fri Mar 14 04:52:17 1997
From: genesis at peter.hd.epson.co.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:43 2009
Subject: P1394> PWG-C Meeting Minute 3/10 in JAPAN
Message-ID: <33291FD0.24F3@peter.hd.epson.co.jp>

We had the steering committee meeting of PWG-C on 3/10 at Apple
Computer Japan. The following describes meeting minutes and
UN-approved draft charter of PWG-C.


          1394 PWG-C Steering Committee Meeting Minutes
         ==============================================
                          March 10, 1997  13:30 - 18:30
    at Apple Japan, Inc./ Hatudai office / Tokyo, JAPAN
    
                      written by Fumio Nagasaka (Epson)


list of participators:
Nobuhiko Shinoda (shinoda@bsd.canon.co.jp) - Canon Inc.
Shigeru Ueda (ueda@pure.cpdc.canon.co.jp)  - Canon Inc.
Tetsuro Kuwayama (tkuwa@ccc.canon.co.jp)   - Canon Inc.
Naohisa Suzuki (nao@cbs.canon.co.jp)       - Canon Inc.
Nobuhiro Ohnishi (ohnishi@cbm.canon.co.jp) - Canon Inc.
Atsushi Nakamura (atsnaka@cbs.canon.co.jp) - Canon Inc.
Kazuhiro Hirata (hirata@vip.iwa.fujixerox.co.jp) - Fuji Xerox Co., Ltd.
Yasushi Nagao (yasushin@microsoft.com)     - Microsoft Co., Ltd.
Keisuke Tsuchida (keisuket@microsoft.com)  - Microsoft Co., Ltd.
Toru Ueda (ueda@iml.mkhar.sharp.co.jp)     - Sharp Corporation
Hiromitsu Kurokawa (kurokawa@prt.sony.co.jp) - Sony Corporation
Yukihiro Aoki (bose@cv.sony.co.jp)         - Sony Corporation
Mikio Watanabe (mikio@den.fujifilm.co.jp)  - Fuji Photo Film Co., Ltd.
Fumihiro Fynazaki (funazaki@den.fujifilm.co.jp) - Fuji Photo Film Co.,
Ltd.
Junji Iwane (jiwane@asia.apple.com)        - Apple Japan, Inc.
Masanori Tanizaki (taniyan@hd.epson.co.jp) - Seiko Epson Corporation
Fumio Nagasaka (genesis@hd.epson.co.jp)    - Seiko Epson Corporation


Started at 13:08


1. Report from IETF


Fumio Nagasaka reported IETF PWG-1394 meeting which was held on 2/26
at Orlando, Florida with e-mail from Larry Stein. And Fumio introduced
status of "PWG-1394 Project".


  Chair: Greg LeClair - Epson
  Secretary: Larry Stein - Warp Nine Engineering
  Editor: Brian Batchelder - HP


I repeated e-mail from Larry Stein at the end of this e-mail.


Questions and Answers


(1) 
[Q] from Sony and Canon
US side of PWG seems to be mainly focusing on PC-based printing
architecture.


[A] from Epson
Yes. Actually very few company those have AV/C peripherals are
participating IETF PWG. All other companies are working on some
PC and OS platforms.


Sony:
The word "Consumer" does not sound good. There are many high end
audio video peripherals fitted with IEEE 1394 connector. Thus
not only consumer AV devices but also professional high end AV
devices will be used in peer to peer printing environment.


Epson:
If you say word "consumer" from quality points of view or marketing
points of view like as low end products or high end products. There
are various types of consumer PCs and printers in mass market. But
just we want to say is "Digital Camera or Digital VCR seems to be
more popular in home market", thus we are calling them as "consumer"
devices. All these device intended to be developed to be used in a home.


Others:
Thus we shall use the word "PC-based" and "non-PC based".......




(2)
[Q] from Canon
Still we are not clear about relationships of IETF PWG and PWG-1394
project.


[A] from Epson
The following shows a figure which was drawn by Larry at Albuquerque.


   IETF       NPA      DMTF
     |   PWG   /         |                1394 TA       1284.X
===============/======================    =======       =======
   /    |    | /    |    |         |           /          /
   /   IPP  JMP/  SENSE MIB/MIF    | 1394 PWG  /          /
   /           /                   ==========--/----------/
   /--1284.1---/                     |                X3T10  SBP-2
                                     | Transport ---- 1284.4
                                     | Data Link ---- 1283.3
                                     | Data Formats -- AV/CE
                                     | Management
                                     |




2. Scope for our focus and charter issue
2.1 Our focus
At first each company introduced what shall be their most biggest
interest in 1394 business.


* Sharp
  Peer to peer printing shall be the biggest concern. Our consumer
  device shall be connected to a printer directly and shall has
  print capability. For the transport layer issue we want to
  involve both consumer device and PC-based device. Is there any
  consumer device which was mentioned in RFC xxxx?


* SONY
  We need definition and standards for consumer device what we are
  calling now. Every commands set and data formats those to be used
  shall be same in PC devices and AV/C devices.
  
* Seiko Epson
  We are planning PC-based printer first. But we would like to keep
  inter-operability for AV/C and PC-based devices. Thus we need to
  define design standard for Power Management and PnP issue.


* FUJIFILM
  We are targeting direct printing from a digital camera to a printer.
  In addition to this points of view we would like to define same
  protocol(s) for PC and Digital camera.


* FUJI XEROX
  We wish to have minimum standards to accomplish direct printing.
  Thus we are interested in minimal transport and session layer, and
  we need minimum specification of data set and commands. Each company
  shall extend these specification by themselves. These architecture
  could be called as "protocol kernelize".
  
  Every consumer device shall operate PnP specification to avoid
  confusion when user connect AV/C device to a PC. So shall we need to
  define "LOGO" mark or trading standards?


* Microsoft
  PCs shall have world wide standard for printing architecture even if
  any consumer device had been connected, at least user shall be 
  notified safely. Thus peer to peer printing architecture should not
  cause any side effect to PCs. And any device which support peer to
  peer printing shall be connectable even for PC.


* Canon
  Printers shall be connectable and shall have capability for
negotiation
  for all IEEE 1394 devices. To do these, we need to classify printers
into
  several class according to their service coverage. And we shall
discuss
  about minimal specification for PC/non PC devices after we classified
them.
  If it is possible we can have common sets of commands and data
formats.
  
* Apple
  Printers shall be controlled from printer driver of Macintosh
environment.
  Apple thinks input portion of imaging protocol is also very important
as
  we are targeting multi media.
  If QuickTime Media Layer has input capability for 1394 imaging class,
user
  will wish to have printing capability also.
  We also would like to support still image in QuickTime IC.


2.2. Scope for Charter
  We had brain storm to write charter of PWG-C. We agreed that the PWG-C
  will be the proposal source for PWG-1394 project, at first. Actually
  we at eight companies were afraid of that how can we co-operate with
  PWG-1394 project. Thus we shall be a proposal source, to propose our
  opinion for PWG. In USA side, very few companies are going to have
  some consumer products for home market fitted with IEEE 1394. But we
  have many companies working for something for home market, such as
  digital cameras or VCRs. So our proposal will have some consumer
devices'
  points of view.


* Purpose (= Why): should contain these terms,
   + IEEE 1394 will enlarge printer market and will be a driving force
to
     get larger amount of users.
   + IEEE 1394 will provide new functionality for printing and possibly
     enhance printing applications.
   + In addition to conventional PC-based printing architecture, new
     non-PC based applications such as direct printing will require
     new standards and inter-operability for PC-based printing.
   + About guideline of implementation for particular system will be
     discussed in other chance. Also certification for standards will
     be discussed in another table.


* Scope (= How):
   + PWG-C as a proposal source for PWG will propose these points.
   	- A standard for the direct printing
   	- A standard for Plug & Play for AV/C device.
   	                 (AV/C = Sony calls 'non-PC based device')
    	- PWG-C will summarize various opinion of AV/C companies and then
    	  will suggest a proposal.
    	- PWG-C shall be opened and public organization for any person who
    	  want to propose or want to discuss something involved with 1394
    	  printing.
        - PWG-C has technical scope for printing standards shown below.
            - to discuss upper layer than transaction layer which was
              described in IEEE 1394-1995.


     * Goal & Milestone (= What):
        * 3/24    Approved Charter by PWG-C
        * 4/2     Announcement to IETF PWG-1394 project
        * 4/14    Announcement to 1394TA
        * 6/24    Preliminary draft
        * 9/E     Reviced preliminary draft
        * 12/E    Final draft 1.0


Fumio Nagasaka shall reports Greg LeClair, Larry Stein and Brian
Batchelder
about meeting for PWG-C. To make it easier for PWG and PWG-C to co-work
in
Japan and USA, We at PWG-C would like to ask PWG-1394 project these
matters shown below.
  (1) PWG-C requests PWG to have some 1394 meetings in Japan in 1997.
  (2) PWG-C requests PWG-1394 Project to send one of editors' position
      from PWG-C steering committee.


3.2 Organization and operation


Larry Stein wrote:
> In Japan, a group referring to itself as "PWG-J" has formed.  It is made up
> of a bunch of companies, including Seiko-Epson, Canon and Sony.  They are
> working on solving the same problem we are.  They seem to be a little more
> focused on the consumer-device (e.g. camera) to printer connection.  We
> talked at length about coordinating our efforts.  It is absolutely critical
> to our success.  Some of the options we discussed were:
> 1)  periodic joint meetings
> 2)  coordination through the chairmen
> 3)  cross-membership on the e-mail reflectors
> 4)  just "making them do it our way" (resoundingly vetoed)
> 5)  working on the common problems first, to help drive inter-operability at
> the lowest levels


As I reported before we decided to change name from "PWG-J" to
"PWG-C" to show our stand points are focusing in the inter-operability
of consumer devices and PC-oriented devices, and to show the "PWG-C" is
opened not only for Japanese but also world wide. 


We had voted rename issue on 3/3 at general meeting of PWG-J, and we
agreed
with new name "PWG-C". On 3/10 we at steering committee of PWG-C
discussed
some idea of operation rules for PWG-C. The following rule will be
discussed
on 3/24 at general meeting of PWG-C.


  * Conditions for participation in PWG-C
  	+ The steering committee of PWG-C will provide general announcement
  	  for PWG-C in Web server served by Epson. The general announcement
  	  shall contain documents to show how to join in PWG-C, and
  	  reflector e-mail address. Each company should register only one
  	  person who is responsible for PWG-C issue.
  	+ Any company which would like to join us shall send e-mail to Chair
  	  man and co-chair man of PWG-C.
        + Each company has single number of vote.
        + Each company shall send e-mail to chair man and co-chair man
to
          join each meeting.
  * Conditions to terminate participation in PWG-C
  	+ every company who wish to quit participating PWG-C
  	  will be allowable.
  * How to open information
	+ Epson will provide Web server
	  Meeting minutes will be opened in the Web pages
  * How to announce for meeting schedule
	+ use mailing reflector


3.3.  Bylaws


  As proposal source for IETF PWG - 1394 project and 1394 TA, we confirm
  same agreement for bylaws of 1394 TA and IETF. The succession of
bylaws
  shall be discussed following PWG-C meeting after we reviewed bylaws of
  upper site of meeting group.


4. Next meeting


  At next steering committee meeting, we would like to focus some
  technical points of view. The schedule of next steering committee
meeting
  is shown bellow.


Date/Time:  3/17 from 11:00 - 
Place:      Canon Inc. Shinkawasaki branch, Japan
Agenda:
  (1) Current problems and objectives (From each companies)
  (2) Technical Issue (From each companies)
        a) Minimum functions
        b) Classification of devices
        c) Succession abilities from the printer drivers point
           Can we cover conventional driver architecture within a
           protocol or within single printer class.
        d) Implementation
        e) Overall architecture
        f) Necessity of protocols other than printing functions
        g) Range  of the protocol stack
  (3) Procedures of Discussion
        Do we need Sub-working groups for AV/C oriented printers


-------------------
Subject: 
         P1394> Minutes from Orlando meeting
   Date: 
         Mon, 03 Mar 1997 16:18:02 -0800
  From: 
         Larry Stein <lstein@fapo.com>
     To: 
         p1394@pwg.org




These minutes and the revised charter are available on the PWG
ftp site "ftp://ftp.pwg.org/pub/p1394"
I've posted them as a Word 6 doc and as a PDF file.
-Larry
******************************************************************


1394 PWG Meeting
Feb. 26, 1997
Orlando, Florida


Mailing lists: 
Web Page:               http://www.pwg.org/p1394
General Discussion:             p1394@pwg.org
To Subscribe:           majordomo@pwg.org 
Archive:                        ftp://ftp.pwg.org/pub/p1394


Since this meeting started without an official Secretary these minutes
were
compiled from notes by Don Wright, Brian Batchelder and Larry Stein.


Larry Stein - Warp Nine Engineering
Alan Bream - HP Roseville
Brian Batchelder- HP Vancouver
Danny Mitchell - TI
Ron Norton - Printronix
Greg LeClair - Epson
Lee Farrell - Canon
Don Wright - Lexmark
Ozay Oktay- Canon
Randy Turner - Sharp




Started at 8:45


Discussion on agenda topics


1)  What kind of organization is this?
(I7(J coordination
(I7(J SDO affiliation
2)  Officers
3)  Charter


Organization
(I7(J Are we affiliated with any SDOs (Standards Development Organizations)?
(I7(J How do we coordinate between the US side and the Japan side?
(I7(J Let Japan side focus on camera-to-printer payload?
(I7(J Let US side deal with DLC/transport part?
(I7(J Everyone working on this effort needs to post their proposals to the
ftp
server
How do we coordinate with other groups?
1394TA
TA sponsored groups must be chaired by a Steering team member and
contain
only TA members.  We want to be more open, so we won$BCU(J be an official TA
sponsored group.  We will coordinate our efforts with the TA, through
their
architectural committee.
Japan
In Japan, a group referring to itself as "PWG-J" has formed.  It is made
up
of a bunch of companies, including Seiko-Epson, Canon and Sony.  They
are
working on solving the same problem we are.  They seem to be a little
more
focused on the consumer-device (e.g. camera) to printer connection.  We
talked at length about coordinating our efforts.  It is absolutely
critical
to our success.  Some of the options we discussed were:
1)  periodic joint meetings
2)  coordination through the chairmen
3)  cross-membership on the e-mail reflectors
4)  just "making them do it our way" (resoundingly vetoed)
5)  working on the common problems first, to help drive interoperability
at
the lowest levels


Charter
We decided that we were trying to avoid the adoption of a multiplicity
of
printing models over 1394.  We all remember too painfully how difficult
it
was to support printing when each printer did everything differently,
and
all apps were DOS apps and they required their own drivers.  In 1394,
without standards, we run the risk of again having all of the printers
do
everything differently.  Since all 1394 devices can speak directly to
every
other 1394 device, we will have to convince every device to support our
unique model of printing.  Not an easy task, even for the biggest player
in
the printing industry.
There was a definite issue of how much we specify?  We decided that we
should specify as little as possible.  We joked that we "wanted to avoid
being creative if at all possible."  We simply meant that we want to
reference existing standards and specifications wherever possible.  Only
where absolutely necessary will we invent anything new.
We are also concerned about the scope of the problem that we are trying
to
solve.  One of our first tasks is to work on defining our scope and
keeping
it as small as possible.  We need to move quickly, and a tight scope
will
enable us to do so.


(I7(J Reviewed charter developed at the Albuquerque meeting
Please see "CHARTER.PDF" or "CHARTER.DOC" on ftp site for final draft of
working charter.
(I7(J Need to add to the charter a statement about producing a 1394 printing
architectural model document
(I7(J How do we deal with the "urgency" of the consumer oriented companies
versus the normal standards process?
(I7(J Should we work on the high level model, get that done and then attack
the
individual pieces?
(I7(J Work to do:
(I7(J CSR definitions
(I7(J Image formats/PDL formats
(I7(J Plug and Play
(I7(J Config ROM contents


Charter Scope:
The 1394 Printer Working Group will be the focal point for the
development
and coordination of a comprehensive printing solution for the IEEE
Std.1394-1995 interfaces.


This project will produce a specification to define a mechanism for
printing on IEEE Std.1394-1995 compliant links.  This specification will
include existing standards or specification and any new specifications
as
necessary.


Areas of review include:
Job Submission
(I7(J push
(I7(J pull
(I7(J remote initiation
Transport and Link protocols
Data Formats
Device Management
Service Discovery
(I7(J Config ROM 
(I7(J Plug $BAO(J Play
(I7(J Control and Status Registers (CSR)
The 1394 Printer Working Group is chartered by the PWG and coordinates
with
the 1394 TA and is open to anyone interested in contributing to the
project.  The 1394 PWG will seek the participation of other industry
groups
and key representatives of the computer and consumer electronics
industry.


----------
By consensus, the group elected the following officers:


Chair: Greg LeClair - Epson
Secretary: Larry Stein - Warp Nine Engineering
Editor: Brian Batchelder - HP


The group decided to seek status as a study group with the MSC.


This has since been requested of the IEEE MSC chair and approval has
been
received.  We are now a study group sponsored by the IEEE MSC.  We have
6
months in order do decide whether or not to seek status as an IEEE
working
group.


In order to better understand how printing on 1394 will be used, a set
of
scenarios should be developed.


Examples scenarios:


1)  PC to a Printer
2)  Source to a Printer with a PC on the link as well
3)  Source to a Printer without a PC on the link
4)  Multiple printers and/or multiple sources
5)  #4 plus more than 1 PC
6)  Two or more 1394 busses interconnected by bridges


Concepts ---
1)  What does 1394 printing mean?  
2)  Does it include printing a video stream being sent across the 1394
bus?  
3)  What initiates the print?  
4)  Is there a print button on the printer than captures a frame out of
the
stream and print it?  
5)  Must the PC or other Source do something special to cause printing
to
occur?  


Should we limit the scope to:


1)  Source initiated print operation - data sent from PC (in a PDL
format)
or Camera (image)?
(I7(J data pushed from source to printer
(I7(J data pulled by printer from source
2)  Sink initiated print operation?
(I7(J push
(I7(J pull
3) Source/Sink Crossbar
        In general, we want to connect any sink to any source on a 1394
link.
4) The architecture consists of :
        Service Discovery
(I7(J Who I am 
(I7(J What I can support
        Job Management
(I7(J Connect source to sink
        Job Submission
(I7(J Source Initiated
(I7(J Sink Initiated
        Transport Type
(I7(J Push
(I7(J Pull
        Transport Mode
(I7(J Isochronous
(I7(J Asynchronous
(I7(J Multicast


Is the printing service required to simultaneously print to multiple
devices (1 to many)?


How does service discovery work?  Is it really device discovery?
(I7(J LDAP
(I7(J Srv Loc
(I7(J Something else
(I7(J How does it interoperate with PnP?
(I7(J What are "my" capabilities?


Next Meeting:
        April 2, 1997
        Austin, Texas
        Sponsored by Dazzle


Meeting notice will be posted on this reflector.


-Larry Stein
Secretary
---------------------
-- Fumio Nagasaka --
#           http://www.venus.dtinet.or.jp/~fumiona/ #
#                EPSON Software Development Center  #
#                        54-1 SumiYoshi, Ueda City  #
#      Nagano-Ken Japan 386    FAX +81 268 25 4627  #

From don at lexmark.com  Fri Mar 14 16:38:00 1997
From: don at lexmark.com (Don Wright)
Date: Wed May  6 14:00:43 2009
Subject: P1394> 1394 Printing Meeting in Japan
Message-ID: <199703142138.AA08881@interlock.lexmark.com>

As a result of the request of the 1394 printing group in
Japan, I would like to propose a combined meeting of the
US and Japan based groups on June 12th and/or 13th in
Tokyo.  This is two weeks before the Boston PWG meeting 
about 4 weeks after the San Diego meeting.  Is that a good
time or does it land on some holiday I am not aware of?


Greg:  what do you think?


Don


*************************************************************
* Don Wright (don@lexmark.com)        Lexmark International *
* Manager                               Strategic Alliances *
* 740 New Circle Rd                     Phone: 606-232-4808 *
* Lexington, KY  40511                    Fax: 606-232-6740 *
*************************************************************

From lstein at fapo.com  Fri Mar 14 16:52:26 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Re: 1394 Printing Meeting in Japan
In-Reply-To: <1394 Printing Meeting in Japan>
Message-ID: <3.0.32.19970314135109.00732524@pop3.fapo.com>

I would like to request that you change that to the beginning of the week,
June 9-10.  Computex, the big computer show in Taiwan, is the week prior
and I'll be there.  It would be much easier to make this one trip.
-Larry


At 04:38 PM 3/14/97 EST, Don Wright wrote:
>As a result of the request of the 1394 printing group in
>Japan, I would like to propose a combined meeting of the
>US and Japan based groups on June 12th and/or 13th in
>Tokyo.  This is two weeks before the Boston PWG meeting 
>about 4 weeks after the San Diego meeting.  Is that a good
>time or does it land on some holiday I am not aware of?
>
>Greg:  what do you think?
>
>Don
>
>*************************************************************
>* Don Wright (don@lexmark.com)        Lexmark International *
>* Manager                               Strategic Alliances *
>* 740 New Circle Rd                     Phone: 606-232-4808 *
>* Lexington, KY  40511                    Fax: 606-232-6740 *
>*************************************************************
>
*****************************************************************************
Larry A. Stein			Phone: (619)292-2740
Warp Nine Engineering		Fax:	(619)292-8020
					Web: 	http://www.fapo.com
*****************************************************************************

From don at lexmark.com  Fri Mar 14 17:41:10 1997
From: don at lexmark.com (Don Wright)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Re: 1394 Printing Meeting in Japan
In-Reply-To: <1394 Printing Meeting in Japan>
Message-ID: <199703142242.AA10759@interlock.lexmark.com>

I chose the 12th and 13th because I have to be there
on Monday and Tuesday of the following week for the
W3C advisory Council meeting.  Oh, well I guess 
our votes will cancel each other out.


Don


To: Don Wright, p1394%pwg.org @ interlock.lexmark.com ("p1394%pwg.org") @ SMTP
cc: gregory_leclair%erc.epson.com @ interlock.lexmark.com 
("gregory_leclair%erc.epson.com") @ SMTP, genesis%peter.hd.epson.co.jp @ 
interlock.lexmark.com (Fumio Nagasaka) @ SMTP 
From: lstein%fapo.com @ interlock.lexmark.com (Larry Stein) @ SMTP
Date: 03/14/97 01:52:26 PM
Subject: Re: 1394 Printing Meeting in Japan


I would like to request that you change that to the beginning of the week,
June 9-10.  Computex, the big computer show in Taiwan, is the week prior
and I'll be there.  It would be much easier to make this one trip.
-Larry


At 04:38 PM 3/14/97 EST, Don Wright wrote:
>As a result of the request of the 1394 printing group in
>Japan, I would like to propose a combined meeting of the
>US and Japan based groups on June 12th and/or 13th in
>Tokyo.  This is two weeks before the Boston PWG meeting 
>about 4 weeks after the San Diego meeting.  Is that a good
>time or does it land on some holiday I am not aware of?
>
>Greg:  what do you think?
>
>Don
>
>*************************************************************
>* Don Wright (don@lexmark.com)        Lexmark International *
>* Manager                               Strategic Alliances *
>* 740 New Circle Rd                     Phone: 606-232-4808 *
>* Lexington, KY  40511                    Fax: 606-232-6740 *
>*************************************************************
>
*****************************************************************************
Larry A. Stein   Phone: (619)292-2740
Warp Nine Engineering  Fax: (619)292-8020
     Web:  http://www.fapo.com
*****************************************************************************


 

From gregory_leclair at erc.epson.com  Fri Mar 14 19:27:56 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Additional meeting time in Austin on 4/3
Message-ID: <9702148583.AA858392368@erc.epson.com>

     
     For anyone attending 1394 PWG meeting in Austin.
     
     Are you available to meet a second day on April 3rd, Thursday to 
     further discuss 1394 issues?
      
     
     FYI - The printer working group in Japan will be sending 
     representatives to this meeting and all future 1394 PWG meetings.
     
     Agenda for the meeting(s) will be forthcoming. I'd like to fit the 
     available time, so it would be useful to know how many people can meet 
     on the additional day of April 3rd.
     
     Please reply in the next few days if you're interested.
     
     
     Thanks,
     
     Greg LeClair
     
     
     **********  Epson Research Center  *********** 
     Gregory LeClair    2833 Junction Ave, Ste. 200 
     greg@erc.epson.com          San Jose, CA 95134 
     408.474.0500 x 3610         (FAX) 408.474.0511

From gregory_leclair at erc.epson.com  Fri Mar 14 19:50:01 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:44 2009
Subject: P1394> 1394 Printing Meeting in Japan
In-Reply-To: <P1394> 1394 Printing Meeting in Japan>
Message-ID: <9702148583.AA858392381@erc.epson.com>

     Don,
     
     This is possible with my current schedule.
     Larry mentioned that June 9-10 may be preferable.
     
     I can work with either date. From my calendar, I'm not aware of any 
     major holiday (Nagasaka-san, can you please confirm?).
     
     Greg
     
     **********  Epson Research Center  *********** 
     Gregory LeClair    2833 Junction Ave, Ste. 200 
     greg@erc.epson.com          San Jose, CA 95134 
     408.474.0500 x 3610         (FAX) 408.474.0511
     
     
     




______________________________ Reply Separator _________________________________
Subject: P1394> 1394 Printing Meeting in Japan
Author:  Don Wright <don@lexmark.com> at Internet
Date:    3/14/97 4:38 PM




As a result of the request of the 1394 printing group in 
Japan, I would like to propose a combined meeting of the 
US and Japan based groups on June 12th and/or 13th in 
Tokyo.  This is two weeks before the Boston PWG meeting 
about 4 weeks after the San Diego meeting.  Is that a good 
time or does it land on some holiday I am not aware of?
     
Greg:  what do you think?
     
Don
     
************************************************************* 
* Don Wright (don@lexmark.com)        Lexmark International * 
* Manager                               Strategic Alliances * 
* 740 New Circle Rd                     Phone: 606-232-4808 * 
* Lexington, KY  40511                    Fax: 606-232-6740 * 
*************************************************************

From lstein at fapo.com  Mon Mar 17 10:36:49 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Re: 1394 Printing Meeting in Japan
In-Reply-To: <1394 Printing Meeting in Japan>
Message-ID: <3.0.32.19970317071758.007309a4@pop3.fapo.com>

I'll flip you for it.  How about Wed/Thur?
I'm trying to get back by the weekend.
-LAS


At 05:41 PM 3/14/97 EST, Don Wright wrote:
>I chose the 12th and 13th because I have to be there
>on Monday and Tuesday of the following week for the
>W3C advisory Council meeting.  Oh, well I guess 
>our votes will cancel each other out.
>
>Don
>
>To: Don Wright, p1394%pwg.org @ interlock.lexmark.com ("p1394%pwg.org") @
SMTP
>cc: gregory_leclair%erc.epson.com @ interlock.lexmark.com 
>("gregory_leclair%erc.epson.com") @ SMTP, genesis%peter.hd.epson.co.jp @ 
>interlock.lexmark.com (Fumio Nagasaka) @ SMTP 
>From: lstein%fapo.com @ interlock.lexmark.com (Larry Stein) @ SMTP
>Date: 03/14/97 01:52:26 PM
>Subject: Re: 1394 Printing Meeting in Japan
>
>I would like to request that you change that to the beginning of the week,
>June 9-10.  Computex, the big computer show in Taiwan, is the week prior
>and I'll be there.  It would be much easier to make this one trip.
>-Larry
>
>At 04:38 PM 3/14/97 EST, Don Wright wrote:
>>As a result of the request of the 1394 printing group in
>>Japan, I would like to propose a combined meeting of the
>>US and Japan based groups on June 12th and/or 13th in
>>Tokyo.  This is two weeks before the Boston PWG meeting 
>>about 4 weeks after the San Diego meeting.  Is that a good
>>time or does it land on some holiday I am not aware of?
>>
>>Greg:  what do you think?
>>
>>Don
>>
>>*************************************************************
>>* Don Wright (don@lexmark.com)        Lexmark International *
>>* Manager                               Strategic Alliances *
>>* 740 New Circle Rd                     Phone: 606-232-4808 *
>>* Lexington, KY  40511                    Fax: 606-232-6740 *
>>*************************************************************
>>
>*****************************************************************************
>Larry A. Stein   Phone: (619)292-2740
>Warp Nine Engineering  Fax: (619)292-8020
>     Web:  http://www.fapo.com
>*****************************************************************************
>
> 
>
>
*****************************************************************************
Larry A. Stein			Phone: (619)292-2740
Warp Nine Engineering		Fax:	(619)292-8020
					Web: 	http://www.fapo.com
*****************************************************************************

From fumiona at venus.dtinet.or.jp  Tue Mar 18 06:07:58 1997
From: fumiona at venus.dtinet.or.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:44 2009
Subject: P1394> 1394 Printing Meeting in Japan
In-Reply-To: <P1394> 1394 Printing Meeting in Japan>
Message-ID: <3.0.32.19970317071758.007309a4@pop3.fapo.com>

>      I can work with either date. From my calendar, I'm not aware of any 
>      major holiday (Nagasaka-san, can you please confirm?).


We had the PWG-C steering committee on March 17. At this meeting
I proposed US-Japan joint meeting issue. Any member company of
PWG-C steering committee does not have holiday from 6/9 to 6/13,
thus any date will be acceptable for us.


By the way, do you have any plan where will we have the meeting? We
think Tokyo is very wet and hot in June. Karuisawa, Nikko or Hakone
could be a good place. To go each of these place from Tokyo, we take
2 hours by train or by cars.


-- Fumio Nagasaka --
#           http://www.venus.dtinet.or.jp/~fumiona/ #
#                EPSON Software Development Center  #
#                        54-1 SumiYoshi, Ueda City  #
#      Nagano-Ken Japan 386    FAX +81 268 25 4627  #

From brianb at vcd.hp.com  Tue Mar 25 21:41:35 1997
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Re: 1394 Printing Meeting in Japan
In-Reply-To: <199703142242.AA10759@interlock.lexmark.com>
Message-ID: <3.0.1.32.19970325184135.008885c0@popmail1.vcd.hp.com>

In discussion at the 1284.3 committee meeting, it became clear that a
number of people will find it hard for $$ or time reasons to go to Japan.
Can we meet halfway?  Hawaii was discussed as an alternative that is a lot
cheaper and closer to the U.S.  I realize that it is further for our
colleagues in Japan, but I believe we would get better overall turnout if
we held any joint meetings halfway.


Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~     Brian Batchelder, I/O Architect, DeskJet Printers      ~
~ E-Mail:   brianb@vcd.hp.com         | Hewlett-Packard      ~
~ Phone:    Telnet or (360) 212-4107  | S/W R&D              ~
~ Fax:      Telnet or (360) 212-4227  | 1115 SE 164th Ave.   ~
~ Cellular: (360) 921-4244            | Vancouver, WA  98684 ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From don at lexmark.com  Wed Mar 26 08:28:51 1997
From: don at lexmark.com (Don Wright)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Re: 1394 Printing Meeting in Japan
In-Reply-To: <P1394> Re: 1394 Printing Meeting in Japan>
Message-ID: <199703261329.AA22540@interlock.lexmark.com>

I think having a meeting in Hawaii a little later in the year will also 
be necessary but I think it is really important for as many of us US-side
participants to meet in Japan and make sure we have our act together.
I  think a late fall meeting midway would be a good idea.  There is 
tentative IETF meeting in Hawaii in December.  Maybe we can ride
that wave?


Don


To: p1394%pwg.org @ interlock.lexmark.com (1394 PWG) @ SMTP
cc:  (bcc: Don Wright)
From: brianb%vcd.hp.com @ interlock.lexmark.com (Brian Batchelder) @ SMTP
Date: 03/25/97 06:41:35 PM
Subject: Re: P1394> Re: 1394 Printing Meeting in Japan


In discussion at the 1284.3 committee meeting, it became clear that a
number of people will find it hard for $$ or time reasons to go to Japan.
Can we meet halfway?  Hawaii was discussed as an alternative that is a lot
cheaper and closer to the U.S.  I realize that it is further for our
colleagues in Japan, but I believe we would get better overall turnout if
we held any joint meetings halfway.


Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~     Brian Batchelder, I/O Architect, DeskJet Printers      ~
~ E-Mail:   brianb@vcd.hp.com         | Hewlett-Packard      ~
~ Phone:    Telnet or (360) 212-4107  | S/W R&D              ~
~ Fax:      Telnet or (360) 212-4227  | 1115 SE 164th Ave.   ~
~ Cellular: (360) 921-4244            | Vancouver, WA  98684 ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


 

From don at lexmark.com  Thu Mar 27 12:19:27 1997
From: don at lexmark.com (Don Wright)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Boston PWG and IEEE Meetings
Message-ID: <199703271719.AA24989@interlock.lexmark.com>

The Boston meetings are currently scheduled as follows:


June 23/24     1284.4
June 25-27     PWG


Does anyone in the Boston area have facilities that can
handle 35 people or so?  The Adobe meetings and the upcoming
Dazel meeting in Austin have been so easy, I thought I would
test my luck on the Boston area.


Don




*************************************************************
* Don Wright (don@lexmark.com)        Lexmark International *
* Manager                               Strategic Alliances *
* 740 New Circle Rd                     Phone: 606-232-4808 *
* Lexington, KY  40511                    Fax: 606-232-6740 *
*************************************************************

From gregory_leclair at erc.epson.com  Fri Mar 28 13:57:42 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:44 2009
Subject: UPDATE: P1394> Additional meeting time in Austin on 4/3
Message-ID: <9702288595.AA859583645@erc.epson.com>

     I received one "nay" and multiple "yea"s for additional meeting time 
     on 4/3.
     
     If room is not available at Dazel, I will try to arrange something at 
     the Omni where I'm staying.
     
     I'm sorry for the collision with IPP. Let's add an agenda item to 
     discuss how we might want to telecon weekly like other groups are 
     doing.
     
     
     Greg LeClair
     
     **********  Epson Research Center  *********** 
     Gregory LeClair    2833 Junction Ave, Ste. 200 
     greg@erc.epson.com          San Jose, CA 95134 
     408.474.0500 x 3610         (FAX) 408.474.0511
     
     




______________________________ Forward Header __________________________________
Subject: P1394> Additional meeting time in Austin on 4/3
Author:  "gregory leclair" <gregory_leclair@erc.epson.com> at Internet
Date:    3/14/97 5:27 PM




     
     For anyone attending 1394 PWG meeting in Austin.
     
     Are you available to meet a second day on April 3rd, Thursday to 
     further discuss 1394 issues?
     
     
     FYI - The printer working group in Japan will be sending 
     representatives to this meeting and all future 1394 PWG meetings.
     
     Agenda for the meeting(s) will be forthcoming. I'd like to fit the 
     available time, so it would be useful to know how many people can meet 
     on the additional day of April 3rd.
     
     Please reply in the next few days if you're interested.
     
     
     Thanks,
     
     Greg LeClair
     
     
     **********  Epson Research Center  *********** 
     Gregory LeClair    2833 Junction Ave, Ste. 200 
     greg@erc.epson.com          San Jose, CA 95134 
     408.474.0500 x 3610         (FAX) 408.474.0511
     

From gregory_leclair at erc.epson.com  Fri Mar 28 14:27:12 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Austin Agenda
Message-ID: <9702288595.AA859583653@erc.epson.com>

     Here is a tentative agenda for 1394 PWG Session in Austin on April 
     2nd, Wednesday. Although it may seem kind of long, I think we'll be  
     able to cover most of these items. 
     
     
     A. Organization Issues
        - Future Meetings / Telecon Schedule 
        - IEEE Study Group
        - Presentation by PWG/C 
        - Coordination with PWG/C
     
     B. Dividing tasks
        - Consumer study group
        - Computer study group
     
     C. Scenario review
        I. Device Discovery
           1394 Bus enumeration
           1394 Plug and Play environment
       II. Service Discovery / Advertisement
           Protocols supported
           Data Types supported
     
     D. Specification Discussion 
        What exists & how does it fit together 
     
     E. Existing Proposal Discussion (if needed) 
        - CANON? / EPSON / FUJI / SONY?
     
     
     Please let me know if you have any comments.
     
     Thanks,
     Greg LeClair
     
     **********  Epson Research Center  *********** 
     Gregory LeClair    2833 Junction Ave, Ste. 200 
     greg@erc.epson.com          San Jose, CA 95134 
     408.474.0500 x 3610         (FAX) 408.474.0511

From don at lexmark.com  Mon Mar 31 13:18:56 1997
From: don at lexmark.com (Don Wright)
Date: Wed May  6 14:00:44 2009
Subject: P1394> 1394 Printing Meeting in Japan
Message-ID: <199703311825.AA15550@interlock.lexmark.com>

After talking face-to-face with Brian B., I am going to assume we are
GO! for a two day meeting in Japan on June 11th and 12th.  
Microsoft Japan will be hosting.  Details (maps, schedule, etc.)
will follow.


Don


To: Don Wright
cc: fumiona%venus.dtinet.or.jp @ interlock.lexmark.com (Fumio Nagasaka) @ SMTP, 
gregory_leclair%erc.epson.com @ interlock.lexmark.com (gregory leclair) @ SMTP, 
p1394%pwg.org @ interlock.lexmark.com ("p1394%pwg.org") @ SMTP, lstein%fapo.com 
@ interlock.lexmark.com ("lstein%fapo.com") @ SMTP, nao%cbs.canon.co.jp @ 
interlock.lexmark.com ("nao%cbs.canon.co.jp") @ SMTP, sakai%prt.sony.co.jp @ 
interlock.lexmark.com ("sakai%prt.sony.co.jp") @ SMTP, bose%cv.sony.co.jp @ 
interlock.lexmark.com ("bose%cv.sony.co.jp") @ SMTP, kurokawa%prt.sony.co.jp @ 
interlock.lexmark.com ("kurokawa%prt.sony.co.jp") @ SMTP, 
genesis%hd.epson.co.jp @ interlock.lexmark.com ("genesis%hd.epson.co.jp") @ 
SMTP, taniyan%hd.epson.co.jp @ interlock.lexmark.com ("taniyan%hd.epson.co.jp") 
@ SMTP, ueda%iml.mkhar.sharp.co.jp @ interlock.lexmark.com 
("ueda%iml.mkhar.sharp.co.jp") @ SMTP, yamanaka%prg.nara.sharp.co.jp @ 
interlock.lexmark.com ("yamanaka%prg.nara.sharp.co.jp") @ SMTP, 
yueno%jimu.iwa.fujixerox.co.jp @ interlock.lexmark.com ("yueno%jimu.iwa.fu
jixerox.co.jp") @ SMTP, hirata%vip.iwa.fujixerox.co.jp @ interlock.lexmark.com 
("hirata%vip.iwa.fujixerox.co.jp") @ SMTP, mikio%den.fujifilm.co.jp @ 
interlock.lexmark.com ("mikio%den.fujifilm.co.jp") @ SMTP, 
funazaki%den.fujifilm.co.jp @ interlock.lexmark.com 
("funazaki%den.fujifilm.co.jp") @ SMTP, masumiu%microsoft.com @ 
interlock.lexmark.com ("masumiu%microsoft.com") @ SMTP, yasushin%microsoft.com 
@ interlock.lexmark.com ("yasushin%microsoft.com") @ SMTP, 
keisuket%microsoft.com @ interlock.lexmark.com ("keisuket%microsoft.com") @ 
SMTP, jiwane%asia.apple.com @ interlock.lexmark.com ("jiwane%asia.apple.com") @ 
SMTP, imran%ka2.so-net.or.jp @ interlock.lexmark.com ("imran%ka2.so-net.or.jp") 
@ SMTP, shinoda%bsd.canon.co.jp @ interlock.lexmark.com ("shinoda%bsd.
canon.co.jp") @ SMTP, isaka%pure.cpdc.canon.co.jp @ interlock.lexmark.com 
("isaka%pure.cpdc.canon.co.jp") @ SMTP, ueda%pure.cpdc.canon.co.jp @ 
interlock.lexmark.com ("ueda%pure.cpdc.canon.co.jp") @ SMTP, 
Shimura%pure.cpdc.canon.co.jp @ interlock.lexmark.com 
("Shimura%pure.cpdc.canon.co.jp") @ SMTP, atsnaka%cbs.canon.co.jp @ 
interlock.lexmark.com ("atsnaka%cbs.canon.co.jp") @ SMTP, 
takase%cbs.canon.co.jp @ interlock.lexmark.com ("takase%cbs.canon.co.jp") @ 
SMTP, ohnishi%cbm.canon.co.jp @ interlock.lexmark.com 
("ohnishi%cbm.canon.co.jp") @ SMTP, tkuwa%ccc.canon.co.jp @ 
interlock.lexmark.com ("tkuwa%ccc.canon.co.jp") @ SMTP 
From: genesis%peter.hd.epson.co.jp @ interlock.lexmark.com (Fumio Nagasaka) @ 
SMTP
Date: 03/21/97 05:36:17 AM
Subject: Re: P1394> 1394 Printing Meeting in Japan


Don Wright wrote:


> of the road or deal with trains would make the trip much easier.  Is there
> a member company in Tokyo with an easy to reach facilities with meeting
> rooms that can be host?  While June may be hot in Tokyo, since we


Don,
Yasushi Nagao from Microsoft Japan will provide a meeting room and
some equipments (LCD Projector, OHP ,..) for us. This meeting room is
located in Sasaduka, which is next stop from Shinjuku Station. It takes
less than 10 minutes by KEIO Train.


The meeting room is large enough for 60 persons. If we need more big
space, we will try to find other rooms.




-- Fumio Nagasaka --
#           http://www.venus.dtinet.or.jp/~fumiona/ #
#                EPSON Software Development Center  #
#                        54-1 SumiYoshi, Ueda City  #
#      Nagano-Ken Japan 386    FAX +81 268 25 4627  #


 

From jds at underscore.com  Wed Apr  2 12:11:54 1997
From: jds at underscore.com (Jeff Schnitzer)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Majordomo Filtering of PWG Mailing lists
Message-ID: <199703311825.AA15550@interlock.lexmark.com>

Several individuals have recently had mail rejected by the Majordomo
mailing list software we are using on the PWG server.  I thought I'd
take this opportunity to explain what is happenning.


In order to eliminate mail storms (like those we experienced when 
Underscore first set up the PWG server), the Majordomo software looks
for suspicious phrases in both the subject line and a more extended
list in the first five lines of the message body.  I'll detail the
forbidden text below.


In addition, Majordomo imposes certain other limits to avoid problems
with various older mail agents:
	-  Header lines must not exceed 192 bytes.
	-  Header fields must not exceed 1024 bytes.
	-  Message size in excess of 120,000 bytes.


The filtered subjects are those that start with:
	-  subscribe
	-  unsubscribe
	-  help
	-  RCPT:
	-  Delivery Confirmation
	-  NON-DELIVERY of
	-  Undeliverable Message
	-  Receipt Confirmation
	-  Failed mail
	-  change <*> address
	-  request <*> addition


The phrase are filtered against appearing anywhere in the first 
five lines of the message body:
	-  delete me
	-  remove me
	-  add me
	-  change <*> address
	-  request <*> addition
	-  subscribe
	-  sub
	-  unsubscribe
	-  unsub
	-  mail11
	-  undeliverable
	-  transcript of session
	-  original message was received
	-  message could not be delivered
	-  block not createable after
	-  bounce
	-  bounced
	-  not deliver after
	-  returned mail


Finally, Majordomo may reject messages if any of the first five lines 
of the message body begin with:
	-  help
	-  info
	-  lists
	-  which
	-  index
	-  who
	-  get
	-  approve
	-  passwd
	-  newinfo
	-  config
	-  newconfig
	-  writeconfig
	-  mkdigest


I hope this helps explain things.  If you can't find a way to rephrase
a forbidden phrase, you might try "pig-latin"... 


 
/Jeff


---------------------------------------------------------------
Jeffrey D. Schnitzer      |   Email:  jds@underscore.com 
Underscore, Inc.          |   Voice:  (603) 889-7000
41-C Sagamore Park Rd     |     Fax:  (603) 889-2699   
Hudson, NH  03051-4915    |     Web:  http://www.underscore.com
---------------------------------------------------------------

From gregory_leclair at erc.epson.com  Sat Apr  5 05:44:21 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Revised Draft of 1394 PWG Charter from 4/3 Meeting
Message-ID: <9703058602.AA860246022@erc.epson.com>

     Following is the revised draft of charter which was put together on 
     4/3 to see if we could create a single unified charter between 1394 
     PWG and PWG-C
     
     Please respond to the list (p1394@pwg.org) with all comments & 
     questions.
     
     Greg LeClair
     Chair, 1394 PWG
     
     ===================================================================
     
     
     1394 Printer Working Group 
     Revised Draft Charter - April 3, 1997 
     
     Current status: Revised charter for 1394 Printer Working Group 
     Mailing lists:
     Web Page: http://www.pwg.org/p1394
     General Discussion: p1394@pwg.org
     To Subscribe: majordomo@pwg.org 
     Archive: ftp://ftp.pwg.org/pub/p1394
     
     Chair: Greg LeClair
     Secretary: Larry Stein
     Editor: Brian Batchelder
     
     Description of Working Group and Goals
     
     Purpose:
     IEEE-1394 High Speed Serial Bus enables new and enhanced printing 
     applications. Standardization of the 1394 printing
     model(s) grows and extends the printing market and accelerates the 
     adoption of the IEEE-1394 standard interface. 
     
     A benefit of 1394 is the ability of all devices to participate equally 
     on the bus. Any device is allowed to inititate direct
     communication with any other device. 1394 printing applications want 
     to take advantage of the new capabilities of 1394,
     including: 
     
          Multiple Asynchronous and Isochronous streams 
          Direct device to device communication 
          Multiple devices on same bus 
          High Bandwidth 
     
     
     Standards for use of these capabilities need to be developed and 
     endorsed for use by 1394 printing devices and other 1394
     devices that wish to communicate with them. 
     
     Scope:
     The 1394 Printer Working Group will be the focal point for the 
     development and coordination of a comprehensive printing
     solution for the 1394 I/F. 
     
     This project will produce specifications to define mechanisms for 
     printing on IEEE Std. 1394-1995 compliant links. These
     specifications will include existing standards or specifications and 
     any new specifications as necessary. 
     
     The first specification will enable device and basic service discovery 
     for traditional computing and non-computing platforms.
     This specification will provide support for discovery and 
     identification of one or more communication protocols. 
     
     Additional specifications will address communication protocols and / 
     or data formats. One of these specifications will address
     a simple, common communication protocol and data format(s) which will 
     enable a high level of interoperability among 1394
     devices. 
     
     The 1394 Printer Working Group is chartered by the PWG and will 
     maintain a close relationship with the 1394 TA. The 1394
     PWG is open to anyone interested in contributing to the project. The 
     1394 PWG will seek the participation of other industry
     groups and key representatives of the electronics industry. 

From DMitchell at ti.com  Sun Apr  6 04:12:43 1997
From: DMitchell at ti.com (Danny Mitchell)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Revised Draft of 1394 PWG Charter from 4/3 Meeting
In-Reply-To: <P1394> Revised Draft of 1394 PWG Charter from 4/3 Meeting>
Message-ID: <199704060812.DAA02279@dlep1.itg.ti.com>

Greg,  do I understand that this is a joint charter between PWGB and PWBC?


A few questions...


1.  How are contentious issues to be handled between the two groups.  Joint
meetings?  Were there any "bylaws" established for approval/disapproval of
specifications.


2.  I did not see any mention of an IEEE standard being developed,  should
that be in the charter?


3.  In listing the two specifications,  I did not see a data transport
mentioned.  I assume that will need to be developed or adopted.


Regards,  Danny Mitchell   1394 Software Development Manager
  _________________________________________________________
 | Texas Instruments |  Voice:  214-480-3411               |
 | 8505 Forest Lane  |  Fax:    214-480-3386               |
 | MS-8710           |  E-mail: DMitchell@ti.com           |
 | Dallas, TX 75243  |  WEB:    http://www.ti.com/sc/1394  |
 |___________________|_____________________________________|


   
At 03:44 AM 4/5/97 PDT, gregory leclair wrote:
>     Following is the revised draft of charter which was put together on 
>     4/3 to see if we could create a single unified charter between 1394 
>     PWG and PWG-C
>     
>     Please respond to the list (p1394@pwg.org) with all comments & 
>     questions.
>     
>     Greg LeClair
>     Chair, 1394 PWG
>     
>     ===================================================================
>     
>     
>     1394 Printer Working Group 
>     Revised Draft Charter - April 3, 1997 
>     
>     Current status: Revised charter for 1394 Printer Working Group 
>     Mailing lists:
>     Web Page: http://www.pwg.org/p1394
>     General Discussion: p1394@pwg.org
>     To Subscribe: majordomo@pwg.org 
>     Archive: ftp://ftp.pwg.org/pub/p1394
>     
>     Chair: Greg LeClair
>     Secretary: Larry Stein
>     Editor: Brian Batchelder
>     
>     Description of Working Group and Goals
>     
>     Purpose:
>     IEEE-1394 High Speed Serial Bus enables new and enhanced printing 
>     applications. Standardization of the 1394 printing
>     model(s) grows and extends the printing market and accelerates the 
>     adoption of the IEEE-1394 standard interface. 
>     
>     A benefit of 1394 is the ability of all devices to participate equally 
>     on the bus. Any device is allowed to inititate direct
>     communication with any other device. 1394 printing applications want 
>     to take advantage of the new capabilities of 1394,
>     including: 
>     
>          Multiple Asynchronous and Isochronous streams 
>          Direct device to device communication 
>          Multiple devices on same bus 
>          High Bandwidth 
>     
>     
>     Standards for use of these capabilities need to be developed and 
>     endorsed for use by 1394 printing devices and other 1394
>     devices that wish to communicate with them. 
>     
>     Scope:
>     The 1394 Printer Working Group will be the focal point for the 
>     development and coordination of a comprehensive printing
>     solution for the 1394 I/F. 
>     
>     This project will produce specifications to define mechanisms for 
>     printing on IEEE Std. 1394-1995 compliant links. These
>     specifications will include existing standards or specifications and 
>     any new specifications as necessary. 
>     
>     The first specification will enable device and basic service discovery 
>     for traditional computing and non-computing platforms.
>     This specification will provide support for discovery and 
>     identification of one or more communication protocols. 
>     
>     Additional specifications will address communication protocols and / 
>     or data formats. One of these specifications will address
>     a simple, common communication protocol and data format(s) which will 
>     enable a high level of interoperability among 1394
>     devices. 
>     
>     The 1394 Printer Working Group is chartered by the PWG and will 
>     maintain a close relationship with the 1394 TA. The 1394
>     PWG is open to anyone interested in contributing to the project. The 
>     1394 PWG will seek the participation of other industry
>     groups and key representatives of the electronics industry. 
>
>
>

From lstein at fapo.com  Mon Apr  7 19:25:48 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:44 2009
Subject: P1394> April 1394PWG Meeting Minutes
Message-ID: <3.0.32.19970407162136.0068b1c4@pop3.fapo.com>

1394 PWG Meeting
2 April 1997
Austin, Tx


Greg LeClair - Chair
Larry Stein - Vice-chair, Sec
Brian Batchelder - Editor


Attendees:  Please refer to www.pwg.org for attendee list.


Meeting Agenda:
=B7 Introductions
=B7 Presentation by PWG/C representative
=B7 Organization Issues
=B7 Scenario Review
=B7 Tasks


Introduction
Meeting started at 11:35PM, after the opening of the PWG meeting.
The meeting will continue on Thursday.
PWG/C
Presented by Mr. Nobuhiko Shinoda (Canon), chair of PWG/C
The full presentation is available on the ftp server =96 "1394pwg-c.pdf"
There are two types of companies involved in the PWG/C:
	Consumer Products
	Computer Products


The consumer devices focus on:
	peer to peer printing
	inter-operability of the PC environment and the PC-less environment


PWG/C Charter is similar to the one developed by the 1394PWG committee.
Please refer to the presentation for more details on this.


The PWG/C has a more formal organizational structure than the 1394PWG
committee.  The PWG/C operates with a Steering Committee which sets the
agenda for the meetings.   The current SC members are:
Apple Japan, Canon, Seiko Epson, Fuji Photo Film, Fuji Xerox, Microsoft
K.K., NEC, Sony and Sharp.


Membership in the committee is open to any company wishing to contribute to
the effort.


PWG/C Schedule
The PWG/C has an aggressive schedule for the development of the printing
standards.  The current schedule is:
	3/24	Draft Charter Approved
	4/2	Announcement to 1394PWG
	6/24	Preliminary draft=20
	12/E?	Final draft1.0


The contacts for the committee are:
	Chairman	Mr. Nobuhiko Shinoda	(Canon)		shinoda@bsd.canon.co.jp
	Co-chairman	Mr. Toru Ueda 		(Sharp)		ueda@iml.mkhar.sharp.co.jp
	Co-chairman	Mr. Yorihiko Sakai 	(Sony)		sakai@prt.sony.co.jp
	Editor(s)		Mr. Fumio Nagasaka	(Seiko Epson)=09
			Mr. Mikio Watanabe	(Fuji Photo Film)
			Mr. Fumihiro Funazaki	(Fuji Photo Film)
	Advisor 		Mr. Micheal Teener	(Firefly)=09
Organizational Issues
Overview of PWG1394 charter
	PWG/C is concerned about the distinction between "peer to peer" and "PC
less" systems.
		Need to determine the needs of the consumer side vs the PC side=20


Through the ensuing discussion it was determined that the requirements for
the PWG/C and the 1394PWG are essentially the same.  The only differences
is in the interpretation of "peer to peer" and "PC less" printing.  Both
committees are concerned with the development of printing from any source
to any target.  The wording will be worked on to make this clearer.
=09
Coordination with 1394TA
	The 1394PWG needs to clarify the relationship with the TA.
	Greg Leclair will be representing the 1394PWG at the next 1394TA meeting,
April 16.  Part of his=20
goal is to:
		Make a presentation at the general TA meeting
		Get a link on the TA web site to the 1394PWG
	It is our goal to be sure the 1394TA refers printing related inquiries to
this committee.


Coordination with PWG/C in Japan
Develop a unified charter with the tasks assigned to the different groups.
Since the goals of the committees are essentially the same, we should try
to establish a common charter to work from.  We want to make sure that we
are not both trying to solve the same problems.  With a common charter and
a closer working relationship we can divide the project into tasks that can
be worked on by either committee, or jointly, as necessary.  It was decided
that the purpose of the second day meeting will be to work on the joint
charter.  This will then be discussed at the next PWG/C meeting the week of
April 7.


	Need a new phrase for "peer to peer".
	All proposals will be posted on the PWG.ORG server
	June 11-12 joint meeting in Tokyo =96 Microsoft
	How can we coordinate email?


Proposal to have one group - 1394PWG, with 2 sub-committees dealing with
the issues of consumer and PC oriented printing.  The 1394PWG chair will be
the official liaison with the TA.
This was agreed to here and will be discussed in Japan by the PWG/C.


IEEE Study Group
This project is officially an IEEE study group under the Microprocessor
Standards Committee (MSC).  We
have until the July 1997 MSC meeting to determine if we want to become a
full working group and present a Project Authorization Request (PAR) form.
Larry Stein (MSC recording secretary)  and Don Wright (MSC vice-chair) will
keep the MSC abreast of this committees development.


Meeting Schedule
May 14 -- San Diego
June 11-12 =96 Tokyo, hosted by Microsoft
June 24-25 =96 Boston


If we have enough to talk about then we can schedule a teleconference
between meetings.
Scenario Review
I.  Device Discovery
Bus enumeration - Printers
Plug and Play string -  same +
II.  Service Discovery/Advertisement
Protocols and Data types supported
Mapped to a 1394 node and address for service handler


This concluded the first days meeting.


The second day meeting notes were provided by Greg Leclair.


DAY TWO
Attendees:
    =20
     Lee Ferrell - Canon
     Atsushi Nakamura - Canon
     Nobuhiko Shinoda - Canon
     Tadashi Yoshida - Canon
     Sam Hirata - Canon
     Brian Batchelder - HP
     Alan Berkema - HP
     Fumio Nagasaka - Seiko EPSON
     Greg LeClair - EPSON
     Lloyd Young - Lexmark
    =20
     Unified Charter was main effort of meeting. PWG-C concerns were listed=
=20
     as:
     1. Peer to Peer printing issue
     2. Clarification of relationship with TA
     3. Operating rules (separate doc)
    =20
     1394PWG chair concerns:
     Spend less time on charter and begin to do work.
    =20
     Peer to Peer means different things including PC. Consumer does not=20
     cover all of AV type products, some are professional. Language adopted=
=20
     was "device to device" and "traditional computing and non-computing=20
     platforms".
    =20
     Added terminology which pointed out benefit of 1394 over USB - it is=20
     not a master slave type of bus.
    =20
     Refined scope:
     Eliminated laundry list of things to do and identified primary task as=
=20
     spec for basic discovery. Chair to post RFP to list.
    =20
     Added other work such as a common comm protocol and data format.
    =20
     Canon presented their idea for basic device discovery. GL will post it=
=20
     to PWG web site.
    =20
     Greg LeClair stated he would be contacting TA contacts about=20
     presentation in Eindhoven and reporting.
    =20
     Last item was discussion of whether PWG-C could just fold into 1394=20
     PWG. Current officers of PWG-C would take on co-responsibility and=20
     could hold meetings in Japan independent of meeting in US. Minutes,=20
     etc would still be posted to p1394@pwg.org list. US members could=20
     attend meeting in Japan. Japanese members could attend meeting in US.
 =20
Conclusion of meeting minutes for the April 1394PWG meeting.
These minutes will be distributed via email to the p1394@pwg.org mailing
list as well as being posted on the www.pwg.org web site.


Thank you,
Larry Stein

From gregory_leclair at erc.epson.com  Tue Apr  8 13:59:55 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Revised Draft of 1394 PWG Charter from 4/3 Mee
Message-ID: <9703098606.AA860605149@erc.epson.com>

     Danny,
     
     Let me try and answer these points. It may be difficult since members 
     from Japan will not meet until 4/11.
     
>do I understand that this is a joint charter between PWGB and PWBC?
     
     It was drafted as a possible joint charter. It is up to PWG/C members 
     as to how they would like to proceed. Either as a separate group or as 
     part of 1394 PWG with their officers as co-chair, etc.
     
     Of course that would require a vote, however, I got the feeling in 
     Austin that this was considered a good idea by members in attendance 
     from both groups.
     
     
>1.  How are contentious issues to be handled between the two groups.  
>Joint meetings?  Were there any "bylaws" established for approval/disapproval 
>of specifications.


        As you can see in the revised charter, the first specification 
        to be developed is the "Device and Service Discovery" mechanism.


        I think once we've identified that there is work to be done, it will 
        be accomplished under a formal standards organization (i.e. IEEE ).


     
2.  I did not see any mention of an IEEE standard being developed,  should 
that be in the charter?


        Good point. I'm open to comments about the draft. As I mentioned 
        above, I think we need to move identified tasks to a WG status 
        within an establish standards body.


3.  In listing the two specifications,  I did not see a data transport 
mentioned.  I assume that will need to be developed or adopted.


        I would agree that transport fits into the second ( or other) 
        specification area. 


        FYI - The Canon proposal was discussed on Thursday and it allows 
        for more than one type of transport and data format. I've posted it 
        to the server and will update the links to point to it today.


Regards,


Greg LeClair




**********  Epson Research Center  *********** 
Gregory LeClair    2833 Junction Ave, Ste. 200 
greg@erc.epson.com          San Jose, CA 95134 
408.474.0500 x 3610         (FAX) 408.474.0511

From gregory_leclair at erc.epson.com  Thu Apr 10 21:32:33 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:44 2009
Subject: P1394> 1394 PWG Web Site Updated
Message-ID: <9703108607.AA860720388@erc.epson.com>

     Hi folks,
     
     The 1394 Printer Working Group web site has been updated with the new 
     charter (the old copy is still available), the Canon proposals from 
     the Austin meeting on 4/3/97 and the planned meetings for the next two 
     months.
     
     If I missed something or something is broken, please let me know.
     
     Thanks,
     
     Greg LeClair
     greg@erc.epson.com

From harryl at us.ibm.com  Wed Apr 16 11:36:13 1997
From: harryl at us.ibm.com (Harry Lewis)
Date: Wed May  6 14:00:44 2009
Subject: P1394> USB Printing
Message-ID: <5030100001447066000002L062*@MHS>

Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems


Can someone in the P1394 group explain why there is no similar USB group in the
PWG? Will the results of P1394 apply in any way to USB? Coexist? Conflict?


Any comments, at all?


Harry Lewis - IBM Printing Systems

From DMitchell at ti.com  Wed Apr 16 12:54:34 1997
From: DMitchell at ti.com (Danny Mitchell)
Date: Wed May  6 14:00:44 2009
Subject: P1394> USB Printing
In-Reply-To: <P1394> USB Printing>
Message-ID: <199704161654.LAA18020@dlep1.itg.ti.com>

Harry,


I cannot speak to why there is no USB printing group in the PWG.  Since it
is an ad-hoc organization that is made up of interested parties,  I would
have to assume there are not enough interested parties. 


However with respect to your coexist, conflict question.  Some of the work
done might be applicable to USB as a straight interface specification.  The
mechanics of sending/receiving status and the data transport would be very
different since 1394 is a peer-to-peer bus and USB is a master slave
relationship.  


With the peer-to-peer bus the printer can "pull" system data from the CPU
and therefore the CPU would not need to poll the device as it currently does
now for the parallel port.  I would expect USB to have a similar
architecture as the current designs.  


I do not see any conflict here.  If the USB groups have started work on a
printer specification I am sure that the PWG would welcome the input.
However since the two busses really are intended for very different
applications there might not be much commonality here.


If a common data format for imaging devices was created then that work would
be applicable.  However I don't think the data transport will resemble
anything that is on USB.


Regards,  Danny Mitchell   Serial Bus Solutions SW Manager ( USB,1394,Fibre
Channel )
  _________________________________________________________
 | Texas Instruments |  Voice:  214-480-3411               |
 | 8505 Forest Lane  |  Fax:    214-480-3386               |
 | MS-8710           |  E-mail: DMitchell@ti.com           |
 | Dallas, TX 75243  |  WEB:    http://www.ti.com/sc/1394  |
 |___________________|_____________________________________|


   At 11:36 AM 4/16/97 -0400, Harry Lewis wrote:
>Classification:
>Prologue:
>Epilogue: Harry Lewis - IBM Printing Systems
>
>Can someone in the P1394 group explain why there is no similar USB group in the
>PWG? Will the results of P1394 apply in any way to USB? Coexist? Conflict?
>
>Any comments, at all?
>
>Harry Lewis - IBM Printing Systems
>
>

From gregory_leclair at erc.epson.com  Wed Apr 23 19:21:06 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:44 2009
Subject: P1394> 1394 PWG - request for proposals
Message-ID: <9703238618.AA861838055@erc.epson.com>

     Yes folks, it is time to ping Larry Stein with your info 
     about attendance at San Diego Meeting. One of the action 
     items from last meeting was to ask for proposals about 
     printing on 1394. 
     
     Note: there are already proposals from Fuji, Canon and Epson 
     on the web site. Also, the links page points to other useful 
     documents.
     
     And the request is:
     
     1. 1394 PWG is accepting proposals for device discovery on 
        IEEE Std. 1394-1995 compliant links. The goal of this effort 
        is to define a common method for printer device discovery.
     
     2. 1394 PWG is accepting proposals for service discovery on 
        IEEE Std. 1394-1995 compliant links. The goal of this effort 
        is to define a common method for printer service discovery.
     
     3. 1394 PWG is accepting proposals for common imaging protocol 
        and format which can be applied to printers connected on IEEE 
        Std. 1394-1995 compliant links. 
     
     I'd like to ask the following:
      - Make your proposals available on the PWG web site via a .PDF 
        file. Try to make it available 1 week ahead of time if 
        possible.
     
      - Also, let me know if you plan to make a presentation regarding 
        your proposal at the 1394 PWG meeting in May. Please provide 
        a .PDF file on PWG web site.
     
      - If you have trouble uploading content, see the PWG web site 
        home page or contact me: greg@erc.epson.com
     
     

From gregory_leclair at erc.epson.com  Wed Apr 23 18:56:38 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Finally - Eindhoven summary
Message-ID: <9703238618.AA861838047@erc.epson.com>

     Hi all. I finally got back on my feet and got my new 'puter working 
     that arrived while I'd been away.
     
     Here is the summary of meetings I attended in Eindhoven or had with 
     members of PWG-C.
     
     Please let me know if you have questions or if this disagrees with 
     your understanding of the issues.
     
     Thanks,
     
     Greg LeClair
     EPSON
     1394 PWG Chair
     
     
     =====================================================================
     
     Following is a summary of meetings that took place in Eindhoven at the 
     1394 TA meeting.
     
     Monday 4/14 A.M.
     ----------------
     As Chair of 1394 PWG I had scheduled time with Peter Johansson of 
     the 1394 Architecture WG to make a status report of our activities. 
     I will post a copy of the presentation to the PWG web site shortly. 
     I made the presentation on Monday meeting of the WG.
     
     This presentation seemed to be well received, although a concern was 
     voiced that many companies outside of the TA may not 'understand' 
     1394. A question was raised as to whether a decision had been made 
     regarding SBP-2 as the transport protocol. I explained that the 
     protocol issue was being addressed.
     
     People seemed pleased that there was an effort being made to create 
     a workable solution for computer and non-computer applications.
     
     Monday 4/14 P.M.
     ----------------
     1394 TA Steering Committee meeting was held. Members of PWG-C and 1394 
     PWG were asked to attend to explain the reason for the request of a 
     Printer Working Group within the TA that was made by Sony and Canon.
     
     I explained that 1394 PWG was not asking to be chartered by TA since 
     we had discussed TA policy after the January TA meeting and decided to 
     simply have a liasion to the TA. This seemed to be acceptable to 
     everyone based on our discussions with the members of PWG-C who 
     attended the last PWG meeting in Austin. I further explained the 
     history of what had happened since the January TA meeting and the 
     recent discussions we'd had with the PWG-C.
     
     After some confusion, we adjourned to a smaller meeting room to 
     discuss the issues. What was discussed can be summarized very simply:
     
     - Some members of PWG-C feel the TA is a better place to establish
       1394 specifications.
     - Some members think the PWG needs stated operating rules. 
     - I explained what the 1394 PWG was doing and understood the concerns 
       voiced by members of the PWG-C who were not in Austin.
     - I explained that neither myself or 1394 PWG was preventing the TA 
       SC from voting on the request made by Sony and Canon. My impression 
       is that the TA SC did not want to create a group that was doing the 
       same work as the 1394 PWG.
     - 1394 PWG should plan to hold meetings at the 1394 TA as well as our 
       current schedule. This will enable members of TA to contribute to 
       our efforts.
     - The idea was floated that perhaps PWG-C members would change the 
       scope of the proposed WG to deal with their highest priority.
     
     We adjourned this meeting with the action item being left to the PWG-C 
     to decide how it wanted to approach the TA. The TA SC would meet again 
     in early May and could vote on an new proposal for a working group.
     
     Tuesday 4/15 P.M.
     -----------------
     Shinoda-san of Canon arrived to discuss WG issues. We met privately on 
     Tuesday afternoon and I explained the events of the prior days 
     meeting. Because the PWG-C members want to move certain areas forward, 
     we discussed how to address this concern. 
     
     We kept coming back to the issue that 1394 PWG effort will only 
     address computer to printer type of application. I stated that I did 
     not feel this to be accurate and that it was only one of the models 
     under discussion.
     
     Because of this, we discussed the idea that members of the PWG-C may 
     feel more comfortable meeting within the TA and that a TA WG could 
     also work with 1394 PWG. 
     
     FYI - A number of companies made presentations regarding their 
     commitment to 1394. (Where possible, I'll post the PDF of those that 
     are available to the web site.)
     
     After I left Eindhoven, members of PWG-C met and Shinoda-san alerted 
     me to the fact that they would pursue the idea of a Still Image 
     Working Group within the TA.
     
     Last but not least, I discussed having the 1394 PWG web site linked 
     off of the TA web site with Toni Tappan. I just have to send her the 
     info and it should happen.
     

From don at lexmark.com  Mon Apr 28 11:07:48 1997
From: don at lexmark.com (Don Wright)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Boston Meeting
Message-ID: <199704281510.AA09225@interlock2.lexmark.com>

Sorry for the multiple postings but there seem to still be
some people who s*bscribe to one of the project lists without
s*bscribing to the PWG's administrative list.  In the future,
all meeting notices, etc. will only go out one to the PWG
mailing list; please s*bscribe to it NOW!!








(Well I guess I am past line 5 now and can say the word
subscribe and not have the filter reject my mail!!!)


J. Martin of Underscore has graciously agreed to arrange the
details for the Boston meeting.  He will forward them to the
PWG list as soon as possible.  Since both the 1394 printing
effort and the IPP effort would like 2 day meetings in 
Boston, the following schedule is mandated:


June 23/24     1394 Printing
June 25/26     IPP
June 27        JMP, etc.




Best regards!


Don




*************************************************************
* Don Wright (don@lexmark.com)        Lexmark International *
* Manager                               Strategic Alliances *
* 740 New Circle Rd                     Phone: 606-232-4808 *
* Lexington, KY  40511                    Fax: 606-232-6740 *
*************************************************************

From lstein at fapo.com  Fri May  2 20:22:36 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Meeting Charges for San Diego
Message-ID: <3.0.32.19970502172147.006c5940@pop3.fapo.com>

Sorry for the multiple postings, but I wanted to have the best chance of
getting to everyone.


The meeting charges for the IEEE P1284.x, IPP, 1394PWG, JPM and PWG
meetings will be $30.00 per person per day.  This includes the meeting room
rentals, AV, continental breakfast, and AM/PM breaks.


If you are staying at the Marriott this will be charged to your room. If
not, then please bring a check or cash.  The Marriott may be able to take
credit cards for the charges.


Thank you,
Larry Stein
*****************************************************************************
Larry A. Stein			Phone: (619)292-2740
Warp Nine Engineering		Fax:	(619)292-8020
					Web: 	http://www.fapo.com
*****************************************************************************

From lstein at fapo.com  Mon May  5 12:25:26 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Meeting Location
Message-ID: <3.0.32.19970505091959.006cebec@pop3.fapo.com>

The May IEEE/PWG meetings will be held in the following rooms at the
Marriott Suites:


P1284.3 	May 8-9	Maestro Room
P1284.4	May 12-13	Maestro Room
1394PWG	May 14		Symphony Bay 1&2
IPP		May 15		Symphony Bay 1&2
JMP/PWG	May 16		Maestro Room


The weathers great in San Diego, dress casual and comfortable.
-Larry
*****************************************************************************
Larry A. Stein			Phone: (619)292-2740
Warp Nine Engineering		Fax:	(619)292-8020
					Web: 	http://www.fapo.com
*****************************************************************************

From jkm at underscore.com  Tue May  6 14:28:42 1997
From: jkm at underscore.com (JK Martin)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Meeting room assignments for the San Diego meetings
Message-ID: <199705061828.OAA27808@uscore.underscore.com>

The previously published meeting room assignments for the upcoming San
Diego meetings have been slightly changed.


The May IEEE/PWG meetings will now be held in the following rooms at the
Marriott Suites in San Diego:


P1284.3 	May 8-9		Maestro Room
P1284.4		May 12-13	Symphony Bay 1
1394PWG		May 14		Symphony Bay 1,2,3
IPP		May 15		Symphony Bay 1,2,3
JMP/PWG		May 16		Symphony Bay 1


	...jay


PS:  Sorry for the massive cross-posting; we don't quite yet have a
     policy/mechanism for sending messages of this type to a single list.


----------------------------------------------------------------------
--  JK Martin               |  Email:   jkm@underscore.com          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------


----- Begin Included Message -----


Date: Mon, 05 May 1997 09:25:26 -0700
To: P1284_3@lexmark.com, p1394@pwg.org, ipp@pwg.org
From: Larry Stein <lstein@fapo.com>


The May IEEE/PWG meetings will be held in the following rooms at the
Marriott Suites:


P1284.3 	May 8-9		Maestro Room
P1284.4		May 12-13	Maestro Room
1394PWG		May 14		Symphony Bay 1&2
IPP		May 15		Symphony Bay 1&2
JMP/PWG		May 16		Maestro Room


The weathers great in San Diego, dress casual and comfortable.
-Larry
*****************************************************************************
Larry A. Stein			Phone: (619)292-2740
Warp Nine Engineering		Fax:	(619)292-8020
				Web: 	http://www.fapo.com
*****************************************************************************


----- End Included Message -----

From gregory_leclair at erc.epson.com  Mon May 12 17:28:53 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Proposed Agenda for 5/14 Meeting in San Diego
Message-ID: <9704128634.AA863470686@erc.epson.com>

     Following this note is the proposed agenda for 1394 PWG Meeting in San 
     Diego on 5/14.
     
     FYI - Canon's proposals have been posted since shortly after the 
     Austin Meeting. Alan Berkema of HP sent me a presentation on 1284.4 
     over SBP-2. These are available on the PWG web site in the 1394 
     documents page.
     
     I hope to have my content uploaded later today or tomorrow. Please let 
     me know if you have comments, questions or suggestions.
     
     Greg LeClair
     greg@erc.epson.com
     
     
     ======================================================================
                     Proposed Agenda for 1394 PWG meeting
                      May 14th, 1997 - San Diego, CA
     
     1. 1394 PWG Meetings
        Japan  - 6/11 & 6/12
               - at Microsoft KK
               - Please ping ???
        Boston - 6/23 & 6/24
               - at Sheraton Tara in Nashua, New Hampshire
               - Please ping Jay Martin (jkm@underscore.com)
        San Jose - 7/31 - 8/1 - Date TBD
               - at 1394 TA Meeting - Fairmont Hotel
               - Please ping Greg LeClair (greg@erc.epson.com)
        Schedule & Agenda Issues
     
     2. Eindhoven 1394 TA summary
     
     3. Proposal Review 
     
     4. Presentations
         - Atsushi Nakamura, CANON 
         - Alan Berkema, HP
         - Greg LeClair, EPSON
     
     5. Discussions
     
     6. Action Items:
         - Define contact person for Japan Meeting?
         - Define liasion for various related projects? 
         - How to proceed?
           - Future Meeting Format?
           - IEEE PAR Decision?
           - Sub-Groups/Task Forces? 
           - Draft Spec (to include)
           - Schedule: Draft Spec by June
     

From yasushin at microsoft.com  Wed May 14 10:02:42 1997
From: yasushin at microsoft.com (Yasushi Nagao)
Date: Wed May  6 14:00:44 2009
Subject: P1394> 1394 Printing Meeting in Japan
Message-ID: <9704128634.AA863470686@erc.epson.com>

/***************************/
/*   PWG meeting in Japan  */
/***************************/


I will arrange PWG meeting in Japan. If you would like to attend PWG
meeting in Japan, please E-mail me.
My E-mail address is yasushin@microsoft.com.


< Date:>  	6/11-12
< Place: >  	Sasazuka NA Bldg., (Microsoft Japan Office) BF1
(When you arrive at Microsoft (Sasazuka NA Bldg.,), go down stair at
first since the meeting will be held on BF1.)


< MAP: >  	Please refer the attached files.
< Accommodation: > I recommend below Hotels as accommodation in Sinjuku.
You may stay these hotels in Microsoft (discount) rate.


    1. Keio Plaza Inter Continental Tokyo
Tel: +81-3-3344-0258
    @ 16000yen(about 134$)/night    Twin/Double Room Single Use   Fax:
+81-3-3344-0247


    2. Tokyo Hilton Hotel
Tel: +81-3-3344-5111
    @ 21000yen(about 175$)/night    Twin/Double Room Single Use   Fax:
+81-3-3340-4403


    3. Century Hyatt Tokyo
Tel: +81-3-3349-0111
    @ 18000yen(about 150$)/night    Twin/Double Room Single Use   Fax:
+81-3-3344-5575


< Guide to Sasazuka NA Bldg., from the hotel:>
    * Get in a Taxi at the hotel
    * Say " To Sasazuka NA Bldg.," with Showing this map to Doorman or
the taxi driver.(Note : The taxi driver will be not able to speak
English.)
   * It will take about 15 minutes.


% CAUTION %: Since this meeting will be held from 6/11 in JAPAN TIME,
you will have to depart for Tokyo (Narita) on 6/9 morning in USA Time.
There is a 16-hours time different between Japan and USA (the West
Cost).
    


     


Thank you,
Yasushi Nagao,
Microsoft Japan,






begin 600 microsof.html
M/"%$3T-465!%($A434P@4%5"3$E#("(M+R])151&+R]$5$0@2%1-3"\O14XB
M/@T*/&AT;6P^#0H-"CQH96%D/@T*/&UE=&$@:'1T<"UE<75I=CTB0V]N=&5N
M="U4>7!E(@T*8V]N=&5N=#TB=&5X="]H=&UL.R!C:&%R<V5T/6ES;RTX.#4Y
M+3$B/@T*/&UE=&$@;F%M93TB1T5.15)!5$]2(B!C;VYT96YT/2)-:6-R;W-O
M9G0@1G)O;G1086=E(#(N,"(^#0H\=&ET;&4^36EC<F]S;V9T/"]T:71L93X-
M"CPO:&5A9#X-"@T*/&)O9'D@8F=C;VQO<CTB(T9&1D9&1B(^#0H-"CQP/CQF
M;VYT('-I>F4](C,B(&9A8V4](C\_(#\_(CX\:6UG('-R8STB26UA9V4W-"YG
M:68B('=I9'1H/2(R-30B#0IH96EG:'0](C@Q(CX\+V9O;G0^/"]P/@T*#0H\
M8FQO8VMQ=6]T93X-"B`@("`\8FQO8VMQ=6]T93X-"B`@("`@("`@/&)L;V-K
M<75O=&4^#0H@("`@("`@("`@("`\8FQO8VMQ=6]T93X-"B`@("`@("`@("`@
M("`@("`\8FQO8VMQ=6]T93X-"B`@("`@("`@("`@("`@("`@("`@/&)L;V-K
M<75O=&4^#0H@("`@("`@("`@("`@("`@("`@("`@("`\8FQO8VMQ=6]T93X-
M"B`@("`@("`@("`@("`@("`@("`@("`@("`@("`\8FQO8VMQ=6]T93X-"B`@
M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@/'`^/&9O;G0@<VEZ93TB
M-B(@9F%C93TB07)I86PB/CQB/CQI/CQU/DUI8W)O<V]F=`T*("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@("!#;RXL($QT9"X@/"]U/CPO:3X\+V(^
M/"]F;VYT/CPO<#X-"B`@("`@("`@("`@("`@("`@("`@("`@("`@("`\+V)L
M;V-K<75O=&4^#0H@("`@("`@("`@("`@("`@("`@("`@("`\+V)L;V-K<75O
M=&4^#0H@("`@("`@("`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@
M("`@("`@("`@("`\+V)L;V-K<75O=&4^#0H@("`@("`@("`@("`\+V)L;V-K
M<75O=&4^#0H@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`\+V)L;V-K<75O
M=&4^#0H\+V)L;V-K<75O=&4^#0H-"CQB;&]C:W%U;W1E/@T*("`@(#QB;&]C
M:W%U;W1E/@T*("`@("`@("`\8FQO8VMQ=6]T93X-"B`@("`@("`@("`@(#QB
M;&]C:W%U;W1E/@T*("`@("`@("`@("`@("`@(#QB;&]C:W%U;W1E/@T*("`@
M("`@("`@("`@("`@("`@("`\8FQO8VMQ=6]T93X-"B`@("`@("`@("`@("`@
M("`@("`@("`@(#QB;&]C:W%U;W1E/@T*("`@("`@("`@("`@("`@("`@("`@
M("`@("`@(#QB;&]C:W%U;W1E/@T*("`@("`@("`@("`@("`@("`@("`@("`@
M("`@("`@("`\<#X\9F]N="!S:7IE/2(S(B!F86-E/2)!<FEA;"(^4V%S87IU
M:V$-"B`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@3D$@0FQD9RXL
M/"]F;VYT/CPO<#X-"B`@("`@("`@("`@("`@("`@("`@("`@("`@("`\+V)L
M;V-K<75O=&4^#0H@("`@("`@("`@("`@("`@("`@("`@("`\+V)L;V-K<75O
M=&4^#0H@("`@("`@("`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@
M("`@("`@("`@("`\+V)L;V-K<75O=&4^#0H@("`@("`@("`@("`\+V)L;V-K
M<75O=&4^#0H@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`\+V)L;V-K<75O
M=&4^#0H@("`@/&)L;V-K<75O=&4^#0H@("`@("`@(#QB;&]C:W%U;W1E/@T*
M("`@("`@("`@("`@/&)L;V-K<75O=&4^#0H@("`@("`@("`@("`@("`@/&)L
M;V-K<75O=&4^#0H@("`@("`@("`@("`@("`@("`@(#QB;&]C:W%U;W1E/@T*
M("`@("`@("`@("`@("`@("`@("`@("`@/&)L;V-K<75O=&4^#0H@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@/&)L;V-K<75O=&4^#0H@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@(#QP/CQF;VYT('-I>F4](C,B(&9A8V4]
M(D%R:6%L(CXU,"TQ+`T*("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@
M("!387-A>G5K82`Q+6-H;VUE+"!3:&EB=7EA+6MU+`T*("`@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("!4;VMY;R`Q-3$\+V9O;G0^/"]P/@T*("`@
M("`@("`@("`@("`@("`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@
M("`@("`@("`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@("`@("`@
M("`@("`@("`@/"]B;&]C:W%U;W1E/@T*("`@("`@("`@("`@("`@(#PO8FQO
M8VMQ=6]T93X-"B`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@("`@
M/"]B;&]C:W%U;W1E/@T*("`@(#PO8FQO8VMQ=6]T93X-"CPO8FQO8VMQ=6]T
M93X-"@T*/'`^/&9O;G0@9F%C93TB07)I86PB/CQB/CQU/E)A:6QR;V%D($UA
M<#PO=3X\+V(^/"]F;VYT/CPO<#X-"@T*/'`^/&9O;G0@<VEZ93TB,B(^*B`R
M-2!M:6XN(&9R;VT@5&]K>6\@4W1A+B!T;R!3:&EN:G5K=2!3=&$N('9I80T*
M2E(@0VAU;R!,:6YE+CPO9F]N=#X\+W`^#0H-"CQP/CQF;VYT('-I>F4](C(B
M/BH@,2!H;W5R(#$P(&UI;BX@9G)O;2!.87)I=&$@06ER<&]R="!T;PT*4VAI
M;FIU:W4@4W1A+B!V:6$@2E(@3F%R=&$@17AP<F5S<RX\+V9O;G0^/"]P/@T*
M#0H\<#XF;F)S<#L\+W`^#0H-"CQP/CQI;6<@<W)C/2));6%G934T+F=I9B(@
M86QI9VX](FQE9G0B(&AS<&%C93TB.2(@=VED=&@](C@W-2(-"FAE:6=H=#TB
M,S8U(CX\+W`^#0H-"CQB;&]C:W%U;W1E/@T*("`@(#QB;&]C:W%U;W1E/@T*
M("`@("`@("`\8FQO8VMQ=6]T93X-"B`@("`@("`@("`@(#QB;&]C:W%U;W1E
M/@T*("`@("`@("`@("`@("`@(#QB;&]C:W%U;W1E/@T*("`@("`@("`@("`@
M("`@("`@("`\8FQO8VMQ=6]T93X-"B`@("`@("`@("`@("`@("`@("`@("`@
M(#QB;&]C:W%U;W1E/@T*("`@("`@("`@("`@("`@("`@("`@("`@("`@(#QB
M;&]C:W%U;W1E/@T*("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`\
M8FQO8VMQ=6]T93X-"B`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@
M("`@(#QB;&]C:W%U;W1E/@T*("`@("`@("`@("`@("`@("`@("`@("`@("`@
M("`@("`@("`@("`@(#QP/B9N8G-P.SPO<#X-"B`@("`@("`@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@/"]B;&]C:W%U;W1E/@T*("`@("`@("`@
M("`@("`@("`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@("`@("`@
M("`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@("`@("`@("`@("`@
M("`@/"]B;&]C:W%U;W1E/@T*("`@("`@("`@("`@("`@(#PO8FQO8VMQ=6]T
M93X-"B`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@("`@/"]B;&]C
M:W%U;W1E/@T*("`@(#PO8FQO8VMQ=6]T93X-"CPO8FQO8VMQ=6]T93X-"@T*
M/'`@86QI9VX](G)I9VAT(CXF;F)S<#L\+W`^#0H-"CQP/B9N8G-P.SPO<#X-
M"@T*/'`^)FYB<W`[/"]P/@T*#0H\<#XF;F)S<#L\+W`^#0H-"CQP/B9N8G-P
M.SPO<#X-"@T*/'`^)FYB<W`[/"]P/@T*#0H\<#XF;F)S<#L\+W`^#0H-"CQP
M/B9N8G-P.SPO<#X-"@T*/'`^)FYB<W`[/"]P/@T*#0H\<#X\9F]N="!F86-E
M/2)!<FEA;"(^/&(^/'4^4F]A9"!-87`\+W4^/"]B/CPO9F]N=#X\+W`^#0H-
M"CQP/CQF;VYT(&9A8V4](D%R:6%L(CX\8CX\:6UG('-R8STB;6EC<F]S,2YG
M:68B('=I9'1H/2(X-C8B#0IH96EG:'0](C,P,R(^/"]B/CPO9F]N=#X\+W`^
M#0H-"CQP/B9N8G-P.SPO<#X-"@T*/'`^/&9O;G0@9F%C93TB07)I86PB/CQB
M/CQU/D%R96$@36%P/"]U/CPO8CX\+V9O;G0^/"]P/@T*#0H\<#X\9F]N="!F
M86-E/2)!<FEA;"(^/&(^/'4^/"]U/CPO8CX\+V9O;G0^)FYB<W`[/"]P/@T*
M#0H\<#X\:6UG('-R8STB26UA9V4W,RYG:68B(&%L:6=N/2)L969T(B!H<W!A
M8V4](CDB('=I9'1H/2(Y.3,B#0IH96EG:'0](C8V.2(^/"]P/@T*#0H\<#XF
M;F)S<#L\+W`^#0H-"CQP/B9N8G-P.SPO<#X-"@T*/'`^)FYB<W`[/"]P/@T*
M#0H\<#XF;F)S<#L\+W`^#0H-"CQP/B9N8G-P.SPO<#X-"@T*/'`^)FYB<W`[
M/"]P/@T*#0H\<#XF;F)S<#L\+W`^#0H-"CQP/B9N8G-P.SPO<#X-"@T*/'`^
M)FYB<W`[/"]P/@T*#0H\<#XF;F)S<#L\+W`^#0H-"CQP/B9N8G-P.SPO<#X-
M"@T*/'`^)FYB<W`[/"]P/@T*#0H\<#XF;F)S<#L\+W`^#0H-"CQP/B9N8G-P
M.SPO<#X-"@T*/'`^)FYB<W`[/"]P/@T*#0H\<#XF;F)S<#L\+W`^#0H-"CQP
M/B9N8G-P.SPO<#X-"@T*/'`^)FYB<W`[/"]P/@T*/"]B;V1Y/@T*/"]H=&UL
#/@T*
`
end


begin 600 micros1.gif
M1TE&.#=AL`+F`/<`````````50``J@``_P`D```D50`DJ@`D_P!)``!)50!)
MJ@!)_P!M``!M50!MJ@!M_P"2``"250"2J@"2_P"V``"V50"VJ@"V_P#;``#;
M50#;J@#;_P#_``#_50#_J@#__R0``"0`520`JB0`_R0D`"0D520DJB0D_R1)
M`"1)521)JB1)_R1M`"1M521MJB1M_R22`"225222JB22_R2V`"2V522VJB2V
M_R3;`"3;523;JB3;_R3_`"3_523_JB3__TD``$D`54D`JDD`_TDD`$DD54DD
MJDDD_TE)`$E)54E)JDE)_TEM`$EM54EMJDEM_TF2`$F254F2JDF2_TFV`$FV
M54FVJDFV_TG;`$G;54G;JDG;_TG_`$G_54G_JDG__VT``&T`56T`JFT`_VTD
M`&TD56TDJFTD_VU)`&U)56U)JFU)_VUM`&UM56UMJFUM_VV2`&V256V2JFV2
M_VVV`&VV56VVJFVV_VW;`&W;56W;JFW;_VW_`&W_56W_JFW__Y(``)(`59(`
MJI(`_Y(D`)(D59(DJI(D_Y))`)))59))JI))_Y)M`))M59)MJI)M_Y*2`)*2
M59*2JI*2_Y*V`)*V59*VJI*V_Y+;`)+;59+;JI+;_Y+_`)+_59+_JI+__[8`
M`+8`5;8`JK8`_[8D`+8D5;8DJK8D_[9)`+9)5;9)JK9)_[9M`+9M5;9MJK9M
M_[:2`+:25;:2JK:2_[:V`+:V5;:VJK:V_[;;`+;;5;;;JK;;_[;_`+;_5;;_
MJK;__]L``-L`5=L`JML`_]LD`-LD5=LDJMLD_]M)`-M)5=M)JMM)_]MM`-MM
M5=MMJMMM_]N2`-N25=N2JMN2_]NV`-NV5=NVJMNV_]O;`-O;5=O;JMO;_]O_
M`-O_5=O_JMO___\``/\`5?\`JO\`__\D`/\D5?\DJO\D__])`/])5?])JO])
M__]M`/]M5?]MJO]M__^2`/^25?^2JO^2__^V`/^V5?^VJO^V___;`/_;5?_;
MJO_;____`/__5?__JO___R'Y!```````+`````"P`N8`0`C_`/\)'$BPH,&#
M"!,J7,BPH<."VQXJC!A1HL6+&#-J?%AQ(\&.'D.*'$FRI$F+($=63'FRI<N7
M,&/*;`D```F;-6_BW*FS9TX2-_^QG$FTZ,&:2),J34IBI=&G4*-"W:9SJ=6K
M.6M^E,JUZ\NA%+T:15K"Y\VS.-'J+)%4K%N5!'\"!6IS[ER<_[0E!+O0J=")
M?Q&F'/JV),B.AY^"E&NWL>/&;(,>)`Q1H-ZM`K=1O@C2UN3,E2\/W(P9].B,
M837ZC6BK:EO3E1M6%%W:XF72L@7:C!R`1._?OH/_3KL3`&S<A9,;!,"6;0#F
M`)Y+CXYT(.V(QB&2R*N;^S_CV;&#_\[^_:_-@<8U?]?6-#``\=P!>(Y)/N[?
M;=GURM\N-'_Y_Q6]UYUNV0G8GV[(E723<S5-YR!UTS%E(&WH!9;:>0'^5R%^
MHQFGWWV9M1>8A>65<)N(]HFGF8CI<?B/+>`-)6!XY5WV'GRG%0B;13XIY=I1
M!F&G%4O;.77A/VB--R2!T!54'V??(>7:50O:U%MQ.RJG94,^UI7676SIE:!&
MMUDVD(B4`7`9A5NV25-5=*E%W%F1U536DV[FJ6>0[8EYIE8*)87$9;:8.!YZ
MYQW*Y'O\H>3DG6<])F=5=7JXYZ6C]<26E$D]A].842466T%E>C5;EH*QN656
MGDY*7$[/H?^%YXB8UFJK1Z"ZU"!T#S['8&]URHKJK<GYV!QS="&[Z9X5M:94
M";F*A9^$Q&(7F7#1^9:MKW(J!5I$JA(K[K@`*G<JN>A^=6FT?IW4KD31FBM2
MO.FB5F.]+M';$G8D;(K5O][B*ZUN4P*LU75NG1H1"?.)UJYZ:GKGDEX?AJ7>
M:B\VBFE*!@,,IZ4"PQ1NR!?-2O+)**<L%0DC`\F:4"VK+#-))L^\4,<XYZPS
MISM3V?//0`<M]-!9"5TPT4&CY:^L1AM\]+]/\RRU54PC;?52KD7=<=57=^WU
MSRP/:W.U`A5*%Z21SGEEM^F-;1A$`?9XK9=IQ[9F8KDB5I[6;87_UW9N]27(
M84=^)F0@B&N2)Z;#IE%EG9D)2QFIG,<V1^=K;F<^$\:G'0>BQ9^'#OKH"+WJ
MKY7!H7XE4Z6&_NV(H+^N=VJNUQZ[[2#*?AKA+Y[6QG:_1_)/&TFT,7SQP[O1
MQC;*)_%/$DFXL4T;Q/_C!O*_&T^\]MAWS[WSHFD#[J$4HT<7Q0%_]VZ0_N1E
MLMZZ'Z2-@$;2:M_NN?N'U5E4^34?[)T#H.Y(Y[GOW.E8ON(4T\!TD_&9:7:B
M0UP$24?!!T*N<9@1E08S.!I]I4P;U`,>$KYW/!)23WO5.^'P4DB]%3I/A=1[
M80MC6$+FV8DXQ_)2T7*(%!/.$'HK]*$0_X\GPR$2KXA$#&(280A$)B+QB$JD
MX?9<2$4I$L^&<R+.ZJJ"O11V\8E>1.$+OUC"YQ5O&]'3'@",EY;BM0&$2:D>
M4,181BA.T8XS#&,5J0>`)$2B:$R!GO&@9YSM30]Y2=`9&>_8Q.Z-T8@LI.,=
M]6A%XS5/B==[9!4=&<5([E&2B\QC$:<GB>TXSXW_&.$@6ZC*Y['RAZODGO%:
M"3WG:<XA;C!C+%VIR>+U4H^^+&,PISA,1(:1E,Z31/0.:<DS7J^9LOR',I.)
M2&/^\IK"!*8VL4G,;6:3FT"LY3>M9\T:2G&9Q,OE,YF'O$S64'FY%&<W>]G(
M58[QE&V01!];F/_(XAQ-E\]3GAG!:4]AUI.7=:SEJW1"R20`KWK*W.4\QSG1
MBI;3H@6=Z#-="4V$;K28@SPH2!&*49)>]*1OI.$PJ[=2?,K0I51LJ2LC\3\/
MGHQZTCOG\BHYO6/R5*<`):;WLMD&6[0A*W'ZTJMT&$=-,C*:W0SI*B7QR9Z.
M\J>1M&H0M7I"KE+/J[D\9TY]JKQM*%,2^'%5M]#2U4BP](=)F)Y23BF)G;(P
MKGS\F21L45<4VE6&8WVD5_^Z596V(;#FO*(RP7956'+UC%A%XDKM"M6A/K6&
M;NRI+!^;T^N1<WF2*$%8'1M#$+Z5CJC4Z6/_:M;HQ>R6L!7,/R(Q6,U8'B^L
M#H7558*EK;+X!*9,7%YJ8RL;IJP-AP%C"72*L[^:O6U4Z]L1_.`5)/M!$(,!
MO&X``2,^6H4%D:%-XD;364*>^*AJ2;U)(F^2TC:4(*9G!")Q/U,XT/^]=KXR
M\2,SOP.4394%4KLJSI7J)#S\AJ0B_?(G=8)5@F6YKE!0J\[F[*,C]X#H/>19
M"8K^\S<7A4A]Y7*25BI<H?)TA#\T6IAI"I2A`95X1!$33/-:RT9/0>=7P6&0
M>=-B$LUXL'Z>N]UV!4<BAG1,*`XT<%26FZQMW25M/6*8DD>2E`;3+<#)LM^4
MS86$\=FT)'VTT^3,>S9DX<3!)SE<V=I&HQ<OIS[@T0VTS#,@D($8SKIIGYC^
M)F+F<O%_6^;*F:^\*QTCU<:!]DB5FCSF]#'DRZB!=*+G)90>26A3VG*-C6N2
M9&*U#TCWG?3)`K2I5M5%+?T2SED\M1))PY;_*CL!CHWO!!V=P*V!HPHR8+3<
MN`J'6M0QX==N$ARL.5WKR3?:+K"7C:E3#V=J@+Q<X)B]ER@M-,$W7(N8FM*H
M]A@HPU%:\;<ZS!X<#:@U+N8UM8MRNJ(!ASI*B1!;UDUO6Y$E)V4!3K&+G1-U
MTSM`V6:*6L%=[RF+2=B,YDE_%TZ<?A;\X7IBFVN.525:\P_B1QGTG:1SDP3J
M1%08-_!R&ZRMG"4UY"@?&'\QG:VD`K+*-4G"KY<MM;L0&B\IS[G.=UZ8CO!*
M)QS'26_B)"M;*YO9E[E%/W>6!$#S/%1E*U+9!M1=B8$$80,!],+4\[KEG,Z6
M@PDRN/]FH\YYN8"P_S&0JY_.ZV;![2_S>5=GWIX[TQ3.WT7&+MJS#CFN@ROL
M8>]@7M:^:_Q5-TB>H1U!Q$>[6Y@=R85O2/D>EVNV2\0_*LH,HSHT&Q(?:'YT
MYKN32I=Y@30%SP<Z%-?K_!^]].F"C]NPY>V5*1?Y!_+6UE!W\+,8&`-*[4@:
M-Z"J[B&.I5M][Z7(>W7O/G%K*#^6@L_J36P4%GTX?YQ.3WU$4YTG:;^#*%)N
M3<J.(P[=AL0?<N[LU\]^]ELLKOGJ,G<(W_[ZV__^1J'-Y/;?F#G9O"9.]W3@
MLG1+Q35WAW?XMS%"@030EC4O9UXSEX"S]RS-56J2@Q3TMV5K-2EJ`7L2B/\O
M:75JJ.9_Z844MH2`']ACF1&`,T-Q-Z8L3)94"603+)ASHN$OI_,KNC4K"(89
MC4(1A2,@?M(Z$X1[=U=?@X>"&Z%BK[-\?Z$7<2=[*]$^9W<:B<<?'9%X2)*!
M'!0E-C8<E0-OL:)O@/(/5/AFU=&#\\<=X6,94KAXEC$_EA8CWN$9V[$4)]@H
MY;,=-56&FB<05`5BSH=[E.$9Z1&!B')DEM%IDR=;O0,Y@%93CT:$(G%##[AJ
M#3)F5<&%!J8-U\);<W%<VT<0&F,9Y/&#Y4$>VZ<C8>%YH&=B&,)GSL.)'[(<
MIC@B[Y4?A1,V,69Z\`&%SD,>AO@AB.@1=;$T?I9Y12^G91ZV$JR('MOP7EK(
M8E0G/E)'9ZF1&EAH'(8X&'["(<;A>*;WBGM&&&T69TS('7TR+3%7%U"R75TR
M*VW6>E2W(8_CC%67BI#S;2Y6>AD!8)IX@26'5./7?JUA:IL&2/.FA)36B"US
M<`SY@<ME9J<V:)F&;561@O_RTA=0,EV?01C%F!GZ@2W3L7'4L2"JMEP167!R
MB#;`HC0[<2DWQS-KR(D=.3].4RMH8R40\C$#"4@0*38:>2OL48/H8I.!-GT*
M$9)<P3@KJ7)Q5R^N]FGTQA[YN&6T]C5-(R%"PX!:^95@>35SHS-\$Y9F699F
MB34PEY9AV6Y$XY9L&9=?`X=3AI1+Z#-:TRWMUS-OJ'+W(C^"MQV4^!*B$3:W
MP3G=L29YPC$*!&T+19,09Y>UHGY#69FC=GQ[`1]1:9EN0IF<R25<,W!8L7[3
MXH#*B',<^909A&"+P5P2EF'<2'D'X1E623OU$QXQTV(@B21.QQ*M^&C8Q3F(
MB1'_N\$3'B=@4E(IGOF9`EAE_95M5[(VD'(ZBK=LVV`+'5%7^#1(GG58VN-9
M:90\IP0]VE`\[Y59@;<-3GEXKT@JR0@HFI$>5)DJIK<[I$$A\@$S=6<0\_,R
MWS(^JJ@4;+(D1@D5O,%R%8<LS[F64L:<XC*$3PB$UB&ABZB?%:J>$VJA28BA
M>Y>52Y467_@3..$/%$.A&QH^)MI=''JB&;JB*HJB&OJB+0JC+DJA_LFAZAD1
MXK12TA,)==538556OJ15),!/GB1/U%.>+-4]34&`!$DE*:*A4>=]<$>7$M.&
M?:>8+<:&"F&(CR.)3&*:Q>%@*WJELHFE5YJBY\*AR6F)_SJ$:6@C*QCJGS)Z
MH31ZIS.:IQ5*/+8@2+P$0M8$J/;$3&A$/(+ZIU`DE+%53"\54W>U1XUJ6(TJ
M4\&46<33CLSA7[EE<9O*15IA1<#U5I/ZJ)1*JJ8ZJJCJJ*D*JB3E23_53_UD
M<9#23ZDVJ0)E6)(D2ITD66]E'$E05VH9<R_41ZT*4]'#J]M)4MT92=J@/,:!
MEJ?41X=T3[K44U1%2#DA/#*%JPB%2I4JJI!:K+N:/!E5/9<4GI44KJS*JMOZ
MJ*"Z#6ZE/=FD3L9$KQ+UJRM$K]K:0I<$;);:15`%2PE567Y51LIC2;K*1+GD
M6PK),TTFG3;A3I,4L-%TL'4DL/\6.[$72[$;V[$:.TE@5+'\6DVYM6--=F9!
M<4DPE$<(NUG!A4EG]$=XA3R5DBQ`1`)GI)V#93TL^UF?Q+,%F[&0Y4Q'U4-H
M)"70LU_$8TINM4FYVK(&"[!`BTFN*K`?.U1""[7C9:[\ZEA9.[53]+4ONU%D
M.U3H6JBXM:_<<ZV'=3QLNU/XFEIQ6SVU86!\L2^N=*WA=%$M5`*(1)!J,1RM
M4C#K-9XA]4(")4^):Z1Q%8B'5WG#<K>0&Y&2>Q0]L3JQPF]X,GT3J9;SMGKQ
M`A;1U78<\1F/.[FX8KJIB7L#<4J)VT2+B[@9Y:QK*73&66L7F$_[]:N@5:0(
M-4UHY%G_0^:@*,,2KKM+Q>,&V_*D=M$J_W46#F>IRB1-HUN7<5$I#'MO%*DJ
ML*8S3D@4YUA=\$,1W9@9O`,:3A>^4[>"$;HC3P(_:N:ER59MBM=[?^%9)`">
M3718B020V0*BI^DO3>>=5"&\#[-E/B<EHC>4A#,;_5LEJR,Y"1DK^(9RXJ><
M__68THHJ2NE=$B,3\;F^[:D^^B$>\^%YP8=&<9%A*OR(H(<C.*DA4@>?_.AB
M+QPD,U)?IQAWM5BZK$$IRB@GQZ4I).$LG=N@'BF2N'L_#J2'158D2*BC(T*;
MCS>@3N-H&BDA*+E%1+<6&?ET=<$M$B)K&$B\Z&*R3M:3/-D@M[1&$_DC,4WA
MP!<3>GP69\Q78;?''S?A>AE2/N]K(U)2O0ZZ7FZ*.KMB8P4S9Y*9,NSH@#5K
M<WU1G<$FR&8<)6&H<).BG(F2+HM<R3XL9TH%=)!1:[ZE$T@8<@Y+P3O1;B[F
M(<]8BGY8(QG2(N;+A[<('P`PGYX\'A8'P%*2D&ES,$>WRRAW&TL7=$]3,#IQ
M@BG7R`1I.58!>5?7=]@%:%25&(W($@UCAK3#E*2I)*N6.JDFG65VG/_$C']R
M\;_Y)LXO:&7GLW/]J\[^5,I&I\OG["8PXC&=DD7^=<_UE\\`ID!#_*0VT<DH
MH[EAC!2FMIS^_!;,0<@!/=#^=!<-O9<CYW)8]J99D82J25P50:M#9VHPJ1.;
M6=$F?=*98]`H77`8:L=QX7,Q3"`OYA]2]KU^0RN;^WSQ(21_P1\P8G;YV3_4
M=R`X8F<`^L&5+'V8&3M.X70L>)VR2;ZPH84OO1Q<)XY%1A$4`79*G,)9HM5"
MH87I6[?N@B`=YM.C,1_H5J9S2BH<+4#_((ZZ>3_S&'A;T5TC7)DE+9+27!OY
M"*;FZ]8.D8WKJY]W-VTIT88.M,W8B=,F#7S_(.8BUGB'.8(@%'8?G';']+B0
M58>*/\U]T$A]^.%ZQ%=`S[@A+C+'+V(H,*$WR0;5!8T=SHB.E;9[!.)AB:DA
M\'<8K"W;NM%=$T)]O:B*M;W2QGW<R)W<RKW<U68:3CHT'<QV#QB/$L;<4$<@
M:*F(UDUSC%&"0<Q<]]?=DG(72;S=,R'>XYW>!6G>D]8:'P.X10.3.5&@.Z?0
M$'+?$3*/["TRWF&[8GC(^'W?U:W2^]TF-^8<)*EJSY8LDF%Y(#&"'%B<5EK@
M]!'*$>X8P];@!3X^=W.5,T-F(KI`@R:B;"=^#HA>-/C!H^LPI-'`E4$90!9Y
MP?:1]W$=@'<:$&FB_VM(U3.>=6[J*9H,;T)N@G3G9>L#UK'1FZ!1/GZ7$/^C
MF$&B-WB-*DZ)&%AJFWP-G!T-F$*Q=*@;,ESYWDG%<CDT>Q?"+8*;8R]X=/(H
MV+09Q[G679\6E5->9&+M@2_1Y@3Q:=N&U%DHV!<48]V,YS"1%7-3<:FV:,FR
M+&RB8C<Z(T(QG]O<WR/2B`+Q:7@":-MH'E57=H+8'74L<TQL'M&X&&P=*"%6
MNCD2-8!^+I.QV('=:5W'$!Z.$1KF7^W,*TPV->L)QG3#-D7#S*,'$7;V(GCA
M'X#,BCU8)J]98O_3).KRZ6>"U,=>(;21U^_!'E/'>RN<'K(W$YBV:,VU8/_%
MP1(#VN!C%]F67<,!0CO1)WCB<8W89B=!2.HNAH7,5]7EEA<GF)^#EQ\JHNV$
MGA!P4I:=(_!KR)%"'1\EAAP_O79V&-_79CH+Y<&^#F\(6H*H,FWMF>TR?8@3
M`A0E%L..`\@5PF8OPB\@K#A_F!=\:"TFUC\(9H>1CB0W_?'NX2%S]A3.F8EV
M86;!H2E&%]54>GS@D3@ZXND:XHR`F6+-][XP,SY-(1J>(7\G9H[$7B0ZZNF\
MLW6VOKZE624Q:8O#OM/[N.2OHV9J8F<HOQZC#B6P,B4.>%R77']*=4`"[B\3
MAF!V4H<IT:>"^7=)'27B+N"9J$"GD]PL7EUC/^P]/A?6"\/DK@>)L*@-?IS"
MC7V*Z59*M&=Z<;_.P(*[$2PG[<>."F87+`?"!''-S2V;BLK`L2J0&0ZB'U,6
MWO^\W-6[=F'WC7N'&D%^XJ&L%$]N>2-GR+LB]FIF+D7#@%I3=02>$#B),QK>
MF3[1*IOV;O_[(V1-X1R\$;6.$(-I&.SQ)1#.<25)R@R-<1(?].0?RWD"-6$=
M&+=/$D&X/Z^?'(HNSJFF<`K=9`"Q[=]`@0,-'D284.%"A@T=/H084>)$BA4M
M7ORG#>-&AP``!/CXD01(D!Y)`#A)(B5*CRA)%.084^9,F21*G`10HF7(G#Q/
MVJ(9M*%)@S"%'C4(]"8`I$T5XO18$NI.G`%45CV9Q*A3KET3:ORWU>O8B]N8
MAB6;5NU:MFW='H0)%.W;C0+%TL6;5Z]$IMO\[=5+@B#_VKL5[1)&?+AP4;!C
M"QY&'!GRY+F4'R?&K#CS9LV7*S?T;/%QX\5J*4<LJ'';Y<Z8YRZTN_HU:(.-
M:;(>C%ORY]!%9\O<VOJT8]]'/?<V"Q?P<L`M<::\RG)G2YTZ6S+';E$Z=)4L
M5YY$DC&[PB2N%6H$L,UV4ULDM,%L/5";MO+C^7IGJ?.D?JO35[*T+T`!V8)I
M/;IRZFZZDO)#":2I<!IPP,;HFZY""\_*"+*\&@,`+`-K*R@]V4J3"2R!^K+-
M'[F,DB0]@E2+\)_V+KQPI)$L%.S#&,G22,<=A:(Q2"&')+)((X]$,DDEEV0R
MR:F.U*])*8-\<DBHGJMR2JI,_TH0@"2>?,ZC)*33LDPSD[3N3#775/(D^'YL
M"D,XYZ2S3CLY2NX]AT),+;<[_\1.3D!E$G100P]%U+X^"T4(QHQ>^BU12<EB
M=-)$>ZK.N_Z^P^^_O@:S-"V/,K6J5)LP/:DVITA#*#F%3,KI(*;`.HM$^;9Q
MCZ$.!_H+HD^'6I$V7.7R,2^J;K+I*DY7L@ZJ4(.2[=E$3\0O2AM-[>G:*VV5
M=J;58/WO03(U-.XKIK+<22>-!#/(Q5870J^W\S[UL2"@*LW-7=H>Y=8M7-/<
MB21,!TYITR2*[39AA97[IR<R%R03UBU)('9ABVQ[4Z`V)&ECFS;<:.,?D-WP
MF&.1)?\IX9\VVBCORY#ER_"]T1AVB-;*MO//H[!.C`BH$^6:2*ZS3-Q3L.,\
M_(==@LR2TQ:8:MUYKW0;A([,[YKMSV*M+7Y3/I4R=:F[E);2[U0$\=V:(=NT
M6;D-ME?^)XDD.HYD;H_MKIONNO]!.62Y.V89\"0BL25O<GT5+\.!MC1)IQ`/
M\E%/7!DJ#4:P)"E/((3#TJ8$5AG&<#I96](FU^5P?IC3"O?3.6W7;XLTX\K^
MTAPMRPWJ-?%_<O^P,5O29#VD4K>4RF%]_2RP.-V3A[EYW2=4E=?H=Y^>=]RK
MGUY/[2-9V6.6MY';#97A;MMCD,>7A#[,;0&YO,!5GGO\D-W_2$+\N4-FN66Y
MX1?/KEUE-,A4HM:PZ[BK:\Y;W$!\]JZO*.\@<K&%G-2S&/4H+6H:^M^,)'8=
M@9AN@J!Z7O9$Z+P#:BXG8\I4=7"2PF2=K3O-J]T(^\<9VV$&1H=QE/9JA\,:
M[G"&MXNA>'KTNHALK&VV..+*"*=$)+9AB2MKHB2:^$0I)G%C36Q#%+&HQ;8U
MCDN=.E75EN*=^R%Q<%M<616AF$8T7G%E;N#B&MTH1S5FD8U6K&,<[3C'/58Q
M?H8;&?A8!K](P`]P+`-;=ZQ%G9[0)PF2@)_X6%;(]P4.?/&[WR7=AS+XE0=D
MZ<ODQUI6@C9X"0EN8YD4PR0)P@$@_Q(I6YE@RLA$/*+QD4W42A?OIPVJ2$(P
M:?3>+U42-[A)`@DM,YYWGI.R3/Y-?G&$XQT_!DT]3A&7=\OE'*OH!C5V$XG<
M-"/)G#G+.4;SEE9\8A_;F$=I9A%S<VL9^>!V/_D1$W_SE&<\[WFPD&U.:_'4
MG]\&V092$M.3];-G)!/*,OL-%*'P-.1"X]>3,8U*.E@[27\L*B9,DJ^C[OMH
M1"'ZOI$^U*$-Q9])0=K0E1I4H25EJ4@]*M"4^NU\]`L92RH:MHVZQ",DG6G<
MSO>^4Z84I3+%'PD@2<I#OJ24%?H23N)7RH`*U:@2%6A+Z8G3A9929<X)TE?3
M]SX`.-1M<S8;&+B<6529@C2K;84K4`]*4Z36E7Y'Y2H]Y5I7H-84JW_5ZSSO
MY[Y!CK2P`STL80$Z/H#:`I+_1%0(YCKV-^]U#&3X`YGY:.H]?7+6GI7];-L^
MVSZ1[2]_Q)0BYAHJ1:ZF\6V@S.S','O(>UI6GK25'VC+)]K='A:WH<3G;[LG
M6N!N=F6$/:3[8NM0D+:,F[?(:R3<P+:.VE:YR26F^"Y;3]YV;[O'C=N7[M8B
MGT9LLF45)&UUZ]W"+K>VVR#M;L\'3Z8!#*I^>Z27[&;)E<&2?O\H`<<$"<FY
M:1>QN.WM>[LK7,#-=[BWA2^$20M<Y'+7O;GE;6;CNUSD>K:W`?7L.\>G7=/"
MC7Z>-+'=),NW^(V,?R"$;/F:R<WLFJ^0H8P$@=T@21K7CV0?T_&/>[QC\Q'X
M8^`S_]F"M\$Q]7*OP1U[)V@+/&"ABK/'1WYDD)&LY2Q7><M>!C*8ARQD+8?9
MQT4&LR1TW.`U4[E^D^W>(VFK#2=7=LG#-9F<W4SDC45"D.+,<VRO3#(W`,"7
M)%CNA4I@7R\!^)%Q4[-5OUQ@]'FY?D8F<XWE#.`VH*NL)AVKW+PGB5&G][5_
M9IL;_#QE,Q.YRV=^M:LC?>:-&1EPL^;SH-%,Z3Y+NM5PYO*8P9?C&G_LQKDN
ML[`?V;(\F[BPW!/9L_?Y6>XM%KSQZ]?"!%=;QK*8VR(6;=[J*>YP3Q5NY#[W
MX(1ZM@TF*$W`^R(SOU?)<]_V'^@.&;[O;>Y\F[L\^@8XO__WS>V`5WC%HF5R
MMU?\)?P8;XQ3*3&WRZW8@2O<W_<N:W@AN3*'=>R;#4LQ@?<;<6^/6^!.-CG!
M12W:0B>A!'+S,T%URL^IBO?@Q;SXS?NM<IZGW.04!W>ZOWURDM^\/#J_M[T#
MWO-RJWSC?TNI6SL9T1-3W:S1;BX2$0A9V"@DVQH2B+^16%#ZTMM]!24!RS)J
M(P4M:SL+PF9$P6OVJ;_<K4N.'W"\OO>$9+OK'4'=5#1J'3_UW=/7B51,_.Y`
MQL/X8FE9_%RTP5522KVD$K_X4VN$(\:A!(LEFZR`F2K(4>[3C%IQ?..YKBBN
M'`XR3@QO2D6>4J`$[G=A2M9W-H7_+>^\W*-/EWWL2TOJ-`Y0<0Q,_')(9)2H
ML%V%8G.0F$#X-+!:2/-"B3S?65^NO<,D?-Q]-$/A!WR1>7&#[Z::<ZRS:+GI
MLYX0#6SJD[\O^:\^;?#1QL*':K<I,ZOM"RH>Y^L.3FH_2/.DE\N^A`F13FD)
MDOB.5%D((GF2KC"*;4""N!@(I0$:]4`(H,$0/8F,SQB($L#`I)$\2-J&>Y$\
M^6"*!3*0TBF*QP$@WXB-#NR[LY`;4BO`<?HOS>,IL2FO%<H6GS*L;+*CO$M`
M2:F=)+`%H)E!^VL*#1FGJ0(K&\&]Z+@2+SFA1GN9/8'"RM"\``3"&T&\PCN\
MJ!B5^IN)_UY!#X+H"^8#H+-P$9XQ"ZVP"TC!$)Z1%3<<()ZYA00*G7:I%:-I
M&/&0H`22$3F$G%WAI3B$'#Y4#I#:./))&D82F(S2E#"QKT&J.II1PZVAENHS
MG2\D#K20&X=Y.)8`P+,!&`@DQ8C(';-0EN%QCN@C/!`"P0QLEIVHH;48FL7A
MD!GZE()@%T%1Q-H@Q($(C\3YGX:9$*9P$4B1P5\!,$1$BT,LQ.1H1A2A&5SA
MEM4`G(8IB;)AG7)DP(IR16])O&AA1Q#9NNG[Q-`(#N4A%^@9'1IYDFAY1:[`
M$I#(E*_I$@9,QWU\B'7AB=YS&"P92.2#EZ7QBA+<C0NBQZ2@'/^&D1?\FXT@
M>A?U8!4Z[+L!<L+#4;V*K,#%:3AP4<7F6Y#]6,B9:$;=\0?X")'Y<$@Y1!JX
M4(S38!%KA+&">*Q7.1*"I,`Q::$P\8\P&D?O$,J):!PAK!8T+`&YR)VEQ`M_
M@CRB)!NVDPHL]*EW<T*:H$9O!(OV2(@_O)?6*<0]/$9#1$2H<959^45&'`C4
M<Q23M)`DI,J+6!VJN9:)`9.\?`C[`L(AK!K`Q`N\[(K-4PF!$0F?"!.D<,L1
M)(CRR,6TS)"7Z"`GA$9@W$-GC!L.R1%(61P]S,!F3`WZ,)#"T$?#!,M3T0F-
M`A>R:4R`^4C67)SNZ`_>(T.=6LW:[$W_:*%'D;3-*$P:E@P>GQI#SDL46Y@;
MH+'*X100YD/)HLR9[6`[Z$R("+(*MX,.%0*`KWQ$W7$*L5@/Q,3.AY`86U20
M3+R)F\B:D1R0U?S-\QR4V]L@D=C.16*T67E'P)0.WJ-%3XD@A$B/OL@<0<RB
M0H00]$")HMB)!:I$T8R@+5$@^@P*VTC(:LD]XZD2"!1."P51Q0N+BGK-P9R:
M9D&6I8!/JHP@9,&2AEL_16S$C.@+=SD>5_&9EY"9A@E%%VG$I[$9RPQ1V)E,
ML(J2O5RDQ<R)QYK*(752T4B(ZMM*9$$="UG1I;0H_H"5Z&.W=MG#TO$+6DD5
M;UR>ZZ"5,C3)4ASQ4@+ZSD]\4HI`"8#9SL5D.]:Y1`B9OS?54X;X"T=QCJN`
MF.+1CT%M(1"=4.O<%(74B>*XBSYQ1^1QO!&QP=J\GCWE"%Z*TP19R90,FP>I
M#TO_!=6+:$^?L!;8K)`T`=&+\HF28%5>],10!13_F8XHB9(Y]8\Q0AM8U=5&
MV:GH,(G=`TBS<0[S!,71X0YE4A9E"19BW=73F4X&@0KW)$,KS-5F;=;_=(E-
MP4<M1%/L3*;&;-4&U!EFM=;E.%*PL9(X11#P+-=F7<"JD)@4U18C;4FJE,[V
MY$YM;;0F;=<[P94F>9#Y[%==W8:EP$*(J4(P0LL#HLJ(R19M93NT'-B)I5@H
M!`JG3-2R24GK"(!%\PCR7$KI])1?)54\)=>*1=F4A1/5I`@G?$ZNB[R33=EH
MX<\$LA?&>(TA8AX]\4`1[)K):97CH<$748ZP+$1!69O(_W"4IY$7E9V4DI19
MR&(>/'':B[`>'JV=7`00??E`J`D+)&B=0(098_S(7:'&S6R7QQF-9AQ0LY#!
MR>E94&G#/+76-\%,C?`9.5$-FH09H!@B&:E`O(U!HD4+"$T<ZDO(G8FAK?!`
M$*07+[4+$T&:FYV+!4J/OXW"&HQ*$/+:_.L?1L3(\$R^XR!0[PC&)]Q(1X6+
M46Q75Y&5VM$9.8&:LV"7LYQ;1$P.S025Y#@,2('!1A0:%GQ=!C+;)P33-K1'
MUZU:V%U3W\C#`IW#M!S7M@2@`>4E"Y)1ODD94-%;+[W=-AW7WPD+WXU<L96@
M@^',M"0:1'2:IIA*?U!$@6B/]_]HP[SE406JE1:D40+*B#;T2-&$"VJLC?_1
M&3T9FO\QBR"MUM:MT'G$61&<U,%@5^,3W0>J4,+5PPV4/+!S2,[I.R;L3Y5M
M4[!X";_=7B_]E;<D4"%5X6@1#*]5FB`M6MR5D?*(WK7D3-E8E_'-QO&%#-6(
MH<YABYIMQ-`AC7/9%:5QRP(EF@XAT[15E<@T05>AXK34X=%,'!6LVBUVT@G6
M2,J-'G;MD<B]8!K$F,%]8-4+C<9%7=\8RU=UU*>YTJ`(EKXC%Y$47)@1BZGM
MW]W]'%RD2#U>08'EXD(VY`")6KY+Y$-FY$9V'9`%CI>US=))DD5VY!()R"9!
MWTNV5P=5G1+HF!XGO<\AZ4E.IHL%W$\D\5!3)LC+P%2`73^Z-<S),)MP0<Z6
MV&199N6FP!B<L67N;+B.V>5._E,73=:J24X5U=,S11<'E`Y*'6:RB"&'59+W
MU/_E:$Z;-'$0@4'864VF4`679*'2D9UC;$Y,8SYF<?X:EW@^B37G?=S09;$*
M?#58+LD*/5W`@Q37M4,62W[GAR!&-.1F?0Z8"YG@?^:Z4T5)"QD\5]W30UMG
M,2*3114BA(:\VQ3(3IE39<'7#[1H^\N/4A6)![3EEO#GA?$A<9R:XI$8`/YH
M"CQ<:'W*(Q7H"G'3=^;`5I%D.,$9C0V)UPR)B*72G>[D9?K3_+B15?9-"&X(
MHE:;$+[INIA(QZN8G'X1'DH]HZC,P:!?XK`OQ@P8ZKR:-H4(S>D7#-SCKN-@
M2.I(PCACO[7!*W;'%!S:%!P.B1CC:P;H$.(:]3M*DL[_Q!6RU%?^HN9+V!-6
M"'9=D=ZHX]+`:B],6K*HF$#6D9G!B*_4ZM83SX8!R+`QYK!F$%AIE1J$&>@Q
MW!!4CA<\#PL^W)O<:@LFW3/>F;\`"I>M:*A6:[TN2)PDH->V%`WR[(,4O-VD
MU2<]XI68YX(I&`!I(!:VQJF48:NFX+1&XXP43Z=FRE?Q1)Z1G%"^[0]B2X3H
M%;KVQ2!Q0"#<U%M$BZELV\EL7@]6%3E&;4%.FM3`0/*5WN9I1/\U8"LVR1ER
M:<ZVVT=]:B^Y2:D>7XGQ;DE!CS':2M=T(094;PL]8S0$D_3KB?@NBF2$W#LL
M(-*Q2P]B4Q@,:)2XW0P41)3X_]"9F-%G;!Y>?(X.*L-D!!\.\3QV^=>/Q>*'
M%$2#G>>3C+YUILT_%E+E>`EG,<&#>&&3?I0&)1=L[$S+E&(<]H>7(%NQ??$>
M#HM?T2!=J6^,L.\:OI#?N.M&@6_,)O*FAN^3I0X3W2#8W,W6T8P096<7@G/I
M"$E9V2G1WM^D2(\#G97'@4$'M5F">&'X9@K*A$1>QF@*E9&4(1:T]4R$P,P,
MR5X>/ML3EVQ%$A?C_-8O0CT$>@_$XQ#-=-O!@)27^`M"U.*YJ%+G(6LMUAZN
MO48HEO(BA]Q"_`LL+W1'+$3?+FM9W-;$`_;PM.R!0$$S5TT38=;#P!E_5%AS
M!,)-QO_N5]S%M1L5<W3GP4B/)E4:IBE&RV0:.5P-`/Y1SJ;=;_'>AJ%HH36.
M/+3UA@';T?P56+%?9NQUZ1U7'5W@HZ@^V11,!%EGB^J[(5J/^*UUO5W+XRD4
M;!0(2'I#7K\+:+P,:&QB+Q?>6X<)]R!&.=YI84]7^=A%+MEK@_`ET=8(?U#T
M/1$:#J^)GMA.!@'J(41#A]93IS31%7*3V1AU"E;B`+9,&A>1/"13L@7$1>]Y
MK[`@&9S1G9%TQG"189Q1#C^7VB%+Y165-A?%B!;73-UV@DB9R<#A(@9Z*LX1
M8EP;I!U>U0CW^?P9"W)&KQ7@=H%027?B]SYB"H8(2C82[;;_%:.X^LK`PZC^
M]<V^"!-QV`<Q46.>\#<ES)]ND-G$%T:YX0)"=[O<S%XQB6'!?"&5((=)#GX%
M$K_?<NLHXK`MP^N-76?7&1+XPV=&>+7(">"ITX/46&%MT,83G?=.&H.,708-
MG>E]<1IAV*_?7<J/GLE_%WA/"9J55%R7B#],T^K;*>V.TO!^0H_>"IV`Z^S%
M$.9T&KCW6NWHSFR!U_Z0TR]B2/K4E&<=S)7W"O`7WO($$:\]:=9LREI\5C&T
M>58&B&W_!@H<".`@@!((`0QL:-"A08&V'C;4]B_)1(C_"C+\9W$;B7\=)V[K
M*))B0Y,:5S8L:!!`@(4D8"8D81/`_\R<.7$B),CR)]"@0H<2+6JT*$B$.WG&
MG%ESYM&H+@E.W0C1Y;:)%C-&[>KU*]BP8`7R1*@P9P`2:9O:C&F6A,*J8N?2
MK6OW;DN?-WMJ[.B2A$6")CD*+-PP(\."MA@"".R11.&0):V2]=A5L<W,/)W*
M3$O3LT*%25PZQFOZ-%V%!T,GY,F:)VJ''P>2I&H9J[;2EF/S[NU;MMFR:I<Z
M9:M:=<C?RI<SEPUQ=LN#>3>J3)D2>D%M'7.?1%EY,LKN*F?*'>IOH,7/,(?C
M?'U0,^?6Z)O3_YWTIM.=^7N6QYM]OD-R8=5??04:N%)9K^TW7'P)XG0@A!$R
ME]%LAA$8X$DV_^F&%67361588!>RY-)9F^'DEFMJ+716?A*Z2%=K:96X5H(S
MM2&B@?$UN)!,M$DX41(\"BDD5"\B6()^KK7&F4U(OE=6AD9*_SFE5P55Y9AN
M5SGFCX45>0D@F'GA&%242@F'GU)P[<160E2Z.=1>"VZFFGQOBC0DGG;NB"<`
MAKTI$U-EO:>B4I[QM9N=B2IZGE4!9GE4EMN4QB&B7U6E)(TTL;B09\5)IRBH
M*<'U7E,\:E:=E!P)*F2'C4*H&Y\\C7D@9C'BI)]";&7:WD%).#9KJ,$R-Y6?
M0I47I:L^3?6KLET]^J1^:ZYG8HE%`BLL?4F=B)::3BYD)U9TEN7K?ZDZA"=D
MP9)UZTQNT;D7M,)]ZARV]=H+*JG<0GM3KCL%Z=2]YI:4XJHGLI;<E')IQ]FC
MX-X)6[".O<?B3MXB66UK)9(6,,<![_\9*\@ABSPRR.*2?#+**:N\,LN`CAQD
MRS''^O&3J\E\\\DSF8PSSR([M7//00L]],D;=RQ6<@U;ZE.C5BKG=*M^2MTT
MU4Y;W6R'76J=-==;>]TUV%W.=:URS*[$U4I?JQTVUT#UAR/98K*]]M='AWJU
ME0@G:W=7?O']]]%Q-R=@X(#[9[A=B2'NE7;F,KVXL%4)3B^59%O$*&\?S3JY
M@;EQ_M/GD/_$D-*BCP@`VJ'3!9U43)=NNFG%'B4[QQO&5A7FQJJ[492J7P6[
M6-JDZ[O=Q.,%0!*GDDP<ZL#_EAO-?*)]GO%X<86C-MLD42E>VK11,\@D8!0P
M]-&CG+WS897_F[Y1U5=I4+O=JIF63DLM.2_[O.V+I)KX95;DXY@&M0$*L(!4
M.^"%&@<L5)UF,A>:"@-G9YZ&8*Z"%+R@4*!UEDWY[U8>W(O;/$0I5XVPA"(\
MX>-,:$`"[@UT^2/*V^;6M@OE;B6!<1F@6".C_JD)?PZQX$"`^`\ALJ\TJR$4
MIVSEEJ#4\'D;D1CA?H68WV&0458,HE>J\T"$!29U*YR@6)K8D(-1*R%K&4X`
M6!,:)#W*?8"3U`LUXL:Q22HT.OM?I\`W)(7$\7:C:A(/-Z.9.=[%;W+<C21.
MHA7>(`LE;?3120SSN@/!2F<9,U&2,JF:%O81AH3$UB3!>,4A"H1Z^].IT)?L
M1Q-.Z>N/=(*(&+LRREEB<8BUI*4M<XG+7=ZRE[KTI1@E!:\D%@P`;;#%)$=Y
ME]RYA'248YTM?"6FS\7R2]G+7I\4MAN+I`=`!:EF@!H%3K%PR'RQ<DN3%)<H
M(/+RE^[\W3:4R;U.-H0$&9D*EZH(S!$=I8:UN0O=9!C0K2'PBP4]*`L3:E`K
MA9*?A#LHB+QIRGQ2M%PAHA?:PAF4B-*%>A0]H$'0YU"KJ-,KIKQ:U*J&-=H!
M])#/V4@^/Y+/@0J4:ZBDJ4)AJM-<1DTR](1(!'\JU*%&#F$$LI))*"20AA)5
M=$'MXU.;*M6IO@@\KYLBU)A*5<-%__6%7=TJ6,/JQ)*^=#<@2:2'Q)J^K[(/
M59]4*US!ZJ=N\E,C2/CG6^/J(K+JE80H/&H`R502H*DL77U]CDLD8<XA?8F1
MLB'+(FW!4(0TDZ3S1&`WO:8X;=3F6"(1D2')Q,#"Q)22)7#28DTE$Y&:TBCM
M?&TMC01'].3UL%>92OW^I]O_?9!?4-%J4[&D*C3][V*63(A(GY:]I&7'3-*9
M2&.L\X][_N2&&<Q+Z>A:NJ01);12\J!2C"M>^05'.K6U%W!M>Q?N+/5A,7FO
M>N`KW_6HZ;R0:^2=YHNB\$*,D['IB!Y_]BE[UO.B_K7,=H+2)]W5<RAL;;";
MM$&GTQ)VC_^XRNA4[:M>8V721&>"3[PV/+H/;@:=*WHP.6G3H`G;3#H+IHX!
M@8+B\.CNJT^]DMZJ^C`Y=9A)\A(QD!LH1R$AQ\.J9<^,XSA";GI)P'_L%4R0
M8Y-P+C*4^-5(B+0+J/T@KSL1J6X7>>?3`_?%-@Y>']3ZM)53N@2ZMV'=@>1E
M235>$HU'?'&0\^R?]%S,6RI2XW#(Z)31D#G#C4I"$MJ`:#<HN@V*7C2B'9WH
M1#_:T6V(1*23X(8K&?@HD$GS)=-T+A%E"*G.FL]H@4)@WAW&,HN9[KJ*I+F"
ME*#0PSJ(C)8GR/?HN=?!\Q#,3JQ*U8(&@&'5C38H76DW2`+1S=;_=!(P?6E*
M0UK3C;:TLDG@Z$C<TVS&<F:`AHD00F\$,%!3<`U%9.")'+.Q-OPR%K.4&.V,
MRU4M"I.!;,$D_NT6C_&9L*\#OC2@[OK#NMWU)N/JO4DGV@V)+H&D(W[M94_Z
MT9%0-*,9S7!+:QS129"$[=+6G4:6Y6'?>L@W'9RL<]>U4>`FTT,F1:PQ"^HQ
M3XJDA/@<'_VN\D3W<Y+`V7>EQF*)Z$8'4]&1GLKC;HOG,<D5CZ2I]*DC*NE5
M/_K5J6[UK6.]Z,B^B**;;>DV0-SBD\9THI_=!H=//-ID;X,D(%X"AC?;#7-_
MM-BI'0F/*&8WX/[(0OST)&&F\#9/K&RR_[BN]</4.H!3^2=?+^60(@LJ),(+
M,R2SKGG%;UXO-LL/Z.\,7G$YZIE=/_WBPQ31V;#^0ZYO+^P-W_KVNIN>Y4EZ
M(ZU$*6*9N6E9=GR`-F4HXI+8R:'U-O(]E/S$![#39J77LIHO?8U0F]J.EL2U
MJ_]HAWM<XAF/./?'SO!(9S_MRHXT$N!N6<$K!2+Z!@]?WQUSC?JU\`%$JV$1
MJU+%"<@B8_Z'>WS++934->V>T<R66>$>[IV+S5C,S_P,B_&*27B;[DU'[O5>
M!0J0`>Y-FWG(];3:XWQ@YK6*K<&.]S2:VY4?]F4?W$E<VKE@"EK?Q;7="BI;
M"R;:6ZB2#A+,0?]@&[;5(/BYX-H)(:.Q(!`VVA&^H!$*81*VX!*R8!$ZFK:M
MG?A<WZ*M7:3=7:0-"G@U'+;='=P]G*1%V\9I8:.QW;-96\39TZ/AH#%=6QHZ
MFC%%X<4E&J:I1O<9TQ2.W<1=FL0IV@RF8!C^8)!(84Y$'*4A@;+A!+=5G-RI
MW;\$6`]67/F57R".81)^'`QFX@K"'<2Y@;1I7_=5VME5'!DZFL.%XAA>HL5M
MHBNJ(`Q>7/KY(/:1'RF>W\:-8:7IHBUFVF714_7EG1MH7-[58"@:XZ05X<=-
M6@W6W<<1(S.:G:+QR-/5!(U<3(SXRT$0HZ058S=^8]B!HR:&8]@E8S?_FF,Y
M8MPYJF,ZJN$RLN,[NB/V:=P0FJ+XT9TI\I>9Y(2?O6&CE4`:TET?+F,I#B$D
M^J`7=M^DG=9[L!VEN<&3/)HQ)>,[AJ.S16,[=EP=UN,T.EN+3>+$B880(AJF
MD4PN<J0\8F0\2@(TAEU+/F,YZITC8N$XEAU)KN/Y(>09DN,X]F0SBN-/\F0S
M1IK8L9VEE8!#'B4*'F52.AI24B+9)>7V!!8P]J2DD8#836'RQ-W;*1I6BJ%7
MBIU-8J7<7:58FB58>N53@->H2"!^/-V@A659AB58;F6B:>57=J5=ZF5>CN59
MTB5?_N5>^F5=]J6D`63%,1IB=F4;8&7ZE9U:_U8,<B@('CJE)*1?MBF67@+D
M8QZE8"[F)SI;]KE!%:[(I#W)(HH=V5UF8!8F5T*F83(:5FJ;M@&`V(6,)B)/
M"433LT43*>I(`_KC:LYE8PJF80(F8;9F8WIF6A[G:CX<M,5F$H"FI1WG8&)A
M7N)E5J+E<B(G%;ZCMIU=>**@8DEE)(RG>"YEM(TG]E'5"2ZE469:^*%@?'I<
M?6(<^=DC*5;BQT%<C8A>G#C9`X[G?F::*8[?QGE<@BHD+_*G@XKB@S8HA!JH
M@19H@L8=1!Z'/MJ/C82?@NXB14HH@CIH.3X;\B":@)G*$'Y/+=(D*=XG5%)D
M@I*=]5&:;<Z,H`1)'=E*&R+.HR8&&V=T'"+>(@K.:(4N:)&^Z)$2*;09J9,J
M:8)ZZ(%"*97*YY$B&L0E9*85J3TRZ/BIYY:^(%5%DQK28WXF:9C6*(BBZ92"
MJ0M*`@Y%8&M\Y(3E8IMF*8@ZI)J>J9TFJ9O^:9L&JI\*:I_V*2#B$&?(J9X.
MZ9+RZ9H:*A\FSWH:6:]8&PY::BCNJ:9:**,RW##>Y??@)J9!Y#+^9-IA9E0Z
M6[/U"I,^JJLZ*JQNZI_B::QVJJW.JI_2*J7IJE,.:J0>:-Q!&Q)68<4%:U(:
MJ[`B*Z*E_Q4PHF)%:J%^IBFGABDO2BE^-FG;91RU=JDEUBBV"NNTVJ.'6NNW
MRFB5FJN51NF1<I^'/JBZ?BM'NFBT+B.,RFB[KFNC1BF>(D_$S6FT].!$,JJ(
M0NF]JFN#;E_T?)]LDF:DF:E.4B)DXJO!CJLHPBB,\B>YMFK%3NB32FNZ4NRW
M9JQZLJ#UO5W)XNFUH>RN]B$L"=5TWN"/?NDM5A_WT>PH4B@OXFSW*0'&FF+>
MX>?//EPMVF#'U>P8&NW,'NW--NGX&:U]*F2U-2W4,FT;5NW4KN+2MF''82JT
M.>3/?N--YB<9BFW5)JW9UJ%M=BV/>$MY_2@BRFS4YJS-BNU\(O]A8XJ+MZR=
M(O;J958A8\9MTE[M]F7MTB(MX!XNW%*MV2*NU>KL%=(MB&I?Y"IMPV)AL]GD
ME'ILYFXNE[8!%='3"2XC$L3GLWEHZ6;:Z3)CM<4D*5XNCRYC"=3A%N:H<R%/
M[<+,J%C:LT$BVIENU'[<WJ+ND;HNM1'O.<9N\4[GZQIO.2)O-R+!8EXDTQ)D
MZR;!Z`)BJ-(N^`"I@@8K)*9N\U;OA38L#HK=Q0'GD)0N%FXM[/KNA2JB^U8O
MK=Y@S43"A+6CI@7L5ZHNL,(O>0XO`"<HVI'B``OO]$)B*8[OMUYN&\*N:E+O
M#\Z=Z4)KV%%P?RKP80[PX#)IQN8KISK_6@FRSZE&G`5K;*(%;Z6AL`=OZ=T%
MKWV&:OWPRAW)L%OV(#>>\).J\,"J,`[_8P]#9QN@<`L[X@_3:!`3L87:[[Q>
MZWYB7$U0#*_PFP>QIL6%)Q`C*19G++\*HQZ-(;^.[0S>X`YS[L;Q\!''I-I-
M3(LN!!_V*O(X7`='FQEB;I*:L1EK;ATO,1:;\!E3(@OKZP\/</`*<@+W,2%;
M;>=.[N3.)_EJWWPV&U5ICQ#"H`_N8B52,B9?,HF274V4UYQ^\KL(2MM5<B_J
M8B9+[BC_84ZJ<B6GLBOCHB5/*"E38L%]<G'$A[2RLBYK<O4%K,G:L"B^885^
M<"J7<BR;\B@/_^U2"C.E<086+K,QDZTN1W-.QNA2"BPV2S,O(_,J:S,JPW+;
ME>R:FK(LLZ`B4_,LI_,R8HU0B4W]M0T\(\LM7*+'S:--#B+FJF84(D0>]5@9
MT0FS09H17Z1>QF,X"B,)A%_6G!NR#$@*,31$/W3A%4O=,`TK[5JGR$CC_017
M?(SK-(O@7%D\GQ!%DZ`[6PA#U\5)R\U*2XUA6&H];Q^TOB;=S>5%1F!;VJX$
M?O)"#&T:QB%1DA_[!G0YX@W>M(2&J1?++37P44UIW`+8.F&G;MP*.ARTO)<E
M^5B[R$NF;:207JU0X]WY!99GN=3GTA]:,RM5<I+,O01JE44_GQP_G?\8D<R+
MAH2P6@\%4Z]<4_,>EJWU5SA?6?MU6COJVU:SV#*<B00;_["E;WVR9F)QB[8R
M*@)B!J9U`:57T(F<"3&93X1<HT0*HE@?]_ULP?ZC3-A/KO6+?J#(']*Q'R>F
M@>X=@*`22-<43H'-3;U>A[0>55(C?978!V&8CT!9^/C%.+W/VE`@=GTNAU1T
MBIG0US`WODW%:A:T_6)W;$]C5J\EH)&1N)C?S"J;F=+K5,;0<Y-94L<5YCS2
M7U/=;160+<0=/9.=*I;L3F\+<"8J5^/G/P;M<_XC;3MT`+4W!B&*@<?6EC16
M@I<53[D$YMP>1/0;KOG<5K?&L>A1R&`V4@#_18/3G]513H./>.V!!8F#280?
MN+=][G_[,6(JZ'3F7>7Q8YJ`#]LZ11L[+\E*0DESN(B7^&;7SC^PI(&VZ.FN
M77@A$;L(AZ&`QC:&\=AB)%ZG3T'`UZ`P#YK`TS^DEES?CC7)QJ2TA&<O5=^)
MG/SY-;)0%V$+"%K1WM<1-E+_3F`0)9PJ\Z5A+J:UY<[H"/V$'D]`6][QJ#/>
MR'I7SFY0B(/G67GD9VFW,9&,"GPI"*4^,QPSJ.<N4J%'&/Q8DELXN:9\2D,;
M1(4%)WEX>73T16$<8-I(!DJ9-:J\6.G`D74QGV4,C\N!1$&@%=,@.D&$R%*E
M"RUF*3U*)(F5B!T9_\JTE-<Q86+Q9CJHD(5-D`1'!=P(_4-Q2IO8Q=V2,PF(
MH<62',?^1MPUB156;!GQH0GR](>&J]9!K+<Z+1@WK0NXR75CE`4WD0MZ2-UW
M?-FO;,9T;0_Z](1*4!:J38=)`!B`1-=+\!_?#83>;`/V;62%[J:PW0^U<`MJ
M*83:J1_OE(9FPPYC`?:&.9^KT*>-J@?;.E<>>3((?[8(.;OC5`33835-[$>0
ML$1Z%!/XG-=%`1B>P=BY>%G0(UYU%#UU_#Q(=$@)-([0BP=0T9A'F(1A*<[!
M`U68QY^U'R6/WHFQ8U*%UZY.BT_%A1/+_51$L3NO!7E=906EP:F4K8<.G?\[
MB<'\WSR)%'M0`.(;;03;'I5`F?=&SLN\7CR]R0G&A,,;XM^)X/N(4U1&8D37
M5B2'7U0&SJ6$J40]WVV/0`S:02"!FU=^VFB#)'"E&XB$DX1R->I6'I'>ZAQ2
M>O7.$WW)7FO4U(3PBIL<R*C]VL/P1\9+4V#U\#6/B!D&DIF)B1T7VC2,+=#)
M:,!Y[#R]GR1-T1,+P@?]9TE,PK=*TFRTPT_&J_E$1TB3/]`5O*,<X3.&+26]
M0SS\EH\@9GNN5M_/A:/3RN,$<4>%QY_UVL^'I-0^0/P3:.O?-H$'$1)$*-"@
M0&T+#S9L6!#B/P`7,6;4"(`$QXH?0884.9)D29/_)TUJDSBP8TN.)%H&<-FR
MX\6:)0"@U+F39T^?_@[:Y(@3)TR70CM&=#B1(D*##Q="]6FRA%2&.0_"Q%J0
MX\6#218">%J3Q+\D5@%8Y1KT(MB<6[<!P&EQ(DZX=`7FA`K58,ZX%3%.?$MQ
M&].%*Q'6E(NTJU;'%XEVG#NUJ42L_@PS9/H0R3^%%CV#/JPVXM-_?`^+)=SP
MH5K2&S?>Q$B9=FW;MC/G7;PX``"9&(MBA$G49N[;QY'SG/@PKF_ASGM'7ERV
M:4&FA4.23GZZ.LB)B+\[9:V48?F0B*6.=\K=?%.][0\[7%\0]7SMY?=&E#RS
MM\S>SITC2R/<Y-LJ+(ZL('K(0/D,(J&YB_H2B`1;%`LJ+_E$HXZ[M!Q,K#NV
M8--(_T/CMBO1Q.2$*^JQX&3"J;>C`#CKQ!EI'.DE$NPR"L:N%JS1QQ]/5(A$
M($'$T;>9;C1J,>)LVLXO]A;$RJ!;\DK*O+*D&NR?"1'"RDNE<J+0H+\N+!`D
M'F,C4LTU4=(F(\6F:\PFETJHD,T[CQ-Q-Z3JQ"B)(?$,5-#Z!(WH33D[^J\_
M1(>2"\5_@,H*M05S\RM*T:0L\\L"%=Q2M3(%NN7),;=122[%-/Q0U4)91:ZO
M/B&#,4>,_HNU!$!;S;7+4X5:$L!8>]156#;O8Q/-BQ:EZ24TX0R6,K@,*L&6
MI]P,BSQ;]'KRPB\%$^A6T2S\JZ%-L\)P5PVIK&S58=F=*O\C6#GZ3;)3E9S7
MRG;Q+:@E)F<:CL=\`0X8Q?WJ5-)%C9CL\][;G&T)._D4%*I+:\G5=*",,AR/
MA(@Y(C,SYN`C3^"13V+VMZ[LHM6YX+P*F60\]3SV1;EP^@S/\#XJ]>6=2[(E
MY=A>JI-E/4M8=^3E).F,YZ5U[8O7F$CX3T=&75(+5Z:=+!BR)0U>5MM<K\9Z
M:>R$(_C8YW0D+E67`?Z.(,3$CMO'B;`%#FUD`WQ.H[#E=C4)NV&L=<#SGGKX
M1)U%[KOOK07G>MF#:ZT)9Y*_TP9DQ3&?VZ(X^5N1MU-_LXZ]S&>\>UG'!`3K
M(P"`VJK8VJ"B$``D;":=Y[YHFEK_L61/GZD[O@6=*-+E;"_^-LPD),N_J.%$
MLGE'"34>.8W\`S"ZK9MLC2US19=*)83R0YP^I5IKB*"BMS0<>.G99(KZO'7<
M<>793EN?_?MMQPXJ.7OU-^5^A9,X_-5F*(^)7_\\(J4(68HBU3+5YD8GI;3\
M`WUEJI:^FM*A#L5N@/C:G]I0]JLCM:A>B^G@"5%XINOQYSG$.9C0G)7"G1CD
M;_%"D]1Z-9GW`(`@JMF*MB+T-KQ8:&/7H<XV>F@A<(5&ANR:$__VQ3^\\4A#
MKVOB%9>F%MG-ZW](*MM&L$B;-Y$P7E';C97^\JE-D0E*YC$0&QV2A!Y^9X<2
M&E,8P>80_\6X:$?!0=W)O&(_/`X28*@2SJ)RI)4Y*9)MA`1)Q.3G1;N@[R_[
M`Q5H%KB>'^;E85LI6JFPDD0*@L^1K,(>U%K4E45%+I6E=*78FC,K%=%I969<
M%`]?63)?P:1Z^^G5?)IR'\.4RBIPJPQ?PC/,7-X)=U)\7OQX>11@+I.:>73(
M(<]FR$7>R'75A`@->X7#>34*0@4!2NU`8C-T7FYT[-'>?51B16_>9CQ_6YZ\
M3M<X''8%G?/TYYIP=C?FJ4U9[\O4/R.X'\_UJBN0(F4CV5F=E2!O/A][J"`1
MVJ:P"(AYO(MF/HECM(R.M$8_8Y)05HDCE<;()O*D)FQ.YAA\?@Z*I&'46]GF
M)35%"2B&-?_UZ8GTIKLD`6TXC:2FT[2B,%7*R2[3_"G[QE1#Z>C)@%[DTE.Q
M.J/AP&M^;Z)EK4A*-Q'R)B8`@HD`LYJYS&Q$:$;:7:)R2+^TSO4X/HLKG8S4
M'P$%QZ6O1*K6CI*[E9D&HW0E66,4^:ZGO61YRS+L8PDH&R]NDWG'*BP6'Y+8
MF?GJ;I`=X%!^ME*\R@M.D[FL9^D*J[(N#ZY'"J%D^GG477&395%,F4A1&[?F
MC--N>[+A;_Z76^&6S$A/K`EI>53;GN:2HG:-7)R>VY&^#I=GL1J.6ZFH33!2
ME[L?<9--0LN_%\VTH355D%$.MK42VN6TW6T71B?G7O<VTTAU:JS_BI+K2T>)
MSJBE%%$)\<8R^0Z8P-4\XTV/"T6B3":CXRIC1H#[F":AM<`5MK#T!'-&6C)O
MG#^CWW0=*0E92M$F)_O3A5&<8O;Q97>NW1$`R7)5$*>0L%6*4U%D@EU><4_%
M/?8QU@JS6-@T:XK`<6HI26,_P_UX)(1R8%"TQYWP?.\@Z6E@>=A(92R/RSP7
MM%KB'J(0'I;O-`ZB*<@L1YZ'V4P;91$BDRG7E$@E9\8R%%])E`GGDE!9->(2
M'<8L\ETOM<RA`=R<1W3CYBJ#2\M]/K1`_+&Q?W$93!1)2USNB)<>>H6#H0E`
MG?4\*(=NI[T8GDJI+4PBL2!A)7"IEFH>_Z@0-Z^-.EM9VUT<]!JN2$5,4GKR
MQJK3Y@U=,S1J7#18UIKI4`=,V?3TYVFUO&SOK(Y[-=F6H;JE&P96RVG8"\N2
M"X*^N^0D59M<R#BM5$>N=*6&'\FUCQLB"0SM16?C"?/H.AWE-R_%>U&I7W8(
M)U+CN(8A\1P(@Q:=;U17Q-[!7(I#.@UFXJG',_%FBI#N2/'0$-;@]Q9@J19>
MTS<.\=H-*3<GR[/&KVVEA^GIR_Y,`QI';U(BGW3CA;!T&I:#QFH'M7"_65?I
M_%A95?(F546HK)+-3),U1S0(MA+7;,-\*DMP#/:B(7;')'XOY`S/"U@^0Z&#
MU"Y"5;[.[QY*=#OU:$O8GE&T>9:<'_9$J.OSW(;2P.<2NF`)E.7I4-W^=D&Y
MSJ9V&T%VW@D=2M'T94QWF=@2Q[4PU<C[:_\_-E"8P$2_M\RF08(.$^Z2DEF+
M6-O!`&C#9RP9G_<\6D*C-ZWC_:*-/V49CDW2GV5P2QFUO"7*;VS,)?V,L5=;
MFR\8D3=$.F.SJ`8F+>7]L(.Q-#M"$SCFQAQ2Y=@6-HL^%.EW)]Z<M0.WLT\,
MU,/=1H<Z]FWW+!%3[F-_Q=(8P7;J9>H7FHB9'[_ZU(/+UEP63/16ST2R)%Q$
M0QLJ*)-T3H_R0TNNXI*VY,V@K_Y*Y>2ZI.R"XOPJ3)DH[LO2Z9&D+#XD8LYX
M3,W&#C]&8LHBJJ+&I\<$0W7*;BS2[?T<$/W*J6(P"3*X8LD,9"_$C8Z6R"\Z
MQ#W`J,UT9H?01([_(*+M:N0%MV0M0D-RFK#YKJK;&D0&>8[2ZH,@IB4O1"\'
MV>(FT*]YZ*+\I*T,,0?HU.6''B;^4LX!WT)G.F7Q<,Y[`M!-UFI#QH/<VI#]
MU@;EQ$(L_.\"`<.83.2@_I`ARN+^/(;GJ@@T@K#L7,WG@H5<3DXJ:HTBD@@0
MS7`3L:@NP*_,OG`P.D1GJ./6=*[=ON5;H(R"6D+VU,=/;._@6$\.U6V)T$)!
M[JWQIF_UD##W>L(P6`W?+J\MHA#+O(2]'.36:NXBUBFS`*V9#'#^&$SIBD/;
M./$:3PA07H=XHFXE#*/?V@-X,F/\O-$"FPW/D$Z):B3\U,7A2"DWO#$),;^)
M>PAQ'(\LR;`Q'_51]V1Q.XZO[O8Q(`4RK0B10'QQ(!$R(5$+($6"#!7R(1$J
$(```.P==
`
end


begin 600 Image54.gif
M1TE&.#EAT`)"`?<``````*"@H/W]_?___P``````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M`````````````````````"'Y!`$```(`+`````#0`D(!0`C_``4('$BPH,&#
M"!,J7,BPH<.'$"-*G$BQHL6+&#-JW,BQH\>/($.*'$FRI,F3*%.J7,GR)("7
M,&/*!#"@ILV;.'/JW*ESID^8+8,*'4JTJ-&C2),J78KQYTN>4*-*G4JUZ@"G
M`)AJW4H1JU>N8,.*'4O6X<^=-*VJ7<NV;=2?9>.JG.GVYDRY>//JW6O1Y]JT
M=0,+'FS5)]_##V42YBD3<=C%D`<[QDMW,.#(F#-;;CRYLV+--3EW9@JZ]-22
MIE-++E@9L]?+JF.7OCOZ<.NZMV7KKKJ2[67`L$/;_(TS^%7APY'K1+V[N52!
MN9U7!9X<:O"8RJD/AYF]^O'O5[%O_XY94/KNO*\_FU_/6R5[T"6U5Z?)'3G]
MI_;M*C].O+A_\>))%=U[!!;8UET&ED:64P+H)U]X^/%''X1I!?B??Q)*^%M]
M]UF(66VU>6=9@CUY2.*)*`IH(FP!;HBAB>`)!V!];&W%H$$I]I0BB*-AF.-X
M$?Z(5DX5>J>>D)$=B1N*1]W($))(\BCE0%EQY==?`T*II6M96M<EE$$Y.>68
M9#:9E)*0H;GEFFJI"61Z<,8IYYQTUOE2F7CFJ5251+FYF)_3L?DCH(*)MA"?
M>B:JZ*)%(1HFH5C"Z)9Q@A;X9:1`1>0HHYQVZBE(FZ)DIYRQ45II@J,:VA1%
MI[9*V*>PFA<4:D=8&?050I=F9JJK*-(FJI@$\2IL6_^Q%AM?4\!"EVQBD)[X
M8(PBVE5D=^!=1V1HTU:;I*I:&2FB<=3)E^UWV5H[I+C[[6HNNL]ZJY]5QL8[
MTJRL-=N32+D.JZ^TY)6U[[_/R2LPJ%3>N*N`LMH+L):^#NSPPQ"[M.QK:!U<
M:KX+6]IPQ!QW[+%$MQ)4Z[]G96P>7!^GK/+*(B<;,H[1LLC=C`\"]Y3-$9J;
M',T;8FSR6X:Q+/30$6-UH$,_GU:P4_N^3/334!?KM``66Y?T8EVEJG6<47?-
MZ-6:+1TTKB[7"IV*/@YY<HNZ>>WVV[T51Z-N55<<Y*0^!:#WWGSW[7<`*"L;
M^$'T#A2SD>5NEUVY18JK<WYXBV<&]^24B_3NN_U=^&W:B<<([K690TOA2W^7
M;OKI>F\\4:A@PU?YZ[!CU+J*,*%N^^U^<]M7@[-_&/OOP#_4NY<QX6X\ZJIS
M5'CPS#?OO%Q8'7_[V"X];_WUV)_)X-;)]YG]]^"'C^S@GBXO_OGH_VYVQ^:G
M[_[[_QZOWW7[2@TO&/SXUR9__G'OY__E;TG;I'2D(/X9<$%,.]7U`$@NS*7K
M6HI[(+4@^"('1HLJ!\R@]DK&0*H$:5P!O)_U[!<8#9IP+LOB'0-#)RT+0NZ%
MU:K;`$Y(PQIB#V`VS*$.?X?#'?KPAT`,HL2XMS4A&O&(*Z/8J5Z#Q"8Z$3$)
ME.'/4AC$!`*->D_,HD(X:#42%@:+&E38%S,%/).![TH'\F)@P)@^,?JF7[$S
MH_-\YD$U;@N.Z'.C!_$8Q[]L;CY_O""YM!,ZYMAQAF*[6XJ>];G_E4HSW?N>
MT8B'QD/>I'\]Q)<E1R?%3>;(5ZV#'A<]J19,_HLYC>S/N$"FI<H)2;"+F;.8
M'DD)I5D**BQBNIPKJ:5*7<I-/:MT(7\ZZ+O\$3-CMGQ/)RVII-!5:)?#?"5C
M7KG,FNR)?#"C_V6-^$?!-7%/FTO4FK[ZA,V%@'.;-:3?2NAXQ;F=4YG)_*4[
MM;3.<FJ1:D3,IS[WR<]^CI)+_@RH0`>:JMGPD7#W3.A0U$F2>+:SF@1\)Z8@
M2KL[)4:A&&4)0QO*3GY)JE`2Q9LMV0B1C08KI#G*:$M,>I']"6YC#DTC2@%J
M45E)9*8[4FF8:.52EV[QHT+"V3SY=<PV=;,YNJL?!5D$NF_EK($<4J3H>!F>
MG6VG9T3M#KK.==2`Z72G(`,JMNRYNIBF9JN.G"!:.]=!MK9+I&1\S,(H*B#7
MK.6KWB/</PLS+[/BE#"1Y,I?3X37A?94JF]!H5\'^]":%O:QGBF;%84%U5'&
M$BFID,UL7'RZORE6DK%DU:QHP3))2M)OA3Z")B!7J]:T"O.MG!2KR7PZVMJ2
MUF!+PNE/E6@@.-F6<I:UR48X.]+!_JI.OS7@7P=J*R>I\ZJ2`B%KI[K+1OY2
M@((487*WVQ"/=C.8+-06:X-YV;LYTVZUDQ[NTJ.IA!@4L=BJ%'?GMVM.3\I$
MO?C=&V;;:[C@"I>^`,[F(>^;WP+OMR(L#;""-4O@`AOOP,I;L(0!'#T'`XZD
MHIJPAK]*V^9VV$8;#C$0/_RI!(OXQ.JC(OOT8ED4&Y'$43,Q2UKLXA..];-1
M&N%T/0?#=4T0JM'$;@.G6\T:\Z^TKEH@8XTL/OD=-;Q3E6`O`^E5Y]&8R=8+
MK$`RB>4N9Y3+7@ZSF+',W#&;F;[BG"B=SLSF)L+ID^QMLYSSYQ6`32VS*O^>
M,_XF:[\\OYB(>CX?G^EJY]#:$,?3T7*@*8?HHFX2PQFLK&EEO&B.[55M,S6T
M^Q9;7L=6.L;))#0)%1T^3I<HKJ^3X_4:71C_WAC5>93M&@\*W(QE6=(1=75L
MWV=JCU(Z9:H.'JZGJ6MY>KK4IB:UUWPC9#]BC22;K)>LV2-4J3)57\INWJ4;
M"U\2FK*.T*Q,S81,WML8THZ)%/4C_4>I<,_GF:VMJGB'/&_<0!A[WWSGMZ>R
M+AKU[#IT(2^%<')N->)SVNM!:Y39'=]Y$]*MX\WN&_$82LJP6K?NL75#?2U(
M=76Q36RS-\*++1O:5!R!:+QV'1>.:8D[NX`I"7:=2&*H\B%/^>94OFJSJ]9K
MDO^)/">W4N`LV&XIM_S'`J=WD%G^JHPO#)70*K?18TC5AJ/6X0<;ML_/"LPN
MJ7MT+D<G4Y(%P*<V?,I4[WB/">D@1S?=F*X%>5!'CJJNTK*997\AVSMNWJ.W
MYYH8WM+7BXF_9I.,[G5_$<1';:'S.KS>CZ.WS8B%%#]O7;F&9QBIE@C!M8)M
M\UC**3DA7?\>GV,^\\[BLZ][OG5^J_[5K&_;HTB/D,NGTT9:OWCKW]3MB@X5
M3/6D_:>U\FM0(=[UO]^]R'L_<8(Z__G"=R+TIT_]ZM<)--;/OO;U"<GM>U]K
MP_>,46+_ZC4J'^S8I[6MPE_%1AU_C,ROZ^[)?V^JL7_$[G]_8_\T_UYG&SKW
MYT/%IQ&ZMT?^IWP%Z'O'9A86<7ZR<68#V%)O-FGZMW+GAV2=]G];Q"H.J!IM
M%H$E)3_7MQN#)U%K1C`WU8&I(6<@N%M@=&?D1VPJF($I85(S:!ISUH+IQBUW
M)FWQ1U,).%CU)Q0157-6QW2Y)H,)=X2P-6ZEE(/#=5B:YF')-RB*A_-D<1<H
MO36$1+A4:L)*!(1V%V0JU45D.R8Z>P=;CM1)@29C<79P4W@H,6A7/[9S[B)Y
M7>56%9B!.F@Y.G>%5Q=?Y09O`/<9;&=V?SA6655O-(<=-<>&;1B"(Z>!#:%U
M-XA\L"98EQ@VE58X08@6^#*'#DB)1;&)G-B)/OB)]])7>VB*L)<7KDAX_XOF
M-!#5APEAB2I(B@$88%,3A+9H%J*(4[JXB_,EA=NV2+AH6=%'C+QHC*J(C,GX
M3G'(C&CFC*(Q5\]H@LM(C=QEC;H3B'YG5$H(76IXC.`TC=RX7?I47[!'AHS(
M8_!80>5EAZM7A7V&CNF87!B86,(#B%2W59.7=@$9>7K(;:TX=WZ6CQ2V/3*%
M<3L8C1?3@PHY82]#5R7X,\`X)Z:!7!,)(J[&4Y)5B\85A=;7D9SRD>/S@OOX
M<7]EDC6DC*,"ARJ90ASTB%&%'XUW,]`5=3>6A!WR3#]X5RYI8R%58;;#1*G(
M@TC#<.X22]0$2$X90E$9&4-)E/]SD?(GCFW7?$ND8V%\,R>5R(X;&4)K4I4F
M1)8#=X0]F7=0V6G@YI9\Z)6G`V.X4GNZ9I8:!)<Z)U1["7M]"8\SPQC^EC,Z
M*2,-)I=SR86W6'HHB9?0IS=@Q8.8#Z9^J[-E=^F8CVE'ARF9R$.978&9H/DD
MCQ:9G'F4GKD[H9F:QK*9I9D[IYD1OZB:LCD6,]&:KOF:$3:;NJDH/\&9PPB;
MNQF<4B(GQT.7U2.<R*D7W@B6():<SGE;^*@_SSF=XY>0B1*;U)F=5/B;>8*=
MVNF<QBDOW@EM2_:=0A.>18,75V:>[&.=2107Z\F>`X.>3S.>&Q&?\MDI]6B/
M":)DTA1R::DYGL,A=ZAV&N)=8I>?G;*2.?8\+52'/;94[SA,JK6&4U<7"IG*
M*0RZ)?[9DAG:G:^G0#HVDA\ZG#>2A[_GCG/#,](4%1WJD"4Z&2Z%A0:::U*7
M<U#QHC,5HS(*:6#&HT!J%#\:I$0:%$-:I$@:<Z>4I$S:I%G#G$X:I3Q2DE):
MI;CW?>YII5I*DJ`'A+ZUI6#*I1N*5&\8IF;*$.DA>$AYIFPJDQ"Y-EG:IB5:
M9[-%G]+WI7(Z)6.*3'$Z8JG_DJ>1Y1=8R29]FDXA&EN9"*@H=R2#6BG1&4;/
M^*B**A1[U:BM(JGPDXW&MH"3ND%^8JFN@JFQ=I"OV*F`!RF@*BRB*DG)IIBF
MRHKVDJK#LJJW1JJ;^JJ&14>RBFW;>$:V2H.XNE*SM*N'AYO(QI^SEJAP(W.K
MAFO$VC3<"3PQZ*I"PZQSE'NNUJO7BJS+9Y^P8JW,@XO/BHW&6JM!>2#E^C3@
MFF*V.JY\FJ[:]JO&%CSK"CL0Z:[OJJS9\Z:ERD,:%ZX'V'K1.CEO.K`?4Z\$
MVW/XZEGP*JV+9;`'^W(25S?6]80C$6U)&8O)JJ_-ZE":^J\HP6Q.A8@!:J`=
M@J#_$G6QEI2*M>2/!4HWW<>Q'>LSA__J1?LF?X^(=.1VH3%2<#;[4N>ZA$S9
M5(MX'VKI;_+VAX/Y=1#[-OMT3C<+-"^KL\1TH\M!GH<$M`O;D%_BCH_7>7>X
M>(5"K<)64!(5M2RI=&S%DV!KABGKAUG+KW0(>6F[=U^+AU6'A%R)*$&W6;P%
MHR>QKMRWLL$XMBSDM2TDME6UMH.9B(!%<6!C<1_K26B;9!L'F=RJL=W:7U?C
MMY-+2I7;*O%QA1>Y3-=&:(4;BYS1M]!Y&Q\DLF\)22OH=$?:$4KWH#:7ABZ4
M=&GEA`^EN24'=)$K%B=J551K=KZ[E>\606J;M+(:NB)ZL84X=3C7ECB:53+#
M?'(+O*>6N9;_V[K7N%K9:[5KZ4MN&Z%01I6TNZ0JJUHW6KUZUZ)LF[SHM;6N
MF+KF`;Y\Y$M.B':'FUK_^4#I"QG0*U]8^Y/]>Z&!"9B%:6Q*V\#@(J_<ZWMV
MAWH6"$.K,7;E!(X+W$I`&8]$YR`?1*".*XOO$W9:"8U!.\$;^SC^RY/A573R
MBT$:3%*")WJ%A\*\ZKV))X0>XGCN%J&""4+OMQ0J9GMPEX70RL.]!;;FM<*S
M^L-LR2XX>KK7JS259VA(G,,ZS"OXFR9M>[?#PZCR%$CC6[\/7(9_EW^DML7P
M8\'>]+>$&L9J>#7FJ(4D4IW+Z,8G#,<JK)&4I1B,"\5Q3"?L2ZGH$<C'[I.$
M2))/+/RX6S,LN4J)_XJ</HP,9S3[N2Q\Q^UHOV^G48]:R0;DK0CFK-O;@1^K
MR>LAK-HZI\0GKJ<LL):HRLX1?$UKGJ0LB4R\?X\\:6GRQ=HU1+?,GKE<B0H+
MS)GF?UBZS';R6,S\S-"<;[H2S=2\S#%;S=C,J1B5S=S<S;L,?]X<SOWT7MI,
M)4$JSN@,S1N9SNQ,1.3</L4<K..GQX2<:-_<Q3Y\SY@(S_*\*/&L5_J\SR#5
M?P']4`S8SWKRS]MIJ>)*T`5=O^JDT`B]4FS,T*3JR87VT-W+4!(]T>M$SX/*
M:1A=K/4\Q.5<EQY=)AW=,NT:L+)\T62[TBE]G*.WA[1<P;KVN:ULSAS8RR()
MZF4RK;5TQ\D#=(&J2*LFYM.49V8=35!GE8OY-%P]K=3P_P*!K`P7:;9N4-W,
M'L%25"V45EV#$P/()*BZA0HR$_'5%LO4Q\5&SHA4FDNV"):":DW#;#:>RYFH
MP#S2O2/7<PT1=;W&86U\V"210.L<?/UY#;MOU5:Q>JO$]2@=[DN.#8S!=GW7
M']&+UAG+CSS,'U&$V*7&K9:50BO:,@S"EXW98JHZ](G,`\VV$@K9I$T@?AVR
ML3V&\6L?NGN5K5%=K`20$2=>C$/&.+T3>C:`Q"6IKIU;L'U,1ANVUN;$V3O-
M,BNDMWW:X4;">C=/'M>4'*>(B4C%KE6AD`B%?3'6J[K<7.LFV.W=5TG'4]O"
M8Q&V58N[\`:8NHW3OBW$>&NW+IS2NRY;92SXI"FZIA*HT6-)M33J>>_H8Q`*
MR2>=%,B$?7,KV!\85MQ*JRR-X.\%CM=5H"UB;8*,="7-AV0QX13.?V!]W!G)
MQ-5=5A*LL9ZMLH$MX`,NAR,5BC%NBC-.XS6>HZA(-L.&G>KM7[5MI#_NHI^V
M*7O*CSK.X3?8XSZ;Y`2WY!M^%Q89'T6>S(M]%%0.Y%:^/EFNY3O^TB__/M.5
MTXM'T]8ECLI'CN9$H]G>^\^<#9-=#N=0D]RYLM)USN5GCN=NH^>]?=,0#N7Y
M?.>`?IXA2>ATT^>DM-.)KNB%W>0(:>C2^.:1WIZ+ON6%;NFC*>69+C5Y7249
MS>E1#.JA#BN";BAU:NKAA.FI_C"K?E!)0]1W!^FQKNDS:4\>7MS\EL*WNZF>
MOL2HGNL+NNG[Q<'*:[>21[X`_I^V/CMG;>R6QJ!3V.N.6+2OA:#J@I-ES(?#
MKGFX3NT00^D0TH]#RV.IM.WX+4",2X'A3B)V2N[Q4[.@N)3I#B$'JN]_J>\X
M$^SHQ^\+/%5"7>8)-^_TKNNIC.\_^Y`&KQH&#I[P@<Z01;VC"QWMB%VF_Q+O
MM,[%W"B%IG$"IQJ_\1P/+!;IH<PR*G#%D23_.IKM\2&5DEB:\(T)F^A-R(G=
MH"`I4"U_4L%%@#>/>#FO\STO%S5/X*Q=*Q3[\T4/BT;.-4EY4+38;I.=MC`K
M3+/;]$:_7#P?]4#!4(#XPN.U2DP5PY@VP!BJ]5N/4EY1.G)R\:AV6OD.(-_N
M3`/_;\3#;I:N]FM_3DZA7LBNU]TUM&(OQ+U$O_-[Q27$]_["EE<OL=)E@*P)
M^$%#8N;CCQV,DQ"\^:*MB!&\M)Z/SS;.^)H8=SE)F*BOW<U;LE6[M-U.FI()
M]6'I7K(;=D.?VJ1?^A\>QD<'Q,\^Q..]T5W9FG@1/_L'46RY/]\?QT@*E[.+
M:[YUI7*%F%ZVJ5_<R3J7F?Q@@;M8)\#,JS/>OMTEPNY)2X[5?YL1;OR<ZU_:
M+U>?/OSG_Y6(SM/KS_3MOQ7V-?GG;[!\@OP`(4#@0((%#1Y$F%#A0H8-'3Z$
M&%'B1(H5+5[$F%'C1H[_$0=\!!E2Y$B2)4V>1)E2Y4@`+5L&@!E3YDR:-6W2
M=-ER(P"!*WW^!!I4:-".18T>19I4Z5*F39T^53A4ZE2J*',"N)E5Z]:K'0%4
M!1M6K$^H9<V>19M6[5JV$\>^A7ORZE:Z=6-V]=I6[UZ^??W^!1RX;US"A0?,
MM9LX*]ZB/`4_AAQ9\F3*E9D:QCP6L6+.,QDWMAQ:]&C2I4VKS9P:[.;.G#\;
M=7Q:]FS:M6W?QLWP*M;6BG<SC9U;^'#BQ8T?5[J[M]W?38,CAQY=^G3JMY4O
MU]K\Z?/JW;U_!Q^^[&Z7V'&^=LI=_'KV[=V_+TB>MWGR:M7#QY]?_W[:\EDG
M2/:OK?OX([!``P^TSS\%%U.PKP$1A#!""2>4J$&!%,2P/L`>I+!##S\LT$*$
M,M0.,@Y!1#%%%:D3<;H35X0Q1AE-:[&Z%V?$,?]''?FJT;L;=P0R2"&1ZC&\
M'X=$,DDE=0L0OR.7A#)*(8M\[TDIK\0212J=S+)++V/<4C\K!U.M3,.^1-/%
M)B<<4R\SWXPK33F-"_/`-MF",T^QYN03MSHCO#,M/0>EJD]#9?N3S<H(952H
M0Q\5+5$/`RVK44O)@C33R"0%D41//_44H4M'14E34S=<\]2D0OJ*U=5:_0C6
MJ60M4U5;!8W5/U)32M+56'W]];!@AP7I*UB/=1598I<-MJ5BB:5UI5NGK53!
M757J]5EC6;VJ66"?%3;<P[H5=MMHQ?55UE9W<Y1:=Y>R]EILD?Q669'6_7;8
M;9DMMU^62,(7W'.!>K<=8-ATE5=:>L%-UR6&<P+X7FZ=?;@D\L)5MUB'VS7*
MN..+XDU8X2%#EM=CDR<"F>1Y1U:9U)-?;LA:A'V"F%^3*)8JVY8OA;GG@QK\
M-ZAH]U5I8((7WME2GY<60,2@&487ZGN5S1C=JE<6,FF>F7ZYQJ>AC=CB=,>&
MVNB1=-::4*Y-+O)KJ\66N&JYZ\64Y;357MO@5`MR>UR<+=[X[5QQIM5ALT7*
M.W'%V=(PH;MY73QRR0%[O-3)+\=\K<I/RKQSSY_:W*3/1R?=J-!+*CUUU2TZ
8G:357X>]H=;/CKUVVP>:'?';=\\R(``[
`
end


begin 600 Image73.gif
M1TE&.#=A/0,K`O<```````$``$Q,3)^?GZ:FIO___P``````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M`````````````````````"'Y!```````+``````]`RL"0`C_``L('$BPH,&#
M"!,J7,BPH<.'$"-*G$BQHL6+&#-JW,BQH\>/($.*'$FRI,F3*"$"6,D20,J7
M,&/*G$FSILV;.'/JW,FS9\R60%<*=%F`*%&#1H<B3*JT:5&"+H\B=2IU8%6?
M6+-JW<JUJTP``L*&O>J5(=F/0%.>+<L6I-"V<./*G4LW*UBQ>/.N[;HW9%6F
M10$+!FS5JF"J?>LJ7LRXL>/'D,U&?%M88>*1ER-K%GGV*&&J4)TJS;RYM&F.
M+4^KEO@W=,&_G@V#?CHT=F6IB4F?[*N[HNW5P(,+-]T;ZEO*@6L;3RZ[^7++
MJ9TCC4J=^?/K0H_CABU]N$JMOVF'S3_<%/=LV^9IB_;.OKW[F<7?RU\8M+[]
M^RRGSM_/O[]_K/']QQ]^!!88X'#1":C@@@QJ=&"#[1DHX8045FCAA1A6N"!R
M$';HX4$/?MA6AB26:.*)(?J%X%UYM2C`9?$A]QE]&TXDXX,<3K;=13F"R%V/
M%`&YE(A>H6CDD2D&E^1F,+[FVG2NI9>>>IXM.5>`'.876(+U*=><?5`:9U10
M7F[)95IE6I>FEH:Q>>-#5@Z(Y)SWH45GG)HE2.2>079)(Y]VQ77GH'ZJ-FA.
MA!K_":A/8,K5J&6+`KA4HG=&RAFEF&9*J*4[/0J7IR!R^IJF1XK*%:FHIJIJ
MG:;>!"I;KSI9UJHFPH3GGK3F>JM[$K;J:J&?`JN?F+I>Z-^NC!:K;*T.ECK=
MLM`BZZN.9&(6[833"GKMMK3^RBV2V1KZ+8%?A9O1N.BFBQ]JZF9H+F3MZKF?
MM+/&:^^])]9F;TF'OMN8O/YN1.^D^!9L\,'KOM=OP(H-#"C"$$>,,,.^51HD
M:U%Z5!R++HHE)'&\2BSRR-#VQ"K%-EJ,\9/J24<8>AE329[,HSI\Y6XDYZQS
MIGR>C#*U<_[LZ,Y$%^VSG<).>[2/Y%X5HTIL]AEU0S:;-0DN3>G.9_36)2H<
MJZE+7\SRE.2%-_9M,U=V6WDP4ZEVBD5+*A_7J7:DH8=ABYKWANUZAV++_Q'>
MJR2%'^X=J>&V]NUUHEAK/35&B%LT)8]8$U[XUXON*R?C\P*L-.:22^G<Y%'-
M5M[9+6]L.=Z@\Q0OWYNRU[K0\,V^>:^7^_DZA)BN%C3M<]MNZ[#?U9PPP;B#
MIWCNL<.;=$T+VUC``-1/7SWU`UB?/?;:=T^]Y\#[);Q:^E4IVF]+[GPXYPT_
MSSJ=OGE__?S;TR__`."'CW2U12YO:>_!XI_QT*2_T,&O*!W3"VZXQT#[-;!^
M$"1@`2]5J-W9;7'1LXO[H.._":8,?H\SBP-'",'[6<U?65,>4`C`PA:Z\(4P
M=&'5K'9```G0(1"KW08]""E]!6TM3K-*"1]H0M,BXB]_G)JA`5<8PR8Z\8E0
MC*(4H6@LD^UP@/ABT/A69K;3`2YF7ES/LTR7.K6)!X=53$CSI&=$$A;QB"'4
M&],`,,4ZVO&.>,RC'O&(1"SV*H<\Y-$5`VD6E1$+?`!HXQ#=B+T^9@Y$>V0A
M'2-)R3JZKTO7HB&&",FD+7+R6;_KCF44^<9%9L^1/8,D)2?9P@K>4',Z3![M
M#/1%TMQ*-[SQY"?]^#<S0J<HC`SF$%&YO@YV#EN[].63CK/,M3E336(\7S0/
M&<=D4LV03MM+(DO)309*_Q!LQQ,;RNY&GP)]48W*M*;&!JE.Y%UM2&=T$BGG
M.;]OABML)R-F`0+`SW[VLT/DI!SQ9D8V,'XLF9$K9--DA<Z>&=)&]#2E]]@)
MSANVR9X-\:=&!\)/CA)$HP$02$CW^5&#C+0@)STI2?>Y4>BMKIW_TJ4XK6,^
MM]',ICAE)F(*@SXE?C"4,'W)UV3J4&0&=3%$#6H&S=C%E1T5GTE]GRR/>B6*
MND6-;J),=+:Z)89VLH8]1(TH/SE4JY:4H_\4J4K5VM&SBO2L(5TK2]O*D+B:
M-*WL,BI5AV;1/`%GJ>0+TR[+VM?_O51%+)O,7JE9S<5B%:P\G:98?TE(J)I5
MBYR'O:J37G91INKK*05=3WY\>IJH4A6PB>4,&DG['\L6EGFT="RL+BM;'[Z3
MC+MAS4%1>$G:WBZV"@UG8JMT(ZVBCJ=:XA)S]"E5YM;6ML[JE`&!1UB,-BB@
MSTV6;S%+-V-6C+5^BU5"CSG5[$*WN^A-[\B6N-O/%=:TXM)K1=5+7Y$UCDFZ
M;2S%JNO<P<FWM/5]K4L%S+"D@O<GU^S_[XH"S.`&/Y1(X[VG)P\,/7=2>+8.
MSG!Z]Z?@D!$X8./+C+Q24S7]%L^VXS0K?"W<7FM]^+807O%?MSM?1VZL3.A[
M9AG;%L9X"A2:!58QC<OY89)8%8B9A:V)^Q/A;.7MPN;E5XN9)F4HC^K$CRVO
MDJ=,7L]9%[%.I1JBDA:C(6/YIV,R<Y01!*<D-[?#-3)HV;XT+)WZ&$A`U#%G
M<RQ-M/P8M#N.+-J<R131I5.,5EZSH-!LSH>I6=&1232DZ1(UKJZM=+#)46LZ
M6T9`K[;(60;NI!O&T"21)8AA5:UD,3/J5KL:IIN^\V#.`\:W&?36/9YSKOO\
MZE[[^M?`#K:P%H=-[&(;^]C(3K:RE\WL9CO[V=".MK3_ITWM:EM;1+2,-3RO
MS>TDOJC;-QL=G<-H9SXGAVRQZ2FXU^VZ!$K:06KYV(R\2KH>IY;=^,[W7]G=
MF4IKY]_ISI*^!UXD>I?OT(7>MJ%7[56"F^3=#K\@&J]\[JPREEB3*J>:LE2=
MBN-X3!AW66/A+#M&>1:G=QXHHO7,ZXCKNS<2?),/EUO<?NN..T`64YM\)%B1
MR_PZ_8/LO5U.]"06'93OA/C1EXY4IC-68BY^L-.G?NAN:YAGYW*<BY1.=5@I
M^^J&ZER+FG3<H7<ZM)V.D-0ZOJ8TX]Q+/^\LGI,+\B_M")I:W5'>K3MEKK?6
M8)KL)4"[;C=V^KU>UE(L!@NF%4*@QE3H:Y;Q5P9Y^,/AC/%)E#K4U/_K:LG_
MA/*P!KRPK[ZLSC\ZEGVL_,-%+QE(<\UU66RUYQ,G8)L=K"ZJUR[I0<UHDE=9
M6:;G/4YNW^S=:^KWQF\TM5]%_-8#._G-7SW)7!Y]1_D*^J1O,^LO"F.KK]%<
MN0\U]L=??;YHOMKA5Q",R,_^V+O7\7Y3()-KW/[Z9_)<L[_^^9W?\C&FG;,^
M%D_U!A4=PV7XA6'VEX"Z$E_"1UW[!WO4Q4$*.(&D\G3I5U5'UH"9\X`!E"_!
M0X')AX!?IC>V0RX!:%-M4VZAHG"X]5FX)H!O,V^;!W]$ED)9]X$@>'\`E7^_
MY7N%=%W>Y5<X&&`:]%^PHX%OMF08:(/A]7T!./_D.,>W9<+%74C(.V9F08O'
M@07W+DTF-;Q6;VD#@+L&-*(&A*>WA.CR=^P3.%6H/UV8A2:X@V<X1VE(A5KX
M&#P(;6_(&)3G9@"F+E+8?7@X9*A%-1(541,U;'N(?'CVA><SA;RTB#58A[BR
MAD@UAS8$>7#23<)D/2,8>7DH@N.2>4XX(IA(BK_#,2^2&X@849\899+X:91(
M@I:X%1.FB:=5*:KH,=K4B8CH@S^#A;!G@,-7B\.H8("48&W(0QDD8D-QB+YX
M/<!XA,QBBT%12=CX0MIDC&,F?,G8/LNH<69W3AI3:_%C9'0HB-PG(]#8CO(S
MC0(B+?61C?18C_9(``>3)CS?N%^GZ$OE1E#C-H841V['M7"TEXK%XQ*M&$RO
M^#"J=(\0&9%\](D@]"W+%XI"4XB&&(WMV)"X\I!ZQ$H0*2RN%(3!588.Z)&X
MAY'!^%"GUAD<R4TJ63@/^5^P!(Y:QH^L<DE]9I!BB'#FB'1*F(M@E4V-LDT+
M>8@SF81WN(%&*(%#290.PY*SM'_'HY`QV4;P_ZA^XN4I%WB)3RF4:')J+XAV
MY_254+B44$F,J*B.FYB4I;25=NAEN@12=KE2;Z41<M6!*$EXZQB5XC>6]D9H
M\&1N!OF"XV@3&MEPZ5B-&=E;X6A2!S%2_N11;+67=YE2;E69WI*3A$>5P8*&
MT35M_`68CA:65`>:*4F#Z%@ZH?<\"257>RD2L[D0LHF71N:'J=F/F\B"9"E-
MK8&6@H2+B3E3765-I;E;G(E6=G69S+E2(/6<E`E7'56;RXE7_Z29^(>:3!>+
M2M64FD5E9`69:CF7<:A:KCF&H@.&S30>IFF&Y;E8BYE;/QA(KA6?QZ*;1Z>:
M!;14^&F<]=F?Y"F7"W+FF6))H)/&GP):E(/)+Q7CA@/ZGD.H?+)X4)OFD\J1
M&V3TD^^'H`CEDB4#.?_)E"_)FWFBGQ&'D3FXHA2Z=FQ95'QGHH/(G3K)HC;:
M8*R&9A#Z7C(*E@::EC<:+21ZCB`CBU88I$CZ>OD9F<54GL)Y@Q;D)H=).J6Y
M4J$2*CL]"I_,]:02=TA!YHV\J:`LADO5@EW8EJ6.X9U-VI`PYS:&F:&!II[%
MN8DC&F-@RJ2-"66STS0H2HU7BJ5X>IHCR*7!MD5Y**:-*6:!"8E#*H43-%1^
M*9]6RJA2ZJ&+TT.\478)MX+$PY@8^J95!SGL-1YN&B4\IIY-A6A_&JDYJGT_
M:IZ$RF_=R*K#A1+:]H102H8M2JO9%:O=J2>CY8BBE1U"J7,`.#F\BI-NTG^#
M>9@H%X8MZ*RGRJ')6JW6>JW8FJW:NJW<VJW>^JW@&J[B.J[D6J[F>J[H_YJN
MZKJN%ZFF[/JN9P:OV?:LRXHVQI4=,A(:'6=I]NJK\-J?'E,:_NJG!15:Q&IK
M.>59L99NS?2O^+:+WY:F]!F#Q15R95IK;N=8`^NPCYI`8]%T\(&P#8MR9Y>>
M),NQ**N'*;NR+`MFX*9B+?NM1DF6I%.O;).O_F:`&_N87K9R/3FR,5MTVH9J
MH]&P!VLZ&,I_+\>I*OBLHD6.01MF)YEW.I)?9;IWYT4=Q.6E.W><8Z50J21=
MHP%P,S>V7FLF.H>VQ!5P.YLL42LP,UBQ<*=WVY%F!YIIO"0;^(IW4Z,=<VNW
M4/*B)6=R/QM-O_F;1HNQ;WM:VM>U,H>U<OLX\B-64SG7M6<K2C7G@GV+IH5'
MG%"[N*"[;4N'6FT;N@Y7NO:)3?2FN[J*YW2'@KJLFZ*[N2T^2J.Q^URPRXQ4
MZIBWFZ#[N;MFRIB]"XO\1J6!)2<!.[Q\H8?L%V[AY;$1B[LITW-0$SK4>[UI
M0EF6*Z*M6Z@;-B`AX[%D%W*=JJ^9.W/(ZC?3"V3\<W-7"W1S*Y8?1T#MFTT;
M1[E?UG<)RGEX\W<?J[3I"[5)Z[2\TB?8<7><]K@(+')IZ[?WVW9MYTHTM7Z]
MN:/NIXQNV5KJ6H+K(V7Q2K#"&&^>2QS!.ZX<W'D"NX]\Q9J9N"K!5Z>5\V*]
MIG3EQV3@.:H3(WN<*SXR_&HADL,IAHOC]\*6*GVOF+O"4<.R!;QIS[2_@?IY
M!(;$UHAYH\?$\[G$.^P65R3%G4O%BI@S+OJ]HX:H79QZD;9]HOI4Z)7$43C&
M6<QA(]>-%RRV$@9VJO957:/#3WR02(0C:'R`79:`96R[80QU>@S#J$=W7OQU
M5GQ+C<S%:HC(VSG'C/S(KPK'&49T!O;'RV;)+&S$8`RN0`QOYN7)W<+#ABS*
MG(PHX6/*3*BK].6ZJQQI).K*E)RUKQRWH_FRP.>0>&S+P"S)S3+"T=;$'N1W
MP9S,1:R8-\QLD`S(DZS,KGRFQ$P<J_^H?J4LS;;\J,T,+^[VS(H:Q-K\R).X
MS&NZR_':LZ%2:6,[K84K6M![S8,+J^.<I"*\QQV*SKAZ<C1BL#$C)2:+K!PC
MN$(XH_6\NZ*YJB#6S166D3IQT,;;@PK-6]5<?"(*T4%*T<(,?@Q=NV_<PA@]
M@85,T$=:9.?)T17-S*@"I"%--,7XT?[U8N84P/O\)W/*J0T:JI@L>.L$B*G&
MABU=>F<,T[X38@)D9T5+:P19OFN[O0W5U%X$JCC\-R&,CA,:U'W*TA/-E6@*
MSE%GDEL(A],\M2=-SRB-SQ+-+05ZL5>-?5!\R8&\U9&\T0FMUDW8.UY-UO:U
MDH0<UR3-U6@;#<JC"-17#*!W7:5SO:L@G-?W;,Y_:=<>5HJN_Z/5BIVGC'W1
M<.W7ERW8<^?3E*W/`JO1=#U-!?MO[9RQ[>R"90O+E)K8<OV'N2S6&3QC@4W-
MM;U90&L>T)IV`:@Z??W90QW;;3W;)'S;W$S4VO+;PZW2GNW:G_S+K_W%R,V7
ME0W82WF3\4@I,=W:?NFN1:W<:SW8E9K2=1V)O!O-!.)`FQW>T7TJW%W"R2W<
MBZTHT/W7D^J!$,6)[O@][<U)WEV.I;:L[(Q<96V!9/S8M%N)W$AITXW9Q`TI
M<*F5CFW!HYW&(RN&1_N7&%S==ZN#"B[9\3WA]4+>H1'A(U3AJ=O@HFB1YTSB
M5F3<FLTL8,%EB925)"3BK7S@C,CB;5;IXG*,X@M]0!`[%C!IXZ8$Y,>LX^8M
MI*VBW:;8@%F-G+H8SUEBXA*%XZNIEE5M6"#^XEJ.V+@[Y;R(0T9N0DB>Y>*-
M8,'=T8W]GNK3JU(W=T*TW[Z(Y?]+*M\OS41-!'$`!-)LJ<(.;N=@$W@>J#IT
MOM]G3MA8-\4M(9$P9&H+WIFF">B=HN(0MN1Y++I4<>C=E.B`^M^<[>B.7MAO
MO:6C_-TH'M"<]G\"?K[EJ[8TQW%D&YX=?M[?8>7OV-_S$L.-+NJ^CHV"/JFN
MNLB":JFZC;`9CH***V:DBM,Z_=4/SG.XWD">SF:P_.O8GNU1Y,B@1NFZ"^-?
M"E0:6AC33C_!7EH@J>WJKNY]^$>I[+V6SN7/+4)E_D#5KB3ION[Z[D0;5*5U
M<[I*WN1L7N.<KDCWOF](L4K[WDI]Y;[-C<L![\P13XN.1[EJ5._V<_!AE_`*
M/Y$Q=]2H6S[,F>UDW*VLYZY_D)5+4('Q):3QZ,[QEI061X/=NM>7-5HG1*M<
M&9YP.5M+6;;:!^K&#(I52%'PC'3R!=V58+WF'![N`\Z"J:/J9Y=:G1&4>>O$
MXIZ]J@U,^MWI2,_T"UCL3=_)T&[?E06>5=[U]/3USI/IK\Z%65W@W@?N+>GC
MY,[RGLCVQ3URW[3>B2SWF&ZR%NOPYBLS9L^S+@_WGNN:053N]9/X_[3=\%Y9
M$7A5TC;/8O>V<*F*=GX?XL`(^'4\[_1N]$>N]RD,FT1EEYQYFPE1FR@UF2M>
M\E.GIO/JGL;5K\AUMNNIM9^!VGY.WXE:SCPMVG$D4ZJ?5M/Y^I:9_'GI5INI
MG2KE^I<W\K][AL#"L,@N]2FWH<+J:2WXT.=']TG.HVU8^<W?_)AY_JRO_+C)
M_#\^]K(L_B.RPM%>;,G9^7P,_[\J_W7/F@`!H,#``@('&B284.%"A@T=/H08
M4>)$BA4M7I0(0.-&C0TY<L084N1(DB47?D2)TN1*EBU=OH09\V1*F35MWL1Y
M,.5.GCL])D2(<&3'G$6-%N7),.E1IDV5]O]4Z53J5*I5=49U2K.B4*M=@4(%
MNU2A5I8&-WI%ZU7L5[(2`[P-T#1N2+ASCX8%F5;O7KX3?4K%.K:@4H)"!1HN
MW/<E7L9YQWZ,:9BK8LHPUQ;^^[#N0KL%YG:."YHS0=&>20\LK7!SPM2F73:>
M7%GV[*:9:__4.?A@XMV)N1ZF;1)V8\)`(\\,GIRD;;:0-8]VC9IA:-;5K4N/
M_OGZ=NFM.Z^$K5S\^,7,R4<D>A[C<,808[>,?5;]_)F!FSNFCS9\?O[]'[?U
M+\"0V,/KI-[>*^NA]`04S[RKG&,0,.)N"LJX@BK4[4#>$$LOJ-\R!#%"IAP4
ML42/"`3+*@0Q6]%`Q+1()-'%R":T"3$--[000PXMU`VXWGZ4,:<8@W01Q10=
M:A$^OY(D4D(`'X2PR1G;DY))*6L:\DH&C81*K:T6U/^2JLN@Q"],X6@T,TV<
MLE0S/RY[$HQ'(2\"LTVC8'S23HOV^S)*/?^\T#Y`^WMS3#$'M'+0,P4ELTY%
MW4-3P2/KDV]/22M-]-'7\M3TO$)M,PO(.T6JM-/R&`W43U,I#8NB+D]TS$99
M1;TJ3A!#Y8W65='C=-?D/NTUJU(11=77)5%E4U,^+8MS5AQ%_3!#9X',U-=D
MC>T*6&VWC9181[$]EE%#5UT6W%VO;9!;===EM]UVP1O67%<='%?9;N7]TUU]
M]^6W7W__+72Y,O&=-\]Z%2V78)D`9KAAAQ^&.&*`2555X7`';K1:,Q.VF%>)
M/P8Y9)'U+5'C8COVN.)4,49B^%YC1X8Y9HF#0Q>WDON,%^4].:U92X[#E#EH
M%)$,5N>46<XH2"M/SE=HIY^&.FIMTSS8Z$N9MEGIHU^6NFNOOX89VYZM9E%E
M!7V^6N.-P6:[;;>Y9#5G<HLF&U:SLZ[R*:3_6WZ[;[^[%ACK0:NN.VZYB]OX
MO\.M)KSLNRFFN\;(CYX4W\8!';ON:ZOU<3"UAY(3])4_E_?RT1>'7'`L)Y]:
MX<S5?)UQNDW>#5=I#<RUQPYS#'THL[XM/.-$3<?Y<0IGW];BV(%>'N6J20^^
M3=.)+UCUA5G'ZF>N)V_:^NB'A#YZZ=&E_N*]UV2=:"H);MYG[K_G6?R.IV]?
M;^\MFQW2]2U_W\[RR1Y3^.0WP$<E27O6JA_";(6?4N4E*M/2G:,ZIS??+,B!
M%PJ4XFI$*ELI*4'0NA$!1>@J\[V*??UC7ZXF@Z';R>EWM\H=CR[80=MY3H4Q
M7)CH;@69WS@'@CWB=QT.<5C#$1;1/<6K7.E0:$2="?`U3(2B8CCGLNW=+XJN
MNV(6.Z6V`VK1B\KZHA??(ZL*L;"&*VQ6CG0D1!)ZJU5AA.,6XYC%:$$P5,!A
M88A"=$9J_<B)<RQBM*35$0]9<'>8PIWGB.)`1!+2D(]\T"`/";S[)!&0:9?$
M9"8;M,`^^A%W/VQA".-3G%%R$H:GU&0J5;E*S+'2E:^$92QE.4M:UM*6M\1E
M+G6Y2U[VTI>_!&8PA3E,8A;3F,=$9C*5N4QF-M.9SX1F-*4Y36I6TYK7Q&8V
MM;E-;G;3F]\$9SC%.?1.<I;3G.<<WQ_1N4YV:O%_[81GXN)Y%SC-TYX%%(`Z
M[YDVGUCPB/L$**$$,%!]]N5-F7Q5Y_)H.SYBT*$+=2@,/V2C@%;4/0/%:$'U
MHM$XB@57/5RD'F<8RAUI,)2ILFA*/8)1EG)417/J'9;2F4B%!A&(SR*I<2AZ
M.XBJU*<'86E073J5H2:2AIY$)5)%V4FTN9"0G3P+0W,7U3T^-894_:E*`1!4
MKA;U+DYJ#HM,RE0@KA!U@/1J5KNY5:YVE3YI->I-:=70/=J4KFK%*RR[6!FX
MVD\R"H7D82"$53).,*^'1:RN$KM8QLJSL8^%;./0>#:B_T+6LI=5+)*2BKC;
MA!-Z?<5L/`4I4J5.BZZ[VRQEQ5G*I9[TA74-K5I'.UFY1M*&8[6C7\J)H)'>
M$*<GC:U/9VO4FN+TM#;5(V=7RUDBNA:$H`TN&]5G2#K1Z2]@6N0#_QK6Q^2F
MN^L!K5DE2%RK%M:YME6M?OZY06O!2I)B1>E<HSNB>;'%N_7=F:0PLU^Q=LB_
M]XTH`[E(23GNQ4/&52-23:O@!&>6<?/]:KC\*I]'QJIB!(Y28%^87?Y2][]D
M.E%$7R;%J?K1A_8%,6E#6%OH0EB$)K/P5P#L2!GSMY+#PG%@:$SC[]:8PR*N
MTX]'3&*H"K&4K/5M;EV\R^'U<&;&K\T-=6T\Y:<`>468BE>0_PIE$9^NQ8OB
M%GKX6N(,QG>'6T9Q!@O9TR7G,E-DD7(_L8RQI<P9P/6!;X^I/&<L(T<Y[$IO
MFP4]*M&N2[.#1C2A"ZVNN";:T3*=)Z!C^FA*/S'2AI:C;J4U79(O%U/2G=[T
MDD$]3$"/.M00-G4P)<VW=YYZEJE6M=<,_"E7&Q/6P/P;%2=,LEH3\]:_S'7?
M>NWK2P<;;)D>MIO/:>RG53?9N%XMLV>6PV<#FYO2]M=+"[C57U?;4M7$=IAI
MT^ULL36CWOXS-,--(`&16T)M):@M$^A.9:Z[GDV]DD;@+=3I&@^W^2T@>/4,
M<$0-O,H'AQ2>R_)F7Z_[7/]KV_>YQ>QLG6[%5`.FLIFAM-\89_S#]YER5-%<
M8XY+)N3`(W`'=6EO=\NFY<*"-Y.&VV@;'Y>LCOV2QBDLY.P>V,K(*=.'>UZK
M,N^\QQ_G^1B'5TN6W[N]F#-W/I/F0N52'95LQGF?:F[RC3_9Z__9LP^Y+.2'
M@E3``4;6TM'ZM7ZW;LC;EOE1JSY!FZ<VWP7W\=#1_G7_FO7H/M?[SG\W=B?G
MN>A*;^.+V1XX<;]=>932'YL9:-^7TU?@?\=NQ^\+$BW[&:4\KE6%ORO!0BI\
M\PR?W^+1Q^C!.3VTR:H\S>":\DG[[]CZP;32#AI=V%L[WVP;SZH]U:_Y]MZ7
ML0=?;]M$)/Q9AZSX^?,]96ZO)^;?2?5,7B+NL8;\QSL)<$ID_::D??SLJP7Z
MQ\>?K,57?7XVW=^QG+>PM@_MZDDMC)]V/]QZ&?_:G'__7G8:^,N_F"$_*WH1
M_W,EX`.V`0SMF_TKOW)C&NZKDNDC-0:,F@)\/X,J&@ETD^MK.`O\&PP\'[[:
M0.7QP`\$0?<3P;.2OA)D-?M3.0=DMM7+M16D/2ER0=U3/XJ3)99[*^>3P0SD
MBRSAP(PX04M;N_R;FX`)PA%LP9/A/@6LBB(DE!2\P28R0%7BOQ$)%E"CP-F@
M0A*TP@<T0A9\0E[CI2VD)R@4O^]KMW,9P_U9N#>2/ZBQP3#<M2LKH6:C&JJ)
MPZ&!#_VSK@&\0_4`GR-,IC],'GA11.*+M2PT/RELID9TE]6A1".))C4,Q!UT
MIDO\%^OS1">D)DV,/#=\IE!\&#$!P,%[BK\O/$54!,)(#,'#@KTCQ$/9@<6@
MJ<-9Y#UAXZ`FS$4[/!Y>;#-79)97"D9?;,.W&31C!`PX2L;Q8SP?;"QG)#+Y
MB485W!E*K"A)](];/,!L7,7VXT/*`9;=0L0F`4<A$<=&5!QAW,3&6RL"=#P=
M;,=[%!GO6T1OFAC-J4)\!,B/$4-YO#9:NZ(B#,B$A!C^8+]LLB2T4A&%E,A/
M5,?<6RMYDYR)U,AWL9?P@YUU5+17<Z.-),ES=!Z+W)B,`O])]J(E\2K)E]R]
M$6K(*FFK*RP29(3)G`3$)"1(<[S"6,&;&*P])(FX?%I)\+@_G51*&FDUQ?/(
M;TL\WU@,.BE*E00:;%S*K'S(4A3%@T1)B[,Z[JJY#5FC4S*CT(FZKCI*I.0?
MK71+2/3)M2R9KXQ*NS,0BFJHO(0M:%'+5FJ]MP3,B"1#`IK)];HYTL++(C-+
MW^)+HP0C(@',P!PW4C2:P@PTC?NW)+.K\I(AJT(V_^G`R-3*=J-,+'Q*,(0B
M"13-T62>P1P@RYPF4UO-I81#U\3*T\0FEYI-G<1%(:0CNOQ(F[P9)-I-F"3,
MGC'#WMQ'$V$WT!2>X@3(,H1+!,(:'MNLS9[\,XY,)^B,QGCT3?`3'!.Z3>P4
MS(C_H3[N',/^L\Z.W+X4&2VPG#H',\S:HCE+),_K"4#YA$STG$$-7$^X"\]Z
MDCS#\TRYN3)(HCG!ZR\"[;+DNT_B;$"H#$[^+$=#+,T)?3^/:M#BDBNIHJDL
MT\_-HZG6`BX'7<YWE!E(VTX*;9B*_,^_O!\0+;&S;*$\&B*ENM$@HE$/+=%!
MI,8I/$\6/='NF<XE+%+Y@A;1(SJ[Z:[2\ZL.`ZSW8LS4\<8QLSTA;<XJ^DYP
M:<JZU-(4W9(@Y4\4%4_J/%+VW%(3K%!\PU#>',DR-=(T-5,YA5%==!\JD4M&
MC,Z,+!"QN="U>=%O7%,7#;,\!3-WA,`^_=+D!$\Z';[\4FQ-[0S*2+6W[)3#
MZW34+?I3I!C4":Q$X1!3:_S!2XW3KC27+F5'2`542:604(U%/R1530W4*\U4
MWU%56(7-SEK1?>%277M!4^W5,R73"&U3W$3_35H51,<!UF)U/4Q=UCE-3GA$
M5N!D2%>%1%2]&DY+5#I<5.'L5FG=56/-F_&LU;D#5:+RU5]E5`"U4ZC[U&GU
M5C45UK%B*J3KT`8+L,.,RTUE2'ZU5*%A5W'UU'(-'FQ-FL2<41R]J[O:0X/=
MSUD=PDZ%UP>UQV>])(?M';HCL]I16+)B6.GD5FA=UXB]57?-U;F<5U;"6'K%
MJJ3R$<'#NC4ST:V4U93U3C!%4VHM$HC%I95ESG2M4XNU58"].#0D5*$%-W\=
M547]UD/%V:)E51E1VDR<6@N-U9J]&W#-68$ES2S]*9]%6:85V79U5HH55*/E
M0I[MJ*H-QX9E6QPL7UFLU=E_S-"Y)<<"&("\Q5N]S=L!V%N_[=N_-=12'=G0
MC$"@75JR'=LA#9`M/%FE"-S(Y=O)!5S*%=S/E+>WY<K/B8]F'5:PY=2X)5S&
MI5NDY32[11+)K=S5_=O655W,_P3&PEV3^IQ/`-R;O4I;HCU5M"U=V<U=TO4+
MRWW=X;5<T]5"S0VTGD(MDO+<&VO>]-/=W8U:PS7>C4+=U&5=XLW>XJU>30+=
MY2"OD+HAES0>W"7'D7$=WIT/Y%5%KG4/X87?[65=@L6D[]6AWZJ[SFVR6-7:
M8'U<,%3;WC7)]8A?URW@P*7?BV7?7:.\>AW*^C/%$YK>X`O@WV,]X02``];@
M[.U>A%I@_XQ>"9[@7ZE@N35)<[O!##9@^5UAUTU@GGSA,U3<]!WAR;19^+G@
MFKPR%M;>%AZ`&%[;$A[&$*;A&A[(D-4K3$O+OAP+'MY@%^[@^OU@NYEA>;W>
MYA-"^XA]326N2H(*"B<&8P..8@468F5]6M/\7UD$UIA\-4-;XI8:(Q]^8LD=
M8S(^T_Y-O7<%8"MRQ)9T8R8^FQX6Y,D%8F@\1(G-XS1NW^\DUA[\8\<DH4$.
MX[PMY*2$P=E]6"-6X\)5/J9SXSP4#$F6X\JMY.,4W4.A7O<MSV?MY,_-W-,T
MH-T094FN_V,TKN)PY`@"T&4.5%]<9F51!=E:#J158[@,GN,-%N:`I4<9U@A=
M=N9GAN9GEDT])EE&KM(IN>$7>TZXX2T=FV5D3N:)99@]SN5H-N=S1F<"T$UJ
MMEX^!F;U+.7O<5Z##,HO/F8PCF=<5>5MW8AT]N=_!N@I8F=?QN!K)N=DIJVJ
MP^;@,YP!-M>#^&9\#N=P16*X+6>`QNB,UFAU-F/@Y6>!YL0((46-/305E4IM
M9<G/9<))+8R('F78!2#?U<=FWNB:MNF;IF<L9M16IFAJ*TL2)2/\M9\%&M#?
MFLJV<SL"GN0GSN>K)&@`N.FHENJIEN;G766;-.C1I386H[#DZN>MC_V)A1JL
M$YOII/Z2>W[IIF;3(>YGJG;KMX9KCM:^KN3IPAGIBEO,CLUK74$CK(NI:68T
MVC'FEQ9EM;Z[TT6)N%;LQ6;LON*>K&:BNR;JE^U,RE:AQ;$PPPHZ.X/G?5R:
MEE[J29[H/FP_QC;MTT9M9PX?.)UG1/;@;(YLE/R6(`MMPA[MK#N(U-;MW79K
MY*$):;S#P5U5C\Z(VA9DPU9'I>#MY6;N73Y<3(S@>IMB*S9K.C'N`T9NR%3N
MYN9NJ>X5XINV>2QC<JWNK;AN'LYNK3F)[F9O:.:9?-3D:!OO];MBR"7L8[[_
M[;7.;>]N;W0VF-\&V.&@Q>FF;H=6)-UR:>+-[\,>BZF&:N86E.O"8Y6>[XX\
MV@7?XJ<LO)](</A-[YM<;P=_Z[;(C`O4TXHV(BW>9)F>(^;K9@/I\.W]<.;<
M;O[V9S@C\0G'9A2720'U'B3C0<2&[=C6<".49;16<`S7[A"/:ASW$Q-_:JO.
M<#A)Z-I%:=VZ6^SS2`.JD!A?8257[P;W;Y5X$BC_5QYWRNOZ)'S=T9\.LJQI
MKF%-0XM$/,A%\OB=\>7+PYPQ\RU!7!S.GLCKHSI"KBHGLQ8A\$1>3JZC*2]7
MW3P7:0/5\4Q&\V$V]$.7(:%.K3@VZH:>\RW7LOAPI73*A?1(OV5EEG(QNA06
MT]'*%JGLX6Q0UG*S+;,FOG,6!G.I=1C-^?,T8[('%O)<)V\#YQ6@N/46%O:?
M%3?A/F*:W7-R2G1%+V_S/F]D3_;E,]\0C>FKI7!M!U\WJ_!AS^F#$_5J?]U2
M[UJ0*D/:!?1*WV;/G+CD\K1PIV^!_:B3./9SOW9=3SO[8/9F9^T]%U^YHU$3
MT_0D3ED6+_!Q1U$[OV_15O_XLE4Z?T_Q/]=0XBJMP7*J>!4CVU1Q=65XZWYX
MVXYXB:?B!L*(NH"+;QT;&27X*;6ZG5+9^@EX<5]IPZ$6<Q=>=-_9?I=3E0?Z
MQ4T@K<CLP_.GRS:L54+55CGZDF[4:8?@?3Y)GW]6H+?ZZ,".DO@.\LCV=L+6
MA,HI!#/+UU)>/IHH8%]DXL9<J;=E2;<BJP]ZN]CZU<B.E8<.U3@-NT<-O4][
M9V?%H2_Q%8NOI!^I@J?/PA?+:E9[S+TE/'E[N'^+[L!ZK-<.RK_[ZRB-UBCK
M5"^VA']SCE5,5@_[O4Y,OVYG6C\F0_F?JS^-UL]ZZ]#\R<_ZS#]]=^_\!9\M
MSB362\MV+=T//;2$=YV&>F92??Z;^]>O_-C?^NR`?>[8_(\?17IWN4=%_=2G
MEVC'=FZW)^R?>O+D_,:_?ND?6-N')^Z7=F)W8!2\,/,_6['M1O&O=^_/=(%1
M^O<><I,E?Z^'_W:?=H0%B`("!Q(L:%`@@`()#S)LZ/`AQ(@2)U*L:+$@@(P:
M,S+<N/$BR)`B1Y(TZ/'DR9(J5[)LZ?(E3(PH8]*L:?,F0I0Z=^K$:5(A4)]"
MA\;L>=`HT:1*!_*<N?0IU*A/D29=&-*JU*PRFW*EVO'E0HY:Q_]F]<K4*=FT
M)+M^5.OV+5R3:*M^91KTKE6L"<5BO1MW+=O`&B/V+:FW\-_$*LWF3"DQ`$'(
M0R5;I%Q`LN6:@A$K[NSY)F.?G!OO/6K7KM[3GT%N%KST\.C5LAV&#ETP\^T`
MNB/KIMS;]V_,D05:QMR;(>[+QXDO9[EY-O3HB^<2Y9P:<5Z"I;7[E4ZX-=NC
MMJ]N]6Y>KF/T'BDVOTW\8>;BPR^_/YB<MW#D+I^?[^]??5M*C3986&(U1AI"
M/_WW$'CAO2;>@N;51EU$O@T4GX7U:;BA<?1=^&&%'H(HXDK\17BB=.,M&-N)
M#78%H('[=<0BBF_M)!Z%O,TGXFXD0@;_W(@C]I@AD`;U6)]\S.WG6HU-?G:C
MDU$VY")7$-$HDG4Q2@D7E%NEMR5.)H(YIE9=DBDEE4U!V!U84UYYIH",F0DG
M6$S:5-AV%+U9%YU3J=CG>6GRI&!8FC&X)Z"@R?EGHA>)611W"0(UV%D&7L?=
M7C%J6:"6C4[WI:<K"FH6J#"Q2&FHKRV:8ZJ.VDE3H9&FYE>LV:$6Z:2JX=KJ
M2(SR^N2HK%9G9:>_WLFJK\;.&)BBJL4JZ:P<V9K@K$'EB9>R6`J;[6K!4K>M
M<]]Q&R:RX(X+HYIW8@2MK.VRFQ.MI^69%Z+GDA:@O;-Y6^JZH$U4;+Z?KH?C
MP`'3]BJ8]1I,)3"^"W>V;\'W*HSEOP`[S%JY_%ZL$,).6KPQL1J#K!;$#4.%
MZ,?_(TLTH<@+/ZJRL<G"K&K)?=D\5+TIS^RFQC)G^_+.J?H<M%`U;]JO:!:A
M2O1W/9M[+M!-,]WBTU-79S19$R]M];(1:U?USQT?"C;7<0U=-JQ8?[UUTJZB
MW;77$K/MLMAPM_SV7V?CO63-[DZ\EK9[K\WOG'0SV_2@INVZ\I3]_FVUWH*7
MJ#9J.D-ZE>5!%\XQV;Q&S;#(-\<[^K22*DAZZ8\K&[GDAE&>=:^LC[OYYO9^
M#OK<NEKK+KNG\J7KLYSG#K+LK6O;=TO[`A8WT;07#^?M/!/F..^[FWZ]]:0O
MSO3SQF-L-/AINFXR]QDS;WO=`FNZ=(#5WELI@MB3/W+M8=X/'C[^^3NXO.KY
MLGS^[-)GO_]T+T+Z.R`"$QB]BO7/?^:;'[<6.$`)=0YG"KP@!C.HP>$QD(,[
M^Q\$5R?`"08*7!L\(0I3J,)@\2]S*@.A!STW0A+&:84VO"$.<WC"V,7_4',/
M[*'09DC#2NFPB$8\(A*1B+D03@V&+FR4!%N7Q"E2L8I6S!]MEOC$#_YPBWV*
M8A.O*,8QDE&!9G,5$R&WJKN%"HP;*R,<XZA$BC5)86Q48X[J%\3#P4R.?OQC
ME:+3P,2@#(!X<UX%S^1&*`*RD6;<DNP&F3<]&?*0:ZPD(_G8*D<Z4HJ)Q%Z-
M]H1)2^:Q@%33I"(YJ;^B?-*'=^13E*[TRD2ILI:VO"654&3*B^E-DIZAT2@]
MA<MA$O./>PQFV<[FRX>-#8B9+"8THYG#`,Z2:\I4Y,'2V$9I<K.;">1E*[E8
M35!"DF=>_*(WTZE.\;D2F=;LW#*[!;J`K;.>#?;<UB[1%,Z9^2R>3V+_F,'N
M*5!NHM&=PMQG'\GF3WG>;Z&A'"A$.ZD^9QY3FVA+ED/_2<1SHC.B'K6B9A":
MRG&&\94YLUE&ZW(M\DAL;WKTDD%7EL^*O!1'&PTD\40ZIID&M&HYPU:!U@8O
MOJ"J?93ZB$6S*#R..DQF/.4I)6=YHT7*D*3/3.H[[_C37&'+=,&[%-*RQR;R
M9"JE597J3&L:TJ<I+Z=6I:5.W8I).U++J[H;G?RN]]5PP4MR3HTK3"EJ*G-!
M[(6`U>=;VYG&0A)HJ44EJJ6.RC[)0E9&G@2;6I4&59EJ=5!4W>1A$1O3\K7,
MK$.4S5\3VTRL#K:S3OEL105[4-7R$Y^G!2UF:].Z6<1A=6NPC2U3Z;1;J-GV
MML!E[&AY*UN^!7-`0@P;;:$76L.=S[3&!59NIYM95FHUF_L#9W1'FES%YLZZ
MU_VE0J?KV.!.5&>Q^>TVP[M3]=(36><]KBAU2U_.5A*8SQ6A?.<;X#=2R+SW
M_SVP5/R+2NJR=K9Q$UV8W/:OL9"*I7<U#%^[`V$$0TZYZ9)K@VT'RV?M%5?1
MDM?VR&E7CJ&X<GU-W>58@S2CTHNHG(M?9&WL0=$9F,-?Y.^+0+S<GL*FQE[:
MU8GQ5-[&A76OTZKQD*=G8??-2WLMOK)8!T0H'U^T@T$F\("%1KV[EEC#O"MS
M6--LY;JN>*QMFO+V-@R\O*[9S6SJ,9>%ZV6<@GF\$<178P\$O[(^=CO1DA8L
MT3-G'#MK<#'6K&2)"+_X32K'@FX+94<<XCR+.*K?;>I^.1U+V(FZU!/V])?!
MZV=3ZYG5KF8F3?\+X%6_.F&UOC67"IIJ4(<9UP;T=7MMH_R]Y4KR;_`%-K*+
MEFSZS;BH-^XJ7N8&X?8]&Z]*&_:NEZWM,FT;S$I-,E=/=U.5^HV.V.9SM]/]
M('43K]':*TVU\#1C+`<5S^R&GII[Q3BE&NID]Z;GF%F,5QCW=7$D+G'I_LV]
M>4=;KRNV%"CI=>5#/_S,%9=7PA6!KO&-<WG:#I>TH.O<YNPY!C;COC.]/\[Q
ME;/\O!ZOL[Q%#FV2*R[@<4ZYM5NN\YU[[^4W-K*1/QYSU'$J=>L[^J!!GG.>
M,[WI$W2?TZ,N]:E3O>I6OSK6LZ[UK7.]ZU[_.MC#+O:QD[WL9C\[VM.N]K6S
MO>UN?SO<XR[WN=.][G:_+3O>\Z[WO?.][W[_.^`#+_C!$[[PAC\\XA.O^,4S
2OO&.?SSD(R_YR5.^\K<."``[
`
end


begin 600 Image74.gif
M1TE&.#=A"`%*`/<``````("`@(```("```"```"`@```@(``@("`0`!`0`"`
M_P!`@$``_X!``/___\#`P/\``/__``#_``#__P``__\`____@`#_@(#__X"`
M__\`@/^`0$A02&AX:`0$!`@("`P,#!$1$186%AP<'"(B(BDI*55554U-34)"
M0CDY.?]\@/]04-8`D\SL_^_6QN?GUJVID#,``&8``)D``,P````S`#,S`&8S
M`)DS`,PS`/\S``!F`#-F`&9F`)EF`,QF`/]F``"9`#.9`&:9`)F9`,R9`/^9
M``#,`#/,`&;,`)G,`,S,`/_,`&;_`)G_`,S_````,S,`,V8`,YD`,\P`,_\`
M,P`S,S,S,V8S,YDS,\PS,_\S,P!F,S-F,V9F,YEF,\QF,_]F,P"9,S.9,V:9
M,YF9,\R9,_^9,P#,,S/,,V;,,YG,,\S,,__,,S/_,V;_,YG_,\S_,___,P``
M9C,`9F8`9ID`9LP`9O\`9@`S9C,S9F8S9IDS9LPS9O\S9@!F9C-F9F9F9IEF
M9LQF9@"99C.99F:99IF99LR99O^99@#,9C/,9IG,9LS,9O_,9@#_9C/_9IG_
M9LS_9O\`S,P`_P"9F9DSF9D`F<P`F0``F3,SF68`F<PSF?\`F0!FF3-FF68S
MF9EFF<QFF?\SF3.9F6:9F9F9F<R9F?^9F0#,F3/,F6;,9IG,F<S,F?_,F0#_
MF3/_F6;,F9G_F<S_F?__F0``S#,`F68`S)D`S,P`S``SF3,SS&8SS)DSS,PS
MS/\SS`!FS#-FS&9FF9EFS,QFS/]FF0"9S#.9S&:9S)F9S,R9S/^9S`#,S#/,
MS&;,S)G,S,S,S/_,S`#_S#/_S&;_F9G_S,S_S/__S#,`S&8`_YD`_P`SS#,S
M_V8S_YDS_\PS__\S_P!F_S-F_V9FS)EF_\QF__]FS`"9_S.9_V:9_YF9_\R9
M__^9_P#,_S/,_V;,_YG,_\S,___,_S/__V;_S)G__\S___]F9F;_9O__9F9F
M__]F_V;__Z4`(5]?7W=W=R'Y!```````+``````(`4H`0`C_`!T('$BPH,&#
M"!,J7,BPH<.'$"-*G$BQHL6+&#-JW,BQH\>/($.*'$FRI,F3(P&H7,FR)8"#
M+F.N1$FSYD:9*@OBM&D0YTZ!/F4.]#DTJ%&"1I,JG5GTIX.@2)?NE$KU94^2
M4)\JU?J3*-&)7YO&5!B6:U6Q+LDZ+6NV)4^=9;.V33N7)5JZ==WFM=HS+E2Y
M487NS1E8,%"GAQ&_7<RXL>/'D"-+GDRYLN7+F#-KWLRYL^?/H$-#7)J0=&*\
MHD$#MDP5KNG!"+?&'GN:<&VVLZ4V?'VWZEJ:?]/ZMOH5-^S!=E?W9GK4H?+E
M?(]#=RPWZ6V]Q0U'5'R=*4R[8(\:_^]NFRUWGN:U9S4^O##J[V?[#H_NGC=T
M^N2]I][/O[___P`&*."`!!9HX($()JC@@@PV^)9]KC4WGH,46J0;?-9)5Z%-
MU6FW6&L19KCA9-R=QR&(^0F&6WOUK<=BB/')A^)\&;YD6TGQ^9;???1E1R-X
M+3)7XEHK(I:>AP]Z15I879FX$&#/38?<>1/N=9^,>C7FHH1$"E5E:4,B&21^
M*:KHI'1AOI=DEVSBY2-M,()'I8DOQID<G48B>29*4.9IF%\T2HGABS\".:6(
M.XZ994VK>;@EG%CB">F3S3&$(J65#KJHG3>.Z.FGH(8JZJBDEFKJJ:BFJNJJ
MK+;JZJNPQ@TJZZRTUFKKK;CFJNNN_Z9"J"B07_(ZYF87:MJDF,)R*N2D'_IZ
M:'E["EMIM"<5^^NFR6ZG6+`F75HFMA(Q:Z&Q^CD7I5K(1EJNE8]Y.Z.8,4J)
M6KS*GONLH846]]2^W5Z:X[;S7>O6C_4B^NV;^6('%)_O%LMDH3SZVR:V#P,Z
M5L*3=BI2<-C]:V::=&%,+F%%?@ROGQFGRZB2`U\\\9W((CSOF<<:K*ZAG`Z;
M,W4R3]7S3-R.?&.5%<=K[\OE4MMOS3]#ZZ72-^-'-,`Z:A@U7T>JN2:<-39-
MG,KH,CNAN$*[K++74;=;])]HLWNUC2?'K'%X/LN-=*=08X4RI&L#"[)P<\9-
M+X]6IZCSX5F,]:E>VP?WO6[$75O,-L&*%CQWM52_YWC2`2>:6]609]JXN'^#
MO7'6.#^J];T:4^NMY6>_[GF]K9+]D>V8FOXYSMGV[OOOP`<O_/#$%V_\\<@G
)K_SRS/\>$``[
`
end

From lstein at fapo.com  Mon May 19 12:55:09 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:44 2009
Subject: P1394> 1394PWG July/August Meeting
Message-ID: <3.0.32.19970519095341.006c1548@pop3.fapo.com>

Greg,


If the 1394PWG will have a meeting at the 1394TA in San Jose on 7/31- 8/1,
does this mean that we will not be meeting with the PWG the week of 8/4 in
Seattle?


-Larry


*****************************************************************************
Larry A. Stein			Phone: (619)292-2740
Warp Nine Engineering		Fax:	(619)292-8020
					Web: 	http://www.fapo.com
*****************************************************************************

From gregory_leclair at erc.epson.com  Mon May 19 16:36:12 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:44 2009
Subject: P1394> 1394PWG July/August Meeting
In-Reply-To: <P1394> 1394PWG July/August Meeting>
Message-ID: <9704198640.AA864085416@erc.epson.com>

     We brought it up briefly in the meeting. I thought we were doing both 
     so the TA meeting would give people with exposure to the TA more 
     awareness of the 1394 PWG and the PWG meeting in Seattle being more of 
     the regular PWG meeting attendees.
     
     I'm willing to hear comments from everybody about how they would like 
     to proceed.
     
     I'll send out a request to the list.
     
     Greg
      




______________________________ Reply Separator _________________________________
Subject: P1394> 1394PWG July/August Meeting
Author:  Larry Stein <lstein@fapo.com> at Internet
Date:    5/19/97 9:28 AM




Greg,
     
If the 1394PWG will have a meeting at the 1394TA in San Jose on 7/31- 8/1, 
does this mean that we will not be meeting with the PWG the week of 8/4 in 
Seattle?
     
-Larry
     
***************************************************************************** 
Larry A. Stein   Phone: (619)292-2740
Warp Nine Engineering  Fax: (619)292-8020
     Web:  http://www.fapo.com
*****************************************************************************

From gregory_leclair at erc.epson.com  Mon May 19 21:17:26 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:44 2009
Subject: P1394> 1394 PWG July/August Meeting
Message-ID: <9704198640.AA864090803@erc.epson.com>

     Folks,
     
     My thinking has been that meetings held off cycle from PWG meeting are a 
     method of gathering feedback from other parties who might not attend PWG 
     meetings. As such, I expect that this type of meeting is informal and may 
     only last 1-2 hours. 
     
     The plan we discussed in San Diego is:
     
     * To have a 1394 PWG meeting at the TA meeting in San Jose on 7/31 or 8/1. 
     
     * PWG is scheduled to meet in Seattle / Redmond starting on 8/4. 
     
     Since these two meeting are very close, I'd like to confirm how we will 
     proceed:
     
     1. 1-2 hour meeting at TA San Jose meeting and regular two day session 
        at PWG Seattle meeting.   
     
     2. 2 day meeting at TA San Jose meeting and no 1394 meeting at PWG 
        Seattle meeting.   
     
     3. No TA San Jose meeting and regular two day session at PWG Seattle
        meeting.   
     
     
     My feeling is to keep the plan as per #1. Please reply with your comments.
     
     Regards,
     Greg LeClair
     
     
     
     
______________________________ Forward Header __________________________________
Subject: P1394> 1394PWG July/August Meeting
Author:  Larry Stein <lstein@fapo.com> at Internet 
Date:    5/19/97 9:28 AM
     
     
Greg,
     
If the 1394PWG will have a meeting at the 1394TA in San Jose on 7/31- 8/1, 
does this mean that we will not be meeting with the PWG the week of 8/4 in 
Seattle?
     
-Larry
     
***************************************************************************** 
Larry A. Stein   Phone: (619)292-2740
Warp Nine Engineering  Fax: (619)292-8020
     Web:  http://www.fapo.com
*****************************************************************************

From DMitchell at ti.com  Tue May 20 09:35:19 1997
From: DMitchell at ti.com (Danny Mitchell)
Date: Wed May  6 14:00:44 2009
Subject: P1394> 1394 PWG July/August Meeting
In-Reply-To: <P1394> 1394 PWG July/August Meeting>
Message-ID: <3.0.32.19970520083518.00cabee8@dlep1.itg.ti.com>

Well just to put my two cents in.  A two day meeting held in conjunction
with the TA would be difficult scheduling wise.  Only because there are
many other interesting things going on at the TA that attendees might want
to attend.  A 2-3 hour meeting would be interesting if only to show
proposals and the current work in progress to non-pwg attendees.  My vote
is for number 1 even though it means more travel.  If we want to really
make some progress we need to make sure we put enough energy into the effort.


We are not at a point toAt 06:17 PM 5/19/97 PDT, gregory leclair wrote:
>     Folks,
>     
>     My thinking has been that meetings held off cycle from PWG meeting
are a 
>     method of gathering feedback from other parties who might not attend
PWG 
>     meetings. As such, I expect that this type of meeting is informal and
may 
>     only last 1-2 hours. 
>     
>     The plan we discussed in San Diego is:
>     
>     * To have a 1394 PWG meeting at the TA meeting in San Jose on 7/31 or
8/1. 
>     
>     * PWG is scheduled to meet in Seattle / Redmond starting on 8/4. 
>     
>     Since these two meeting are very close, I'd like to confirm how we will 
>     proceed:
>     
>     1. 1-2 hour meeting at TA San Jose meeting and regular two day session 
>        at PWG Seattle meeting.   
>     
>     2. 2 day meeting at TA San Jose meeting and no 1394 meeting at PWG 
>        Seattle meeting.   
>     
>     3. No TA San Jose meeting and regular two day session at PWG Seattle
>        meeting.   
>     
>     
>     My feeling is to keep the plan as per #1. Please reply with your
comments.
>     
>     Regards,
>     Greg LeClair
>     
>     
>     
>     
>______________________________ Forward Header
__________________________________
>Subject: P1394> 1394PWG July/August Meeting
>Author:  Larry Stein <lstein@fapo.com> at Internet 
>Date:    5/19/97 9:28 AM
>     
>     
>Greg,
>     
>If the 1394PWG will have a meeting at the 1394TA in San Jose on 7/31- 8/1, 
>does this mean that we will not be meeting with the PWG the week of 8/4 in 
>Seattle?
>     
>-Larry
>     
>***************************************************************************
** 
>Larry A. Stein   Phone: (619)292-2740
>Warp Nine Engineering  Fax: (619)292-8020
>     Web:  http://www.fapo.com
>*****************************************************************************
>
>
>
Regards, Danny Mitchell (Dallas, TX)


 BuS Solutions Software Manager (FC, 1394, USB)
 Ph: 972-480-3411     www.ti.com/sc/USB 
 Fx: 972-480-3160     www.ti.com/sc/1394
 Texas Instruments, 8505 Forest Lane, MS-8710, Dallas, TX 75243

From don at lexmark.com  Tue May 20 10:39:26 1997
From: don at lexmark.com (Don Wright)
Date: Wed May  6 14:00:44 2009
Subject: P1394> 1394 PWG July/August Meeting
In-Reply-To: <P1394> 1394 PWG July/August Meeting>
Message-ID: <199705201441.AA10163@interlock2.lexmark.com>

I agree with Greg and Danny; the right thing to do is to have
an overview session at the TA meeting and still have the regular
working group meeting in Seattle (where real work will happen.)


Don


To: p1394%pwg.org @ interlock.lexmark.com @ SMTP
cc: gregory_leclair%erc.epson.com @ interlock.lexmark.com @ SMTP (bcc: Don 
Wright)
From: gregory_leclair%erc.epson.com @ interlock.lexmark.com ("gregory leclair") 
@ SMTP
Date: 05/19/97 06:17:26 PM
Subject: P1394> 1394 PWG July/August Meeting


     Folks,
     
     My thinking has been that meetings held off cycle from PWG meeting are a 
     method of gathering feedback from other parties who might not attend PWG 
     meetings. As such, I expect that this type of meeting is informal and may 
     only last 1-2 hours. 
     
     The plan we discussed in San Diego is:
     
     * To have a 1394 PWG meeting at the TA meeting in San Jose on 7/31 or 8/1. 
     
     * PWG is scheduled to meet in Seattle / Redmond starting on 8/4. 
     
     Since these two meeting are very close, I'd like to confirm how we will 
     proceed:
     
     1. 1-2 hour meeting at TA San Jose meeting and regular two day session 
        at PWG Seattle meeting.   
     
     2. 2 day meeting at TA San Jose meeting and no 1394 meeting at PWG 
        Seattle meeting.   
     
     3. No TA San Jose meeting and regular two day session at PWG Seattle
        meeting.   
     
     
     My feeling is to keep the plan as per #1. Please reply with your comments.
     
     Regards,
     Greg LeClair
     
     
     
     
______________________________ Forward Header __________________________________
Subject: P1394> 1394PWG July/August Meeting
Author:  Larry Stein <lstein@fapo.com> at Internet 
Date:    5/19/97 9:28 AM
     
     
Greg,
     
If the 1394PWG will have a meeting at the 1394TA in San Jose on 7/31- 8/1, 
does this mean that we will not be meeting with the PWG the week of 8/4 in 
Seattle?
     
-Larry
     
***************************************************************************** 
Larry A. Stein   Phone: (619)292-2740
Warp Nine Engineering  Fax: (619)292-8020
     Web:  http://www.fapo.com
*****************************************************************************
 

From ALAN_BERKEMA at HP-Roseville-om2.om.hp.com  Tue May 20 13:38:35 1997
From: ALAN_BERKEMA at HP-Roseville-om2.om.hp.com (ALAN_BERKEMA@HP-Roseville-om2.om.hp.com)
Date: Wed May  6 14:00:44 2009
Subject: P1394> July August meetings
Message-ID: <H0000d930cdbcbd5@MHS>

Item Subject: cc:Mail Text
Vote for No. 1


Second reasons given by Danny and Don.


Alan
--------------------------------------------------------------------------
     
     1. 1-2 hour meeting at TA San Jose meeting and regular two day session 
        at PWG Seattle meeting.   
     
--------------------------------------------------------------------------- 
Alan Berkema
Direct Connect Operation
Hewlett Packard MS# 5558
8000 Foothills Blvd
95747
alan_berkema@hp.com
916 785-5605
916 785-5959 (fax)


     
     
 

From lstein at fapo.com  Tue May 20 14:26:36 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:44 2009
Subject: P1394> May Meeting Minutes
Message-ID: <3.0.32.19970520112512.006d9bbc@pop3.fapo.com>

--=====================_864177996==_
Content-Type: text/plain; charset="us-ascii"


I have attached the meeting minutes from the May 1394PWG meeting in San
Diego.  Please direct any corrections to me (lstein@fapo.com).


Referenced presentations will be available on the PWG web site at
"www.pwg.org".


Thank you,
Larry Stein
--=====================_864177996==_
Content-Type: application/msword; name="min_9705.doc";
 x-mac-type="42494E41"; x-mac-creator="4D535744"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="min_9705.doc"


[encoded data, 37345 characters]
AAAA
--=====================_864177996==_
Content-Type: text/plain; charset="us-ascii"




*****************************************************************************
Larry A. Stein			Phone: (619)292-2740
Warp Nine Engineering		Fax:	(619)292-8020
					Web: 	http://www.fapo.com
*****************************************************************************
--=====================_864177996==_--

From genesis at hd.epson.co.jp  Wed May 21 06:02:57 1997
From: genesis at hd.epson.co.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:44 2009
Subject: P1394> 1394 PWG July/August Meeting
Message-ID: <01BC6619.997309C0@cpu06.ued.epson.co.jp>

My vote is for number 1.


-----
Fumio Nagasaka
Epson Software Development Center


-----Original Message-----
From:	gregory leclair [SMTP:gregory_leclair@erc.epson.com]
Sent:	Tuesday, May 20, 1997 10:17 AM
To:	p1394@pwg.org
Cc:	gregory_leclair@erc.epson.com
Subject:	P1394> 1394 PWG July/August Meeting


     Folks,
     
     My thinking has been that meetings held off cycle from PWG meeting are a 
     method of gathering feedback from other parties who might not attend PWG 
     meetings. As such, I expect that this type of meeting is informal and may 
     only last 1-2 hours. 
     
     The plan we discussed in San Diego is:
     
     * To have a 1394 PWG meeting at the TA meeting in San Jose on 7/31 or 8/1. 
     
     * PWG is scheduled to meet in Seattle / Redmond starting on 8/4. 
     
     Since these two meeting are very close, I'd like to confirm how we will 
     proceed:
     
     1. 1-2 hour meeting at TA San Jose meeting and regular two day session 
        at PWG Seattle meeting.   
     
     2. 2 day meeting at TA San Jose meeting and no 1394 meeting at PWG 
        Seattle meeting.   
     
     3. No TA San Jose meeting and regular two day session at PWG Seattle
        meeting.   
     
     
     My feeling is to keep the plan as per #1. Please reply with your comments.
     
     Regards,
     Greg LeClair
     
     
     
     
______________________________ Forward Header __________________________________
Subject: P1394> 1394PWG July/August Meeting
Author:  Larry Stein <lstein@fapo.com> at Internet 
Date:    5/19/97 9:28 AM
     
     
Greg,
     
If the 1394PWG will have a meeting at the 1394TA in San Jose on 7/31- 8/1, 
does this mean that we will not be meeting with the PWG the week of 8/4 in 
Seattle?
     
-Larry
     
***************************************************************************** 
Larry A. Stein   Phone: (619)292-2740
Warp Nine Engineering  Fax: (619)292-8020
     Web:  http://www.fapo.com
*****************************************************************************

From yasushin at microsoft.com  Thu May 22 10:00:12 1997
From: yasushin at microsoft.com (Yasushi Nagao)
Date: Wed May  6 14:00:44 2009
Subject: FW: P1394> 1394 Printing Meeting in Japan
Message-ID: <01BC6619.997309C0@cpu06.ued.epson.co.jp>

F.Y.I.
http://www.geodesicjapan.com/HelpVisitTokyo/#anchor383847
http://www.jreast.co.jp/e-info/index.htm


Regards,
Yasushi Nagao,
Microsoft Japan,


> -----Original Message-----
> From:	Yasushi Nagao 
> Sent:	Wednesday, May 14, 1997 11:02 PM
> To:	p1394@pwg.org; pp1394@cpdc.canon.co.jp;
> gregory_leclair@erc.epson.com
> Cc:	Hitoshi Sekine
> Subject:	P1394> 1394 Printing Meeting in Japan
> 
> /***************************/
> /*   PWG meeting in Japan  */
> /***************************/
> 
> I will arrange PWG meeting in Japan. If you would like to attend PWG
> meeting in Japan, please E-mail me.
> My E-mail address is yasushin@microsoft.com.
> 
> < Date:>  	6/11-12
> < Place: >  	Sasazuka NA Bldg., (Microsoft Japan Office) BF1
> (When you arrive at Microsoft (Sasazuka NA Bldg.,), go down stair at
> first since the meeting will be held on BF1.)
> 
> < MAP: >  	Please refer the attached files.
> < Accommodation: > I recommend below Hotels as accommodation in
> Sinjuku. You may stay these hotels in Microsoft (discount) rate.
> 
>     1. Keio Plaza Inter Continental Tokyo
> Tel: +81-3-3344-0258
>     @ 16000yen(about 134$)/night    Twin/Double Room Single Use   Fax:
> +81-3-3344-0247
> 
>     2. Tokyo Hilton Hotel
> Tel: +81-3-3344-5111
>     @ 21000yen(about 175$)/night    Twin/Double Room Single Use   Fax:
> +81-3-3340-4403
> 
>     3. Century Hyatt Tokyo
> Tel: +81-3-3349-0111
>     @ 18000yen(about 150$)/night    Twin/Double Room Single Use   Fax:
> +81-3-3344-5575
> 
> < Guide to Sasazuka NA Bldg., from the hotel:>
>     * Get in a Taxi at the hotel
>     * Say " To Sasazuka NA Bldg.," with Showing this map to Doorman or
> the taxi driver.(Note : The taxi driver will be not able to speak
> English.)
>    * It will take about 15 minutes.
> 
> % CAUTION %: Since this meeting will be held from 6/11 in JAPAN TIME,
> you will have to depart for Tokyo (Narita) on 6/9 morning in USA Time.
> There is a 16-hours time different between Japan and USA (the West
> Cost).
>     
> 
>      
> 
> Thank you,
> Yasushi Nagao,
> Microsoft Japan,
> 
> 


begin 600 microsof.html
M/"%$3T-465!%($A434P@4%5"3$E#("(M+R])151&+R]$5$0@2%1-3"\O14XB
M/@T*/&AT;6P^#0H-"CQH96%D/@T*/&UE=&$@:'1T<"UE<75I=CTB0V]N=&5N
M="U4>7!E(@T*8V]N=&5N=#TB=&5X="]H=&UL.R!C:&%R<V5T/6ES;RTX.#4Y
M+3$B/@T*/&UE=&$@;F%M93TB1T5.15)!5$]2(B!C;VYT96YT/2)-:6-R;W-O
M9G0@1G)O;G1086=E(#(N,"(^#0H\=&ET;&4^36EC<F]S;V9T/"]T:71L93X-
M"CPO:&5A9#X-"@T*/&)O9'D@8F=C;VQO<CTB(T9&1D9&1B(^#0H-"CQP/CQF
M;VYT('-I>F4](C,B(&9A8V4](C\_(#\_(CX\:6UG('-R8STB26UA9V4W-"YG
M:68B('=I9'1H/2(R-30B#0IH96EG:'0](C@Q(CX\+V9O;G0^/"]P/@T*#0H\
M8FQO8VMQ=6]T93X-"B`@("`\8FQO8VMQ=6]T93X-"B`@("`@("`@/&)L;V-K
M<75O=&4^#0H@("`@("`@("`@("`\8FQO8VMQ=6]T93X-"B`@("`@("`@("`@
M("`@("`\8FQO8VMQ=6]T93X-"B`@("`@("`@("`@("`@("`@("`@/&)L;V-K
M<75O=&4^#0H@("`@("`@("`@("`@("`@("`@("`@("`\8FQO8VMQ=6]T93X-
M"B`@("`@("`@("`@("`@("`@("`@("`@("`@("`\8FQO8VMQ=6]T93X-"B`@
M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@/'`^/&9O;G0@<VEZ93TB
M-B(@9F%C93TB07)I86PB/CQB/CQI/CQU/DUI8W)O<V]F=`T*("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@("!#;RXL($QT9"X@/"]U/CPO:3X\+V(^
M/"]F;VYT/CPO<#X-"B`@("`@("`@("`@("`@("`@("`@("`@("`@("`\+V)L
M;V-K<75O=&4^#0H@("`@("`@("`@("`@("`@("`@("`@("`\+V)L;V-K<75O
M=&4^#0H@("`@("`@("`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@
M("`@("`@("`@("`\+V)L;V-K<75O=&4^#0H@("`@("`@("`@("`\+V)L;V-K
M<75O=&4^#0H@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`\+V)L;V-K<75O
M=&4^#0H\+V)L;V-K<75O=&4^#0H-"CQB;&]C:W%U;W1E/@T*("`@(#QB;&]C
M:W%U;W1E/@T*("`@("`@("`\8FQO8VMQ=6]T93X-"B`@("`@("`@("`@(#QB
M;&]C:W%U;W1E/@T*("`@("`@("`@("`@("`@(#QB;&]C:W%U;W1E/@T*("`@
M("`@("`@("`@("`@("`@("`\8FQO8VMQ=6]T93X-"B`@("`@("`@("`@("`@
M("`@("`@("`@(#QB;&]C:W%U;W1E/@T*("`@("`@("`@("`@("`@("`@("`@
M("`@("`@(#QB;&]C:W%U;W1E/@T*("`@("`@("`@("`@("`@("`@("`@("`@
M("`@("`@("`\<#X\9F]N="!S:7IE/2(S(B!F86-E/2)!<FEA;"(^4V%S87IU
M:V$-"B`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@3D$@0FQD9RXL
M/"]F;VYT/CPO<#X-"B`@("`@("`@("`@("`@("`@("`@("`@("`@("`\+V)L
M;V-K<75O=&4^#0H@("`@("`@("`@("`@("`@("`@("`@("`\+V)L;V-K<75O
M=&4^#0H@("`@("`@("`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@
M("`@("`@("`@("`\+V)L;V-K<75O=&4^#0H@("`@("`@("`@("`\+V)L;V-K
M<75O=&4^#0H@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`\+V)L;V-K<75O
M=&4^#0H@("`@/&)L;V-K<75O=&4^#0H@("`@("`@(#QB;&]C:W%U;W1E/@T*
M("`@("`@("`@("`@/&)L;V-K<75O=&4^#0H@("`@("`@("`@("`@("`@/&)L
M;V-K<75O=&4^#0H@("`@("`@("`@("`@("`@("`@(#QB;&]C:W%U;W1E/@T*
M("`@("`@("`@("`@("`@("`@("`@("`@/&)L;V-K<75O=&4^#0H@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@/&)L;V-K<75O=&4^#0H@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@(#QP/CQF;VYT('-I>F4](C,B(&9A8V4]
M(D%R:6%L(CXU,"TQ+`T*("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@
M("!387-A>G5K82`Q+6-H;VUE+"!3:&EB=7EA+6MU+`T*("`@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("!4;VMY;R`Q-3$\+V9O;G0^/"]P/@T*("`@
M("`@("`@("`@("`@("`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@
M("`@("`@("`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@("`@("`@
M("`@("`@("`@/"]B;&]C:W%U;W1E/@T*("`@("`@("`@("`@("`@(#PO8FQO
M8VMQ=6]T93X-"B`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@("`@
M/"]B;&]C:W%U;W1E/@T*("`@(#PO8FQO8VMQ=6]T93X-"CPO8FQO8VMQ=6]T
M93X-"@T*/'`^/&9O;G0@9F%C93TB07)I86PB/CQB/CQU/E)A:6QR;V%D($UA
M<#PO=3X\+V(^/"]F;VYT/CPO<#X-"@T*/'`^/&9O;G0@<VEZ93TB,B(^*B`R
M-2!M:6XN(&9R;VT@5&]K>6\@4W1A+B!T;R!3:&EN:G5K=2!3=&$N('9I80T*
M2E(@0VAU;R!,:6YE+CPO9F]N=#X\+W`^#0H-"CQP/CQF;VYT('-I>F4](C(B
M/BH@,2!H;W5R(#$P(&UI;BX@9G)O;2!.87)I=&$@06ER<&]R="!T;PT*4VAI
M;FIU:W4@4W1A+B!V:6$@2E(@3F%R=&$@17AP<F5S<RX\+V9O;G0^/"]P/@T*
M#0H\<#XF;F)S<#L\+W`^#0H-"CQP/CQI;6<@<W)C/2));6%G934T+F=I9B(@
M86QI9VX](FQE9G0B(&AS<&%C93TB.2(@=VED=&@](C@W-2(-"FAE:6=H=#TB
M,S8U(CX\+W`^#0H-"CQB;&]C:W%U;W1E/@T*("`@(#QB;&]C:W%U;W1E/@T*
M("`@("`@("`\8FQO8VMQ=6]T93X-"B`@("`@("`@("`@(#QB;&]C:W%U;W1E
M/@T*("`@("`@("`@("`@("`@(#QB;&]C:W%U;W1E/@T*("`@("`@("`@("`@
M("`@("`@("`\8FQO8VMQ=6]T93X-"B`@("`@("`@("`@("`@("`@("`@("`@
M(#QB;&]C:W%U;W1E/@T*("`@("`@("`@("`@("`@("`@("`@("`@("`@(#QB
M;&]C:W%U;W1E/@T*("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`\
M8FQO8VMQ=6]T93X-"B`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@
M("`@(#QB;&]C:W%U;W1E/@T*("`@("`@("`@("`@("`@("`@("`@("`@("`@
M("`@("`@("`@("`@(#QP/B9N8G-P.SPO<#X-"B`@("`@("`@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@/"]B;&]C:W%U;W1E/@T*("`@("`@("`@
M("`@("`@("`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@("`@("`@
M("`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@("`@("`@("`@("`@
M("`@/"]B;&]C:W%U;W1E/@T*("`@("`@("`@("`@("`@(#PO8FQO8VMQ=6]T
M93X-"B`@("`@("`@("`@(#PO8FQO8VMQ=6]T93X-"B`@("`@("`@/"]B;&]C
M:W%U;W1E/@T*("`@(#PO8FQO8VMQ=6]T93X-"CPO8FQO8VMQ=6]T93X-"@T*
M/'`@86QI9VX](G)I9VAT(CXF;F)S<#L\+W`^#0H-"CQP/B9N8G-P.SPO<#X-
M"@T*/'`^)FYB<W`[/"]P/@T*#0H\<#XF;F)S<#L\+W`^#0H-"CQP/B9N8G-P
M.SPO<#X-"@T*/'`^)FYB<W`[/"]P/@T*#0H\<#XF;F)S<#L\+W`^#0H-"CQP
M/B9N8G-P.SPO<#X-"@T*/'`^)FYB<W`[/"]P/@T*#0H\<#X\9F]N="!F86-E
M/2)!<FEA;"(^/&(^/'4^4F]A9"!-87`\+W4^/"]B/CPO9F]N=#X\+W`^#0H-
M"CQP/CQF;VYT(&9A8V4](D%R:6%L(CX\8CX\:6UG('-R8STB;6EC<F]S,2YG
M:68B('=I9'1H/2(X-C8B#0IH96EG:'0](C,P,R(^/"]B/CPO9F]N=#X\+W`^
M#0H-"CQP/B9N8G-P.SPO<#X-"@T*/'`^/&9O;G0@9F%C93TB07)I86PB/CQB
M/CQU/D%R96$@36%P/"]U/CPO8CX\+V9O;G0^/"]P/@T*#0H\<#X\9F]N="!F
M86-E/2)!<FEA;"(^/&(^/'4^/"]U/CPO8CX\+V9O;G0^)FYB<W`[/"]P/@T*
M#0H\<#X\:6UG('-R8STB26UA9V4W,RYG:68B(&%L:6=N/2)L969T(B!H<W!A
M8V4](CDB('=I9'1H/2(Y.3,B#0IH96EG:'0](C8V.2(^/"]P/@T*#0H\<#XF
M;F)S<#L\+W`^#0H-"CQP/B9N8G-P.SPO<#X-"@T*/'`^)FYB<W`[/"]P/@T*
M#0H\<#XF;F)S<#L\+W`^#0H-"CQP/B9N8G-P.SPO<#X-"@T*/'`^)FYB<W`[
M/"]P/@T*#0H\<#XF;F)S<#L\+W`^#0H-"CQP/B9N8G-P.SPO<#X-"@T*/'`^
M)FYB<W`[/"]P/@T*#0H\<#XF;F)S<#L\+W`^#0H-"CQP/B9N8G-P.SPO<#X-
M"@T*/'`^)FYB<W`[/"]P/@T*#0H\<#XF;F)S<#L\+W`^#0H-"CQP/B9N8G-P
M.SPO<#X-"@T*/'`^)FYB<W`[/"]P/@T*#0H\<#XF;F)S<#L\+W`^#0H-"CQP
M/B9N8G-P.SPO<#X-"@T*/'`^)FYB<W`[/"]P/@T*/"]B;V1Y/@T*/"]H=&UL
#/@T*
`
end


begin 600 micros1.gif
M1TE&.#=AL`+F`/<`````````50``J@``_P`D```D50`DJ@`D_P!)``!)50!)
MJ@!)_P!M``!M50!MJ@!M_P"2``"250"2J@"2_P"V``"V50"VJ@"V_P#;``#;
M50#;J@#;_P#_``#_50#_J@#__R0``"0`520`JB0`_R0D`"0D520DJB0D_R1)
M`"1)521)JB1)_R1M`"1M521MJB1M_R22`"225222JB22_R2V`"2V522VJB2V
M_R3;`"3;523;JB3;_R3_`"3_523_JB3__TD``$D`54D`JDD`_TDD`$DD54DD
MJDDD_TE)`$E)54E)JDE)_TEM`$EM54EMJDEM_TF2`$F254F2JDF2_TFV`$FV
M54FVJDFV_TG;`$G;54G;JDG;_TG_`$G_54G_JDG__VT``&T`56T`JFT`_VTD
M`&TD56TDJFTD_VU)`&U)56U)JFU)_VUM`&UM56UMJFUM_VV2`&V256V2JFV2
M_VVV`&VV56VVJFVV_VW;`&W;56W;JFW;_VW_`&W_56W_JFW__Y(``)(`59(`
MJI(`_Y(D`)(D59(DJI(D_Y))`)))59))JI))_Y)M`))M59)MJI)M_Y*2`)*2
M59*2JI*2_Y*V`)*V59*VJI*V_Y+;`)+;59+;JI+;_Y+_`)+_59+_JI+__[8`
M`+8`5;8`JK8`_[8D`+8D5;8DJK8D_[9)`+9)5;9)JK9)_[9M`+9M5;9MJK9M
M_[:2`+:25;:2JK:2_[:V`+:V5;:VJK:V_[;;`+;;5;;;JK;;_[;_`+;_5;;_
MJK;__]L``-L`5=L`JML`_]LD`-LD5=LDJMLD_]M)`-M)5=M)JMM)_]MM`-MM
M5=MMJMMM_]N2`-N25=N2JMN2_]NV`-NV5=NVJMNV_]O;`-O;5=O;JMO;_]O_
M`-O_5=O_JMO___\``/\`5?\`JO\`__\D`/\D5?\DJO\D__])`/])5?])JO])
M__]M`/]M5?]MJO]M__^2`/^25?^2JO^2__^V`/^V5?^VJO^V___;`/_;5?_;
MJO_;____`/__5?__JO___R'Y!```````+`````"P`N8`0`C_`/\)'$BPH,&#
M"!,J7,BPH<."VQXJC!A1HL6+&#-J?%AQ(\&.'D.*'$FRI$F+($=63'FRI<N7
M,&/*;`D```F;-6_BW*FS9TX2-_^QG$FTZ,&:2),J34IBI=&G4*-"W:9SJ=6K
M.6M^E,JUZ\NA%+T:15K"Y\VS.-'J+)%4K%N5!'\"!6IS[ER<_[0E!+O0J=")
M?Q&F'/JV),B.AY^"E&NWL>/&;(,>)`Q1H-ZM`K=1O@C2UN3,E2\/W(P9].B,
M837ZC6BK:EO3E1M6%%W:XF72L@7:C!R`1._?OH/_3KL3`&S<A9,;!,"6;0#F
M`)Y+CXYT(.V(QB&2R*N;^S_CV;&#_\[^_:_-@<8U?]?6-#``\=P!>(Y)/N[?
M;=GURM\N-'_Y_Q6]UYUNV0G8GV[(E723<S5-YR!UTS%E(&WH!9;:>0'^5R%^
MHQFGWWV9M1>8A>65<)N(]HFGF8CI<?B/+>`-)6!XY5WV'GRG%0B;13XIY=I1
M!F&G%4O;.77A/VB--R2!T!54'V??(>7:50O:U%MQ.RJG94,^UI7676SIE:!&
MMUDVD(B4`7`9A5NV25-5=*E%W%F1U536DV[FJ6>0[8EYIE8*)87$9;:8.!YZ
MYQW*Y'O\H>3DG6<])F=5=7JXYZ6C]<26E$D]A].842466T%E>C5;EH*QN656
MGDY*7$[/H?^%YXB8UFJK1Z"ZU"!T#S['8&]URHKJK<GYV!QS="&[Z9X5M:94
M";F*A9^$Q&(7F7#1^9:MKW(J!5I$JA(K[K@`*G<JN>A^=6FT?IW4KD31FBM2
MO.FB5F.]+M';$G8D;(K5O][B*ZUN4P*LU75NG1H1"?.)UJYZ:GKGDEX?AJ7>
M:B\VBFE*!@,,IZ4"PQ1NR!?-2O+)**<L%0DC`\F:4"VK+#-))L^\4,<XYZPS
MISM3V?//0`<M]-!9"5TPT4&CY:^L1AM\]+]/\RRU54PC;?52KD7=<=57=^WU
MSRP/:W.U`A5*%Z21SGEEM^F-;1A$`?9XK9=IQ[9F8KDB5I[6;87_UW9N]27(
M84=^)F0@B&N2)Z;#IE%EG9D)2QFIG,<V1^=K;F<^$\:G'0>BQ9^'#OKH"+WJ
MKY7!H7XE4Z6&_NV(H+^N=VJNUQZ[[2#*?AKA+Y[6QG:_1_)/&TFT,7SQP[O1
MQC;*)_%/$DFXL4T;Q/_C!O*_&T^\]MAWS[WSHFD#[J$4HT<7Q0%_]VZ0_N1E
MLMZZ'Z2-@$;2:M_NN?N'U5E4^34?[)T#H.Y(Y[GOW.E8ON(4T\!TD_&9:7:B
M0UP$24?!!T*N<9@1E08S.!I]I4P;U`,>$KYW/!)23WO5.^'P4DB]%3I/A=1[
M80MC6$+FV8DXQ_)2T7*(%!/.$'HK]*$0_X\GPR$2KXA$#&(280A$)B+QB$JD
MX?9<2$4I$L^&<R+.ZJJ"O11V\8E>1.$+OUC"YQ5O&]'3'@",EY;BM0&$2:D>
M4,181BA.T8XS#&,5J0>`)$2B:$R!GO&@9YSM30]Y2=`9&>_8Q.Z-T8@LI.,=
M]6A%XS5/B==[9!4=&<5([E&2B\QC$:<GB>TXSXW_&.$@6ZC*Y['RAZODGO%:
M"3WG:<XA;C!C+%VIR>+U4H^^+&,PISA,1(:1E,Z31/0.:<DS7J^9LOR',I.)
M2&/^\IK"!*8VL4G,;6:3FT"LY3>M9\T:2G&9Q,OE,YF'O$S64'FY%&<W>]G(
M58[QE&V01!];F/_(XAQ-E\]3GAG!:4]AUI.7=:SEJW1"R20`KWK*W.4\QSG1
MBI;3H@6=Z#-="4V$;K28@SPH2!&*49)>]*1OI.$PJ[=2?,K0I51LJ2LC\3\/
MGHQZTCOG\BHYO6/R5*<`):;WLMD&6[0A*W'ZTJMT&$=-,C*:W0SI*B7QR9Z.
M\J>1M&H0M7I"KE+/J[D\9TY]JKQM*%,2^'%5M]#2U4BP](=)F)Y23BF)G;(P
MKGS\F21L45<4VE6&8WVD5_^Z596V(;#FO*(RP7956'+UC%A%XDKM"M6A/K6&
M;NRI+!^;T^N1<WF2*$%8'1M#$+Z5CJC4Z6/_:M;HQ>R6L!7,/R(Q6,U8'B^L
M#H7558*EK;+X!*9,7%YJ8RL;IJP-AP%C"72*L[^:O6U4Z]L1_.`5)/M!$(,!
MO&X``2,^6H4%D:%-XD;364*>^*AJ2;U)(F^2TC:4(*9G!")Q/U,XT/^]=KXR
M\2,SOP.4394%4KLJSI7J)#S\AJ0B_?(G=8)5@F6YKE!0J\[F[*,C]X#H/>19
M"8K^\S<7A4A]Y7*25BI<H?)TA#\T6IAI"I2A`95X1!$33/-:RT9/0>=7P6&0
M>=-B$LUXL'Z>N]UV!4<BAG1,*`XT<%26FZQMW25M/6*8DD>2E`;3+<#)LM^4
MS86$\=FT)'VTT^3,>S9DX<3!)SE<V=I&HQ<OIS[@T0VTS#,@D($8SKIIGYC^
M)F+F<O%_6^;*F:^\*QTCU<:!]DB5FCSF]#'DRZB!=*+G)90>26A3VG*-C6N2
M9&*U#TCWG?3)`K2I5M5%+?T2SED\M1))PY;_*CL!CHWO!!V=P*V!HPHR8+3<
MN`J'6M0QX==N$ARL.5WKR3?:+K"7C:E3#V=J@+Q<X)B]ER@M-,$W7(N8FM*H
M]A@HPU%:\;<ZS!X<#:@U+N8UM8MRNJ(!ASI*B1!;UDUO6Y$E)V4!3K&+G1-U
MTSM`V6:*6L%=[RF+2=B,YDE_%TZ<?A;\X7IBFVN.525:\P_B1QGTG:1SDP3J
M1%08-_!R&ZRMG"4UY"@?&'\QG:VD`K+*-4G"KY<MM;L0&B\IS[G.=UZ8CO!*
M)QS'26_B)"M;*YO9E[E%/W>6!$#S/%1E*U+9!M1=B8$$80,!],+4\[KEG,Z6
M@PDRN/]FH\YYN8"P_S&0JY_.ZV;![2_S>5=GWIX[TQ3.WT7&+MJS#CFN@ROL
M8>]@7M:^:_Q5-TB>H1U!Q$>[6Y@=R85O2/D>EVNV2\0_*LH,HSHT&Q(?:'YT
MYKN32I=Y@30%SP<Z%-?K_!^]].F"C]NPY>V5*1?Y!_+6UE!W\+,8&`-*[4@:
M-Z"J[B&.I5M][Z7(>W7O/G%K*#^6@L_J36P4%GTX?YQ.3WU$4YTG:;^#*%)N
M3<J.(P[=AL0?<N[LU\]^]ELLKOGJ,G<(W_[ZV__^1J'-Y/;?F#G9O"9.]W3@
MLG1+Q35WAW?XMS%"@030EC4O9UXSEX"S]RS-56J2@Q3TMV5K-2EJ`7L2B/\O
M:75JJ.9_Z844MH2`']ACF1&`,T-Q-Z8L3)94"603+)ASHN$OI_,KNC4K"(89
MC4(1A2,@?M(Z$X1[=U=?@X>"&Z%BK[-\?Z$7<2=[*]$^9W<:B<<?'9%X2)*!
M'!0E-C8<E0-OL:)O@/(/5/AFU=&#\\<=X6,94KAXEC$_EA8CWN$9V[$4)]@H
MY;,=-56&FB<05`5BSH=[E.$9Z1&!B')DEM%IDR=;O0,Y@%93CT:$(G%##[AJ
M#3)F5<&%!J8-U\);<W%<VT<0&F,9Y/&#Y4$>VZ<C8>%YH&=B&,)GSL.)'[(<
MIC@B[Y4?A1,V,69Z\`&%SD,>AO@AB.@1=;$T?I9Y12^G91ZV$JR('MOP7EK(
M8E0G/E)'9ZF1&EAH'(8X&'["(<;A>*;WBGM&&&T69TS('7TR+3%7%U"R75TR
M*VW6>E2W(8_CC%67BI#S;2Y6>AD!8)IX@26'5./7?JUA:IL&2/.FA)36B"US
M<`SY@<ME9J<V:)F&;561@O_RTA=0,EV?01C%F!GZ@2W3L7'4L2"JMEP167!R
MB#;`HC0[<2DWQS-KR(D=.3].4RMH8R40\C$#"4@0*38:>2OL48/H8I.!-GT*
M$9)<P3@KJ7)Q5R^N]FGTQA[YN&6T]C5-(R%"PX!:^95@>35SHS-\$Y9F699F
MB34PEY9AV6Y$XY9L&9=?`X=3AI1+Z#-:TRWMUS-OJ'+W(C^"MQV4^!*B$3:W
MP3G=L29YPC$*!&T+19,09Y>UHGY#69FC=GQ[`1]1:9EN0IF<R25<,W!8L7[3
MXH#*B',<^909A&"+P5P2EF'<2'D'X1E623OU$QXQTV(@B21.QQ*M^&C8Q3F(
MB1'_N\$3'B=@4E(IGOF9`EAE_95M5[(VD'(ZBK=LVV`+'5%7^#1(GG58VN-9
M:90\IP0]VE`\[Y59@;<-3GEXKT@JR0@HFI$>5)DJIK<[I$$A\@$S=6<0\_,R
MWS(^JJ@4;+(D1@D5O,%R%8<LS[F64L:<XC*$3PB$UB&ABZB?%:J>$VJA28BA
M>Y>52Y467_@3..$/%$.A&QH^)MI=''JB&;JB*HJB&OJB+0JC+DJA_LFAZAD1
MXK12TA,)==538556OJ15),!/GB1/U%.>+-4]34&`!$DE*:*A4>=]<$>7$M.&
M?:>8+<:&"F&(CR.)3&*:Q>%@*WJELHFE5YJBY\*AR6F)_SJ$:6@C*QCJGS)Z
MH31ZIS.:IQ5*/+8@2+P$0M8$J/;$3&A$/(+ZIU`DE+%53"\54W>U1XUJ6(TJ
M4\&46<33CLSA7[EE<9O*15IA1<#U5I/ZJ)1*JJ8ZJJCJJ*D*JB3E23_53_UD
M<9#23ZDVJ0)E6)(D2ITD66]E'$E05VH9<R_41ZT*4]'#J]M)4MT92=J@/,:!
MEJ?41X=T3[K44U1%2#DA/#*%JPB%2I4JJI!:K+N:/!E5/9<4GI44KJS*JMOZ
MJ*"Z#6ZE/=FD3L9$KQ+UJRM$K]K:0I<$;);:15`%2PE567Y51LIC2;K*1+GD
M6PK),TTFG3;A3I,4L-%TL'4DL/\6.[$72[$;V[$:.TE@5+'\6DVYM6--=F9!
M<4DPE$<(NUG!A4EG]$=XA3R5DBQ`1`)GI)V#93TL^UF?Q+,%F[&0Y4Q'U4-H
M)"70LU_$8TINM4FYVK(&"[!`BTFN*K`?.U1""[7C9:[\ZEA9.[53]+4ONU%D
M.U3H6JBXM:_<<ZV'=3QLNU/XFEIQ6SVU86!\L2^N=*WA=%$M5`*(1)!J,1RM
M4C#K-9XA]4(")4^):Z1Q%8B'5WG#<K>0&Y&2>Q0]L3JQPF]X,GT3J9;SMGKQ
M`A;1U78<\1F/.[FX8KJIB7L#<4J)VT2+B[@9Y:QK*73&66L7F$_[]:N@5:0(
M-4UHY%G_0^:@*,,2KKM+Q>,&V_*D=M$J_W46#F>IRB1-HUN7<5$I#'MO%*DJ
ML*8S3D@4YUA=\$,1W9@9O`,:3A>^4[>"$;HC3P(_:N:ER59MBM=[?^%9)`">
M3718B020V0*BI^DO3>>=5"&\#[-E/B<EHC>4A#,;_5LEJR,Y"1DK^(9RXJ><
M__68THHJ2NE=$B,3\;F^[:D^^B$>\^%YP8=&<9%A*OR(H(<C.*DA4@>?_.AB
M+QPD,U)?IQAWM5BZK$$IRB@GQZ4I).$LG=N@'BF2N'L_#J2'158D2*BC(T*;
MCS>@3N-H&BDA*+E%1+<6&?ET=<$M$B)K&$B\Z&*R3M:3/-D@M[1&$_DC,4WA
MP!<3>GP69\Q78;?''S?A>AE2/N]K(U)2O0ZZ7FZ*.KMB8P4S9Y*9,NSH@#5K
M<WU1G<$FR&8<)6&H<).BG(F2+HM<R3XL9TH%=)!1:[ZE$T@8<@Y+P3O1;B[F
M(<]8BGY8(QG2(N;+A[<('P`PGYX\'A8'P%*2D&ES,$>WRRAW&TL7=$]3,#IQ
M@BG7R`1I.58!>5?7=]@%:%25&(W($@UCAK3#E*2I)*N6.JDFG65VG/_$C']R
M\;_Y)LXO:&7GLW/]J\[^5,I&I\OG["8PXC&=DD7^=<_UE\\`ID!#_*0VT<DH
MH[EAC!2FMIS^_!;,0<@!/=#^=!<-O9<CYW)8]J99D82J25P50:M#9VHPJ1.;
M6=$F?=*98]`H77`8:L=QX7,Q3"`OYA]2]KU^0RN;^WSQ(21_P1\P8G;YV3_4
M=R`X8F<`^L&5+'V8&3M.X70L>)VR2;ZPH84OO1Q<)XY%1A$4`79*G,)9HM5"
MH87I6[?N@B`=YM.C,1_H5J9S2BH<+4#_((ZZ>3_S&'A;T5TC7)DE+9+27!OY
M"*;FZ]8.D8WKJY]W-VTIT88.M,W8B=,F#7S_(.8BUGB'.8(@%'8?G';']+B0
M58>*/\U]T$A]^.%ZQ%=`S[@A+C+'+V(H,*$WR0;5!8T=SHB.E;9[!.)AB:DA
M\'<8K"W;NM%=$T)]O:B*M;W2QGW<R)W<RKW<U68:3CHT'<QV#QB/$L;<4$<@
M:*F(UDUSC%&"0<Q<]]?=DG(72;S=,R'>XYW>!6G>D]8:'P.X10.3.5&@.Z?0
M$'+?$3*/["TRWF&[8GC(^'W?U:W2^]TF-^8<)*EJSY8LDF%Y(#&"'%B<5EK@
M]!'*$>X8P];@!3X^=W.5,T-F(KI`@R:B;"=^#HA>-/C!H^LPI-'`E4$90!9Y
MP?:1]W$=@'<:$&FB_VM(U3.>=6[J*9H,;T)N@G3G9>L#UK'1FZ!1/GZ7$/^C
MF$&B-WB-*DZ)&%AJFWP-G!T-F$*Q=*@;,ESYWDG%<CDT>Q?"+8*;8R]X=/(H
MV+09Q[G679\6E5->9&+M@2_1Y@3Q:=N&U%DHV!<48]V,YS"1%7-3<:FV:,FR
M+&RB8C<Z(T(QG]O<WR/2B`+Q:7@":-MH'E57=H+8'74L<TQL'M&X&&P=*"%6
MNCD2-8!^+I.QV('=:5W'$!Z.$1KF7^W,*TPV->L)QG3#-D7#S*,'$7;V(GCA
M'X#,BCU8)J]98O_3).KRZ6>"U,=>(;21U^_!'E/'>RN<'K(W$YBV:,VU8/_%
MP1(#VN!C%]F67<,!0CO1)WCB<8W89B=!2.HNAH7,5]7EEA<GF)^#EQ\JHNV$
MGA!P4I:=(_!KR)%"'1\EAAP_O79V&-_79CH+Y<&^#F\(6H*H,FWMF>TR?8@3
M`A0E%L..`\@5PF8OPB\@K#A_F!=\:"TFUC\(9H>1CB0W_?'NX2%S]A3.F8EV
M86;!H2E&%]54>GS@D3@ZXND:XHR`F6+-][XP,SY-(1J>(7\G9H[$7B0ZZNF\
MLW6VOKZE624Q:8O#OM/[N.2OHV9J8F<HOQZC#B6P,B4.>%R77']*=4`"[B\3
MAF!V4H<IT:>"^7=)'27B+N"9J$"GD]PL7EUC/^P]/A?6"\/DK@>)L*@-?IS"
MC7V*Z59*M&=Z<;_.P(*[$2PG[<>."F87+`?"!''-S2V;BLK`L2J0&0ZB'U,6
MWO^\W-6[=F'WC7N'&D%^XJ&L%$]N>2-GR+LB]FIF+D7#@%I3=02>$#B),QK>
MF3[1*IOV;O_[(V1-X1R\$;6.$(-I&.SQ)1#.<25)R@R-<1(?].0?RWD"-6$=
M&+=/$D&X/Z^?'(HNSJFF<`K=9`"Q[=]`@0,-'D284.%"A@T=/H084>)$BA4M
M7ORG#>-&AP``!/CXD01(D!Y)`#A)(B5*CRA)%.084^9,F21*G`10HF7(G#Q/
MVJ(9M*%)@S"%'C4(]"8`I$T5XO18$NI.G`%45CV9Q*A3KET3:ORWU>O8B]N8
MAB6;5NU:MFW='H0)%.W;C0+%TL6;5Z]$IMO\[=5+@B#_VKL5[1)&?+AP4;!C
M"QY&'!GRY+F4'R?&K#CS9LV7*S?T;/%QX\5J*4<LJ'';Y<Z8YRZTN_HU:(.-
M:;(>C%ORY]!%9\O<VOJT8]]'/?<V"Q?P<L`M<::\RG)G2YTZ6S+';E$Z=)4L
M5YY$DC&[PB2N%6H$L,UV4ULDM,%L/5";MO+C^7IGJ?.D?JO35[*T+T`!V8)I
M/;IRZFZZDO)#":2I<!IPP,;HFZY""\_*"+*\&@,`+`-K*R@]V4J3"2R!^K+-
M'[F,DB0]@E2+\)_V+KQPI)$L%.S#&,G22,<=A:(Q2"&')+)((X]$,DDEEV0R
MR:F.U*])*8-\<DBHGJMR2JI,_TH0@"2>?,ZC)*33LDPSD[3N3#775/(D^'YL
M"D,XYZ2S3CLY2NX]AT),+;<[_\1.3D!E$G100P]%U+X^"T4(QHQ>^BU12<EB
M=-)$>ZK.N_Z^P^^_O@:S-"V/,K6J5)LP/:DVITA#*#F%3,KI(*;`.HM$^;9Q
MCZ$.!_H+HD^'6I$V7.7R,2^J;K+I*DY7L@ZJ4(.2[=E$3\0O2AM-[>G:*VV5
M=J;58/WO03(U-.XKIK+<22>-!#/(Q5870J^W\S[UL2"@*LW-7=H>Y=8M7-/<
MB21,!TYITR2*[39AA97[IR<R%R03UBU)('9ABVQ[4Z`V)&ECFS;<:.,?D-WP
MF&.1)?\IX9\VVBCORY#ER_"]T1AVB-;*MO//H[!.C`BH$^6:2*ZS3-Q3L.,\
M_(==@LR2TQ:8:MUYKW0;A([,[YKMSV*M+7Y3/I4R=:F[E);2[U0$\=V:(=NT
M6;D-ME?^)XDD.HYD;H_MKIONNO]!.62Y.V89\"0BL25O<GT5+\.!MC1)IQ`/
M\E%/7!DJ#4:P)"E/((3#TJ8$5AG&<#I96](FU^5P?IC3"O?3.6W7;XLTX\K^
MTAPMRPWJ-?%_<O^P,5O29#VD4K>4RF%]_2RP.-V3A[EYW2=4E=?H=Y^>=]RK
MGUY/[2-9V6.6MY';#97A;MMCD,>7A#[,;0&YO,!5GGO\D-W_2$+\N4-FN66Y
MX1?/KEUE-,A4HM:PZ[BK:\Y;W$!\]JZO*.\@<K&%G-2S&/4H+6H:^M^,)'8=
M@9AN@J!Z7O9$Z+P#:BXG8\I4=7"2PF2=K3O-J]T(^\<9VV$&1H=QE/9JA\,:
M[G"&MXNA>'KTNHALK&VV..+*"*=$)+9AB2MKHB2:^$0I)G%C36Q#%+&HQ;8U
MCDN=.E75EN*=^R%Q<%M<616AF$8T7G%E;N#B&MTH1S5FD8U6K&,<[3C'/58Q
M?H8;&?A8!K](P`]P+`-;=ZQ%G9[0)PF2@)_X6%;(]P4.?/&[WR7=AS+XE0=D
MZ<ODQUI6@C9X"0EN8YD4PR0)P@$@_Q(I6YE@RLA$/*+QD4W42A?OIPVJ2$(P
M:?3>+U42-[A)`@DM,YYWGI.R3/Y-?G&$XQT_!DT]3A&7=\OE'*OH!C5V$XG<
M-"/)G#G+.4;SEE9\8A_;F$=I9A%S<VL9^>!V/_D1$W_SE&<\[WFPD&U.:_'4
MG]\&V092$M.3];-G)!/*,OL-%*'P-.1"X]>3,8U*.E@[27\L*B9,DJ^C[OMH
M1"'ZOI$^U*$-Q9])0=K0E1I4H25EJ4@]*M"4^NU\]`L92RH:MHVZQ",DG6G<
MSO>^4Z84I3+%'PD@2<I#OJ24%?H23N)7RH`*U:@2%6A+Z8G3A9929<X)TE?3
M]SX`.-1M<S8;&+B<6529@C2K;84K4`]*4Z36E7Y'Y2H]Y5I7H-84JW_5ZSSO
MY[Y!CK2P`STL80$Z/H#:`I+_1%0(YCKV-^]U#&3X`YGY:.H]?7+6GI7];-L^
MVSZ1[2]_Q)0BYAHJ1:ZF\6V@S.S','O(>UI6GK25'VC+)]K='A:WH<3G;[LG
M6N!N=F6$/:3[8NM0D+:,F[?(:R3<P+:.VE:YR26F^"Y;3]YV;[O'C=N7[M8B
MGT9LLF45)&UUZ]W"+K>VVR#M;L\'3Z8!#*I^>Z27[&;)E<&2?O\H`<<$"<FY
M:1>QN.WM>[LK7,#-=[BWA2^$20M<Y'+7O;GE;6;CNUSD>K:W`?7L.\>G7=/"
MC7Z>-+'=),NW^(V,?R"$;/F:R<WLFJ^0H8P$@=T@21K7CV0?T_&/>[QC\Q'X
M8^`S_]F"M\$Q]7*OP1U[)V@+/&"ABK/'1WYDD)&LY2Q7><M>!C*8ARQD+8?9
MQT4&LR1TW.`U4[E^D^W>(VFK#2=7=LG#-9F<W4SDC45"D.+,<VRO3#(W`,"7
M)%CNA4I@7R\!^)%Q4[-5OUQ@]'FY?D8F<XWE#.`VH*NL)AVKW+PGB5&G][5_
M9IL;_#QE,Q.YRV=^M:LC?>:-&1EPL^;SH-%,Z3Y+NM5PYO*8P9?C&G_LQKDN
ML[`?V;(\F[BPW!/9L_?Y6>XM%KSQZ]?"!%=;QK*8VR(6;=[J*>YP3Q5NY#[W
MX(1ZM@TF*$W`^R(SOU?)<]_V'^@.&;[O;>Y\F[L\^@8XO__WS>V`5WC%HF5R
MMU?\)?P8;XQ3*3&WRZW8@2O<W_<N:W@AN3*'=>R;#4LQ@?<;<6^/6^!.-CG!
M12W:0B>A!'+S,T%URL^IBO?@Q;SXS?NM<IZGW.04!W>ZOWURDM^\/#J_M[T#
MWO-RJWSC?TNI6SL9T1-3W:S1;BX2$0A9V"@DVQH2B+^16%#ZTMM]!24!RS)J
M(P4M:SL+PF9$P6OVJ;_<K4N.'W"\OO>$9+OK'4'=5#1J'3_UW=/7B51,_.Y`
MQL/X8FE9_%RTP5522KVD$K_X4VN$(\:A!(LEFZR`F2K(4>[3C%IQ?..YKBBN
M'`XR3@QO2D6>4J`$[G=A2M9W-H7_+>^\W*-/EWWL2TOJ-`Y0<0Q,_')(9)2H
ML%V%8G.0F$#X-+!:2/-"B3S?65^NO<,D?-Q]-$/A!WR1>7&#[Z::<ZRS:+GI
MLYX0#6SJD[\O^:\^;?#1QL*':K<I,ZOM"RH>Y^L.3FH_2/.DE\N^A`F13FD)
MDOB.5%D((GF2KC"*;4""N!@(I0$:]4`(H,$0/8F,SQB($L#`I)$\2-J&>Y$\
M^6"*!3*0TBF*QP$@WXB-#NR[LY`;4BO`<?HOS>,IL2FO%<H6GS*L;+*CO$M`
M2:F=)+`%H)E!^VL*#1FGJ0(K&\&]Z+@2+SFA1GN9/8'"RM"\``3"&T&\PCN\
MJ!B5^IN)_UY!#X+H"^8#H+-P$9XQ"ZVP"TC!$)Z1%3<<()ZYA00*G7:I%:-I
M&/&0H`22$3F$G%WAI3B$'#Y4#I#:./))&D82F(S2E#"QKT&J.II1PZVAENHS
MG2\D#K20&X=Y.)8`P+,!&`@DQ8C(';-0EN%QCN@C/!`"P0QLEIVHH;48FL7A
MD!GZE()@%T%1Q-H@Q($(C\3YGX:9$*9P$4B1P5\!,$1$BT,LQ.1H1A2A&5SA
MEM4`G(8IB;)AG7)DP(IR16])O&AA1Q#9NNG[Q-`(#N4A%^@9'1IYDFAY1:[`
M$I#(E*_I$@9,QWU\B'7AB=YS&"P92.2#EZ7QBA+<C0NBQZ2@'/^&D1?\FXT@
M>A?U8!4Z[+L!<L+#4;V*K,#%:3AP4<7F6Y#]6,B9:$;=\0?X")'Y<$@Y1!JX
M4(S38!%KA+&">*Q7.1*"I,`Q::$P\8\P&D?O$,J):!PAK!8T+`&YR)VEQ`M_
M@CRB)!NVDPHL]*EW<T*:H$9O!(OV2(@_O)?6*<0]/$9#1$2H<959^45&'`C4
M<Q23M)`DI,J+6!VJN9:)`9.\?`C[`L(AK!K`Q`N\[(K-4PF!$0F?"!.D<,L1
M)(CRR,6TS)"7Z"`GA$9@W$-GC!L.R1%(61P]S,!F3`WZ,)#"T$?#!,M3T0F-
M`A>R:4R`^4C67)SNZ`_>(T.=6LW:[$W_:*%'D;3-*$P:E@P>GQI#SDL46Y@;
MH+'*X100YD/)HLR9[6`[Z$R("+(*MX,.%0*`KWQ$W7$*L5@/Q,3.AY`86U20
M3+R)F\B:D1R0U?S-\QR4V]L@D=C.16*T67E'P)0.WJ-%3XD@A$B/OL@<0<RB
M0H00]$")HMB)!:I$T8R@+5$@^@P*VTC(:LD]XZD2"!1."P51Q0N+BGK-P9R:
M9D&6I8!/JHP@9,&2AEL_16S$C.@+=SD>5_&9EY"9A@E%%VG$I[$9RPQ1V)E,
ML(J2O5RDQ<R)QYK*(752T4B(ZMM*9$$="UG1I;0H_H"5Z&.W=MG#TO$+6DD5
M;UR>ZZ"5,C3)4ASQ4@+ZSD]\4HI`"8#9SL5D.]:Y1`B9OS?54X;X"T=QCJN`
MF.+1CT%M(1"=4.O<%(74B>*XBSYQ1^1QO!&QP=J\GCWE"%Z*TP19R90,FP>I
M#TO_!=6+:$^?L!;8K)`T`=&+\HF28%5>],10!13_F8XHB9(Y]8\Q0AM8U=5&
MV:GH,(G=`TBS<0[S!,71X0YE4A9E"19BW=73F4X&@0KW)$,KS-5F;=;_=(E-
MP4<M1%/L3*;&;-4&U!EFM=;E.%*PL9(X11#P+-=F7<"JD)@4U18C;4FJE,[V
MY$YM;;0F;=<[P94F>9#Y[%==W8:EP$*(J4(P0LL#HLJ(R19M93NT'-B)I5@H
M!`JG3-2R24GK"(!%\PCR7$KI])1?)54\)=>*1=F4A1/5I`@G?$ZNB[R33=EH
MX<\$LA?&>(TA8AX]\4`1[)K):97CH<$748ZP+$1!69O(_W"4IY$7E9V4DI19
MR&(>/'':B[`>'JV=7`00??E`J`D+)&B=0(098_S(7:'&S6R7QQF-9AQ0LY#!
MR>E94&G#/+76-\%,C?`9.5$-FH09H!@B&:E`O(U!HD4+"$T<ZDO(G8FAK?!`
M$*07+[4+$T&:FYV+!4J/OXW"&HQ*$/+:_.L?1L3(\$R^XR!0[PC&)]Q(1X6+
M46Q75Y&5VM$9.8&:LV"7LYQ;1$P.S025Y#@,2('!1A0:%GQ=!C+;)P33-K1'
MUZU:V%U3W\C#`IW#M!S7M@2@`>4E"Y)1ODD94-%;+[W=-AW7WPD+WXU<L96@
M@^',M"0:1'2:IIA*?U!$@6B/]_]HP[SE406JE1:D40+*B#;T2-&$"VJLC?_1
M&3T9FO\QBR"MUM:MT'G$61&<U,%@5^,3W0>J4,+5PPV4/+!S2,[I.R;L3Y5M
M4[!X";_=7B_]E;<D4"%5X6@1#*]5FB`M6MR5D?*(WK7D3-E8E_'-QO&%#-6(
MH<YABYIMQ-`AC7/9%:5QRP(EF@XAT[15E<@T05>AXK34X=%,'!6LVBUVT@G6
M2,J-'G;MD<B]8!K$F,%]8-4+C<9%7=\8RU=UU*>YTJ`(EKXC%Y$47)@1BZGM
MW]W]'%RD2#U>08'EXD(VY`")6KY+Y$-FY$9V'9`%CI>US=))DD5VY!()R"9!
MWTNV5P=5G1+HF!XGO<\AZ4E.IHL%W$\D\5!3)LC+P%2`73^Z-<S),)MP0<Z6
MV&199N6FP!B<L67N;+B.V>5._E,73=:J24X5U=,S11<'E`Y*'6:RB"&'59+W
MU/_E:$Z;-'$0@4'864VF4`679*'2D9UC;$Y,8SYF<?X:EW@^B37G?=S09;$*
M?#58+LD*/5W`@Q37M4,62W[GAR!&-.1F?0Z8"YG@?^:Z4T5)"QD\5]W30UMG
M,2*3114BA(:\VQ3(3IE39<'7#[1H^\N/4A6)![3EEO#GA?$A<9R:XI$8`/YH
M"CQ<:'W*(Q7H"G'3=^;`5I%D.,$9C0V)UPR)B*72G>[D9?K3_+B15?9-"&X(
MHE:;$+[INIA(QZN8G'X1'DH]HZC,P:!?XK`OQ@P8ZKR:-H4(S>D7#-SCKN-@
M2.I(PCACO[7!*W;'%!S:%!P.B1CC:P;H$.(:]3M*DL[_Q!6RU%?^HN9+V!-6
M"'9=D=ZHX]+`:B],6K*HF$#6D9G!B*_4ZM83SX8!R+`QYK!F$%AIE1J$&>@Q
MW!!4CA<\#PL^W)O<:@LFW3/>F;\`"I>M:*A6:[TN2)PDH->V%`WR[(,4O-VD
MU2<]XI68YX(I&`!I(!:VQJF48:NFX+1&XXP43Z=FRE?Q1)Z1G%"^[0]B2X3H
M%;KVQ2!Q0"#<U%M$BZELV\EL7@]6%3E&;4%.FM3`0/*5WN9I1/\U8"LVR1ER
M:<ZVVT=]:B^Y2:D>7XGQ;DE!CS':2M=T(094;PL]8S0$D_3KB?@NBF2$W#LL
M(-*Q2P]B4Q@,:)2XW0P41)3X_]"9F-%G;!Y>?(X.*L-D!!\.\3QV^=>/Q>*'
M%$2#G>>3C+YUILT_%E+E>`EG,<&#>&&3?I0&)1=L[$S+E&(<]H>7(%NQ??$>
M#HM?T2!=J6^,L.\:OI#?N.M&@6_,)O*FAN^3I0X3W2#8W,W6T8P096<7@G/I
M"$E9V2G1WM^D2(\#G97'@4$'M5F">&'X9@K*A$1>QF@*E9&4(1:T]4R$P,P,
MR5X>/ML3EVQ%$A?C_-8O0CT$>@_$XQ#-=-O!@)27^`M"U.*YJ%+G(6LMUAZN
MO48HEO(BA]Q"_`LL+W1'+$3?+FM9W-;$`_;PM.R!0$$S5TT38=;#P!E_5%AS
M!,)-QO_N5]S%M1L5<W3GP4B/)E4:IBE&RV0:.5P-`/Y1SJ;=;_'>AJ%HH36.
M/+3UA@';T?P56+%?9NQUZ1U7'5W@HZ@^V11,!%EGB^J[(5J/^*UUO5W+XRD4
M;!0(2'I#7K\+:+P,:&QB+Q?>6X<)]R!&.=YI84]7^=A%+MEK@_`ET=8(?U#T
M/1$:#J^)GMA.!@'J(41#A]93IS31%7*3V1AU"E;B`+9,&A>1/"13L@7$1>]Y
MK[`@&9S1G9%TQG"189Q1#C^7VB%+Y165-A?%B!;73-UV@DB9R<#A(@9Z*LX1
M8EP;I!U>U0CW^?P9"W)&KQ7@=H%027?B]SYB"H8(2C82[;;_%:.X^LK`PZC^
M]<V^"!-QV`<Q46.>\#<ES)]ND-G$%T:YX0)"=[O<S%XQB6'!?"&5((=)#GX%
M$K_?<NLHXK`MP^N-76?7&1+XPV=&>+7(">"ITX/46&%MT,83G?=.&H.,708-
MG>E]<1IAV*_?7<J/GLE_%WA/"9J55%R7B#],T^K;*>V.TO!^0H_>"IV`Z^S%
M$.9T&KCW6NWHSFR!U_Z0TR]B2/K4E&<=S)7W"O`7WO($$:\]:=9LREI\5C&T
M>58&B&W_!@H<".`@@!((`0QL:-"A08&V'C;4]B_)1(C_"C+\9W$;B7\=)V[K
M*))B0Y,:5S8L:!!`@(4D8"8D81/`_\R<.7$B),CR)]"@0H<2+6JT*$B$.WG&
MG%ESYM&H+@E.W0C1Y;:)%C-&[>KU*]BP8`7R1*@P9P`2:9O:C&F6A,*J8N?2
MK6OW;DN?-WMJ[.B2A$6")CD*+-PP(\."MA@"".R11.&0):V2]=A5L<W,/)W*
M3$O3LT*%25PZQFOZ-%V%!T,GY,F:)VJ''P>2I&H9J[;2EF/S[NU;MMFR:I<Z
M9:M:=<C?RI<SEPUQ=LN#>3>J3)D2>D%M'7.?1%EY,LKN*F?*'>IOH,7/,(?C
M?'U0,^?6Z)O3_YWTIM.=^7N6QYM]OD-R8=5??04:N%)9K^TW7'P)XG0@A!$R
ME]%LAA$8X$DV_^F&%67361588!>RY-)9F^'DEFMJ+716?A*Z2%=K:96X5H(S
MM2&B@?$UN)!,M$DX41(\"BDD5"\B6()^KK7&F4U(OE=6AD9*_SFE5P55Y9AN
M5SGFCX45>0D@F'GA&%242@F'GU)P[<160E2Z.=1>"VZFFGQOBC0DGG;NB"<`
MAKTI$U-EO:>B4I[QM9N=B2IZGE4!9GE4EMN4QB&B7U6E)(TTL;B09\5)IRBH
M*<'U7E,\:E:=E!P)*F2'C4*H&Y\\C7D@9C'BI)]";&7:WD%).#9KJ,$R-Y6?
M0I47I:L^3?6KLET]^J1^:ZYG8HE%`BLL?4F=B)::3BYD)U9TEN7K?ZDZA"=D
MP9)UZTQNT;D7M,)]ZARV]=H+*JG<0GM3KCL%Z=2]YI:4XJHGLI;<E')IQ]FC
MX-X)6[".O<?B3MXB66UK)9(6,,<![_\9*\@ABSPRR.*2?#+**:N\,LN`CAQD
MRS''^O&3J\E\\\DSF8PSSR([M7//00L]],D;=RQ6<@U;ZE.C5BKG=*M^2MTT
MU4Y;W6R'76J=-==;>]TUV%W.=:URS*[$U4I?JQTVUT#UAR/98K*]]M='AWJU
ME0@G:W=7?O']]]%Q-R=@X(#[9[A=B2'NE7;F,KVXL%4)3B^59%O$*&\?S3JY
M@;EQ_M/GD/_$D-*BCP@`VJ'3!9U43)=NNFG%'B4[QQO&5A7FQJJ[492J7P6[
M6-JDZ[O=Q.,%0!*GDDP<ZL#_EAO-?*)]GO%X<86C-MLD42E>VK11,\@D8!0P
M]-&CG+WS897_F[Y1U5=I4+O=JIF63DLM.2_[O.V+I)KX95;DXY@&M0$*L(!4
M.^"%&@<L5)UF,A>:"@-G9YZ&8*Z"%+R@4*!UEDWY[U8>W(O;/$0I5XVPA"(\
MX>-,:$`"[@UT^2/*V^;6M@OE;B6!<1F@6".C_JD)?PZQX$"`^`\ALJ\TJR$4
MIVSEEJ#4\'D;D1CA?H68WV&0458,HE>J\T"$!29U*YR@6)K8D(-1*R%K&4X`
M6!,:)#W*?8"3U`LUXL:Q22HT.OM?I\`W)(7$\7:C:A(/-Z.9.=[%;W+<C21.
MHA7>(`LE;?3120SSN@/!2F<9,U&2,JF:%O81AH3$UB3!>,4A"H1Z^].IT)?L
M1Q-.Z>N/=(*(&+LRREEB<8BUI*4M<XG+7=ZRE[KTI1@E!:\D%@P`;;#%)$=Y
ME]RYA'248YTM?"6FS\7R2]G+7I\4MAN+I`=`!:EF@!H%3K%PR'RQ<DN3%)<H
M(/+RE^[\W3:4R;U.-H0$&9D*EZH(S!$=I8:UN0O=9!C0K2'PBP4]*`L3:E`K
MA9*?A#LHB+QIRGQ2M%PAHA?:PAF4B-*%>A0]H$'0YU"KJ-,KIKQ:U*J&-=H!
M])#/V4@^/Y+/@0J4:ZBDJ4)AJM-<1DTR](1(!'\JU*%&#F$$LI))*"20AA)5
M=$'MXU.;*M6IO@@\KYLBU)A*5<-%__6%7=TJ6,/JQ)*^=#<@2:2'Q)J^K[(/
M59]4*US!ZJ=N\E,C2/CG6^/J(K+JE80H/&H`R502H*DL77U]CDLD8<XA?8F1
MLB'+(FW!4(0TDZ3S1&`WO:8X;=3F6"(1D2')Q,#"Q)22)7#28DTE$Y&:TBCM
M?&TMC01'].3UL%>92OW^I]O_?9!?4-%J4[&D*C3][V*63(A(GY:]I&7'3-*9
M2&.L\X][_N2&&<Q+Z>A:NJ01);12\J!2C"M>^05'.K6U%W!M>Q?N+/5A,7FO
M>N`KW_6HZ;R0:^2=YHNB\$*,D['IB!Y_]BE[UO.B_K7,=H+2)]W5<RAL;;";
MM$&GTQ)VC_^XRNA4[:M>8V721&>"3[PV/+H/;@:=*WHP.6G3H`G;3#H+IHX!
M@8+B\.CNJT^]DMZJ^C`Y=9A)\A(QD!LH1R$AQ\.J9<^,XSA";GI)P'_L%4R0
M8Y-P+C*4^-5(B+0+J/T@KSL1J6X7>>?3`_?%-@Y>']3ZM)53N@2ZMV'=@>1E
M235>$HU'?'&0\^R?]%S,6RI2XW#(Z)31D#G#C4I"$MJ`:#<HN@V*7C2B'9WH
M1#_:T6V(1*23X(8K&?@HD$GS)=-T+A%E"*G.FL]H@4)@WAW&,HN9[KJ*I+F"
ME*#0PSJ(C)8GR/?HN=?!\Q#,3JQ*U8(&@&'5C38H76DW2`+1S=;_=!(P?6E*
M0UK3C;:TLDG@Z$C<TVS&<F:`AHD00F\$,%!3<`U%9.")'+.Q-OPR%K.4&.V,
MRU4M"I.!;,$D_NT6C_&9L*\#OC2@[OK#NMWU)N/JO4DGV@V)+H&D(W[M94_Z
MT9%0-*,9S7!+:QS129"$[=+6G4:6Y6'?>L@W'9RL<]>U4>`FTT,F1:PQ"^HQ
M3XJDA/@<'_VN\D3W<Y+`V7>EQF*)Z$8'4]&1GLKC;HOG,<D5CZ2I]*DC*NE5
M/_K5J6[UK6.]Z,B^B**;;>DV0-SBD\9THI_=!H=//-ID;X,D(%X"AC?;#7-_
MM-BI'0F/*&8WX/[(0OST)&&F\#9/K&RR_[BN]</4.H!3^2=?+^60(@LJ),(+
M,R2SKGG%;UXO-LL/Z.\,7G$YZIE=/_WBPQ31V;#^0ZYO+^P-W_KVNIN>Y4EZ
M(ZU$*6*9N6E9=GR`-F4HXI+8R:'U-O(]E/S$![#39J77LIHO?8U0F]J.EL2U
MJ_]HAWM<XAF/./?'SO!(9S_MRHXT$N!N6<$K!2+Z!@]?WQUSC?JU\`%$JV$1
MJU+%"<@B8_Z'>WS++934->V>T<R66>$>[IV+S5C,S_P,B_&*27B;[DU'[O5>
M!0J0`>Y-FWG(];3:XWQ@YK6*K<&.]S2:VY4?]F4?W$E<VKE@"EK?Q;7="BI;
M"R;:6ZB2#A+,0?]@&[;5(/BYX-H)(:.Q(!`VVA&^H!$*81*VX!*R8!$ZFK:M
MG?A<WZ*M7:3=7:0-"G@U'+;='=P]G*1%V\9I8:.QW;-96\39TZ/AH#%=6QHZ
MFC%%X<4E&J:I1O<9TQ2.W<1=FL0IV@RF8!C^8)!(84Y$'*4A@;+A!+=5G-RI
MW;\$6`]67/F57R".81)^'`QFX@K"'<2Y@;1I7_=5VME5'!DZFL.%XAA>HL5M
MHBNJ(`Q>7/KY(/:1'RF>W\:-8:7IHBUFVF714_7EG1MH7-[58"@:XZ05X<=-
M6@W6W<<1(S.:G:+QR-/5!(U<3(SXRT$0HZ058S=^8]B!HR:&8]@E8S?_FF,Y
M8MPYJF,ZJN$RLN,[NB/V:=P0FJ+XT9TI\I>9Y(2?O6&CE4`:TET?+F,I#B$D
M^J`7=M^DG=9[L!VEN<&3/)HQ)>,[AJ.S16,[=EP=UN,T.EN+3>+$B880(AJF
MD4PN<J0\8F0\2@(TAEU+/F,YZITC8N$XEAU)KN/Y(>09DN,X]F0SBN-/\F0S
M1IK8L9VEE8!#'B4*'F52.AI24B+9)>7V!!8P]J2DD8#836'RQ-W;*1I6BJ%7
MBIU-8J7<7:58FB58>N53@->H2"!^/-V@A659AB58;F6B:>57=J5=ZF5>CN59
MTB5?_N5>^F5=]J6D`63%,1IB=F4;8&7ZE9U:_U8,<B@('CJE)*1?MBF67@+D
M8QZE8"[F)SI;]KE!%:[(I#W)(HH=V5UF8!8F5T*F83(:5FJ;M@&`V(6,)B)/
M"433LT43*>I(`_KC:LYE8PJF80(F8;9F8WIF6A[G:CX<M,5F$H"FI1WG8&)A
M7N)E5J+E<B(G%;ZCMIU=>**@8DEE)(RG>"YEM(TG]E'5"2ZE469:^*%@?'I<
M?6(<^=DC*5;BQT%<C8A>G#C9`X[G?F::*8[?QGE<@BHD+_*G@XKB@S8HA!JH
M@19H@L8=1!Z'/MJ/C82?@NXB14HH@CIH.3X;\B":@)G*$'Y/+=(D*=XG5%)D
M@I*=]5&:;<Z,H`1)'=E*&R+.HR8&&V=T'"+>(@K.:(4N:)&^Z)$2*;09J9,J
M:8)ZZ(%"*97*YY$B&L0E9*85J3TRZ/BIYY:^(%5%DQK28WXF:9C6*(BBZ92"
MJ0M*`@Y%8&M\Y(3E8IMF*8@ZI)J>J9TFJ9O^:9L&JI\*:I_V*2#B$&?(J9X.
MZ9+RZ9H:*A\FSWH:6:]8&PY::BCNJ:9:**,RW##>Y??@)J9!Y#+^9-IA9E0Z
M6[/U"I,^JJLZ*JQNZI_B::QVJJW.JI_2*J7IJE,.:J0>:-Q!&Q)68<4%:U(:
MJ[`B*Z*E_Q4PHF)%:J%^IBFGABDO2BE^-FG;91RU=JDEUBBV"NNTVJ.'6NNW
MRFB5FJN51NF1<I^'/JBZ?BM'NFBT+B.,RFB[KFNC1BF>(D_$S6FT].!$,JJ(
M0NF]JFN#;E_T?)]LDF:DF:E.4B)DXJO!CJLHPBB,\B>YMFK%3NB32FNZ4NRW
M9JQZLJ#UO5W)XNFUH>RN]B$L"=5TWN"/?NDM5A_WT>PH4B@OXFSW*0'&FF+>
MX>?//EPMVF#'U>P8&NW,'NW--NGX&:U]*F2U-2W4,FT;5NW4KN+2MF''82JT
M.>3/?N--YB<9BFW5)JW9UJ%M=BV/>$MY_2@BRFS4YJS-BNU\(O]A8XJ+MZR=
M(O;J958A8\9MTE[M]F7MTB(MX!XNW%*MV2*NU>KL%=(MB&I?Y"IMPV)AL]GD
ME'ILYFXNE[8!%='3"2XC$L3GLWEHZ6;:Z3)CM<4D*5XNCRYC"=3A%N:H<R%/
M[<+,J%C:LT$BVIENU'[<WJ+ND;HNM1'O.<9N\4[GZQIO.2)O-R+!8EXDTQ)D
MZR;!Z`)BJ-(N^`"I@@8K)*9N\U;OA38L#HK=Q0'GD)0N%FXM[/KNA2JB^U8O
MK=Y@S43"A+6CI@7L5ZHNL,(O>0XO`"<HVI'B``OO]$)B*8[OMUYN&\*N:E+O
M#\Z=Z4)KV%%P?RKP80[PX#)IQN8KISK_6@FRSZE&G`5K;*(%;Z6AL`=OZ=T%
MKWV&:OWPRAW)L%OV(#>>\).J\,"J,`[_8P]#9QN@<`L[X@_3:!`3L87:[[Q>
MZWYB7$U0#*_PFP>QIL6%)Q`C*19G++\*HQZ-(;^.[0S>X`YS[L;Q\!''I-I-
M3(LN!!_V*O(X7`='FQEB;I*:L1EK;ATO,1:;\!E3(@OKZP\/</`*<@+W,2%;
M;>=.[N3.)_EJWWPV&U5ICQ#"H`_N8B52,B9?,HF274V4UYQ^\KL(2MM5<B_J
M8B9+[BC_84ZJ<B6GLBOCHB5/*"E38L%]<G'$A[2RLBYK<O4%K,G:L"B^885^
M<"J7<BR;\B@/_^U2"C.E<086+K,QDZTN1W-.QNA2"BPV2S,O(_,J:S,JPW+;
ME>R:FK(LLZ`B4_,LI_,R8HU0B4W]M0T\(\LM7*+'S:--#B+FJF84(D0>]5@9
MT0FS09H17Z1>QF,X"B,)A%_6G!NR#$@*,31$/W3A%4O=,`TK[5JGR$CC_017
M?(SK-(O@7%D\GQ!%DZ`[6PA#U\5)R\U*2XUA6&H];Q^TOB;=S>5%1F!;VJX$
M?O)"#&T:QB%1DA_[!G0YX@W>M(2&J1?++37P44UIW`+8.F&G;MP*.ARTO)<E
M^5B[R$NF;:207JU0X]WY!99GN=3GTA]:,RM5<I+,O01JE44_GQP_G?\8D<R+
MAH2P6@\%4Z]<4_,>EJWU5SA?6?MU6COJVU:SV#*<B00;_["E;WVR9F)QB[8R
M*@)B!J9U`:57T(F<"3&93X1<HT0*HE@?]_ULP?ZC3-A/KO6+?J#(']*Q'R>F
M@>X=@*`22-<43H'-3;U>A[0>55(C?978!V&8CT!9^/C%.+W/VE`@=GTNAU1T
MBIG0US`WODW%:A:T_6)W;$]C5J\EH)&1N)C?S"J;F=+K5,;0<Y-94L<5YCS2
M7U/=;160+<0=/9.=*I;L3F\+<"8J5^/G/P;M<_XC;3MT`+4W!B&*@<?6EC16
M@I<53[D$YMP>1/0;KOG<5K?&L>A1R&`V4@#_18/3G]513H./>.V!!8F#280?
MN+=][G_[,6(JZ'3F7>7Q8YJ`#]LZ11L[+\E*0DESN(B7^&;7SC^PI(&VZ.FN
M77@A$;L(AZ&`QC:&\=AB)%ZG3T'`UZ`P#YK`TS^DEES?CC7)QJ2TA&<O5=^)
MG/SY-;)0%V$+"%K1WM<1-E+_3F`0)9PJ\Z5A+J:UY<[H"/V$'D]`6][QJ#/>
MR'I7SFY0B(/G67GD9VFW,9&,"GPI"*4^,QPSJ.<N4J%'&/Q8DELXN:9\2D,;
M1(4%)WEX>73T16$<8-I(!DJ9-:J\6.G`D74QGV4,C\N!1$&@%=,@.D&$R%*E
M"RUF*3U*)(F5B!T9_\JTE-<Q86+Q9CJHD(5-D`1'!=P(_4-Q2IO8Q=V2,PF(
MH<62',?^1MPUB156;!GQH0GR](>&J]9!K+<Z+1@WK0NXR75CE`4WD0MZ2-UW
M?-FO;,9T;0_Z](1*4!:J38=)`!B`1-=+\!_?#83>;`/V;62%[J:PW0^U<`MJ
M*83:J1_OE(9FPPYC`?:&.9^KT*>-J@?;.E<>>3((?[8(.;OC5`33835-[$>0
ML$1Z%!/XG-=%`1B>P=BY>%G0(UYU%#UU_#Q(=$@)-([0BP=0T9A'F(1A*<[!
M`U68QY^U'R6/WHFQ8U*%UZY.BT_%A1/+_51$L3NO!7E=906EP:F4K8<.G?\[
MB<'\WSR)%'M0`.(;;03;'I5`F?=&SLN\7CR]R0G&A,,;XM^)X/N(4U1&8D37
M5B2'7U0&SJ6$J40]WVV/0`S:02"!FU=^VFB#)'"E&XB$DX1R->I6'I'>ZAQ2
M>O7.$WW)7FO4U(3PBIL<R*C]VL/P1\9+4V#U\#6/B!D&DIF)B1T7VC2,+=#)
M:,!Y[#R]GR1-T1,+P@?]9TE,PK=*TFRTPT_&J_E$1TB3/]`5O*,<X3.&+26]
M0SS\EH\@9GNN5M_/A:/3RN,$<4>%QY_UVL^'I-0^0/P3:.O?-H$'$1)$*-"@
M0&T+#S9L6!#B/P`7,6;4"(`$QXH?0884.9)D29/_)TUJDSBP8TN.)%H&<-FR
MX\6:)0"@U+F39T^?_@[:Y(@3)TR70CM&=#B1(D*##Q="]6FRA%2&.0_"Q%J0
MX\6#218">%J3Q+\D5@%8Y1KT(MB<6[<!P&EQ(DZX=`7FA`K58,ZX%3%.?$MQ
M&].%*Q'6E(NTJU;'%XEVG#NUJ42L_@PS9/H0R3^%%CV#/JPVXM-_?`^+)=SP
MH5K2&S?>Q$B9=FW;MC/G7;PX``"9&(MBA$G49N[;QY'SG/@PKF_ASGM'7ERV
M:4&FA4.23GZZ.LB)B+\[9:V48?F0B*6.=\K=?%.][0\[7%\0]7SMY?=&E#RS
MM\S>SITC2R/<Y-LJ+(ZL('K(0/D,(J&YB_H2B`1;%`LJ+_E$HXZ[M!Q,K#NV
M8--(_T/CMBO1Q.2$*^JQX&3"J;>C`#CKQ!EI'.DE$NPR"L:N%JS1QQ]/5(A$
M($'$T;>9;C1J,>)LVLXO]A;$RJ!;\DK*O+*D&NR?"1'"RDNE<J+0H+\N+!`D
M'F,C4LTU4=(F(\6F:\PFETJHD,T[CQ-Q-Z3JQ"B)(?$,5-#Z!(WH33D[^J\_
M1(>2"\5_@,H*M05S\RM*T:0L\\L"%=Q2M3(%NN7),;=122[%-/Q0U4)91:ZO
M/B&#,4>,_HNU!$!;S;7+4X5:$L!8>]156#;O8Q/-BQ:EZ24TX0R6,K@,*L&6
MI]P,BSQ;]'KRPB\%$^A6T2S\JZ%-L\)P5PVIK&S58=F=*O\C6#GZ3;)3E9S7
MRG;Q+:@E)F<:CL=\`0X8Q?WJ5-)%C9CL\][;G&T)._D4%*I+:\G5=*",,AR/
MA(@Y(C,SYN`C3^"13V+VMZ[LHM6YX+P*F60\]3SV1;EP^@S/\#XJ]>6=2[(E
MY=A>JI-E/4M8=^3E).F,YZ5U[8O7F$CX3T=&75(+5Z:=+!BR)0U>5MM<K\9Z
M:>R$(_C8YW0D+E67`?Z.(,3$CMO'B;`%#FUD`WQ.H[#E=C4)NV&L=<#SGGKX
M1)U%[KOOK07G>MF#:ZT)9Y*_TP9DQ3&?VZ(X^5N1MU-_LXZ]S&>\>UG'!`3K
M(P"`VJK8VJ"B$``D;":=Y[YHFEK_L61/GZD[O@6=*-+E;"_^-LPD),N_J.%$
MLGE'"34>.8W\`S"ZK9MLC2US19=*)83R0YP^I5IKB*"BMS0<>.G99(KZO'7<
M<>793EN?_?MMQPXJ.7OU-^5^A9,X_-5F*(^)7_\\(J4(68HBU3+5YD8GI;3\
M`WUEJI:^FM*A#L5N@/C:G]I0]JLCM:A>B^G@"5%XINOQYSG$.9C0G)7"G1CD
M;_%"D]1Z-9GW`(`@JMF*MB+T-KQ8:&/7H<XV>F@A<(5&ANR:$__VQ3^\\4A#
MKVOB%9>F%MG-ZW](*MM&L$B;-Y$P7E';C97^\JE-D0E*YC$0&QV2A!Y^9X<2
M&E,8P>80_\6X:$?!0=W)O&(_/`X28*@2SJ)RI)4Y*9)MA`1)Q.3G1;N@[R_[
M`Q5H%KB>'^;E85LI6JFPDD0*@L^1K,(>U%K4E45%+I6E=*78FC,K%=%I969<
M%`]?63)?P:1Z^^G5?)IR'\.4RBIPJPQ?PC/,7-X)=U)\7OQX>11@+I.:>73(
M(<]FR$7>R'75A`@->X7#>34*0@4!2NU`8C-T7FYT[-'>?51B16_>9CQ_6YZ\
M3M<X''8%G?/TYYIP=C?FJ4U9[\O4/R.X'\_UJBN0(F4CV5F=E2!O/A][J"`1
MVJ:P"(AYO(MF/HECM(R.M$8_8Y)05HDCE<;()O*D)FQ.YAA\?@Z*I&'46]GF
M)35%"2B&-?_UZ8GTIKLD`6TXC:2FT[2B,%7*R2[3_"G[QE1#Z>C)@%[DTE.Q
M.J/AP&M^;Z)EK4A*-Q'R)B8`@HD`LYJYS&Q$:$;:7:)R2+^TSO4X/HLKG8S4
M'P$%QZ6O1*K6CI*[E9D&HW0E66,4^:ZGO61YRS+L8PDH&R]NDWG'*BP6'Y+8
MF?GJ;I`=X%!^ME*\R@M.D[FL9^D*J[(N#ZY'"J%D^GG477&395%,F4A1&[?F
MC--N>[+A;_Z76^&6S$A/K`EI>53;GN:2HG:-7)R>VY&^#I=GL1J.6ZFH33!2
ME[L?<9--0LN_%\VTH355D%$.MK42VN6TW6T71B?G7O<VTTAU:JS_BI+K2T>)
MSJBE%%$)\<8R^0Z8P-4\XTV/"T6B3":CXRIC1H#[F":AM<`5MK#T!'-&6C)O
MG#^CWW0=*0E92M$F)_O3A5&<8O;Q97>NW1$`R7)5$*>0L%6*4U%D@EU><4_%
M/?8QU@JS6-@T:XK`<6HI26,_P_UX)(1R8%"TQYWP?.\@Z6E@>=A(92R/RSP7
MM%KB'J(0'I;O-`ZB*<@L1YZ'V4P;91$BDRG7E$@E9\8R%%])E`GGDE!9->(2
M'<8L\ETOM<RA`=R<1W3CYBJ#2\M]/K1`_+&Q?W$93!1)2USNB)<>>H6#H0E`
MG?4\*(=NI[T8GDJI+4PBL2!A)7"IEFH>_Z@0-Z^-.EM9VUT<]!JN2$5,4GKR
MQJK3Y@U=,S1J7#18UIKI4`=,V?3TYVFUO&SOK(Y[-=F6H;JE&P96RVG8"\N2
M"X*^N^0D59M<R#BM5$>N=*6&'\FUCQLB"0SM16?C"?/H.AWE-R_%>U&I7W8(
M)U+CN(8A\1P(@Q:=;U17Q-[!7(I#.@UFXJG',_%FBI#N2/'0$-;@]Q9@J19>
MTS<.\=H-*3<GR[/&KVVEA^GIR_Y,`QI';U(BGW3CA;!T&I:#QFH'M7"_65?I
M_%A95?(F546HK)+-3),U1S0(MA+7;,-\*DMP#/:B(7;')'XOY`S/"U@^0Z&#
MU"Y"5;[.[QY*=#OU:$O8GE&T>9:<'_9$J.OSW(;2P.<2NF`)E.7I4-W^=D&Y
MSJ9V&T%VW@D=2M'T94QWF=@2Q[4PU<C[:_\_-E"8P$2_M\RF08(.$^Z2DEF+
M6-O!`&C#9RP9G_<\6D*C-ZWC_:*-/V49CDW2GV5P2QFUO"7*;VS,)?V,L5=;
MFR\8D3=$.F.SJ`8F+>7]L(.Q-#M"$SCFQAQ2Y=@6-HL^%.EW)]Z<M0.WLT\,
MU,/=1H<Z]FWW+!%3[F-_Q=(8P7;J9>H7FHB9'[_ZU(/+UEP63/16ST2R)%Q$
M0QLJ*)-T3H_R0TNNXI*VY,V@K_Y*Y>2ZI.R"XOPJ3)DH[LO2Z9&D+#XD8LYX
M3,W&#C]&8LHBJJ+&I\<$0W7*;BS2[?T<$/W*J6(P"3*X8LD,9"_$C8Z6R"\Z
MQ#W`J,UT9H?01([_(*+M:N0%MV0M0D-RFK#YKJK;&D0&>8[2ZH,@IB4O1"\'
MV>(FT*]YZ*+\I*T,,0?HU.6''B;^4LX!WT)G.F7Q<,Y[`M!-UFI#QH/<VI#]
MU@;EQ$(L_.\"`<.83.2@_I`ARN+^/(;GJ@@T@K#L7,WG@H5<3DXJ:HTBD@@0
MS7`3L:@NP*_,OG`P.D1GJ./6=*[=ON5;H(R"6D+VU,=/;._@6$\.U6V)T$)!
M[JWQIF_UD##W>L(P6`W?+J\MHA#+O(2]'.36:NXBUBFS`*V9#'#^&$SIBD/;
M./$:3PA07H=XHFXE#*/?V@-X,F/\O-$"FPW/D$Z):B3\U,7A2"DWO#$),;^)
M>PAQ'(\LR;`Q'_51]V1Q.XZO[O8Q(`4RK0B10'QQ(!$R(5$+($6"#!7R(1$J
$(```.P==
`
end


begin 600 Image54.gif
M1TE&.#EAT`)"`?<``````*"@H/W]_?___P``````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M`````````````````````"'Y!`$```(`+`````#0`D(!0`C_``4('$BPH,&#
M"!,J7,BPH<.'$"-*G$BQHL6+&#-JW,BQH\>/($.*'$FRI,F3*%.J7,GR)("7
M,&/*!#"@ILV;.'/JW*ESID^8+8,*'4JTJ-&C2),J78KQYTN>4*-*G4JUZ@"G
M`)AJW4H1JU>N8,.*'4O6X<^=-*VJ7<NV;=2?9>.JG.GVYDRY>//JW6O1Y]JT
M=0,+'FS5)]_##V42YBD3<=C%D`<[QDMW,.#(F#-;;CRYLV+--3EW9@JZ]-22
MIE-++E@9L]?+JF.7OCOZ<.NZMV7KKKJ2[67`L$/;_(TS^%7APY'K1+V[N52!
MN9U7!9X<:O"8RJD/AYF]^O'O5[%O_XY94/KNO*\_FU_/6R5[T"6U5Z?)'3G]
MI_;M*C].O+A_\>))%=U[!!;8UET&ED:64P+H)U]X^/%''X1I!?B??Q)*^%M]
M]UF(66VU>6=9@CUY2.*)*`IH(FP!;HBAB>`)!V!];&W%H$$I]I0BB*-AF.-X
M$?Z(5DX5>J>>D)$=B1N*1]W($))(\BCE0%EQY==?`T*II6M96M<EE$$Y.>68
M9#:9E)*0H;GEFFJI"61Z<,8IYYQTUOE2F7CFJ5251+FYF)_3L?DCH(*)MA"?
M>B:JZ*)%(1HFH5C"Z)9Q@A;X9:1`1>0HHYQVZBE(FZ)DIYRQ45II@J,:VA1%
MI[9*V*>PFA<4:D=8&?050I=F9JJK*-(FJI@$\2IL6_^Q%AM?4\!"EVQBD)[X
M8(PBVE5D=^!=1V1HTU:;I*I:&2FB<=3)E^UWV5H[I+C[[6HNNL]ZJY]5QL8[
MTJRL-=N32+D.JZ^TY)6U[[_/R2LPJ%3>N*N`LMH+L):^#NSPPQ"[M.QK:!U<
M:KX+6]IPQ!QW[+%$MQ)4Z[]G96P>7!^GK/+*(B<;,H[1LLC=C`\"]Y3-$9J;
M',T;8FSR6X:Q+/30$6-UH$,_GU:P4_N^3/334!?KM``66Y?T8EVEJG6<47?-
MZ-6:+1TTKB[7"IV*/@YY<HNZ>>WVV[T51Z-N55<<Y*0^!:#WWGSW[7<`*"L;
M^$'T#A2SD>5NEUVY18JK<WYXBV<&]^24B_3NN_U=^&W:B<<([K690TOA2W^7
M;OKI>F\\4:A@PU?YZ[!CU+J*,*%N^^U^<]M7@[-_&/OOP#_4NY<QX6X\ZJIS
M5'CPS#?OO%Q8'7_[V"X];_WUV)_)X-;)]YG]]^"'C^S@GBXO_OGH_VYVQ^:G
M[_[[_QZOWW7[2@TO&/SXUR9__G'OY__E;TG;I'2D(/X9<$%,.]7U`$@NS*7K
M6HI[(+4@^"('1HLJ!\R@]DK&0*H$:5P!O)_U[!<8#9IP+LOB'0-#)RT+0NZ%
MU:K;`$Y(PQIB#V`VS*$.?X?#'?KPAT`,HL2XMS4A&O&(*Z/8J5Z#Q"8Z$3$)
ME.'/4AC$!`*->D_,HD(X:#42%@:+&E38%S,%/).![TH'\F)@P)@^,?JF7[$S
MH_-\YD$U;@N.Z'.C!_$8Q[]L;CY_O""YM!,ZYMAQAF*[6XJ>];G_E4HSW?N>
MT8B'QD/>I'\]Q)<E1R?%3>;(5ZV#'A<]J19,_HLYC>S/N$"FI<H)2;"+F;.8
M'DD)I5D**BQBNIPKJ:5*7<I-/:MT(7\ZZ+O\$3-CMGQ/)RVII-!5:)?#?"5C
M7KG,FNR)?#"C_V6-^$?!-7%/FTO4FK[ZA,V%@'.;-:3?2NAXQ;F=4YG)_*4[
MM;3.<FJ1:D3,IS[WR<]^CI)+_@RH0`>:JMGPD7#W3.A0U$F2>+:SF@1\)Z8@
M2KL[)4:A&&4)0QO*3GY)JE`2Q9LMV0B1C08KI#G*:$M,>I']"6YC#DTC2@%J
M45E)9*8[4FF8:.52EV[QHT+"V3SY=<PV=;,YNJL?!5D$NF_EK($<4J3H>!F>
MG6VG9T3M#KK.==2`Z72G(`,JMNRYNIBF9JN.G"!:.]=!MK9+I&1\S,(H*B#7
MK.6KWB/</PLS+[/BE#"1Y,I?3X37A?94JF]!H5\'^]":%O:QGBF;%84%U5'&
M$BFID,UL7'RZORE6DK%DU:QHP3))2M)OA3Z")B!7J]:T"O.MG!2KR7PZVMJ2
MUF!+PNE/E6@@.-F6<I:UR48X.]+!_JI.OS7@7P=J*R>I\ZJ2`B%KI[K+1OY2
M@((487*WVQ"/=C.8+-06:X-YV;LYTVZUDQ[NTJ.IA!@4L=BJ%'?GMVM.3\I$
MO?C=&V;;:[C@"I>^`,[F(>^;WP+OMR(L#;""-4O@`AOOP,I;L(0!'#T'`XZD
MHIJPAK]*V^9VV$8;#C$0/_RI!(OXQ.JC(OOT8ED4&Y'$43,Q2UKLXA..];-1
M&N%T/0?#=4T0JM'$;@.G6\T:\Z^TKEH@8XTL/OD=-;Q3E6`O`^E5Y]&8R=8+
MK$`RB>4N9Y3+7@ZSF+',W#&;F;[BG"B=SLSF)L+ID^QMLYSSYQ6`32VS*O^>
M,_XF:[\\OYB(>CX?G^EJY]#:$,?3T7*@*8?HHFX2PQFLK&EEO&B.[55M,S6T
M^Q9;7L=6.L;))#0)%1T^3I<HKJ^3X_4:71C_WAC5>93M&@\*W(QE6=(1=75L
MWV=JCU(Z9:H.'JZGJ6MY>KK4IB:UUWPC9#]BC22;K)>LV2-4J3)57\INWJ4;
M"U\2FK*.T*Q,S81,WML8THZ)%/4C_4>I<,_GF:VMJGB'/&_<0!A[WWSGMZ>R
M+AKU[#IT(2^%<')N->)SVNM!:Y39'=]Y$]*MX\WN&_$82LJP6K?NL75#?2U(
M=76Q36RS-\*++1O:5!R!:+QV'1>.:8D[NX`I"7:=2&*H\B%/^>94OFJSJ]9K
MDO^)/">W4N`LV&XIM_S'`J=WD%G^JHPO#)70*K?18TC5AJ/6X0<;ML_/"LPN
MJ7MT+D<G4Y(%P*<V?,I4[WB/">D@1S?=F*X%>5!'CJJNTK*997\AVSMNWJ.W
MYYH8WM+7BXF_9I.,[G5_$<1';:'S.KS>CZ.WS8B%%#]O7;F&9QBIE@C!M8)M
M\UC**3DA7?\>GV,^\\[BLZ][OG5^J_[5K&_;HTB/D,NGTT9:OWCKW]3MB@X5
M3/6D_:>U\FM0(=[UO]^]R'L_<8(Z__G"=R+TIT_]ZM<)--;/OO;U"<GM>U]K
MP_>,46+_ZC4J'^S8I[6MPE_%1AU_C,ROZ^[)?V^JL7_$[G]_8_\T_UYG&SKW
MYT/%IQ&ZMT?^IWP%Z'O'9A86<7ZR<68#V%)O-FGZMW+GAV2=]G];Q"H.J!IM
M%H$E)3_7MQN#)U%K1C`WU8&I(6<@N%M@=&?D1VPJF($I85(S:!ISUH+IQBUW
M)FWQ1U,).%CU)Q0157-6QW2Y)H,)=X2P-6ZEE(/#=5B:YF')-RB*A_-D<1<H
MO36$1+A4:L)*!(1V%V0JU45D.R8Z>P=;CM1)@29C<79P4W@H,6A7/[9S[B)Y
M7>56%9B!.F@Y.G>%5Q=?Y09O`/<9;&=V?SA6655O-(<=-<>&;1B"(Z>!#:%U
M-XA\L"98EQ@VE58X08@6^#*'#DB)1;&)G-B)/OB)]])7>VB*L)<7KDAX_XOF
M-!#5APEAB2I(B@$88%,3A+9H%J*(4[JXB_,EA=NV2+AH6=%'C+QHC*J(C,GX
M3G'(C&CFC*(Q5\]H@LM(C=QEC;H3B'YG5$H(76IXC.`TC=RX7?I47[!'AHS(
M8_!80>5EAZM7A7V&CNF87!B86,(#B%2W59.7=@$9>7K(;:TX=WZ6CQ2V/3*%
M<3L8C1?3@PHY82]#5R7X,\`X)Z:!7!,)(J[&4Y)5B\85A=;7D9SRD>/S@OOX
M<7]EDC6DC*,"ARJ90ASTB%&%'XUW,]`5=3>6A!WR3#]X5RYI8R%58;;#1*G(
M@TC#<.X22]0$2$X90E$9&4-)E/]SD?(GCFW7?$ND8V%\,R>5R(X;&4)K4I4F
M1)8#=X0]F7=0V6G@YI9\Z)6G`V.X4GNZ9I8:!)<Z)U1["7M]"8\SPQC^EC,Z
M*2,-)I=SR86W6'HHB9?0IS=@Q8.8#Z9^J[-E=^F8CVE'ARF9R$.978&9H/DD
MCQ:9G'F4GKD[H9F:QK*9I9D[IYD1OZB:LCD6,]&:KOF:$3:;NJDH/\&9PPB;
MNQF<4B(GQT.7U2.<R*D7W@B6():<SGE;^*@_SSF=XY>0B1*;U)F=5/B;>8*=
MVNF<QBDOW@EM2_:=0A.>18,75V:>[&.=2107Z\F>`X.>3S.>&Q&?\MDI]6B/
M":)DTA1R::DYGL,A=ZAV&N)=8I>?G;*2.?8\+52'/;94[SA,JK6&4U<7"IG*
M*0RZ)?[9DAG:G:^G0#HVDA\ZG#>2A[_GCG/#,](4%1WJD"4Z&2Z%A0:::U*7
M<U#QHC,5HS(*:6#&HT!J%#\:I$0:%$-:I$@:<Z>4I$S:I%G#G$X:I3Q2DE):
MI;CW?>YII5I*DJ`'A+ZUI6#*I1N*5&\8IF;*$.DA>$AYIFPJDQ"Y-EG:IB5:
M9[-%G]+WI7(Z)6.*3'$Z8JG_DJ>1Y1=8R29]FDXA&EN9"*@H=R2#6BG1&4;/
M^*B**A1[U:BM(JGPDXW&MH"3ND%^8JFN@JFQ=I"OV*F`!RF@*BRB*DG)IIBF
MRHKVDJK#LJJW1JJ;^JJ&14>RBFW;>$:V2H.XNE*SM*N'AYO(QI^SEJAP(W.K
MAFO$VC3<"3PQZ*I"PZQSE'NNUJO7BJS+9Y^P8JW,@XO/BHW&6JM!>2#E^C3@
MFF*V.JY\FJ[:]JO&%CSK"CL0Z:[OJJS9\Z:ERD,:%ZX'V'K1.CEO.K`?4Z\$
MVW/XZEGP*JV+9;`'^W(25S?6]80C$6U)&8O)JJ_-ZE":^J\HP6Q.A8@!:J`=
M@J#_$G6QEI2*M>2/!4HWW<>Q'>LSA__J1?LF?X^(=.1VH3%2<#;[4N>ZA$S9
M5(MX'VKI;_+VAX/Y=1#[-OMT3C<+-"^KL\1TH\M!GH<$M`O;D%_BCH_7>7>X
M>(5"K<)64!(5M2RI=&S%DV!KABGKAUG+KW0(>6F[=U^+AU6'A%R)*$&W6;P%
MHR>QKMRWLL$XMBSDM2TDME6UMH.9B(!%<6!C<1_K26B;9!L'F=RJL=W:7U?C
MMY-+2I7;*O%QA1>Y3-=&:(4;BYS1M]!Y&Q\DLF\)22OH=$?:$4KWH#:7ABZ4
M=&GEA`^EN24'=)$K%B=J551K=KZ[E>\606J;M+(:NB)ZL84X=3C7ECB:53+#
M?'(+O*>6N9;_V[K7N%K9:[5KZ4MN&Z%01I6TNZ0JJUHW6KUZUZ)LF[SHM;6N
MF+KF`;Y\Y$M.B':'FUK_^4#I"QG0*U]8^Y/]>Z&!"9B%:6Q*V\#@(J_<ZWMV
MAWH6"$.K,7;E!(X+W$I`&8]$YR`?1*".*XOO$W9:"8U!.\$;^SC^RY/A573R
MBT$:3%*")WJ%A\*\ZKV))X0>XGCN%J&""4+OMQ0J9GMPEX70RL.]!;;FM<*S
M^L-LR2XX>KK7JS259VA(G,,ZS"OXFR9M>[?#PZCR%$CC6[\/7(9_EW^DML7P
M8\'>]+>$&L9J>#7FJ(4D4IW+Z,8G#,<JK)&4I1B,"\5Q3"?L2ZGH$<C'[I.$
M2))/+/RX6S,LN4J)_XJ</HP,9S3[N2Q\Q^UHOV^G48]:R0;DK0CFK-O;@1^K
MR>LAK-HZI\0GKJ<LL):HRLX1?$UKGJ0LB4R\?X\\:6GRQ=HU1+?,GKE<B0H+
MS)GF?UBZS';R6,S\S-"<;[H2S=2\S#%;S=C,J1B5S=S<S;L,?]X<SOWT7MI,
M)4$JSN@,S1N9SNQ,1.3</L4<K..GQX2<:-_<Q3Y\SY@(S_*\*/&L5_J\SR#5
M?P']4`S8SWKRS]MIJ>)*T`5=O^JDT`B]4FS,T*3JR87VT-W+4!(]T>M$SX/*
M:1A=K/4\Q.5<EQY=)AW=,NT:L+)\T62[TBE]G*.WA[1<P;KVN:ULSAS8RR()
MZF4RK;5TQ\D#=(&J2*LFYM.49V8=35!GE8OY-%P]K=3P_P*!K`P7:;9N4-W,
M'L%25"V45EV#$P/()*BZA0HR$_'5%LO4Q\5&SHA4FDNV"):":DW#;#:>RYFH
MP#S2O2/7<PT1=;W&86U\V"210.L<?/UY#;MOU5:Q>JO$]2@=[DN.#8S!=GW7
M']&+UAG+CSS,'U&$V*7&K9:50BO:,@S"EXW98JHZ](G,`\VV$@K9I$T@?AVR
ML3V&\6L?NGN5K5%=K`20$2=>C$/&.+T3>C:`Q"6IKIU;L'U,1ANVUN;$V3O-
M,BNDMWW:X4;">C=/'M>4'*>(B4C%KE6AD`B%?3'6J[K<7.LFV.W=5TG'4]O"
M8Q&V58N[\`:8NHW3OBW$>&NW+IS2NRY;92SXI"FZIA*HT6-)M33J>>_H8Q`*
MR2>=%,B$?7,KV!\85MQ*JRR-X.\%CM=5H"UB;8*,="7-AV0QX13.?V!]W!G)
MQ-5=5A*LL9ZMLH$MX`,NAR,5BC%NBC-.XS6>HZA(-L.&G>KM7[5MI#_NHI^V
M*7O*CSK.X3?8XSZ;Y`2WY!M^%Q89'T6>S(M]%%0.Y%:^/EFNY3O^TB__/M.5
MTXM'T]8ECLI'CN9$H]G>^\^<#9-=#N=0D]RYLM)USN5GCN=NH^>]?=,0#N7Y
M?.>`?IXA2>ATT^>DM-.)KNB%W>0(:>C2^.:1WIZ+ON6%;NFC*>69+C5Y7249
MS>E1#.JA#BN";BAU:NKAA.FI_C"K?E!)0]1W!^FQKNDS:4\>7MS\EL*WNZF>
MOL2HGNL+NNG[Q<'*:[>21[X`_I^V/CMG;>R6QJ!3V.N.6+2OA:#J@I-ES(?#
MKGFX3NT00^D0TH]#RV.IM.WX+4",2X'A3B)V2N[Q4[.@N)3I#B$'JN]_J>\X
M$^SHQ^\+/%5"7>8)-^_TKNNIC.\_^Y`&KQH&#I[P@<Z01;VC"QWMB%VF_Q+O
MM,[%W"B%IG$"IQJ_\1P/+!;IH<PR*G#%D23_.IKM\2&5DEB:\(T)F^A-R(G=
MH"`I4"U_4L%%@#>/>#FO\STO%S5/X*Q=*Q3[\T4/BT;.-4EY4+38;I.=MC`K
M3+/;]$:_7#P?]4#!4(#XPN.U2DP5PY@VP!BJ]5N/4EY1.G)R\:AV6OD.(-_N
M3`/_;\3#;I:N]FM_3DZA7LBNU]TUM&(OQ+U$O_-[Q27$]_["EE<OL=)E@*P)
M^$%#8N;CCQV,DQ"\^:*MB!&\M)Z/SS;.^)H8=SE)F*BOW<U;LE6[M-U.FI()
M]6'I7K(;=D.?VJ1?^A\>QD<'Q,\^Q..]T5W9FG@1/_L'46RY/]\?QT@*E[.+
M:[YUI7*%F%ZVJ5_<R3J7F?Q@@;M8)\#,JS/>OMTEPNY)2X[5?YL1;OR<ZU_:
M+U>?/OSG_Y6(SM/KS_3MOQ7V-?GG;[!\@OP`(4#@0((%#1Y$F%#A0H8-'3Z$
M&%'B1(H5+5[$F%'C1H[_$0=\!!E2Y$B2)4V>1)E2Y4@`+5L&@!E3YDR:-6W2
M=-ER(P"!*WW^!!I4:-".18T>19I4Z5*F39T^53A4ZE2J*',"N)E5Z]:K'0%4
M!1M6K$^H9<V>19M6[5JV$\>^A7ORZE:Z=6-V]=I6[UZ^??W^!1RX;US"A0?,
MM9LX*]ZB/`4_AAQ9\F3*E9D:QCP6L6+.,QDWMAQ:]&C2I4VKS9P:[.;.G#\;
M=7Q:]FS:M6W?QLWP*M;6BG<SC9U;^'#BQ8T?5[J[M]W?38,CAQY=^G3JMY4O
MU]K\Z?/JW;U_!Q^^[&Z7V'&^=LI=_'KV[=V_+TB>MWGR:M7#QY]?_W[:\EDG
M2/:OK?OX([!``P^TSS\%%U.PKP$1A#!""2>4J$&!%,2P/L`>I+!##S\LT$*$
M,M0.,@Y!1#%%%:D3<;H35X0Q1AE-:[&Z%V?$,?]''?FJT;L;=P0R2"&1ZC&\
M'X=$,DDE=0L0OR.7A#)*(8M\[TDIK\0212J=S+)++V/<4C\K!U.M3,.^1-/%
M)B<<4R\SWXPK33F-"_/`-MF",T^QYN03MSHCO#,M/0>EJD]#9?N3S<H(952H
M0Q\5+5$/`RVK44O)@C33R"0%D41//_44H4M'14E34S=<\]2D0OJ*U=5:_0C6
MJ60M4U5;!8W5/U)32M+56'W]];!@AP7I*UB/=1598I<-MJ5BB:5UI5NGK53!
M757J]5EC6;VJ66"?%3;<P[H5=MMHQ?55UE9W<Y1:=Y>R]EILD?Q669'6_7;8
M;9DMMU^62,(7W'.!>K<=8-ATE5=:>L%-UR6&<P+X7FZ=?;@D\L)5MUB'VS7*
MN..+XDU8X2%#EM=CDR<"F>1Y1U:9U)-?;LA:A'V"F%^3*)8JVY8OA;GG@QK\
M-ZAH]U5I8((7WME2GY<60,2@&487ZGN5S1C=JE<6,FF>F7ZYQJ>AC=CB=,>&
MVNB1=-::4*Y-+O)KJ\66N&JYZ\64Y;357MO@5`MR>UR<+=[X[5QQIM5ALT7*
M.W'%V=(PH;MY73QRR0%[O-3)+\=\K<I/RKQSSY_:W*3/1R?=J-!+*CUUU2TZ
8G:357X>]H=;/CKUVVP>:'?';=\\R(``[
`
end


begin 600 Image73.gif
M1TE&.#=A/0,K`O<```````$``$Q,3)^?GZ:FIO___P``````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M`````````````````````"'Y!```````+``````]`RL"0`C_``L('$BPH,&#
M"!,J7,BPH<.'$"-*G$BQHL6+&#-JW,BQH\>/($.*'$FRI,F3*"$"6,D20,J7
M,&/*G$FSILV;.'/JW,FS9\R60%<*=%F`*%&#1H<B3*JT:5&"+H\B=2IU8%6?
M6+-JW<JUJTP``L*&O>J5(=F/0%.>+<L6I-"V<./*G4LW*UBQ>/.N[;HW9%6F
M10$+!FS5JF"J?>LJ7LRXL>/'D,U&?%M88>*1ER-K%GGV*&&J4)TJS;RYM&F.
M+4^KEO@W=,&_G@V#?CHT=F6IB4F?[*N[HNW5P(,+-]T;ZEO*@6L;3RZ[^7++
MJ9TCC4J=^?/K0H_CABU]N$JMOVF'S3_<%/=LV^9IB_;.OKW[F<7?RU\8M+[]
M^RRGSM_/O[]_K/']QQ]^!!88X'#1":C@@@QJ=&"#[1DHX8045FCAA1A6N"!R
M$';HX4$/?MA6AB26:.*)(?J%X%UYM2C`9?$A]QE]&TXDXX,<3K;=13F"R%V/
M%`&YE(A>H6CDD2D&E^1F,+[FVG2NI9>>>IXM.5>`'.876(+U*=><?5`:9U10
M7F[)95IE6I>FEH:Q>>-#5@Z(Y)SWH45GG)HE2.2>079)(Y]VQ77GH'ZJ-FA.
MA!K_":A/8,K5J&6+`KA4HG=&RAFEF&9*J*4[/0J7IR!R^IJF1XK*%:FHIJIJ
MG:;>!"I;KSI9UJHFPH3GGK3F>JM[$K;J:J&?`JN?F+I>Z-^NC!:K;*T.ECK=
MLM`BZZN.9&(6[833"GKMMK3^RBV2V1KZ+8%?A9O1N.BFBQ]JZF9H+F3MZKF?
MM+/&:^^])]9F;TF'OMN8O/YN1.^D^!9L\,'KOM=OP(H-#"C"$$>,,,.^51HD
M:U%Z5!R++HHE)'&\2BSRR-#VQ"K%-EJ,\9/J24<8>AE329[,HSI\Y6XDYZQS
MIGR>C#*U<_[LZ,Y$%^VSG<).>[2/Y%X5HTIL]AEU0S:;-0DN3>G.9_36)2H<
MJZE+7\SRE.2%-_9M,U=V6WDP4ZEVBD5+*A_7J7:DH8=ABYKWANUZAV++_Q'>
MJR2%'^X=J>&V]NUUHEAK/35&B%LT)8]8$U[XUXON*R?C\P*L-.:22^G<Y%'-
M5M[9+6]L.=Z@\Q0OWYNRU[K0\,V^>:^7^_DZA)BN%C3M<]MNZ[#?U9PPP;B#
MIWCNL<.;=$T+VUC``-1/7SWU`UB?/?;:=T^]Y\#[);Q:^E4IVF]+[GPXYPT_
MSSJ=OGE__?S;TR__`."'CW2U12YO:>_!XI_QT*2_T,&O*!W3"VZXQT#[-;!^
M$"1@`2]5J-W9;7'1LXO[H.._":8,?H\SBP-'",'[6<U?65,>4`C`PA:Z\(4P
M=&'5K'9```G0(1"KW08]""E]!6TM3K-*"1]H0M,BXB]_G)JA`5<8PR8Z\8E0
MC*(4H6@LD^UP@/ABT/A69K;3`2YF7ES/LTR7.K6)!X=53$CSI&=$$A;QB"'4
M&],`,,4ZVO&.>,RC'O&(1"SV*H<\Y-$5`VD6E1$+?`!HXQ#=B+T^9@Y$>V0A
M'2-)R3JZKTO7HB&&",FD+7+R6;_KCF44^<9%9L^1/8,D)2?9P@K>4',Z3![M
M#/1%TMQ*-[SQY"?]^#<S0J<HC`SF$%&YO@YV#EN[].63CK/,M3E336(\7S0/
M&<=D4LV03MM+(DO)309*_Q!LQQ,;RNY&GP)]48W*M*;&!JE.Y%UM2&=T$BGG
M.;]OABML)R-F`0+`SW[VLT/DI!SQ9D8V,'XLF9$K9--DA<Z>&=)&]#2E]]@)
MSANVR9X-\:=&!\)/CA)$HP$02$CW^5&#C+0@)STI2?>Y4>BMKIW_TJ4XK6,^
MM]',ICAE)F(*@SXE?C"4,'W)UV3J4&0&=3%$#6H&S=C%E1T5GTE]GRR/>B6*
MND6-;J),=+:Z)89VLH8]1(TH/SE4JY:4H_\4J4K5VM&SBO2L(5TK2]O*D+B:
M-*WL,BI5AV;1/`%GJ>0+TR[+VM?_O51%+)O,7JE9S<5B%:P\G:98?TE(J)I5
MBYR'O:J37G91INKK*05=3WY\>IJH4A6PB>4,&DG['\L6EGFT="RL+BM;'[Z3
MC+MAS4%1>$G:WBZV"@UG8JMT(ZVBCJ=:XA)S]"E5YM;6ML[JE`&!1UB,-BB@
MSTV6;S%+-V-6C+5^BU5"CSG5[$*WN^A-[\B6N-O/%=:TXM)K1=5+7Y$UCDFZ
M;2S%JNO<P<FWM/5]K4L%S+"D@O<GU^S_[XH"S.`&/Y1(X[VG)P\,/7=2>+8.
MSG!Z]Z?@D!$X8./+C+Q24S7]%L^VXS0K?"W<7FM]^+807O%?MSM?1VZL3.A[
M9AG;%L9X"A2:!58QC<OY89)8%8B9A:V)^Q/A;.7MPN;E5XN9)F4HC^K$CRVO
MDJ=,7L]9%[%.I1JBDA:C(6/YIV,R<Y01!*<D-[?#-3)HV;XT+)WZ&$A`U#%G
M<RQ-M/P8M#N.+-J<R131I5.,5EZSH-!LSH>I6=&1232DZ1(UKJZM=+#)46LZ
M6T9`K[;(60;NI!O&T"21)8AA5:UD,3/J5KL:IIN^\V#.`\:W&?36/9YSKOO\
MZE[[^M?`#K:P%H=-[&(;^]C(3K:RE\WL9CO[V=".MK3_ITWM:EM;1+2,-3RO
MS>TDOJC;-QL=G<-H9SXGAVRQZ2FXU^VZ!$K:06KYV(R\2KH>IY;=^,[W7]G=
MF4IKY]_ISI*^!UXD>I?OT(7>MJ%7[56"F^3=#K\@&J]\[JPREEB3*J>:LE2=
MBN-X3!AW66/A+#M&>1:G=QXHHO7,ZXCKNS<2?),/EUO<?NN..T`64YM\)%B1
MR_PZ_8/LO5U.]"06'93OA/C1EXY4IC-68BY^L-.G?NAN:YAGYW*<BY1.=5@I
M^^J&ZER+FG3<H7<ZM)V.D-0ZOJ8TX]Q+/^\LGI,+\B_M")I:W5'>K3MEKK?6
M8)KL)4"[;C=V^KU>UE(L!@NF%4*@QE3H:Y;Q5P9Y^,/AC/%)E#K4U/_K:LG_
MA/*P!KRPK[ZLSC\ZEGVL_,-%+QE(<\UU66RUYQ,G8)L=K"ZJUR[I0<UHDE=9
M6:;G/4YNW^S=:^KWQF\TM5]%_-8#._G-7SW)7!Y]1_D*^J1O,^LO"F.KK]%<
MN0\U]L=??;YHOMKA5Q",R,_^V+O7\7Y3()-KW/[Z9_)<L[_^^9W?\C&FG;,^
M%D_U!A4=PV7XA6'VEX"Z$E_"1UW[!WO4Q4$*.(&D\G3I5U5'UH"9\X`!E"_!
M0X')AX!?IC>V0RX!:%-M4VZAHG"X]5FX)H!O,V^;!W]$ED)9]X$@>'\`E7^_
MY7N%=%W>Y5<X&&`:]%^PHX%OMF08:(/A]7T!./_D.,>W9<+%74C(.V9F08O'
M@07W+DTF-;Q6;VD#@+L&-*(&A*>WA.CR=^P3.%6H/UV8A2:X@V<X1VE(A5KX
M&#P(;6_(&)3G9@"F+E+8?7@X9*A%-1(541,U;'N(?'CVA><SA;RTB#58A[BR
MAD@UAS8$>7#23<)D/2,8>7DH@N.2>4XX(IA(BK_#,2^2&X@849\899+X:91(
M@I:X%1.FB:=5*:KH,=K4B8CH@S^#A;!G@,-7B\.H8("48&W(0QDD8D-QB+YX
M/<!XA,QBBT%12=CX0MIDC&,F?,G8/LNH<69W3AI3:_%C9'0HB-PG(]#8CO(S
MC0(B+?61C?18C_9(``>3)CS?N%^GZ$OE1E#C-H841V['M7"TEXK%XQ*M&$RO
M^#"J=(\0&9%\](D@]"W+%XI"4XB&&(WMV)"X\I!ZQ$H0*2RN%(3!588.Z)&X
MAY'!^%"GUAD<R4TJ63@/^5^P!(Y:QH^L<DE]9I!BB'#FB'1*F(M@E4V-LDT+
M>8@SF81WN(%&*(%#290.PY*SM'_'HY`QV4;P_ZA^XN4I%WB)3RF4:')J+XAV
MY_254+B44$F,J*B.FYB4I;25=NAEN@12=KE2;Z41<M6!*$EXZQB5XC>6]D9H
M\&1N!OF"XV@3&MEPZ5B-&=E;X6A2!S%2_N11;+67=YE2;E69WI*3A$>5P8*&
MT35M_`68CA:65`>:*4F#Z%@ZH?<\"257>RD2L[D0LHF71N:'J=F/F\B"9"E-
MK8&6@H2+B3E3765-I;E;G(E6=G69S+E2(/6<E`E7'56;RXE7_Z29^(>:3!>+
M2M64FD5E9`69:CF7<:A:KCF&H@.&S30>IFF&Y;E8BYE;/QA(KA6?QZ*;1Z>:
M!;14^&F<]=F?Y"F7"W+FF6))H)/&GP):E(/)+Q7CA@/ZGD.H?+)X4)OFD\J1
M&V3TD^^'H`CEDB4#.?_)E"_)FWFBGQ&'D3FXHA2Z=FQ95'QGHH/(G3K)HC;:
M8*R&9A#Z7C(*E@::EC<:+21ZCB`CBU88I$CZ>OD9F<54GL)Y@Q;D)H=).J6Y
M4J$2*CL]"I_,]:02=TA!YHV\J:`LADO5@EW8EJ6.X9U-VI`PYS:&F:&!II[%
MN8DC&F-@RJ2-"66STS0H2HU7BJ5X>IHCR*7!MD5Y**:-*6:!"8E#*H43-%1^
M*9]6RJA2ZJ&+TT.\478)MX+$PY@8^J95!SGL-1YN&B4\IIY-A6A_&JDYJGT_
M:IZ$RF_=R*K#A1+:]H102H8M2JO9%:O=J2>CY8BBE1U"J7,`.#F\BI-NTG^#
M>9@H%X8MZ*RGRJ')6JW6>JW8FJW:NJW<VJW>^JW@&J[B.J[D6J[F>J[H_YJN
MZKJN%ZFF[/JN9P:OV?:LRXHVQI4=,A(:'6=I]NJK\-J?'E,:_NJG!15:Q&IK
M.>59L99NS?2O^+:+WY:F]!F#Q15R95IK;N=8`^NPCYI`8]%T\(&P#8MR9Y>>
M),NQ**N'*;NR+`MFX*9B+?NM1DF6I%.O;).O_F:`&_N87K9R/3FR,5MTVH9J
MH]&P!VLZ&,I_+\>I*OBLHD6.01MF)YEW.I)?9;IWYT4=Q.6E.W><8Z50J21=
MHP%P,S>V7FLF.H>VQ!5P.YLL42LP,UBQ<*=WVY%F!YIIO"0;^(IW4Z,=<VNW
M4/*B)6=R/QM-O_F;1HNQ;WM:VM>U,H>U<OLX\B-64SG7M6<K2C7G@GV+IH5'
MG%"[N*"[;4N'6FT;N@Y7NO:)3?2FN[J*YW2'@KJLFZ*[N2T^2J.Q^URPRXQ4
MZIBWFZ#[N;MFRIB]"XO\1J6!)2<!.[Q\H8?L%V[AY;$1B[LITW-0$SK4>[UI
M0EF6*Z*M6Z@;-B`AX[%D%W*=JJ^9.W/(ZC?3"V3\<W-7"W1S*Y8?1T#MFTT;
M1[E?UG<)RGEX\W<?J[3I"[5)Z[2\TB?8<7><]K@(+')IZ[?WVW9MYTHTM7Z]
MN:/NIXQNV5KJ6H+K(V7Q2K#"&&^>2QS!.ZX<W'D"NX]\Q9J9N"K!5Z>5\V*]
MIG3EQV3@.:H3(WN<*SXR_&HADL,IAHOC]\*6*GVOF+O"4<.R!;QIS[2_@?IY
M!(;$UHAYH\?$\[G$.^P65R3%G4O%BI@S+OJ]HX:H79QZD;9]HOI4Z)7$43C&
M6<QA(]>-%RRV$@9VJO957:/#3WR02(0C:'R`79:`96R[80QU>@S#J$=W7OQU
M5GQ+C<S%:HC(VSG'C/S(KPK'&49T!O;'RV;)+&S$8`RN0`QOYN7)W<+#ABS*
MG(PHX6/*3*BK].6ZJQQI).K*E)RUKQRWH_FRP.>0>&S+P"S)S3+"T=;$'N1W
MP9S,1:R8-\QLD`S(DZS,KGRFQ$P<J_^H?J4LS;;\J,T,+^[VS(H:Q-K\R).X
MS&NZR_':LZ%2:6,[K84K6M![S8,+J^.<I"*\QQV*SKAZ<C1BL#$C)2:+K!PC
MN$(XH_6\NZ*YJB#6S166D3IQT,;;@PK-6]5<?"(*T4%*T<(,?@Q=NV_<PA@]
M@85,T$=:9.?)T17-S*@"I"%--,7XT?[U8N84P/O\)W/*J0T:JI@L>.L$B*G&
MABU=>F<,T[X38@)D9T5+:P19OFN[O0W5U%X$JCC\-R&,CA,:U'W*TA/-E6@*
MSE%GDEL(A],\M2=-SRB-SQ+-+05ZL5>-?5!\R8&\U9&\T0FMUDW8.UY-UO:U
MDH0<UR3-U6@;#<JC"-17#*!W7:5SO:L@G-?W;,Y_:=<>5HJN_Z/5BIVGC'W1
M<.W7ERW8<^?3E*W/`JO1=#U-!?MO[9RQ[>R"90O+E)K8<OV'N2S6&3QC@4W-
MM;U90&L>T)IV`:@Z??W90QW;;3W;)'S;W$S4VO+;PZW2GNW:G_S+K_W%R,V7
ME0W82WF3\4@I,=W:?NFN1:W<:SW8E9K2=1V)O!O-!.)`FQW>T7TJW%W"R2W<
MBZTHT/W7D^J!$,6)[O@][<U)WEV.I;:L[(Q<96V!9/S8M%N)W$AITXW9Q`TI
M<*F5CFW!HYW&(RN&1_N7&%S==ZN#"B[9\3WA]4+>H1'A(U3AJ=O@HFB1YTSB
M5F3<FLTL8,%EB925)"3BK7S@C,CB;5;IXG*,X@M]0!`[%C!IXZ8$Y,>LX^8M
MI*VBW:;8@%F-G+H8SUEBXA*%XZNIEE5M6"#^XEJ.V+@[Y;R(0T9N0DB>Y>*-
M8,'=T8W]GNK3JU(W=T*TW[Z(Y?]+*M\OS41-!'$`!-)LJ<(.;N=@$W@>J#IT
MOM]G3MA8-\4M(9$P9&H+WIFF">B=HN(0MN1Y++I4<>C=E.B`^M^<[>B.7MAO
MO:6C_-TH'M"<]G\"?K[EJ[8TQW%D&YX=?M[?8>7OV-_S$L.-+NJ^CHV"/JFN
MNLB":JFZC;`9CH***V:DBM,Z_=4/SG.XWD">SF:P_.O8GNU1Y,B@1NFZ"^-?
M"E0:6AC33C_!7EH@J>WJKNY]^$>I[+V6SN7/+4)E_D#5KB3ION[Z[D0;5*5U
M<[I*WN1L7N.<KDCWOF](L4K[WDI]Y;[-C<L![\P13XN.1[EJ5._V<_!AE_`*
M/Y$Q=]2H6S[,F>UDW*VLYZY_D)5+4('Q):3QZ,[QEI061X/=NM>7-5HG1*M<
M&9YP.5M+6;;:!^K&#(I52%'PC'3R!=V58+WF'![N`\Z"J:/J9Y=:G1&4>>O$
MXIZ]J@U,^MWI2,_T"UCL3=_)T&[?E06>5=[U]/3USI/IK\Z%65W@W@?N+>GC
MY,[RGLCVQ3URW[3>B2SWF&ZR%NOPYBLS9L^S+@_WGNN:053N]9/X_[3=\%Y9
M$7A5TC;/8O>V<*F*=GX?XL`(^'4\[_1N]$>N]RD,FT1EEYQYFPE1FR@UF2M>
M\E.GIO/JGL;5K\AUMNNIM9^!VGY.WXE:SCPMVG$D4ZJ?5M/Y^I:9_'GI5INI
MG2KE^I<W\K][AL#"L,@N]2FWH<+J:2WXT.=']TG.HVU8^<W?_)AY_JRO_+C)
M_#\^]K(L_B.RPM%>;,G9^7P,_[\J_W7/F@`!H,#``@('&B284.%"A@T=/H08
M4>)$BA4M7I0(0.-&C0TY<L084N1(DB47?D2)TN1*EBU=OH09\V1*F35MWL1Y
M,.5.GCL])D2(<&3'G$6-%N7),.E1IDV5]O]4Z53J5*I5=49U2K.B4*M=@4(%
MNU2A5I8&-WI%ZU7L5[(2`[P-T#1N2+ASCX8%F5;O7KX3?4K%.K:@4H)"!1HN
MW/<E7L9YQWZ,:9BK8LHPUQ;^^[#N0KL%YG:."YHS0=&>20\LK7!SPM2F73:>
M7%GV[*:9:__4.?A@XMV)N1ZF;1)V8\)`(\\,GIRD;;:0-8]VC9IA:-;5K4N/
M_OGZ=NFM.Z^$K5S\^,7,R4<D>A[C<,808[>,?5;]_)F!FSNFCS9\?O[]'[?U
M+\"0V,/KI-[>*^NA]`04S[RKG&,0,.)N"LJX@BK4[4#>$$LOJ-\R!#%"IAP4
ML42/"`3+*@0Q6]%`Q+1()-'%R":T"3$--[000PXMU`VXWGZ4,:<8@W01Q10=
M:A$^OY(D4D(`'X2PR1G;DY))*6L:\DH&C81*K:T6U/^2JLN@Q"],X6@T,TV<
MLE0S/RY[$HQ'(2\"LTVC8'S23HOV^S)*/?^\T#Y`^WMS3#$'M'+0,P4ELTY%
MW4-3P2/KDV]/22M-]-'7\M3TO$)M,PO(.T6JM-/R&`W43U,I#8NB+D]TS$99
M1;TJ3A!#Y8W65='C=-?D/NTUJU(11=77)5%E4U,^+8MS5AQ%_3!#9X',U-=D
MC>T*6&VWC9181[$]EE%#5UT6W%VO;9!;===EM]UVP1O67%<='%?9;N7]TUU]
M]^6W7W__+72Y,O&=-\]Z%2V78)D`9KAAAQ^&.&*`2555X7`';K1:,Q.VF%>)
M/P8Y9)'U+5'C8COVN.)4,49B^%YC1X8Y9HF#0Q>WDON,%^4].:U92X[#E#EH
M%)$,5N>46<XH2"M/SE=HIY^&.FIMTSS8Z$N9MEGIHU^6NFNOOX89VYZM9E%E
M!7V^6N.-P6:[;;>Y9#5G<HLF&U:SLZ[R*:3_6WZ[;[^[%ACK0:NN.VZYB]OX
MO\.M)KSLNRFFN\;(CYX4W\8!';ON:ZOU<3"UAY(3])4_E_?RT1>'7'`L)Y]:
MX<S5?)UQNDW>#5=I#<RUQPYS#'THL[XM/.-$3<?Y<0IGW];BV(%>'N6J20^^
M3=.)+UCUA5G'ZF>N)V_:^NB'A#YZZ=&E_N*]UV2=:"H);MYG[K_G6?R.IV]?
M;^\MFQW2]2U_W\[RR1Y3^.0WP$<E27O6JA_";(6?4N4E*M/2G:,ZIS??+,B!
M%PJ4XFI$*ELI*4'0NA$!1>@J\[V*??UC7ZXF@Z';R>EWM\H=CR[80=MY3H4Q
M7)CH;@69WS@'@CWB=QT.<5C#$1;1/<6K7.E0:$2="?`U3(2B8CCGLNW=+XJN
MNV(6.Z6V`VK1B\KZHA??(ZL*L;"&*VQ6CG0D1!)ZJU5AA.,6XYC%:$$P5,!A
M88A"=$9J_<B)<RQBM*35$0]9<'>8PIWGB.)`1!+2D(]\T"`/";S[)!&0:9?$
M9"8;M,`^^A%W/VQA".-3G%%R$H:GU&0J5;E*S+'2E:^$92QE.4M:UM*6M\1E
M+G6Y2U[VTI>_!&8PA3E,8A;3F,=$9C*5N4QF-M.9SX1F-*4Y36I6TYK7Q&8V
MM;E-;G;3F]\$9SC%.?1.<I;3G.<<WQ_1N4YV:O%_[81GXN)Y%SC-TYX%%(`Z
M[YDVGUCPB/L$**$$,%!]]N5-F7Q5Y_)H.SYBT*$+=2@,/V2C@%;4/0/%:$'U
MHM$XB@57/5RD'F<8RAUI,)2ILFA*/8)1EG)417/J'9;2F4B%!A&(SR*I<2AZ
M.XBJU*<'86E073J5H2:2AIY$)5)%V4FTN9"0G3P+0W,7U3T^-894_:E*`1!4
MKA;U+DYJ#HM,RE0@KA!U@/1J5KNY5:YVE3YI->I-:=70/=J4KFK%*RR[6!FX
MVD\R"H7D82"$53).,*^'1:RN$KM8QLJSL8^%;./0>#:B_T+6LI=5+)*2BKC;
MA!-Z?<5L/`4I4J5.BZZ[VRQEQ5G*I9[TA74-K5I'.UFY1M*&8[6C7\J)H)'>
M$*<GC:U/9VO4FN+TM#;5(V=7RUDBNA:$H`TN&]5G2#K1Z2]@6N0#_QK6Q^2F
MN^L!K5DE2%RK%M:YME6M?OZY06O!2I)B1>E<HSNB>;'%N_7=F:0PLU^Q=LB_
M]XTH`[E(23GNQ4/&52-23:O@!&>6<?/]:KC\*I]'QJIB!(Y28%^87?Y2][]D
M.E%$7R;%J?K1A_8%,6E#6%OH0EB$)K/P5P#L2!GSMY+#PG%@:$SC[]:8PR*N
MTX]'3&*H"K&4K/5M;EV\R^'U<&;&K\T-=6T\Y:<`>468BE>0_PIE$9^NQ8OB
M%GKX6N(,QG>'6T9Q!@O9TR7G,E-DD7(_L8RQI<P9P/6!;X^I/&<L(T<Y[$IO
MFP4]*M&N2[.#1C2A"ZVNN";:T3*=)Z!C^FA*/S'2AI:C;J4U79(O%U/2G=[T
MDD$]3$"/.M00-G4P)<VW=YYZEJE6M=<,_"E7&Q/6P/P;%2=,LEH3\]:_S'7?
M>NWK2P<;;)D>MIO/:>RG53?9N%XMLV>6PV<#FYO2]M=+"[C57U?;4M7$=IAI
MT^ULL36CWOXS-,--(`&16T)M):@M$^A.9:Z[GDV]DD;@+=3I&@^W^2T@>/4,
M<$0-O,H'AQ2>R_)F7Z_[7/]KV_>YQ>QLG6[%5`.FLIFAM-\89_S#]YER5-%<
M8XY+)N3`(W`'=6EO=\NFY<*"-Y.&VV@;'Y>LCOV2QBDLY.P>V,K(*=.'>UZK
M,N^\QQ_G^1B'5TN6W[N]F#-W/I/F0N52'95LQGF?:F[RC3_9Z__9LP^Y+.2'
M@E3``4;6TM'ZM7ZW;LC;EOE1JSY!FZ<VWP7W\=#1_G7_FO7H/M?[SG\W=B?G
MN>A*;^.+V1XX<;]=>932'YL9:-^7TU?@?\=NQ^\+$BW[&:4\KE6%ORO!0BI\
M\PR?W^+1Q^C!.3VTR:H\S>":\DG[[]CZP;32#AI=V%L[WVP;SZH]U:_Y]MZ7
ML0=?;]M$)/Q9AZSX^?,]96ZO)^;?2?5,7B+NL8;\QSL)<$ID_::D??SLJP7Z
MQ\>?K,57?7XVW=^QG+>PM@_MZDDMC)]V/]QZ&?_:G'__7G8:^,N_F"$_*WH1
M_W,EX`.V`0SMF_TKOW)C&NZKDNDC-0:,F@)\/X,J&@ETD^MK.`O\&PP\'[[:
M0.7QP`\$0?<3P;.2OA)D-?M3.0=DMM7+M16D/2ER0=U3/XJ3)99[*^>3P0SD
MBRSAP(PX04M;N_R;FX`)PA%LP9/A/@6LBB(DE!2\P28R0%7BOQ$)%E"CP-F@
M0A*TP@<T0A9\0E[CI2VD)R@4O^]KMW,9P_U9N#>2/ZBQP3#<M2LKH6:C&JJ)
MPZ&!#_VSK@&\0_4`GR-,IC],'GA11.*+M2PT/RELID9TE]6A1".))C4,Q!UT
MIDO\%^OS1">D)DV,/#=\IE!\&#$!P,%[BK\O/$54!,)(#,'#@KTCQ$/9@<6@
MJ<-9Y#UAXZ`FS$4[/!Y>;#-79)97"D9?;,.W&31C!`PX2L;Q8SP?;"QG)#+Y
MB485W!E*K"A)](];/,!L7,7VXT/*`9;=0L0F`4<A$<=&5!QAW,3&6RL"=#P=
M;,=[%!GO6T1OFAC-J4)\!,B/$4-YO#9:NZ(B#,B$A!C^8+]LLB2T4A&%E,A/
M5,?<6RMYDYR)U,AWL9?P@YUU5+17<Z.-),ES=!Z+W)B,`O])]J(E\2K)E]R]
M$6K(*FFK*RP29(3)G`3$)"1(<[S"6,&;&*P])(FX?%I)\+@_G51*&FDUQ?/(
M;TL\WU@,.BE*E00:;%S*K'S(4A3%@T1)B[,Z[JJY#5FC4S*CT(FZKCI*I.0?
MK71+2/3)M2R9KXQ*NS,0BFJHO(0M:%'+5FJ]MP3,B"1#`IK)];HYTL++(C-+
MW^)+HP0C(@',P!PW4C2:P@PTC?NW)+.K\I(AJT(V_^G`R-3*=J-,+'Q*,(0B
M"13-T62>P1P@RYPF4UO-I81#U\3*T\0FEYI-G<1%(:0CNOQ(F[P9)-I-F"3,
MGC'#WMQ'$V$WT!2>X@3(,H1+!,(:'MNLS9[\,XY,)^B,QGCT3?`3'!.Z3>P4
MS(C_H3[N',/^L\Z.W+X4&2VPG#H',\S:HCE+),_K"4#YA$STG$$-7$^X"\]Z
MDCS#\TRYN3)(HCG!ZR\"[;+DNT_B;$"H#$[^+$=#+,T)?3^/:M#BDBNIHJDL
MT\_-HZG6`BX'7<YWE!E(VTX*;9B*_,^_O!\0+;&S;*$\&B*ENM$@HE$/+=%!
MI,8I/$\6/='NF<XE+%+Y@A;1(SJ[Z:[2\ZL.`ZSW8LS4\<8QLSTA;<XJ^DYP
M:<JZU-(4W9(@Y4\4%4_J/%+VW%(3K%!\PU#>',DR-=(T-5,YA5%==!\JD4M&
MC,Z,+!"QN="U>=%O7%,7#;,\!3-WA,`^_=+D!$\Z';[\4FQ-[0S*2+6W[)3#
MZW34+?I3I!C4":Q$X1!3:_S!2XW3KC27+F5'2`542:604(U%/R1530W4*\U4
MWU%56(7-SEK1?>%277M!4^W5,R73"&U3W$3_35H51,<!UF)U/4Q=UCE-3GA$
M5N!D2%>%1%2]&DY+5#I<5.'L5FG=56/-F_&LU;D#5:+RU5]E5`"U4ZC[U&GU
M5C45UK%B*J3KT`8+L,.,RTUE2'ZU5*%A5W'UU'(-'FQ-FL2<41R]J[O:0X/=
MSUD=PDZ%UP>UQV>])(?M';HCL]I16+)B6.GD5FA=UXB]57?-U;F<5U;"6'K%
MJJ3R$<'#NC4ST:V4U93U3C!%4VHM$HC%I95ESG2M4XNU58"].#0D5*$%-W\=
M547]UD/%V:)E51E1VDR<6@N-U9J]&W#-68$ES2S]*9]%6:85V79U5HH55*/E
M0I[MJ*H-QX9E6QPL7UFLU=E_S-"Y)<<"&("\Q5N]S=L!V%N_[=N_-=12'=G0
MC$"@75JR'=LA#9`M/%FE"-S(Y=O)!5S*%=S/E+>WY<K/B8]F'5:PY=2X)5S&
MI5NDY32[11+)K=S5_=O655W,_P3&PEV3^IQ/`-R;O4I;HCU5M"U=V<U=TO4+
MRWW=X;5<T]5"S0VTGD(MDO+<&VO>]-/=W8U:PS7>C4+=U&5=XLW>XJU>30+=
MY2"OD+HAES0>W"7'D7$=WIT/Y%5%KG4/X87?[65=@L6D[]6AWZJ[SFVR6-7:
M8'U<,%3;WC7)]8A?URW@P*7?BV7?7:.\>AW*^C/%$YK>X`O@WV,]X02``];@
M[.U>A%I@_XQ>"9[@7ZE@N35)<[O!##9@^5UAUTU@GGSA,U3<]!WAR;19^+G@
MFKPR%M;>%AZ`&%[;$A[&$*;A&A[(D-4K3$O+OAP+'MY@%^[@^OU@NYEA>;W>
MYA-"^XA]326N2H(*"B<&8P..8@468F5]6M/\7UD$UIA\-4-;XI8:(Q]^8LD=
M8S(^T_Y-O7<%8"MRQ)9T8R8^FQX6Y,D%8F@\1(G-XS1NW^\DUA[\8\<DH4$.
MX[PMY*2$P=E]6"-6X\)5/J9SXSP4#$F6X\JMY.,4W4.A7O<MSV?MY,_-W-,T
MH-T094FN_V,TKN)PY`@"T&4.5%]<9F51!=E:#J158[@,GN,-%N:`I4<9U@A=
M=N9GAN9GEDT])EE&KM(IN>$7>TZXX2T=FV5D3N:)99@]SN5H-N=S1F<"T$UJ
MMEX^!F;U+.7O<5Z##,HO/F8PCF=<5>5MW8AT]N=_!N@I8F=?QN!K)N=DIJVJ
MP^;@,YP!-M>#^&9\#N=P16*X+6>`QNB,UFAU-F/@Y6>!YL0((46-/305E4IM
M9<G/9<))+8R('F78!2#?U<=FWNB:MNF;IF<L9M16IFAJ*TL2)2/\M9\%&M#?
MFLJV<SL"GN0GSN>K)&@`N.FHENJIEN;G766;-.C1I386H[#DZN>MC_V)A1JL
M$YOII/Z2>W[IIF;3(>YGJG;KMX9KCM:^KN3IPAGIBEO,CLUK74$CK(NI:68T
MVC'FEQ9EM;Z[TT6)N%;LQ6;LON*>K&:BNR;JE^U,RE:AQ;$PPPHZ.X/G?5R:
MEE[J29[H/FP_QC;MTT9M9PX?.)UG1/;@;(YLE/R6(`MMPA[MK#N(U-;MW79K
MY*$):;S#P5U5C\Z(VA9DPU9'I>#MY6;N73Y<3(S@>IMB*S9K.C'N`T9NR%3N
MYN9NJ>X5XINV>2QC<JWNK;AN'LYNK3F)[F9O:.:9?-3D:!OO];MBR"7L8[[_
M[;7.;>]N;W0VF-\&V.&@Q>FF;H=6)-UR:>+-[\,>BZF&:N86E.O"8Y6>[XX\
MV@7?XJ<LO)](</A-[YM<;P=_Z[;(C`O4TXHV(BW>9)F>(^;K9@/I\.W]<.;<
M;O[V9S@C\0G'9A2720'U'B3C0<2&[=C6<".49;16<`S7[A"/:ASW$Q-_:JO.
M<#A)Z-I%:=VZ6^SS2`.JD!A?8257[P;W;Y5X$BC_5QYWRNOZ)'S=T9\.LJQI
MKF%-0XM$/,A%\OB=\>7+PYPQ\RU!7!S.GLCKHSI"KBHGLQ8A\$1>3JZC*2]7
MW3P7:0/5\4Q&\V$V]$.7(:%.K3@VZH:>\RW7LOAPI73*A?1(OV5EEG(QNA06
MT]'*%JGLX6Q0UG*S+;,FOG,6!G.I=1C-^?,T8[('%O)<)V\#YQ6@N/46%O:?
M%3?A/F*:W7-R2G1%+V_S/F]D3_;E,]\0C>FKI7!M!U\WJ_!AS^F#$_5J?]U2
M[UJ0*D/:!?1*WV;/G+CD\K1PIV^!_:B3./9SOW9=3SO[8/9F9^T]%U^YHU$3
MT_0D3ED6+_!Q1U$[OV_15O_XLE4Z?T_Q/]=0XBJMP7*J>!4CVU1Q=65XZWYX
MVXYXB:?B!L*(NH"+;QT;&27X*;6ZG5+9^@EX<5]IPZ$6<Q=>=-_9?I=3E0?Z
MQ4T@K<CLP_.GRS:L54+55CGZDF[4:8?@?3Y)GW]6H+?ZZ,".DO@.\LCV=L+6
MA,HI!#/+UU)>/IHH8%]DXL9<J;=E2;<BJP]ZN]CZU<B.E8<.U3@-NT<-O4][
M9V?%H2_Q%8NOI!^I@J?/PA?+:E9[S+TE/'E[N'^+[L!ZK-<.RK_[ZRB-UBCK
M5"^VA']SCE5,5@_[O4Y,OVYG6C\F0_F?JS^-UL]ZZ]#\R<_ZS#]]=^_\!9\M
MSB362\MV+=T//;2$=YV&>F92??Z;^]>O_-C?^NR`?>[8_(\?17IWN4=%_=2G
MEVC'=FZW)^R?>O+D_,:_?ND?6-N')^Z7=F)W8!2\,/,_6['M1O&O=^_/=(%1
M^O<><I,E?Z^'_W:?=H0%B`("!Q(L:%`@@`()#S)LZ/`AQ(@2)U*L:+$@@(P:
M,S+<N/$BR)`B1Y(TZ/'DR9(J5[)LZ?(E3(PH8]*L:?,F0I0Z=^K$:5(A4)]"
MA\;L>=`HT:1*!_*<N?0IU*A/D29=&-*JU*PRFW*EVO'E0HY:Q_]F]<K4*=FT
M)+M^5.OV+5R3:*M^91KTKE6L"<5BO1MW+=O`&B/V+:FW\-_$*LWF3"DQ`$'(
M0R5;I%Q`LN6:@A$K[NSY)F.?G!OO/6K7KM[3GT%N%KST\.C5LAV&#ETP\^T`
MNB/KIMS;]V_,D05:QMR;(>[+QXDO9[EY-O3HB^<2Y9P:<5Z"I;7[E4ZX-=NC
MMJ]N]6Y>KF/T'BDVOTW\8>;BPR^_/YB<MW#D+I^?[^]??5M*C3986&(U1AI"
M/_WW$'CAO2;>@N;51EU$O@T4GX7U:;BA<?1=^&&%'H(HXDK\17BB=.,M&-N)
M#78%H('[=<0BBF_M)!Z%O,TGXFXD0@;_W(@C]I@AD`;U6)]\S.WG6HU-?G:C
MDU$VY")7$-$HDG4Q2@D7E%NEMR5.)H(YIE9=DBDEE4U!V!U84UYYIH",F0DG
M6$S:5-AV%+U9%YU3J=CG>6GRI&!8FC&X)Z"@R?EGHA>)611W"0(UV%D&7L?=
M7C%J6:"6C4[WI:<K"FH6J#"Q2&FHKRV:8ZJ.VDE3H9&FYE>LV:$6Z:2JX=KJ
M2(SR^N2HK%9G9:>_WLFJK\;.&)BBJL4JZ:P<V9K@K$'EB9>R6`J;[6K!4K>M
M<]]Q&R:RX(X+HYIW8@2MK.VRFQ.MI^69%Z+GDA:@O;-Y6^JZH$U4;+Z?KH?C
MP`'3]BJ8]1I,)3"^"W>V;\'W*HSEOP`[S%JY_%ZL$,).6KPQL1J#K!;$#4.%
MZ,?_(TLTH<@+/ZJRL<G"K&K)?=D\5+TIS^RFQC)G^_+.J?H<M%`U;]JO:!:A
M2O1W/9M[+M!-,]WBTU-79S19$R]M];(1:U?USQT?"C;7<0U=-JQ8?[UUTJZB
MW;77$K/MLMAPM_SV7V?CO63-[DZ\EK9[K\WOG'0SV_2@INVZ\I3]_FVUWH*7
MJ#9J.D-ZE>5!%\XQV;Q&S;#(-\<[^K22*DAZZ8\K&[GDAE&>=:^LC[OYYO9^
M#OK<NEKK+KNG\J7KLYSG#K+LK6O;=TO[`A8WT;07#^?M/!/F..^[FWZ]]:0O
MSO3SQF-L-/AINFXR]QDS;WO=`FNZ=(#5WELI@MB3/W+M8=X/'C[^^3NXO.KY
MLGS^[-)GO_]T+T+Z.R`"$QB]BO7/?^:;'[<6.$`)=0YG"KP@!C.HP>$QD(,[
M^Q\$5R?`"08*7!L\(0I3J,)@\2]S*@.A!STW0A+&:84VO"$.<WC"V,7_4',/
M[*'09DC#2NFPB$8\(A*1B+D03@V&+FR4!%N7Q"E2L8I6S!]MEOC$#_YPBWV*
M8A.O*,8QDE&!9G,5$R&WJKN%"HP;*R,<XZA$BC5)86Q48X[J%\3#P4R.?OQC
ME:+3P,2@#(!X<UX%S^1&*`*RD6;<DNP&F3<]&?*0:ZPD(_G8*D<Z4HJ)Q%Z-
M]H1)2^:Q@%33I"(YJ;^B?-*'=^13E*[TRD2ILI:VO"654&3*B^E-DIZAT2@]
MA<MA$O./>PQFV<[FRX>-#8B9+"8THYG#`,Z2:\I4Y,'2V$9I<K.;">1E*[E8
M35!"DF=>_*(WTZE.\;D2F=;LW#*[!;J`K;.>#?;<UB[1%,Z9^2R>3V+_F,'N
M*5!NHM&=PMQG'\GF3WG>;Z&A'"A$.ZD^9QY3FVA+ED/_2<1SHC.B'K6B9A":
MRG&&\94YLUE&ZW(M\DAL;WKTDD%7EL^*O!1'&PTD\40ZIID&M&HYPU:!U@8O
MOJ"J?93ZB$6S*#R..DQF/.4I)6=YHT7*D*3/3.H[[_C37&'+=,&[%-*RQR;R
M9"JE597J3&L:TJ<I+Z=6I:5.W8I).U++J[H;G?RN]]5PP4MR3HTK3"EJ*G-!
M[(6`U>=;VYG&0A)HJ44EJJ6.RC[)0E9&G@2;6I4&59EJ=5!4W>1A$1O3\K7,
MK$.4S5\3VTRL#K:S3OEL105[4-7R$Y^G!2UF:].Z6<1A=6NPC2U3Z;1;J-GV
MML!E[&AY*UN^!7-`0@P;;:$76L.=S[3&!59NIYM95FHUF_L#9W1'FES%YLZZ
MU_VE0J?KV.!.5&>Q^>TVP[M3]=(36><]KBAU2U_.5A*8SQ6A?.<;X#=2R+SW
M_SVP5/R+2NJR=K9Q$UV8W/:OL9"*I7<U#%^[`V$$0TZYZ9)K@VT'RV?M%5?1
MDM?VR&E7CJ&X<GU-W>58@S2CTHNHG(M?9&WL0=$9F,-?Y.^+0+S<GL*FQE[:
MU8GQ5-[&A76OTZKQD*=G8??-2WLMOK)8!T0H'U^T@T$F\("%1KV[EEC#O"MS
M6--LY;JN>*QMFO+V-@R\O*[9S6SJ,9>%ZV6<@GF\$<178P\$O[(^=CO1DA8L
MT3-G'#MK<#'6K&2)"+_X32K'@FX+94<<XCR+.*K?;>I^.1U+V(FZU!/V])?!
MZV=3ZYG5KF8F3?\+X%6_.F&UOC67"IIJ4(<9UP;T=7MMH_R]Y4KR;_`%-K*+
MEFSZS;BH-^XJ7N8&X?8]&Z]*&_:NEZWM,FT;S$I-,E=/=U.5^HV.V.9SM]/]
M('43K]':*TVU\#1C+`<5S^R&GII[Q3BE&NID]Z;GF%F,5QCW=7$D+G'I_LV]
M>4=;KRNV%"CI=>5#/_S,%9=7PA6!KO&-<WG:#I>TH.O<YNPY!C;COC.]/\[Q
ME;/\O!ZOL[Q%#FV2*R[@<4ZYM5NN\YU[[^4W-K*1/QYSU'$J=>L[^J!!GG.>
M,[WI$W2?TZ,N]:E3O>I6OSK6LZ[UK7.]ZU[_.MC#+O:QD[WL9C\[VM.N]K6S
MO>UN?SO<XR[WN=.][G:_+3O>\Z[WO?.][W[_.^`#+_C!$[[PAC\\XA.O^,4S
2OO&.?SSD(R_YR5.^\K<."``[
`
end


begin 600 Image74.gif
M1TE&.#=A"`%*`/<``````("`@(```("```"```"`@```@(``@("`0`!`0`"`
M_P!`@$``_X!``/___\#`P/\``/__``#_``#__P``__\`____@`#_@(#__X"`
M__\`@/^`0$A02&AX:`0$!`@("`P,#!$1$186%AP<'"(B(BDI*55554U-34)"
M0CDY.?]\@/]04-8`D\SL_^_6QN?GUJVID#,``&8``)D``,P````S`#,S`&8S
M`)DS`,PS`/\S``!F`#-F`&9F`)EF`,QF`/]F``"9`#.9`&:9`)F9`,R9`/^9
M``#,`#/,`&;,`)G,`,S,`/_,`&;_`)G_`,S_````,S,`,V8`,YD`,\P`,_\`
M,P`S,S,S,V8S,YDS,\PS,_\S,P!F,S-F,V9F,YEF,\QF,_]F,P"9,S.9,V:9
M,YF9,\R9,_^9,P#,,S/,,V;,,YG,,\S,,__,,S/_,V;_,YG_,\S_,___,P``
M9C,`9F8`9ID`9LP`9O\`9@`S9C,S9F8S9IDS9LPS9O\S9@!F9C-F9F9F9IEF
M9LQF9@"99C.99F:99IF99LR99O^99@#,9C/,9IG,9LS,9O_,9@#_9C/_9IG_
M9LS_9O\`S,P`_P"9F9DSF9D`F<P`F0``F3,SF68`F<PSF?\`F0!FF3-FF68S
MF9EFF<QFF?\SF3.9F6:9F9F9F<R9F?^9F0#,F3/,F6;,9IG,F<S,F?_,F0#_
MF3/_F6;,F9G_F<S_F?__F0``S#,`F68`S)D`S,P`S``SF3,SS&8SS)DSS,PS
MS/\SS`!FS#-FS&9FF9EFS,QFS/]FF0"9S#.9S&:9S)F9S,R9S/^9S`#,S#/,
MS&;,S)G,S,S,S/_,S`#_S#/_S&;_F9G_S,S_S/__S#,`S&8`_YD`_P`SS#,S
M_V8S_YDS_\PS__\S_P!F_S-F_V9FS)EF_\QF__]FS`"9_S.9_V:9_YF9_\R9
M__^9_P#,_S/,_V;,_YG,_\S,___,_S/__V;_S)G__\S___]F9F;_9O__9F9F
M__]F_V;__Z4`(5]?7W=W=R'Y!```````+``````(`4H`0`C_`!T('$BPH,&#
M"!,J7,BPH<.'$"-*G$BQHL6+&#-JW,BQH\>/($.*'$FRI,F3(P&H7,FR)8"#
M+F.N1$FSYD:9*@OBM&D0YTZ!/F4.]#DTJ%&"1I,JG5GTIX.@2)?NE$KU94^2
M4)\JU?J3*-&)7YO&5!B6:U6Q+LDZ+6NV)4^=9;.V33N7)5JZ==WFM=HS+E2Y
M487NS1E8,%"GAQ&_7<RXL>/'D"-+GDRYLN7+F#-KWLRYL^?/H$-#7)J0=&*\
MHD$#MDP5KNG!"+?&'GN:<&VVLZ4V?'VWZEJ:?]/ZMOH5-^S!=E?W9GK4H?+E
M?(]#=RPWZ6V]Q0U'5'R=*4R[8(\:_^]NFRUWGN:U9S4^O##J[V?[#H_NGC=T
M^N2]I][/O[___P`&*."`!!9HX($()JC@@@PV^)9]KC4WGH,46J0;?-9)5Z%-
MU6FW6&L19KCA9-R=QR&(^0F&6WOUK<=BB/')A^)\&;YD6TGQ^9;???1E1R-X
M+3)7XEHK(I:>AP]Z15I879FX$&#/38?<>1/N=9^,>C7FHH1$"E5E:4,B&21^
M*:KHI'1AOI=DEVSBY2-M,()'I8DOQID<G48B>29*4.9IF%\T2HGABS\".:6(
M.XZ994VK>;@EG%CB">F3S3&$(J65#KJHG3>.Z.FGH(8JZJBDEFKJJ:BFJNJJ
MK+;JZJNPQ@TJZZRTUFKKK;CFJNNN_Z9"J"B07_(ZYF87:MJDF,)R*N2D'_IZ
M:'E["EMIM"<5^^NFR6ZG6+`F75HFMA(Q:Z&Q^CD7I5K(1EJNE8]Y.Z.8,4J)
M6KS*GONLH846]]2^W5Z:X[;S7>O6C_4B^NV;^6('%)_O%LMDH3SZVR:V#P,Z
M5L*3=BI2<-C]:V::=&%,+F%%?@ROGQFGRZB2`U\\\9W((CSOF<<:K*ZAG`Z;
M,W4R3]7S3-R.?&.5%<=K[\OE4MMOS3]#ZZ72-^-'-,`Z:A@U7T>JN2:<-39-
MG,KH,CNAN$*[K++74;=;])]HLWNUC2?'K'%X/LN-=*=08X4RI&L#"[)P<\9-
M+X]6IZCSX5F,]:E>VP?WO6[$75O,-L&*%CQWM52_YWC2`2>:6]609]JXN'^#
MO7'6.#^J];T:4^NMY6>_[GF]K9+]D>V8FOXYSMGV[OOOP`<O_/#$%V_\\<@G
)K_SRS/\>$``[
`
end

From don at lexmark.com  Wed May 28 12:06:42 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Separation of PWG and IETF activities
Message-ID: <199705281606.AA06284@interlock2.lexmark.com>

--0__=urMNDk2o5XVzGdWekujhtsUfoBTmt3cAIGtAR9IuAu15Iz68vvLy1BkC
Content-type: text/plain; charset=us-ascii






(Embedded image moved to file: PIC29258.PCX)


To:       pwg@pwg.org, PMP@pwg.org, JMP@pwg.org, ipp@pwg.org, P1394@pwg.org
cc:
From:     Don Wright @ LEXMARK@LEXMTA
Date:     05/28/97 12:06:42 PM
Subject:  Separation of PWG and IETF activities


Through the course of the last few weeks, there have been
a number of cases where the activities of the PWG and the
IETF have been confused.  In order to clearly separate the
two, I think the following needs to happen:


1) We need to add a disclaimer to the PWG home page clearly
   indicating:


    The contents of these WEB pages reflect work done by
    the people of the Printer Working Group which may or
    may not be submitted to the IETF, IEEE or other standards
    organizations.  Official IETF, IEEE, or other standards
    organization documents, if available, will be found on
    their WEB page, FTP server or other service.


2) We need to clearly separate PWG administrative e-mail from
   IETF working groups technical and administrative e-mail.
   Therefore, according to my understanding, since meetings
   of the PWG are not "official" IETF activities, all future
   PWG meeting notices will ONLY be sent to the PWG mailing
   list and not to the PMP, JMP, or IPP lists.  In contrast,
   the IEEE does sanction the regular meetings of a working
   group.  Since the 1394 printing effort is a study group
   and hopefully soon an official working group, a more
   liberal policy will be applied to the P1394 mailing list.


   I am not sure how to handle the notices of meeting minutes
   but my first pass at it says that PWG meeting minutes
   for IPP, JMP and PMP should not be posted or acknowledged
   on these lists.  (If a meeting "didn't happen" how can
   minutes exist?)  Am I going too far?
To insure the broadest possible distribution, I have posted
this message to all the appropriate mailing lists and I
encourage a BRIEF discussion of this proposal but ONLY on
the PWG mailing list.


Thanks!


Don




*************************************************************
* Don Wright (don@lexmark.com)        Lexmark International *
* Manager                               Strategic Alliances *
* 740 New Circle Rd                     Phone: 606-232-4808 *
* Lexington, KY  40511                    Fax: 606-232-6740 *
*************************************************************


--0__=urMNDk2o5XVzGdWekujhtsUfoBTmt3cAIGtAR9IuAu15Iz68vvLy1BkC
Content-type: application/octet-stream; 
	name="PIC29258.PCX"
Content-transfer-encoding: base64


CgMBAQAAAAA4AgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABSAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAADl/9L/yf/F/8L/geUA0gDJAMUAAAGE5QDSAMkAxQAAAcHw5f/S/8n/xf/C
/7g=


--0__=urMNDk2o5XVzGdWekujhtsUfoBTmt3cAIGtAR9IuAu15Iz68vvLy1BkC--

From don at lexmark.com  Thu May 29 08:29:35 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:44 2009
Subject: P1394> New Reflector for the Digital Still Image WG
Message-ID: <199705291229.AA01304@interlock2.lexmark.com>

FYI...


Don


To:       1394-sig%1394ta.org @ interlock.lexmark.com
cc:        (bcc: Don Wright)
From:     toni%skipstone.com @ interlock.lexmark.com @ LEXMTA
Date:     05/27/97 04:25:33 PM
Subject:  New Reflector for the Digital Still Image WG








Hi Everyone,
Tomorrow(5/28/97) we will have a  reflector set up  for the new Digital
Still Image Working Group.
The address is:  1394-DSI-1394ta.org
Please go to the MO section to subscribe to this reflector if you are
interested in participating.
toni
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Toni Tappan
1394 TA Administrator
512-305-0203(1394 Trade Association)
512-305-0212(Fax)
toni@skipstone.com
www.1394ta.org(TA Web Site)
1394 Trade Association
c/o Adaptec
3925 W. Braker Ln., Ste. 425
Austin, TX  78759
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From gregory_leclair at erc.epson.com  Thu May 29 15:12:34 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:44 2009
Subject: P1394> web site updated
Message-ID: <9704298649.AA864934344@erc.epson.com>

     The web site has been updated with the latest docs, minutes, and Japan 
     info.
     
     http://www.pwg.org/p1394
     
     Greg

From lstein at fapo.com  Tue Jun  3 10:35:29 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Sorry about this.
Message-ID: <3.0.32.19970603072823.006d6780@pop3.fapo.com>

Sorry about the distribution of this email.


The Marriott hotel managed to screw up the accounting for the May meetings
in San Diego.  They're giving me a hard time about the meeting charge
payments made at the front desk.


If you made a payment at the front desk please send me a note with the
amount and date (if possible).  Please respond to me only (lstein@fapo.com).


Thanks,
Larry
*****************************************************************************
Larry A. Stein			Phone: (619)292-2740
Warp Nine Engineering		Fax:	(619)292-8020
					Web: 	http://www.fapo.com
*****************************************************************************

From lstein at fapo.com  Tue Jun  3 10:35:30 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Speaker Wanted
Message-ID: <3.0.32.19970603073305.006f5a2c@pop3.fapo.com>

Al Keene, from IMI, is looking for a speaker to talk about Internet
Printing at the 8th Annual Laser Printing Conference.  If you are
interested please respond to me (lstein@fapo.com) by Wednesday.  The
conference is July 21-23 at the Bahia Hotel in San Diego.  The speaker gets
a free room and conference attendance.


I'm going to be talking about 1284.4 and 1394 printing (possibly).


Thanks,
Larry
*****************************************************************************
Larry A. Stein			Phone: (619)292-2740
Warp Nine Engineering		Fax:	(619)292-8020
					Web: 	http://www.fapo.com
*****************************************************************************

From gregory_leclair at erc.epson.com  Thu Jun  5 21:19:37 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Agenda for Japan Meeting
Message-ID: <9705058655.AA865560862@erc.epson.com>

     
Hi folks,
     
I was asked to forward the following info to the 1394 PWG list.
     
If you're attending the meeting next week in Japan, please refer to the agenda 
and instructions regarding documents you may want to present.
     
     
     
Regards,
     
Greg LeClair
     
     -------------Notice from PWG-C------------------------
     
     
Dear PWG-C members and Guests:
     
Followings are the Meeting Agenda of PWG-C General Meeting held on June 
11th. and 12th.
     
PWG-C board requests all presentator to send PDF file of proposal
documents to Naohisa Suzuki of Canon by June 6th. (nao@cbs.canon.co.jp)  He 
will notice all the member how to access the materials.
     
And if the presentator needs to deliver some packets to Microsoft Japan 
Sasazuka Office prior to the meeting,  please ask 
Mr.Nagao(yasushin@microsoft.com) of Microsoft Japan Chofu Office how and 
where you ship those items.
     
     
     
     -------------Meeting Agenda------------------------
     
     
     
     
Date:     June 11th.
Place:   Microsoft Japan Sasazuka Office
Time:    10:00am to 17:50  ( Reception starts from 9:30)
     
     
     
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  Hewlet 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
     
     
Date:     June 12th.
Place:   Microsoft Japan Sasazuka Office
Time:    10:00am to 12:00  ( Reception starts from 9:30)
     
Further Technical Discussions
     
     
Place:   Microsoft Japan Sasazuka Office/ Apple Japan Hatsudai Office 
Time:    13:00 to 17:50  
     
If further Technical Discussions are remained, we might divide to 
Sub-Working groups for more concentrated discussion by topics.
     
     
Nobuhiko Shinoda
Chairman of PWG-C
     
----------------------------------------- 
Atsushi Nakamura
----------------------------------------- 
BJ Printing Technology
Develpoment 22,
Canon Inc.
tel:+81-3-5482-8396
fax:+81-3-3756-6052
email-1:Atsushi_Nakamura@cbj.canon.co.jp 
email-2:atsnaka@cbs.canon.co.jp
-----------------------------------------

From eileenh at apple.com  Fri Jun  6 12:16:17 1997
From: eileenh at apple.com (Eileen Chun)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Printer Workgroup Reflector
Message-ID: <199706062314.QAA22844@scv2.apple.com>

Hello. I got this mail address from the firewire.org web page. I would 
like
some more information on this Workgroup. I am associated with the Apple
Imaging Division and we are investigating Firewire solutions for our
printer product line. I would 
appreciate any information you could give me on the charter of your
group and any documents that may be related to your current work.


Eileen Chun
Apple Computer
eileenh@apple.com

From brianb at vcd.hp.com  Sun Jun  8 06:17:11 1997
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Printer Workgroup Reflector
In-Reply-To: <199706062314.QAA22844@scv2.apple.com>
Message-ID: <3.0.2.32.19970608031711.0077b348@popmail1.vcd.hp.com>

At 04:16 PM 6/6/97 -0000, you wrote:
>Hello. I got this mail address from the firewire.org web page. I would 
>like
>some more information on this Workgroup. I am associated with the Apple
>Imaging Division and we are investigating Firewire solutions for our
>printer product line. I would 
>appreciate any information you could give me on the charter of your
>group and any documents that may be related to your current work.
>
>Eileen Chun
>Apple Computer
>eileenh@apple.com


Please try our web site at http://www.pwg.org/p1394/index.html .


Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder, I/O Architect, DeskJet Printers
mailto:brianb@vcd.hp.com  |  Hewlett-Packard
Phone: (360) 212-4107     |  1115 SE 164th Ave.
Fax:   (360) 212-4227     |  Vancouver, WA  98684

From DMitchell at ti.com  Thu Jun 12 05:28:54 1997
From: DMitchell at ti.com (Danny Mitchell)
Date: Wed May  6 14:00:44 2009
Subject: P1394> Follow up reminder - AV WG meeting
Message-ID: <3.0.2.32.19970612042854.00ee6c40@dlep1.itg.ti.com>

>To: Multiple recipients of list 1394-av <1394-av@1394ta.org>
>Sender: owner-1394-av@1394ta.org
>Reply-To: aaronl@lsi.sel.sony.com
>Subject: Follow up reminder - AV WG meeting
>Date: Mon, 9 Jun 97 13:13:55 +0100
>X-Sender: aaronl@newt.lsi.sel.sony.com
>X-Mailer: Claris Emailer 1.1
>From: Aaron Ludtke <aaronl@lsi.sel.sony.com>
>
Here is the off-cycle AV working group meeting announcement.  


>Hi Everybody -
>
>This is another reminder about the off-cycle AV Working Group meeting 
>which will be hosted by Sony in San Jose, CA.
>
>Date:     June 25 and 26, 1997
>Time:     9 AM to 5 PM (both days)
>Place:    Somewhere in San Jose - the exact location is to be determined, 
>based on expected attendance and the availability of facilities.
>
>
>So, I request that you PLEASE respond with your intention to either 
>attend, or to NOT attend. We need this information to help plan the 
>catering and meeting space requirements.
>
>Please respond with this information no later than Friday, June 13 (uh 
>oh...Friday the 13th...).
>
>Those of you who do not respond, but do show up, will be required to sit 
>in a separate room listening to scratchy analog recordings of Air Supply, 
>the Little River Band, and that mega super group known as Bread. I hope 
>you realize that we're only doing this for your own good...
>
>
>The main purpose of this off cycle meeting will be review the AV/C tuner 
>model and command set, which has undergone some revision since you last 
>heard about it at the March meeting in Eindhoven. In addition, there may 
>be some other proposals that you'll be interested in hearing about.
>
>Remember, we intend to vote on the AV/C tuner proposal at the July TA 
>meeting, so it's important that you understand it.
>
>Many thanks in advance for your participation, and ALSO for your prompt 
>response indicating that you will be attending the June meeting.
>
>Aaron
>
>
Regards,  Danny Mitchell  ( Tokyo, Japan )


 BuS Solutions SW Manager ( 1394, USB )
 Ph: 972-480-3411     www.ti.com/sc/USB 
 Fx: 972-480-3160     www.ti.com/sc/1394
 Texas Instruments, 8505 Forest Lane, MS-8710, Dallas, TX 75243

From don at lexmark.com  Wed Jun 11 20:43:15 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:44 2009
Subject: P1394> August Printer Working Group Meetings
Message-ID: <199706121548.AA27330@interlock2.lexmark.com>

The August Printer Working Group meeting will be held at Microsoft
in Redmond.  The current schedule is as follows:


August 4th, 5th        9AM - 6PM        1394 Printing Working Group
August 6th, 7th        8:30 AM - 6PM    IPP Work Group
August 8th             8:30 AM - 6PM    JMP, etc. as required


Each of you is on your own for hotel reservations.  Recommendations
for hotels are as follows:


Double Tree (was Red Lion) Bellvue  425-455-1300
Hyatt Bellvue                       425-462-1234
Hilton Bellvue                      425-455-3330


Ask for the Microsoft rate at these hotels.


Maps, directions, buildings and rooms will be distributed in a
later note.


If you have any concerns about the above schedule (other than the
times which are fixed by room availability at Microsoft) please
let me know ASAP so people can make their travel plans.


Thanks,


Don




*************************************************************
* Don Wright (don@lexmark.com)        Lexmark International *
* Manager                               Strategic Alliances *
* 740 New Circle Rd                     Phone: 606-232-4808 *
* Lexington, KY  40511                    Fax: 606-232-6740 *
*************************************************************

From ohnishi at cbm.canon.co.jp  Mon Jun 16 04:27:13 1997
From: ohnishi at cbm.canon.co.jp (Ohnishi, Nobuhiro)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Meeting minutes -- June 11 and 12
Message-ID: <199706160822.RAA07350@leo.cbm.canon.co.jp>

--=====================_866417233==_
Content-Type: text/plain; charset="ISO-2022-JP"


Dear PWG members and PWG-C members:


Attached files are the minutes of PWG-C and PWG joint meeting in Japan (June
11-12,1997).
* I will add one more sub-meeting minutes( Section 4.7.2. Network printing )
as soon as I get the report.  
*The files of the presentation slides (mentioned in the minutes) will be
uploaded to Canon(or other ) ftp site soon. (I will inform when ready.)


If you have any questions , please feel free to contact me.


Regards,




--=====================_866417233==_
Content-Type: application/pdf; name="970611-12minutes.PDF"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="970611-12minutes.PDF"


[encoded data, 60968 characters]
--=====================_866417233==_
Content-Type: application/pdf; name="ddarch.PDF"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ddarch.PDF"


[encoded data, 9086 characters]
ZWYNCjYyNzgNCiUlRU9GDQo=
--=====================_866417233==_
Content-Type: text/plain; charset="ISO-2022-JP"


==***tel and fax numbers changed !!
Nobuhiro Ohnishi
International Standard Planing Dept.
International Standard Planning&Promoting Center
Product Development Headquarters
Canon Inc. Shimomaruko
Phone:+81-3-3757-6535(ex27543)FAX:+81-3-3757-7133
e-mail:ohnishi@cbm.canon.co.jp


--=====================_866417233==_--

From jkm at underscore.com  Mon Jun 16 13:36:19 1997
From: jkm at underscore.com (JK Martin)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Please RSVP to the June Meetings if you have not already done so
Message-ID: <199706161736.NAA04481@uscore.underscore.com>

[Sorry for the cross-posting, but this message must get out to *everyone*
 as soon as possible...]


The hotel is asking that we have a firm attendance count by Wednesday,
June 18 (that is, the day after tomorrow) for the series of PWG meetings
to be held Monday thru Friday, June 23-27 (ie, NEXT WEEK).


If you have not already sent me a message with the dates of the meetings
you plan to attend--OR IF YOU HAVE CHANGED YOUR PLANS since sending me a
message--then please send me (jkm@underscore.com) a message BEFORE NOON EDT
on Wednesday, June 18.


Following are the lists of people who claim to be attending the various
PWG meetings scheduled for next week.  If you have already sent an RSVP
(aka "ping") message, then please be sure your name is listed under the
appropriate meeting(s):


P1394 (Monday-Tuesday, June 23-24)


    Alan Berkema
    Brian Batchelder
    Danny Mitchell
    Don Wright
    Frank Zhao
    Fumio Nagasaka
    Greg LeClair
    Hamid Shenavai
    Jeff Rackowitz
    Larry Stein
    Richard Andrade
    Shigeru Ueda




IPP (Wednesday-Thursday, June 25-26)


    Angelo Caruso
    Bob Pentecost
    Carl-Uno Manros
    Charles Gordon
    Chuck Adams
    Don Wright
    Frank Zhao
    Greg LeClair    (Wed only)
    Jasper Wong
    Jay Martin
    Jeff Copeland
    Jeff Rackowitz
    Lloyd Young     (Thurs only)
    Richard Landau
    Richard Schneider
    Robert Herriot
    Scott Isaacson
    Shigeru Ueda
    Stuart Rowley
    Tom Hastings




JMP (Thursday nite, Friday, June 26-27)


    Angelo Caruso
    Bob Pentecost
    Chuck Adams
    Don Wright
    Jeff Rackowitz
    Lloyd Young
    Richard Landau
    Stuart Rowley
    Tom Hastings




Folks, we really need to have ACCURATE counts of attendees, so if you're
planning to attend one or more of next week's meetings, then by all means
please send me a message NOW if you haven't already done so.  Similarly,
if your plans have changed such that you will not be attending one or more
meetings (or if I have you down for the wrong meetings), please let me know
ASAP.


Thanks for your cooperation.


	...jay


----------------------------------------------------------------------
--  JK Martin               |  Email:   jkm@underscore.com          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

From ewa at apple.com  Tue Jun 17 03:10:29 1997
From: ewa at apple.com (Eric W. Anderson)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Comments on recent PWG-C/PWG meeting
Message-ID: <AFCB8678-10CC4@17.216.16.180>

[Apologies if you receive multiple copies of this.  There seem to
 be several mailing lists to choose from. - Eric]


Hello,


I have read the minutes from the June 11-12 meetings.
Thank you for making them available so quickly.


I would like to provide some input from a computer software/
operating system point of view.




** 1. FCP or SBP-2?


As mentioned in the minutes, there are some concerns about using
FCP for printers.  The specification for SBP-2 seems to be very
complicated, but this is only because it has been documented very
carefully.  I believe that SBP-2 would be the best choice for
printers, and I suggest that you give it consideration.


Protocol                           SBP-2    FCP
-----------------------------------------------
High performance?                  Yes      No
Computer friendly?                 Yes      No
Complicated?                       No       No
Needs changes for flow control?    No       Yes
Multiple independent units?        Yes      No




** 2. Device Discovery


1394 and 1212 use a flexible CSR ROM.  From a computer point of
view, it is very important that the CSR ROM be used as a tree,
so that multiple, independent things can be put inside it.  For
this reason, it will be very hard for operating systems to use
a CSR ROM that has device discovery information at the root
level.  It may be impossible for a computer to participate in
more than one such protocol at the same time.


I believe that the example below is most compatible with 1394 and
1212.  This example is a fax/printer.  Please consider it:


      CSR ROM


      ROOT ---+--- UNIT1 (PRINT) ---+--- UNIT-DIR (SBP-2)
              |                     |
              |                     +--- UNIT-DIR (Vendor-Unique)
              |
              +--- UNIT2 (FAX) ---+--- UNIT-DIR (SBP-2)


In this example, the Print function and the Fax function are
completely independent.  Of course, you can build a module with
a single embedded controller that performs both functions.  Or
you can use different controllers.  Either way, the CSR-ROM looks
the same, and the same computer software can be used.


Why does independence matter?  Unlike a printer, the CSR-ROM in
the computer will depend on what software is loaded.  It must be
possible for many different units to share this CSR ROM.  If they
all put their information at the root, there will be a conflict.


Consider this example:  I have a legacy (parallel-port) printer.
I want it to operate with my 1394 scanner.  I can write driver
software for my PC that emulates a 1394 printer.  The PC will have
information in its CSR ROM, and the scanner will "see" a real 1394
printer.  Now the scanner can print directly to the printer, using
the PC as a bridge.  No application software or GUI is required on
the PC.


But at the same time, I also have superior OCR software on my PC.
I want my 1394 fax/printer to send faxes to the OCR software.  The
PC will have data in its CSR ROM to describe the OCR software, and
to make this software look like a printer, so that the 1394 fax/printer
will send data to it automatically.


Here is the general problem:  Both the OCR software and the printer
emulation software must put data in the CSR ROM.  But, these drivers
are made by different vendors.  They do not cooperate, and they cannot
share a common root-level interface.  They must have different register
addresses, so that they can operate fully independently.  This is why
the original 1394/1212 CSR ROM model is so powerful.


By the way, FCP uses a fixed address (FFFFF0000B00), so it is
impossible to have independent FCP units within a node (such as
a PC).  This is one of the reasons why I believe that SBP-2 will
work better for use with printers and similar devices.


I welcome your comments on these matters.  Please be sure to send
them directly to me, because I have not yet managed to get on the
mailing list due to a problem with the server.


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------

From DMitchell at ti.com  Tue Jun 17 05:10:28 1997
From: DMitchell at ti.com (Danny Mitchell)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Re: Device discovery on 1394
In-Reply-To: <Device discovery on 1394>
Message-ID: <3.0.2.32.19970617041028.00af4194@dlep1.itg.ti.com>

Peter,


I believe the problem I am seeing is the easy determination of what type of
devices are out there.  For example in current os's a generic monitor
driver can be loaded just by knowing an unknown device is a monitor.  For a
printer or other generic device ( like a camera complying with the sony
desktop camera specification ) could be loaded.  In the case of a low-end
digital camera,  the camera would like to be able to assess that a printer
is out there that would support the "Digital Still Image" protocol with
very little overhead.  


This is where the PWG(s) are coming from.


Unless you are stating that the >From: PJohansson@aol.com
>Date: Fri, 13 Jun 1997 13:47:41 -0400 (EDT)
>To: DMitchell@ti.com
>Subject: Re: Device discovery on 1394
>
>In a message dated 97-06-13 07:22:56 EDT, DMitchell@ti.com (Danny Mitchell)
>writes:
>
><< Even if we decide to use an SBP2 transport protocol there is no method for
> device discovery.  This begins to push us to an FCP like protocol which at
> least has defined methods for device discovery.
>  >>
>
>I believe that there is an education problem here, not a lack of "defined
>methods for discovery" in SBP-2.
>
>The method is simple: the initiator examines configuration ROM for a unit
>directory with a Unit_Spec_ID of 0x00609e and a Unit_SW_Version of 0x010483.
>At this point the initiator knows it has discovered an SBP-2 device. What
>kind of device is it looking for? A printer? A disk that uses the SCSI
>command set? A still image camera? An Internet capable node? At this point,
>in the same unit directory, it takes a look at Command_Set_Spec_ID and
>Command_Set to find the desired match.
>
>To make this example a little more concrete, if the PWG invented a new
>command set that is unlike things that have existed in the past, the PWG (or
>whatever standards body becomes responsible for the care and feeding and
>future extensions to your standard) would acquire a 24-bit "company" ID from
>the IEEE and then pick a number to mean "PWG printer command set." These
>numbers would be Command_Set_Spec_ID and Command_Set.
>
>FCP operates along fundamentally similar lines: the searcher (initiator)
>examines configuration ROM looking for a unit directory that declares itself
>to be FCP.
>
>FCP also has a broadcast "Is anyone there?" feature. I think I can safely
>speak for quite a few in the 1394 community who believe that broadcast is not
>as attractive as it might appear---particularly if the volume becomes higher.
>Among broadcast's problems are a) required fixed address offsets to receive
>the broadcast, b) FIFO overflow problems in devices that have to receive the
>broadcast to determine that they're not interested, c) probable poor use of
>"global" broadcast in a bridged environment and d) lack of confirmation (did
>you fail to get an answer to your "Are you there query?" because no one was
>there or because the broadcast was discarded by a target whose FIFO was
>full?).
>
>Please feel free to recirculate this with the PWG.
>
>Regards,
>
>Peter Johansson
>
>Congruent Software, Inc.
>3998 Whittle Avenue
>Oakland, CA  94602
>
>(510) 531-5472
>(510) 531-2942 FAX
>
>pjohansson@aol.com
>
>
>
Regards,  Danny Mitchell  ( Dallas, Tx )


 BuS Solutions SW Manager ( 1394, USB )
 Ph: 972-480-3411     www.ti.com/sc/USB 
 Fx: 972-480-3160     www.ti.com/sc/1394
 Texas Instruments, 8505 Forest Lane, MS-8710, Dallas, TX 75243

From atsnaka at mxa.meshnet.or.jp  Tue Jun 17 11:16:14 1997
From: atsnaka at mxa.meshnet.or.jp (Atsushi Nakamura)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Re: Device discovery on 1394
In-Reply-To: <P1394> Re: Device discovery on 1394>
Message-ID: <199706171517.AAA26944@meshsv02.tk.mesh.ad.jp>

Some comments regarding this issue,


> >At this point the initiator knows it has discovered an SBP-2 device.
What
> >kind of device is it looking for? A printer? A disk that uses the SCSI
> >command set? A still image camera? An Internet capable node? At this
point,
> >in the same unit directory, it takes a look at Command_Set_Spec_ID and
> >Command_Set to find the desired match.


> >FCP operates along fundamentally similar lines: the searcher (initiator)
> >examines configuration ROM looking for a unit directory that declares
itself
> >to be FCP.


This is exactly the issue we want to solve;
Currently in the above example, there is no way to tell that a 
SCSI/SBP-2 device is not a disk, but maybe a printer.
There may also be an internet capable digital camera,video
camcorder,scanner......which one will it be?
As for the FCP example, the initiator will find a FCP device,
and furthur know that it supports the AV/C command set(for example),
but it will not discover it's actual function(printer,camera,stereo...)
unless the initiator supports that protocol and initiates communication
in AV/C over FCP, then inquiring.


The unit_directory definitions of current transport protocols
is defined in a way that the initiator will discover the characteristics 
of a node by it's protocol first, and then finding the actual device
function by "talking"in that protocol
It shows that the current ROM definitions support protocol(device)
discovery, but not function device discovery.


PWG/PWG-C's approach to the device discovery scheme
(not the printing protocol, they are separate because device discovery
is a scheme that applies to any device, not just printers.)
is to provide a common (protocol-free)"short-cut" to
discovering the "device",or functions FIRST, then the protocol
it supports.
It will not conflict with the existing ROM definitions (SBP-2,FCP),
but co-exist so that the initiator can choose discovery paths;
existing ROM definitions for protocol-first device discovery,
and the PWG/PWG-C path for function-first device discovery.


> I believe the problem I am seeing is the easy determination of what type
of
> devices are out there.  For example in current os's a generic monitor
> driver can be loaded just by knowing an unknown device is a monitor.  For
a
> printer or other generic device ( like a camera complying with the sony
> desktop camera specification ) could be loaded.  In the case of a low-end
> digital camera,  the camera would like to be able to assess that a
printer
> is out there that would support the "Digital Still Image" protocol with
> very little overhead.  
> 
> This is where the PWG(s) are coming from.


I agree with Danny's opinion. 


Regards,


Atsushi Nakamura
BJ Printing Technology Development 22
Canon Inc.


+81-3-5482-8396 (tel)
+81-3-3756-6052 (fax)
Atsushi_Nakamura@cbj.canon.co.jp


----------
> �·�o�l : Danny Mitchell <DMitchell@ti.com>
> ˆ¶�æ : pjohansson@aol.com
> CC : Pwg1394@cbs.canon.co.jp; p1394@pwg.org
> Œ�–¼ : P1394> Re: Device discovery on 1394
> ‘—�M“úŽž : 1997”N6ŒŽ17“ú 18:10
> 
> Peter,
> 
> I believe the problem I am seeing is the easy determination of what type
of
> devices are out there.  For example in current os's a generic monitor
> driver can be loaded just by knowing an unknown device is a monitor.  For
a
> printer or other generic device ( like a camera complying with the sony
> desktop camera specification ) could be loaded.  In the case of a low-end
> digital camera,  the camera would like to be able to assess that a
printer
> is out there that would support the "Digital Still Image" protocol with
> very little overhead.  
> 
> This is where the PWG(s) are coming from.
> 
> Unless you are stating that the >From: PJohansson@aol.com
> >Date: Fri, 13 Jun 1997 13:47:41 -0400 (EDT)
> >To: DMitchell@ti.com
> >Subject: Re: Device discovery on 1394
> >
> >In a message dated 97-06-13 07:22:56 EDT, DMitchell@ti.com (Danny
Mitchell)
> >writes:
> >
> ><< Even if we decide to use an SBP2 transport protocol there is no
method for
> > device discovery.  This begins to push us to an FCP like protocol which
at
> > least has defined methods for device discovery.
> >  >>
> >
> >I believe that there is an education problem here, not a lack of
"defined
> >methods for discovery" in SBP-2.
> >
> >The method is simple: the initiator examines configuration ROM for a
unit
> >directory with a Unit_Spec_ID of 0x00609e and a Unit_SW_Version of
0x010483.
> >At this point the initiator knows it has discovered an SBP-2 device.
What
> >kind of device is it looking for? A printer? A disk that uses the SCSI
> >command set? A still image camera? An Internet capable node? At this
point,
> >in the same unit directory, it takes a look at Command_Set_Spec_ID and
> >Command_Set to find the desired match.
> >
> >To make this example a little more concrete, if the PWG invented a new
> >command set that is unlike things that have existed in the past, the PWG
(or
> >whatever standards body becomes responsible for the care and feeding and
> >future extensions to your standard) would acquire a 24-bit "company" ID
from
> >the IEEE and then pick a number to mean "PWG printer command set." These
> >numbers would be Command_Set_Spec_ID and Command_Set.
> >
> >FCP operates along fundamentally similar lines: the searcher (initiator)
> >examines configuration ROM looking for a unit directory that declares
itself
> >to be FCP.
> >
> >FCP also has a broadcast "Is anyone there?" feature. I think I can
safely
> >speak for quite a few in the 1394 community who believe that broadcast
is not
> >as attractive as it might appear---particularly if the volume becomes
higher.
> >Among broadcast's problems are a) required fixed address offsets to
receive
> >the broadcast, b) FIFO overflow problems in devices that have to receive
the
> >broadcast to determine that they're not interested, c) probable poor use
of
> >"global" broadcast in a bridged environment and d) lack of confirmation
(did
> >you fail to get an answer to your "Are you there query?" because no one
was
> >there or because the broadcast was discarded by a target whose FIFO was
> >full?).
> >
> >Please feel free to recirculate this with the PWG.
> >
> >Regards,
> >
> >Peter Johansson
> >
> >Congruent Software, Inc.
> >3998 Whittle Avenue
> >Oakland, CA  94602
> >
> >(510) 531-5472
> >(510) 531-2942 FAX
> >
> >pjohansson@aol.com
> >
> >
> >
> Regards,  Danny Mitchell  ( Dallas, Tx )
> 
>  BuS Solutions SW Manager ( 1394, USB )
>  Ph: 972-480-3411     www.ti.com/sc/USB 
>  Fx: 972-480-3160     www.ti.com/sc/1394
>  Texas Instruments, 8505 Forest Lane, MS-8710, Dallas, TX 75243

From PJohansson at aol.com  Tue Jun 17 13:41:52 1997
From: PJohansson at aol.com (PJohansson@aol.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Re: Device discovery on 1394
In-Reply-To: <Device discovery on 1394>
Message-ID: <199706171517.AAA26944@meshsv02.tk.mesh.ad.jp>

In a message dated 97-06-17 08:21:42 EDT, DMitchell@ti.com (Danny Mitchell)
writes:


<<I believe the problem I am seeing is the easy determination of what type of
devices are out there.  For example in current os's a generic monitor driver
can be loaded just by knowing an unknown device is a monitor.  For a printer
or other generic device ( like a camera complying with the sony desktop
camera specification ) could be loaded.  In the case of a low-end digital
camera,  the camera would like to be able to assess that a printer is out
there that would support the "Digital Still Image" protocol with very little
overhead.>>


I'm still uncertain as to whether or not you and the PWG believe there is a
difficulty.


I read what you've written above and say to myself, "Ya, sure...that's the
way it works."


Is there agreement that it is a Unit Directory that identifies the presence
of any particular 1394 device? If we are, the searcher (the digital camera in
your example) needs to read configuration ROM of the other nodes on the bus.


OK. No there's the question of the order in which you determine a) protocol
and b) device type. At the moment the presumed order is protocol first,
device type second. This is because there is no universal registration
authority to assign device class ID numbers---it is left to the specifier of
the protocol to assign numeric values to device class ID's. The SCSI family
of commands is one illustration: you have to know that the device is a SCSI
device, first, before you can discover that device type 0x02 means a printer.


Could you be more specific as to where you think the problems, if any, lie?


Regards,


Peter Johansson


Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602


(510) 531-5472
(510) 531-2942 FAX


pjohansson@aol.com

From DMitchell at ti.com  Tue Jun 17 11:45:59 1997
From: DMitchell at ti.com (Danny Mitchell)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Re: Sony proposal for Device Discovery
In-Reply-To: <9706160411.AA11559@newt.lsi.sel.sony.com>
Message-ID: <3.0.2.32.19970617104559.00af008c@dlep1.itg.ti.com>

PWG members.


Aaron would like to know how many of the PWG folks might attend the AV
group meeting to take care of seating logistics.  Please send him your
plans privately and not on the reflector.


Aaron is proposing holding the Sony presentation on Wednesday morning.  I
am sure it is able to be scheduled to be convenient ( I hope. )


 At 09:15 PM 6/15/97 +0100, Aaron Ludtke wrote:
>Hi Danny,
>
>Thanks for the email. I'm looking forward to discussing these topics with 
>you and the PWG people.
>
>>During the Printer Working Group meetings Sony announced that it would have
>>a proposal for 1394 device discovery would be presented at the off-site AV
>>meeting.
>>
>>The PWG members are having a meeting earlier that week but would like to
>>possibly attend to see this proposal.  Can we get an idea when the
>>presentation would be given so they can not have to fly back from Boston
>>overnight to get to this meeting?
>>
>
>Well, I'll tell you what. Since your people will be here at the beginning 
>of that week, why don't we start out with this discussion first thing. 
>That would be Wednesday morning, June 25, starting at 9:00 AM, somewhere 
>in San Jose.
>
>Unfortunately I can't tell you exactly where, because it's a matter of 
>national security...et, uh, I mean, we have not yet been able to find 
>facilities large enough (many of the local hotels seem to be all booked 
>up that week...probably some damn printer groups having meetings or 
>something ;).
>
>So, as soon as I find out the location, I will let you know.
>
>Now I need to ask a favor from you. Can you help me find out how many 
>people from the PWG will be attending this discussion? I need to know for 
>facilities, catering, etc. I have requested feedback on the 1394-av 
>reflector, but I hesitate to broadcast a message on other reflectors 
>regarding special discussions, attendance plans, etc.
>
>Please send any info straight to me, do not broadcast on 1394-av.
>
>Thanks,
>
>Aaron
>
>
Regards,  Danny Mitchell  ( Dallas, Tx )


 BuS Solutions SW Manager ( 1394, USB )
 Ph: 972-480-3411     www.ti.com/sc/USB 
 Fx: 972-480-3160     www.ti.com/sc/1394
 Texas Instruments, 8505 Forest Lane, MS-8710, Dallas, TX 75243

From DMitchell at ti.com  Tue Jun 17 17:46:11 1997
From: DMitchell at ti.com (Danny Mitchell)
Date: Wed May  6 14:00:45 2009
Subject: P1394> AVC working group meeting
Message-ID: <3.0.2.32.19970617164611.00b0e860@dlep1.itg.ti.com>

Aaron Ludtke of Sony has suggested the below.  Again please respond to
Aaron directly if anyone plans to attend.


aaronl@newt.lsi.sel.sony.com






******
I saw the other email to the pwg - thanks for sending it out and helping 
to coordinate. Did you mean the 26th in your message above? The AV WG 
meeting will be only two days - 25th and 26th. Again, the 26th is 
completely OK...I didn't know that the PWG people would be in Boston on 
the 25th. I apologize that the schedule is so tight; I know that it is 
tough to fly back here for a meeting on the next day.


I'll tell you what - to try and make this as convenient as we can for the 
PWG people, how about if we plan on discussing SDD in the afternoon on 
the 26th? That would allow us to go completely through our other major 
topic (the AV/C tuner) and finish it off, then let everybody shift their 
mindset over to SDD and not worry about shifting back to the tuner.
*****
Regards,  Danny Mitchell  ( Dallas, Tx )


 BuS Solutions SW Manager ( 1394, USB )
 Ph: 972-480-3411     www.ti.com/sc/USB 
 Fx: 972-480-3160     www.ti.com/sc/1394
 Texas Instruments, 8505 Forest Lane, MS-8710, Dallas, TX 75243

From ohnishi at cbm.canon.co.jp  Wed Jun 18 08:54:43 1997
From: ohnishi at cbm.canon.co.jp (Ohnishi, Nobuhiro)
Date: Wed May  6 14:00:45 2009
Subject: P1394> slides of the Jun11 meeting
Message-ID: <199706181249.VAA25059@leo.cbm.canon.co.jp>

Hello all,


The following files (June 11 meeting slides/proposals) are added on the ftp
site 


ftp://ftp.canon.co.jp/pub/tmp/1394/printer/


The following are the lists of them.
 (the numbers are the paragraph numbers in the minutes);
970611si.pdf --- 4.1 
PWG_Overview_9706.pdf ---4.2 
SBP2.PDF --- 4.4.3 
FUJI0_501.pdf --- 4.5.2 
97_JUNE.PDF --- 4.5.3
1284SBP2.PDF --- 4.5.4
pwg-c9706msj.pdf --- 4.5.7


Regards,


Nobuhiro Ohnishi
Canon Inc.

From PJohansson at aol.com  Wed Jun 18 14:55:57 1997
From: PJohansson at aol.com (PJohansson@aol.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Re: Device discovery on 1394
In-Reply-To: <P1394> Re: Device discovery on 1394>
Message-ID: <199706181249.VAA25059@leo.cbm.canon.co.jp>

In a message dated 97-06-17 11:28:34 EDT, atsnaka@mxa.meshnet.or.jp (Atsushi
Nakamura) writes:


<<The unit_directory definitions of current transport protocols is defined in
a way that the initiator will discover the characteristics of a node by it's
protocol first, and then finding the actual device function by "talking"in
that protocol It shows that the current ROM definitions support
protocol(device) discovery, but not function device discovery.>>


"Talking" in the specific protocol is not necessarily as involved as sending
a command in the protocol. SBP-2 defines a device type field in configuration
ROM that can be simply accessed. See the Logical_Unit_Entry, described in
7.3.9 of the SBP-2 draft.


<<PWG/PWG-C's approach to the device discovery scheme (not the printing
protocol, they are separate because device discovery is a scheme that applies
to any device, not just printers.) is to provide a common
(protocol-free)"short-cut" to discovering the "device",or functions FIRST,
then the protocol it supports. It will not conflict with the existing ROM
definitions (SBP-2,FCP), but co-exist so that the initiator can choose
discovery paths; existing ROM definitions for protocol-first device
discovery, and the PWG/PWG-C path for function-first device discovery.>>


This is an interesting and worthwhile discussion to have, but because it
hinges on the matter of a central registration authority it is a higher level
matter than PWG-Xxxxxxx. Perhaps the IEEE P1212 revision project should
undertake this.


Unfortunately, your assertion that "...it will not conflict with existing ROM
definitions..." is not true. The meanings of ALL entries in the unit
directory are specified by either a) ISO/IEC 13213:1994 (the CSR
architecture) or b) the organization or company that owns the 24-bit ID in
the Unit_Spec_ID entry in the unit directory.


Issues like this need broader visibility or it is likely that a number of
incompatible solutions will be developed.


I suggest that the matter of device function identification be addressed at
the July meeting of the Architecture working group at the 1394 Trade
Association meeting.


Regards,


Peter Johansson


Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602


(510) 531-5472
(510) 531-2942 FAX


pjohansson@aol.com

From ohnishi at cbm.canon.co.jp  Wed Jun 18 20:52:35 1997
From: ohnishi at cbm.canon.co.jp (Ohnishi, Nobuhiro)
Date: Wed May  6 14:00:45 2009
Subject: P1394> CORRECTION in the June 11-12 meeting minutes
Message-ID: <199706190047.JAA18598@leo.cbm.canon.co.jp>

--=====================_866649155==_
Content-Type: text/plain; charset="ISO-2022-JP"


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.	($B"K"K(J)
Stephen N. Zilles	Adobe Systems Incorporated($B"K"K(J)
Junji Iwane	Apple Japan Inc.	($B"K"K(J)
Kiyotaka Ohara	Brother Industries,ltd.	($B"K"K(J)
Akihiro Shimura	Canon Inc.($B"K"K(J)
Kouji Fukunaga	Canon Inc.(-$B"K(J)
Atsushi Nakamura	Canon Inc.($B"K"K(J)
Naohisa Suzuki 	Canon Inc.	($B"K(J-)	
Nobuhiko Shinoda	Canon Inc.($B"K"K(J)
Nobuhiro Ohnishi	Canon Inc.($B"K"K(J)
Shigeru Ueda	Canon Inc.	($B"K"K(J)
Takashi Isoda	Canon Inc.	($B"K"K(J)
Lee Farrell	Canon Information Systems	($B"K"K(J)
Kyouichi Ohno	CASIO Electoronics Manufacturing Co.,Ltd.($B"K(J-)	
Yoshinori Murakami 	Epson Imaging Technology Center	($B"K"K(J)
Fumio Nagasaka	Epson Software Development Laboratory($B"K"K(J)
Tanizaki Masanori	Epson TP System Design	($B"K"K(J)
Fumihiro Funazaki	Fuji Photo Film Co., Ltd.($B"K"K(J)
Mikio Watanabe	Fuji Photo Film Co., Ltd.($B"K"K(J)
Kazuhiro HiRATA	Fuji Xerox Co.,Ltd.($B"K"K(J)
Tatsuya Matsumoto	Fuji Xerox Co.,Ltd.($B"K"K(J)
Akira Karasudani 	Fujitsu Labs. I/O Systems Lab.	($B"K"K(J)
Yasuhiko Nakano 	Fujitsu Labs. I/O Systems Lab.	($B"K(J-)	
Yoshiyuki Okada 	Fujitsu Labs. I/O Systems Lab.	($B"K(J-)	
Alan Berkema	Hewlett-Packard Company	($B"K"K(J)
Brian Batchelder	Hewlett-Packard Company	($B"K"K(J)
Richard Andrade	Intel Corporation($B"K"K(J)
Kazushige Harada	Kobe Steel, Ltd.($B"K(J-)	
Shigeo Tochino	Kobe Steel, Ltd.($B"K(J-)	
Shoji Akashita	Kobe Steel, Ltd.($B"K(J-)	
Hiromi Jyoshita	Kyusyu Matsushita Electric ($B"K(J-)	
Don Write	Lexmark International, Inc.($B"K"K(J)
Takahiko Nankou	Matsushita Electric Industrial Co.,Ltd.	($B"K"K(J)
Yasuo Nishiwaki	Matsushita Electric Industrial Co.,Ltd.	($B"K"K(J)
Kiyonori Sekiguchi	Matsushita Graphic Communication Systems, Inc.	($B"K"K(J)
Keisuke Tsuchida	Microsoft Co., Ltd($B"K"K(J)
Toshio Shimoaraiso	Microsoft Co., Ltd($B"K"K(J)
Yasushi Nagao	Microsoft Co., Ltd($B"K"K(J)
Yasunari Kitagaki	Minolta Co., Ltd.($B"K"K(J)
Hironori Nagai	NEC Corporation	($B"K(J-)
Mikio Saisu	NEC Corporation	($B"K"K(J)
Kiwamu Sumino	Nippon Motorola Ltd.($B"K"K(J)
Mitsuhisa Kanaya	Ricoh Company, Ltd.($B"K"K(J)
Okubo Akinori	Ricoh Company, Ltd.($B"K"K(J)
Kyoji Marumoto	Rohm Co., Ltd.	($B"K(J-)	
Shigemichi Aoki	Rohm Co., Ltd.	($B"K(J-)	
Hiroshi Wakai	Sharp Corporation($B"K"K(J)
Masahiro Ohsawa	Sharp Corporation($B"K(J-)	
Toru Ueda	Sharp Corporation($B"K"K(J)
Hiromitsu Kurokawa	Sony Corporation($B"K"K(J)
Makoto Sato	Sony Corporation($B"K"K(J)
Takashi Kojima	Sony Corporation($B"K"K(J)
Yorihiko Sakai	Sony Corporation($B"K"K(J)
Masakazu Kikuchi	Syou Engineering($B"K(J-)	
Danny Mitchell	Texas Instruments Incorporated($B"K"K(J)
Junichi Komura	Texas Instruments Japan Limited	($B"K"K(J)
Keijiroh Kaneda	Texas Instruments Japan Limited	($B"K"K(J)
Akira Saitoh	Toshiba Corporation	($B"K"K(J)
Noriko Kure	Toshiba Corporation	($B"K"K(J)
Yoshiki Hayakashi	Toshiba Corporation	($B"K(J-)	
Katsuhiko Terada	Victor Company of Japan, Limited($B"K"K(J)
Larry A. Stein	Warp Nine Engineering	($B"K"K(J)
Masanori Gonda 	YASKAWA Information Systems Co., Ltd.	($B"K(J-)	
Kazuo Nagata	Yokogawa Electric Corporation	($B"K(J-)	
Makoto Simizu	Yokogawa Electric Corporation	($B"K(J-)	


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:
$B!&(J Formed in Feb 1997, became an IEEE Study Group. Submitting a Project
 Authorization Request at July MSC meeting
$B!&(J Put group on track to generate an International Standard
$B!&(J Hope to become a standard within a year - "fast track"
$B!&(J Proposed title:  "Standard for Device and Service Discovery for Printing
 on an IEEE Std. 1394 Topology" 
$B!&(J Scope:
(see slides) 
$B!&(J Pupose:
(see slides)
$B!&(J 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
 
$B!&(J 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)
$B!&(J Module, Node and Unit were defined. (see slides)
$B!&(J Device Discovery
* Mechanism by which a device is discovered and its unit types are
 determined
$B!&(J Service Discovery
* Mechanism by which a unit's services are discovered
$B!&(J 1394 provices a mechanism to discover devices throu the config ROM
$B!&(J No standardized mechanism for discovering services in 1394.
$B!&(J Discoverer should only need to decode info about which it is interested.
$B!&(J Service discovery should occur at the layer where that service is
 exposed. Each layer should provide service discovery for the layer above
 it.
$B!&(J 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)
$B!&(J Provides a simple way to exchange messages
* Accessed through uniquely defined address
$B!&(J Possible to support multiple submits in a FCP unit
$B!&(J Standard of IEC 61883-1 (to be published)
$B!&(J WRITE transactions of 1394 Asynchronous communication
$B!&(J COMMAND and RESPONSE frames are addressed to defined registers
$B!&(J 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)
$B!&(J DDSR - Device Discovery and Status Retrieval Protocol
* Also called "Basic Framework"
* Allows discovery and access to both PC Print Protocol and Direct Print
 Protocol
$B!&(J Several Terminology definitions offered:
* Device Discovery
* Transport
* Datalink
* Service Discovery
$B!&(J 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)
$B!&(J Changes from v0.2 "Login" proposal were described
* Name changed to "DDSR"
* Simpler functions
* 2 methods for RAM space access
* Configuration ROM defined
$B!&(J 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
$B!&(J 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.
 
$B!&(J DPP - Direct Print Protocol
* Common protocol for any DPP compliant image source to print to any DPP
 supporting printer
* Simple, expandable
$B!&(J Defines minimum requirements and expansion rules
$B!&(J Follows DDSR Protocol
$B!&(J Basic Architecture diagram (see slides)
$B!&(J Image Format and Data Flow Model candidates listed
* Need to specify minimum mandatory requirements
$B!&(J Remaining Open Issues
* Data Flow model
* Image format
* Is protocol layering needed?
* Is bi-directional data-transport required?
* Service Discovery definition
$B!&(J 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.:
$B!&(J Host device
* Image source devices and PC
$B!&(J Color Image Printing
* Bit map color data
* Image file data
$B!&(J Interoperability
$B!&(J Device Discovery
* ConfigROM (Unit directory)
- unit_spec_version
- command-set_spec_ID
$B!&(J Register based control
$B!&(J Image Format
* Raw Image - RGB, YCbCr, Vendor unique color
* High level Format - Exif (JPEG)
$B!&(J Data Format
$B!&(J Data Flow Model
* Asynch Transfer Model
- Repeat push Block transaction to dat butffer window
- Can simp;ify the control
* Isoch Transfer Model
$B!&(J 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:
$B!&(J Design overview of 1394 printer driver for Macintosh (see slides)
$B!&(J 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.
$B!&(J Wants to convert Push model to Pull model (to reduce flow control
 communication?)
$B!&(J 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.
$B!&(J 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)
$B!&(J 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)
$B!&(J Wide Range of Use
* The market of consumer devices with still image handling capability is
 dramatically increasing
$B!&(J Wide Range of Devices
$B!&(J Requirements
* Small footprint
* Physical Media Independent
* Data Format/Command Free
* Segmentation/Reassembly of data 
$B!&(J "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)
$B!&(J 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
$B!&(J Data Transport (Stack Model) diagram (see slides)
* FCP command/response transaction
* Realize data transport transaction
- single comand, single response
- split commands
- split responses
$B!&(J Split commands and responses diagrams (see slides)
$B!&(J Device Discovery - Minimum Requirements
* Node Unique ID
* Supported transport protocol over 1394 (FCP, SBP2, etc.)
* Command_set_ID
$B!&(J Device Discovery - Unit Dependent Information
* Unit Type
* Data Format
* Data transfer efficiency (capability of device)
$B!&(J 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:
$B!&(J "Good analysis tools reduce development costs"
$B!&(J Product listens to 1394 bus traffic and displays packet info
$B!&(J Identifies existing topology of nodes on the bus
$B!&(J Can generate Bus Reset
$B!&(J Set trigger conditions on specific data in header field
$B!&(J 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.
$B!&(J "Device" discovery is now really "unit" discovery
$B!&(J 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:
$B!&(J Device/Service Discovery
$B!&(J Network Printing
$B!&(J 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==_--


From gregory_leclair at erc.epson.com  Wed Jun 18 21:20:54 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Proposed 1394 PWG Nashua Agenda
Message-ID: <9705188666.AA866684334@erc.epson.com>

     Hello everybody. 
     
     Sorry for the lateness of this proposed agenda for the 1394 PWG 
     meeting on Monday & Tuesday of next week in Nashua ("Boston"). I 
     wanted to review the docs from last weeks meetings and hopefully 
     provide some continuity so we make good progress.
     
     Please provide feedback, comments, suggestions on the agenda to the 
     reflector at: p1394@pwg.org
     
     Thanks,
     Greg
     
     P.S. Ties are optional  ;-)
     
     ===================================================================
     
     
     6/23 Monday
     
     - Summary of Meetings on 6/11 & 6/12 (Volunteers? Larry, Brian???)
     
     - Device / Service Discovery
     
     - Protocol Discussion
       - FCP / SBP-2 / 1284.4 / Other 
     
     
     6/24 Tuesday
     
     - IEEE PAR Discussion / Review / Draft
     
     - Continue with 
       - Device / Service Discovery 
                and/or
       - Protocol Discussion 
     
     

From DMitchell at ti.com  Fri Jun 20 07:35:04 1997
From: DMitchell at ti.com (Danny Mitchell)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Location for the AV WG meeting
Message-ID: <3.0.32.19970620061648.00b9de38@dlep1.itg.ti.com>

Printer folk,  here is the location and agenda for the AVC working group
meeting.


>Subject: Location for the AV WG meeting
>Date: Thu, 19 Jun 97 20:04:42 +0100
>X-Sender: aaronl@newt.lsi.sel.sony.com
>From: Aaron Ludtke <aaronl@lsi.sel.sony.com>
>To: <DMitchell@ti.com>
>Cc: "Harumi Kawamura" <harumi@cv.sony.co.jp>
>
>Hi Danny -
>
>Here's the location and agenda info for the AV WG meeting:
>
>Date:     June 25 and 26, 1997
>Time:     9 AM to 5 PM (both days)
>Location: Sunnyvale Hilton Hotel
>
>Directions -
>
>The hotel is located off of Lawrence Expressway in Sunnyvale (right next 
>to San Jose), near the junction with highway 101.
>
>If you are heading south on 101, take the Lawrence South exit, which will 
>go to the right.
>If you are heading north on 101, take the Lawrence North exit (this will 
>cause you to pass underneath Lawrence and loop around).
>
>Once on Lawrence, go left at the first light which is Oakmead.
>On Oakmead, make a left at the first light which is Lakeside.
>
>The hotel is on the right hand side, at 1250 Lakeside Drive.
>
>The phone is +1-408-738-4888
>
>
>Agenda:
>1) An announcement about the Audio and MIDI Transmission protocol 
>document, and its proposal to the IEC
>
>2) A short update on the Audio Sub-working Group activities
>
>3) A short presentation describing the use of AV/C subunit type 
>definitions, and a proposal for a new type definition
>
>The above three items will probably take no longer than 20 - 30 minutes 
>total.
>
>4) A presentation and discussion of the AV/C tuner model - this will last 
>for the rest of the day, and into the first half of the second day 
>(nobody goes home - it's a marathon session!!!!;)...just kidding. We stop 
>at about 5:00 pm.
>
>5) A proposal for Self Describing Devices (SDD) - starting at 1:00 pm on 
>the 26th.
>
>We'll have plenty of food available, so if the PWG people want to show up 
>for lunch (probably at about 12:00 ish) then there's no problem! Mange, 
>mange!
>
>Thanks,
>
>Aaron
>
>
Regards, Danny Mitchell (Dallas, TX)


 BuS Solutions Software Manager
 www.ti.com/sc/1394
 Ph: 972-480-3411     
 Fx: 972-480-3160     
 Texas Instruments, 8505 Forest Lane, MS-8710, Dallas, TX 75243

From fumiona at venus.dtinet.or.jp  Sat Jun 21 15:48:47 1997
From: fumiona at venus.dtinet.or.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Comments on recent PWG-C/PWG meeting
Message-ID: <3.0.32.19970620061648.00b9de38@dlep1.itg.ti.com>

I think SBP-2 is more suitable for printing protocol from flow control point
of view. The SBP-2 is designed based on memory bus model which we 
can perform fetch-model. Thus I agree with Eric.


The SBP-2 does not support login less operation. Is this mean that we
can not invoke login-less status-get operation? Is this a drawback of
the SBP-2? Answer is "No".


The SBP-2 does not forbid multiple login, thus we can invoke login just
for getting status. Or even if the unusual implementation of SBP-2 does
not allow multiple login, a Login ORB may specify status_FIFO address
and a target device may return command set dependent status block.


This feature gives us satisfaction for the question I asked to Alan at the
meeting held on 6/12 at Tokyo.


-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to genesis@hd.epson.co.jp


-----Original Message-----
From:	Eric W. Anderson [SMTP:ewa@apple.com]
Sent:	Tuesday, June 17, 1997 4:10 PM
To:	p1394@pwg.org
Subject:	P1394> Comments on recent PWG-C/PWG meeting


[Apologies if you receive multiple copies of this.  There seem to
 be several mailing lists to choose from. - Eric]


Hello,


I have read the minutes from the June 11-12 meetings.
Thank you for making them available so quickly.


I would like to provide some input from a computer software/
operating system point of view.




** 1. FCP or SBP-2?


As mentioned in the minutes, there are some concerns about using
FCP for printers.  The specification for SBP-2 seems to be very
complicated, but this is only because it has been documented very
carefully.  I believe that SBP-2 would be the best choice for
printers, and I suggest that you give it consideration.


Protocol                           SBP-2    FCP
-----------------------------------------------
High performance?                  Yes      No
Computer friendly?                 Yes      No
Complicated?                       No       No
Needs changes for flow control?    No       Yes
Multiple independent units?        Yes      No




** 2. Device Discovery


1394 and 1212 use a flexible CSR ROM.  From a computer point of
view, it is very important that the CSR ROM be used as a tree,
so that multiple, independent things can be put inside it.  For
this reason, it will be very hard for operating systems to use
a CSR ROM that has device discovery information at the root
level.  It may be impossible for a computer to participate in
more than one such protocol at the same time.


I believe that the example below is most compatible with 1394 and
1212.  This example is a fax/printer.  Please consider it:


      CSR ROM


      ROOT ---+--- UNIT1 (PRINT) ---+--- UNIT-DIR (SBP-2)
              |                     |
              |                     +--- UNIT-DIR (Vendor-Unique)
              |
              +--- UNIT2 (FAX) ---+--- UNIT-DIR (SBP-2)


In this example, the Print function and the Fax function are
completely independent.  Of course, you can build a module with
a single embedded controller that performs both functions.  Or
you can use different controllers.  Either way, the CSR-ROM looks
the same, and the same computer software can be used.


Why does independence matter?  Unlike a printer, the CSR-ROM in
the computer will depend on what software is loaded.  It must be
possible for many different units to share this CSR ROM.  If they
all put their information at the root, there will be a conflict.


Consider this example:  I have a legacy (parallel-port) printer.
I want it to operate with my 1394 scanner.  I can write driver
software for my PC that emulates a 1394 printer.  The PC will have
information in its CSR ROM, and the scanner will "see" a real 1394
printer.  Now the scanner can print directly to the printer, using
the PC as a bridge.  No application software or GUI is required on
the PC.


But at the same time, I also have superior OCR software on my PC.
I want my 1394 fax/printer to send faxes to the OCR software.  The
PC will have data in its CSR ROM to describe the OCR software, and
to make this software look like a printer, so that the 1394 fax/printer
will send data to it automatically.


Here is the general problem:  Both the OCR software and the printer
emulation software must put data in the CSR ROM.  But, these drivers
are made by different vendors.  They do not cooperate, and they cannot
share a common root-level interface.  They must have different register
addresses, so that they can operate fully independently.  This is why
the original 1394/1212 CSR ROM model is so powerful.


By the way, FCP uses a fixed address (FFFFF0000B00), so it is
impossible to have independent FCP units within a node (such as
a PC).  This is one of the reasons why I believe that SBP-2 will
work better for use with printers and similar devices.


I welcome your comments on these matters.  Please be sure to send
them directly to me, because I have not yet managed to get on the
mailing list due to a problem with the server.


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------

From fumiona at venus.dtinet.or.jp  Sat Jun 21 15:48:59 1997
From: fumiona at venus.dtinet.or.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:45 2009
Subject: P1394> RE: [PP1394:00042] PWG Network sub-group minutes
Message-ID: <3.0.32.19970620061648.00b9de38@dlep1.itg.ti.com>

Alan Berkema wrote:
* Shimura san of Cannon asked a question about the 1284.4 over SBP-2 
* presentation.
* He wanted to know if bi-directional communication could be 
* accomplished with the initiator performing 2 logins, one for each 
* direction. This is an alternative to the idea presented where the 
* Initiator logs into the Target for outbound communication and the 
* Target logs into the Initiator for inbound communication.
* This idea requires further investigation and discussion


Actually we don't need to operate 2 logins for bi-directional communication.
SBP-2 is designed to cover HDD, so we can operate read/write within
single login. If we use function code = 4 in Management ORB, it does means
we can do any command set dependent operation. Thus our target device
may return an address offset for reverse channel output buffer, according to
the specification. I guess 2 logins for bi-directional communications bring
us difficulties to design 1284.4 over SBP-2.


-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to genesis@hd.epson.co.jp


-----Original Message-----
From:	ALAN_BERKEMA@hp-roseville-om2.om.hp.com [SMTP:ALAN_BERKEMA@hp-roseville-om2.om.hp.com]
Sent:	Saturday, June 21, 1997 5:46 AM
To:	pp1394 ML
Subject:	[PP1394:00042] PWG Network sub-group minutes


Item Subject: cc:Mail Text
12 June 1997


Minutes for the ad-hoc 1394 Network PWG meeting.


Agenda:
- What do we mean by networking over 1394?
- Status of IP1394
- 1284.4 over SBP-2
- Issues


- What do we mean by networking over 1394?
--------------------------------------------------------


This question deserves considerable thought and we welcome additional opinions. 
The following is only my opinion.


Networking over 1394 probably refers to the IP1394 effort. Once IP is truly 
encapsulated in 1394 packets, Networking over 1394 in the Local Area should work
very similar to how it works over Ethernet today. Networking in a Wide Area 
would require 1394 to network routers.


In small work groups 1284.4 over SBP could be viewed as a network, since devices
could have multiple connections.




- Status of IP1394


IP over 1394 started with work by DAVIC. DAVIC decided to pass the IP over 1394 
standards work to the IETF. The IETF held a Birds Of a Feather meeting at the 
IETF quarterly meeting in April 1997. The IETF decided three was sufficient 
interest to form a working group with Myron Hattig of Intel as one of the 
co-chairs. IP1394 is still waiting to be approved as an official working group.


To subscribe to the IP1394 reflector send e-mail to: 
       listserv@mailbag.intel.com 
       no subject, a one line message of "subscribe ip1394".
There are currently 3 proposals.


The DAVIC proposal, the Microsoft proposal and a proposal by Peter Johansson.


The pre-approved charter of the IETF IP1394 working is provided below.


     ==========================================================================
          IP1394 WORKING GROUP CHARTER
          


          The goal of the IP1394 Working Group is to define IP networking 
     over 
          1394 Serial Bus. 1394 Serial Bus (1394) is specified by IEEE Std 
          1394-1995 and the draft standard IEEE P1394a.  The IP1394 working 
     group 
          will define facilities for the 1394 asynchronous and isochronous 
          transmission of unicast, broadcast and multicast IP packets.
          
          The IP1394 working group is utilizing 1394 facilities to provide 
     the 
          functions similar to other data link networks residing between IP 
     and 
          physical layer protocols. Unlike most other data link networks, 
     1394 
          is capable of both asynchronous and isochronous transmission.  
     These 
          capabilities have a significant impact on the usage of IP over 
     1394. 
          The IP1394 working group will prepare an architecture document 
     and 
          appropriate protocol documents for the usage of these unique link 
          layer properties.  Both IPv4 and IPv6 will be addressed, although 
     in 
          separate documents.
          
          The IP1394 working group intends for the specification to be 
     utilized 
          by devices with a broad range of capabilities. The devices are 
     not 
          limited to but are expected to include both traditional equipment 
     such 
          as computers, as well as equipment that has not been 
     traditionally 
          networked such as consumer electronics (e.g. TVs & VCRs).
          
          The IP1394 working group will maintain informal liaison with 
     other 
          standards groups and industry organizations. Liaison will be 
          accomplished by the circulation of drafts and the submission of 
     brief 
          reports to the other groups.
          
          The IP1394 working group is chartered to deliver the documents 
          described below. Some of these documents may depend upon 
     facilities not 
          currently standardized in 1394. If the working group considers it 
          advisable to request modification or extension of existing IEEE 
          standards or IEEE standards in development, it will make 
          recommendation(s) to the relevant IEEE working group. The IP1394 
          working group will not request documents that depend upon such 
     changes 
          to be advanced to standards track RFCs until the changes have 
     been 
          endorsed by the relevant IEEE working group(s).
          
          The deliverable documents are as follows:
          
          - A document listing two groups. IEEE groups for which the IP1394 
          working group may need approval. Groups that benefit from 
     informal 
          liaisons. These lists are to be reviewed at regular intervals.
          
          - An architecture document detailing the interactions between 
     1394 
          asynchronous and isochronous transmissions, resource reservation 
     and 
          multicast.
          
          - An IPv4 over 1394 document covering the encapsulation and 
     framing of 
          IPv4 unicast, multicast and broadcast packets over asynchronous 
     and 
          isochronous 1394, including address resolution.
          
          - An IPv6 over 1394 document covering the encapsulation and 
     framing of 
          IPv6 unicast, multicast and broadcast packets over asynchronous 
     and 
          isochronous 1394, including neighbor discovery.
          
          - A media-specific MIB for managing 1394 interfaces.
          
          Goals and Milestones:
          
          May 97
          Create list of liaisons and dependent IEEE 1394 working groups.
          Meet to discuss pros/cons of proposals for Internet-Draft on IPv4 
     over 
          1394 & interaction architecture.
          
          Jun 97
          Meet to reduce number of proposals based on pros/cons presented 
     for 
          Internet-Draft on IPv4 over 1394 & interaction architecture.
          
          July 97
          Meet to reduce number of proposals Internet-Draft on IPv4 over 
     1394 & 
          interaction architecture.
          
          Aug 97
          Update list of liaisons and dependent IEEE 1394 working groups.
          Post Internet-Draft listing all remaining proposals on IPv4 over 
     1394 
          & interaction architecture.
          Meet at IETF to discuss two drafts.
          
          Sep 97
          Update final list of liaisons and dependent IEEE 1394 working 
     groups 
          for IPv4 & Interaction Arch last call documents.
          Meet to finalize Internet-Draft on IPv4 over 1394 & interaction 
          architecture.
          Post Internet-Draft on IPv4 over 1394 & interaction architecture 
     for 
          last call.
          Create schedule for discussing 1394 MIB and IPv6. Target dates 
     are 
          June 98 for last call, Dec 98 for submission to Standards Track 
     RFC.
          
          Dec 97
          Meet to record implementation experiences with Internet-Draft on 
     IPv4 
          & interaction architecture.
          Discuss IPv6 and MIB.
          
          April 98
          Meet to incorporate feed back from implementations into IPv4 and 
          interaction architecture drafts.
          Get official feedback from appropriate IEEE 1394 working groups. 
          Submit IPv4 and Arch documents for Standards Track RFC.
          Discuss IPv6 and MIB.
          
          June 98
          Post 1394 MIB and IPv6 doc for last call.
          
          Dec 98
          Post 1394 MIB and IPv6 doc for Standards Track RFC.
          
     ======================================================================
     ====
     
     - 1284.4 over SBP-2
     -------------------------
     
     Shimura san of Cannon asked a question about the 1284.4 over SBP-2 
     presentation.
     He wanted to know if bi-directional communication could be 
     accomplished with the initiator performing 2 logins, one for each 
     direction. This is an alternative to the idea presented where the 
     Initiator logs into the Target for outbound communication and the 
     Target logs into the Initiator for inbound communication.
     This idea requires further investigation and discussion.
     
     
     - Issues
     --------
     
     1284.4 over SBP-2 issues will be handled separately.
     
     If the IETF is working on IP1394 is there any additional work required 
     by the PWG?
     
     --------
     
     Regards,
     
     Alan Berkema
     Direct Connect Operation
     Hewlett Packard MS# 5558
     8000 Foothills Blvd
     Roseville Ca.
     95747
     alan_berkema@hp.com
     916 785-5605
     916 785-5959 (fax)
     
     
     
     

From gregory_leclair at erc.epson.com  Tue Jun 24 07:02:12 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:45 2009
Subject: P1394> 1394 Web Site updated
Message-ID: <9705248671.AA867151271@erc.epson.com>

     FYI - The 1394 PWG web site has been updated with yesterdays's 
     presentations.
     
     
     Greg 

From PJohansson at aol.com  Tue Jun 24 10:36:43 1997
From: PJohansson at aol.com (PJohansson@aol.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Printers and SBP-2
Message-ID: <9705248671.AA867151271@erc.epson.com>

Printer-reflector folk:


I've copied two messages that went back and forth between Danny Mitchell and
me. I thought they might be of general interest to the groups.


Regards,


Peter Johansson


Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602


(510) 531-5472
(510) 531-2942 FAX


pjohansson@aol.com


************************************************************
In a message dated 97-06-19 00:17:33 EDT, DMitchell@ti.com (Danny Mitchell)
writes:


<<Some of the discussions here indicate that a printer might need to be both
initiator and target??  The discussion is along the line of compatability
with the 1284 protocols that have been developed for printers.  I am still
investigating that,  I do not really see the need for this type of complexity
for sending status data.>>


I haven't been part of the discussions about the necessity for a printer to
be a "targiator" and fulfill both roles, so perhaps I am missing something
when I say I do ot see the need for that sort of complexity, either.


Is the printer you contemplate FUNDAMENTALLY different from the model
implemented by parallel SCSI printers today? If it's much the same, there is
no need for the printer to be anything other than a target. The SBP-2 status
mechanisms, both that associated with a particular ORB and unsolicited
status, should be adequate.


Regards,


Peter Johansson


Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602


(510) 531-5472
(510) 531-2942 FAX


pjohansson@aol.com
************************************************************
In a message dated 97-06-22 01:27:36 EDT, DMitchell@ti.com (Danny Mitchell)
writes:


<<What about the case where the printer would want to send data back to the
host for status reporting ( paper out,  status of job,  etc.  ) and other
things that the printer group has defined using the 1284 specification  ( I
believe it defines bi-directional communication channels ).>>


This sounds like unsolicited status to me; covered by SBP-2.


<<Can I assume that a printer could provide "read" functions like a HDD
would?>>


You can provide any commands you want; for any one command the data can
either move from the initiator (e.g., PRINT) or to the initiator (e.g.,
REQUEST SENSE).


What are the addresses of the various PWG reflector(s)? I should be answering
these questions for the whole group.


Regards,


Peter
************************************************************

From don at lexmark.com  Tue Jun 24 15:32:59 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Function Discovery Standard
Message-ID: <199706242032.AA26688@interlock2.lexmark.com>

To:       p1394@pwg.org
cc:
From:     Don Wright @ LEXMARK@LEXMTA
Date:     06/24/97 03:32:59 PM
Subject:  Function Discovery Standard


Here's the Title, Scope and Purpose of the 1394 function
discovery PAR that the working group discussed and which
will be present to the IEEE MSC on July 14th.


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


   "Standard for Node and Unit Functional Discovery for Control
 and Status Register (CSR) (ISO/IEC 13213,  ANSI/IEEE Std 1212-
  1991) Architecture implementations on the IEEE Std. 1394-1995
                           Serial Bus"




SCOPE:


This standard will define a method for node and unit function
discovery independent of communication or transport protocols for
nodes connected to IEEE 1394-1995 buses.  As a part of this
discovery process, this standard will define a set of unit
functions and  associated numeric and textual identifiers for
each.  These functions will include, for example, printer,
processor, fixed storage, removable storage, scanner, camera,
etc.  This standard will define a method of utilizing the Control
and Status Register Architecture define by  ISO/IEC 13213,
ANSI/IEEE Std 1212-1991 to provide this discovery process.
Additionally, after a function has been discovered, this standard
will provide the means to determine the supported communication
protocols available to access that service.


PURPOSE:


IEEE Std 1394-1995, a High Performance Serial Bus,  enables many
new and enhanced devices to communicate.  Discovery of the
functions provided by these devices currently requires a
significant understanding of a variety of transport and
communications protocols.  In today's computer operating system
environments, it is often necessary to discover, install and
configure devices by class of functionality such as storage,
printing and scanning all at one time.  In order to expedite and
simplify this process, a method is needed to identify all the
nodes providing a specified function at one time regardless of
communication or transport protocols.  This standard provides a
consistent means of specifying what functions are provided by any
node or unit.


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


Don


*************************************************************
* Don Wright (don@lexmark.com)        Lexmark International *
* Manager                               Strategic Alliances *
* 740 New Circle Rd                     Phone: 606-232-4808 *
* Lexington, KY  40511                    Fax: 606-232-6740 *
*************************************************************

From genesis at hd.epson.co.jp  Wed Jun 25 16:16:47 1997
From: genesis at hd.epson.co.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:45 2009
Subject: P1394> RE: [PP1394:00048] Printers and SBP-2
Message-ID: <01BC8204.96634720@gw-solo-fumio>

Peter, Danny, thank you for your helpful information.


* This sounds like unsolicited status to me; covered by SBP-2.


Actually some printers are needed to have reverse directional data transfer.
The reverse directional (printer --> PC) data flow is intended to designed to
service status. And we also would like to use reverse direction as pure
data flow. One of the good example is printer cluster which is consisted by
tow or more printers. When one of these printer has some trouble (due to 
lacks of paper or some other reason), other printer may perform printing
instead it.


For this sort of application, IEEE P1284.4 has capability to service reverse
data flow. Off cause this feature could be convenient even for status reporting
from a printer.


I think "Normal command block ORB's" are supporting full feature of reverse
data flow. Thus I believe SBP-2 can cover "Credit Base Transaction (CBT)"
of IEEE P1284.4.


I guess we may enclose our packets in data buffer associated by ORBs.
I have a question to implement SBP-2 for printers. Can we have multiple
fetch agent in a target device. I am curious whether we can enclose particular
packets those have a tag as a header of each packet, and also can have
a particular fetch agent which seeks special packets those have the tag.


If it is possible it could be helpful to make priority queue style linked ORBs.
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to genesis@hd.epson.co.jp


-----Original Message-----
From:	PJohansson@aol.com [SMTP:PJohansson@aol.com]
Sent:	Tuesday, June 24, 1997 11:37 PM
To:	pp1394 ML
Subject:	[PP1394:00048] Printers and SBP-2


Printer-reflector folk:


I've copied two messages that went back and forth between Danny Mitchell and
me. I thought they might be of general interest to the groups.


Regards,


Peter Johansson


Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602


(510) 531-5472
(510) 531-2942 FAX


pjohansson@aol.com


************************************************************
In a message dated 97-06-19 00:17:33 EDT, DMitchell@ti.com (Danny Mitchell)
writes:


<<Some of the discussions here indicate that a printer might need to be both
initiator and target??  The discussion is along the line of compatability
with the 1284 protocols that have been developed for printers.  I am still
investigating that,  I do not really see the need for this type of complexity
for sending status data.>>


I haven't been part of the discussions about the necessity for a printer to
be a "targiator" and fulfill both roles, so perhaps I am missing something
when I say I do ot see the need for that sort of complexity, either.


Is the printer you contemplate FUNDAMENTALLY different from the model
implemented by parallel SCSI printers today? If it's much the same, there is
no need for the printer to be anything other than a target. The SBP-2 status
mechanisms, both that associated with a particular ORB and unsolicited
status, should be adequate.


Regards,


Peter Johansson


Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602


(510) 531-5472
(510) 531-2942 FAX


pjohansson@aol.com
************************************************************
In a message dated 97-06-22 01:27:36 EDT, DMitchell@ti.com (Danny Mitchell)
writes:


<<What about the case where the printer would want to send data back to the
host for status reporting ( paper out,  status of job,  etc.  ) and other
things that the printer group has defined using the 1284 specification  ( I
believe it defines bi-directional communication channels ).>>


This sounds like unsolicited status to me; covered by SBP-2.


<<Can I assume that a printer could provide "read" functions like a HDD
would?>>


You can provide any commands you want; for any one command the data can
either move from the initiator (e.g., PRINT) or to the initiator (e.g.,
REQUEST SENSE).


What are the addresses of the various PWG reflector(s)? I should be answering
these questions for the whole group.


Regards,


Peter
************************************************************

From DMitchell at ti.com  Wed Jun 25 19:55:03 1997
From: DMitchell at ti.com (Danny Mitchell)
Date: Wed May  6 14:00:45 2009
Subject: P1394> RE: [PP1394:00048] Printers and SBP-2
In-Reply-To: <01BC8204.96634720@gw-solo-fumio>
Message-ID: <3.0.2.32.19970625185503.00af4718@dlep1.itg.ti.com>

Nagasaka-san,


I think that SBP2 will work for your application just fine.  You could have
a printer cluster that has multiple logins for example,  or have a
controller that fetches each job and assigns the job to the appropriate
printer that is funcitonal and let that printer perform the fetch.


SBP2 spec has any combination of status sent back after each ORB or the PC
can pick the ORB that it desires status to be sent back.  Since the PC can
determine when/how much status is needed you should be able to get as much
or as little status as you need.  


At 05:16 AM 6/26/97 +0900, Fumio Nagasaka wrote:
>Peter, Danny, thank you for your helpful information.
>
>* This sounds like unsolicited status to me; covered by SBP-2.
>
>Actually some printers are needed to have reverse directional data transfer.
>The reverse directional (printer --> PC) data flow is intended to designed to
>service status. And we also would like to use reverse direction as pure
>data flow. One of the good example is printer cluster which is consisted by
>tow or more printers. When one of these printer has some trouble (due to 
>lacks of paper or some other reason), other printer may perform printing
>instead it.
>
>For this sort of application, IEEE P1284.4 has capability to service reverse
>data flow. Off cause this feature could be convenient even for status
reporting
>from a printer.
>
>I think "Normal command block ORB's" are supporting full feature of reverse
>data flow. Thus I believe SBP-2 can cover "Credit Base Transaction (CBT)"
>of IEEE P1284.4.
>
>I guess we may enclose our packets in data buffer associated by ORBs.
>I have a question to implement SBP-2 for printers. Can we have multiple
>fetch agent in a target device. I am curious whether we can enclose
particular
>packets those have a tag as a header of each packet, and also can have
>a particular fetch agent which seeks special packets those have the tag.
>
>If it is possible it could be helpful to make priority queue style linked
ORBs.
>-------------------------------
>Fumio Nagasaka
>Epson Software Development Laboratory Inc.
>Tel +81 268 25 4111,  Fax +81 268 25 4627
>E-mail to genesis@hd.epson.co.jp
>
>-----Original Message-----
>From:	PJohansson@aol.com [SMTP:PJohansson@aol.com]
>Sent:	Tuesday, June 24, 1997 11:37 PM
>To:	pp1394 ML
>Subject:	[PP1394:00048] Printers and SBP-2
>
>Printer-reflector folk:
>
>I've copied two messages that went back and forth between Danny Mitchell and
>me. I thought they might be of general interest to the groups.
>
>Regards,
>
>Peter Johansson
>
>Congruent Software, Inc.
>3998 Whittle Avenue
>Oakland, CA  94602
>
>(510) 531-5472
>(510) 531-2942 FAX
>
>pjohansson@aol.com
>
>************************************************************
>In a message dated 97-06-19 00:17:33 EDT, DMitchell@ti.com (Danny Mitchell)
>writes:
>
><<Some of the discussions here indicate that a printer might need to be both
>initiator and target??  The discussion is along the line of compatability
>with the 1284 protocols that have been developed for printers.  I am still
>investigating that,  I do not really see the need for this type of complexity
>for sending status data.>>
>
>I haven't been part of the discussions about the necessity for a printer to
>be a "targiator" and fulfill both roles, so perhaps I am missing something
>when I say I do ot see the need for that sort of complexity, either.
>
>Is the printer you contemplate FUNDAMENTALLY different from the model
>implemented by parallel SCSI printers today? If it's much the same, there is
>no need for the printer to be anything other than a target. The SBP-2 status
>mechanisms, both that associated with a particular ORB and unsolicited
>status, should be adequate.
>
>Regards,
>
>Peter Johansson
>
>Congruent Software, Inc.
>3998 Whittle Avenue
>Oakland, CA  94602
>
>(510) 531-5472
>(510) 531-2942 FAX
>
>pjohansson@aol.com
>************************************************************
>In a message dated 97-06-22 01:27:36 EDT, DMitchell@ti.com (Danny Mitchell)
>writes:
>
><<What about the case where the printer would want to send data back to the
>host for status reporting ( paper out,  status of job,  etc.  ) and other
>things that the printer group has defined using the 1284 specification  ( I
>believe it defines bi-directional communication channels ).>>
>
>This sounds like unsolicited status to me; covered by SBP-2.
>
><<Can I assume that a printer could provide "read" functions like a HDD
>would?>>
>
>You can provide any commands you want; for any one command the data can
>either move from the initiator (e.g., PRINT) or to the initiator (e.g.,
>REQUEST SENSE).
>
>What are the addresses of the various PWG reflector(s)? I should be answering
>these questions for the whole group.
>
>Regards,
>
>Peter
>************************************************************
>
>
>
>
Regards,  Danny Mitchell  ( Dallas, TX )


 BuS Solutions SW Manager
 www.ti.com/sc/1394 
 Ph: 972-480-3411     
 Fx: 972-480-3160     
 Texas Instruments, 8505 Forest Lane, MS-8710, Dallas, TX 75243

From don at lexmark.com  Wed Jun 25 08:18:13 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Re: Direct Printing Protocol
In-Reply-To: <Direct Printing Protocol>
Message-ID: <199706260337.AA12853@interlock2.lexmark.com>

Shinoda-san


I think there is a small misunderstanding about what was decided at
yesterday's meeting.  First, after considerable discussion the group
completed an IEEE Project Authorization Request for the service/
functional discovery work that we have talked about at length at
the last several meeting.  Second, it was not obvious to all of us
that where we were going with both the direct printing protocol
(or thin) and the PC printer protocol (or thick) were going to need
to be stand-alone standards.  We felt there was a significant probability
that we might simply need to define a command set and data format
for printing over FCP to meet the needs of the direct printing
environment and that we would only need to define command
descriptor blocks for SBP2.  Therefore we decided not to submit an
IEEE PAR until we had concluded that a stand-alone standard was
needed.  If only command sets and command descriptor blocks are
needed then perhaps a 1394TA document will be sufficient.


There is ABSOLUTELY NO intent to abandon our efforts to define
how to do direct print or PC printing over 1394.  The only question
is when we are done, what name (IEEE, 1394TA, IEC/ISO, ANSI,
etc.) is on the cover of the document.


Don


To:       pwg-c-sc%cpdc.canon.co.jp@interlock.lexmark.com,
          gregory_leclair%erc.epson.com@interlock.lexmark.com,
          lstein%fapo.com@interlock.lexmark.com,
          alan_berkema%hp.com@interlock.lexmark.com, Don Wright@Lexmark
cc:
From:     shinoda%bsd.canon.co.jp@interlock.lexmark.com @ LEXMTA
Date:     06/25/97 04:05:34 PM ZE9
Subject:  Direct Printing Protocol






Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable






Dear PWG-C SC members and PWG board members:
I was informed PWG meeting in Boston decided ( or not decided ? ) not t=
o
continue discussions and standardization activities of direct printing
protocol. I think we have agreed to involve this issue jointly PWG and
PWG-C.  So we made a unified charter in Austin and held joint meeting i=
n
Tokyo this month.


I would like to discuss this item with PWG-C members after I receive
further
report from Canon's attendants what kind discussions and conclusions
happened in Boston and PWG meeting minutes.
Regards,
Nob Shinoda
Chairman of PWG-C


?????                    Nobuhiko Shinoda
????????              General Manager
????????              BJP System Development Division
???(Shin-Kawasaki)         Canon Inc.
Faxphone 044-549-6301
??(Tamagawa)
Direct? 044-844-3913/ Fax 044-811-9391
???????????????
Fax      044-811-9391


???????????????????????????
My E-Mailaddress has been changed to shinoda@bsd.canon.co.jp. Also
organization name has been changed again.




=

From brianb at vcd.hp.com  Thu Jun 26 18:56:09 1997
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:45 2009
Subject: P1394> 1394PWG Meeting Minutes - June 23-24
Message-ID: <3.0.2.32.19970626155609.008a2be0@popmail1.vcd.hp.com>

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: 

From gregory_leclair at erc.epson.com  Mon Jun 30 22:00:09 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:45 2009
Subject: P1394> AV/C Working Group Meeting Summary 6/26
Message-ID: <9705308677.AA867724550@erc.epson.com>

     Hi all.
     
     I attended the end of the AV/C WG off-cycle meeting on Thursday 6/26 
     in Sunnyvale, CA upon return from Nashua.
     
     Sony handed out a copy of a proposal titled:
     
     "Proposal For The 1394 Trade Association: Self Describing Devices"
     "Preliminary suggestions for Descriptive Information in a 
     Configuration ROM"
     "Version 0.3"
     
     The information to be added would appear in a Root dependent directory 
     and also would be added to Unit directories. Compatibility with SBP-2 
     was not explicitly addressed.
     
     Some of the entries offer a different idea on what should be in Config 
     ROM, such as device icons which can be read from the device for use on 
     the UI.
     
     It seems the critical issue that is trying to be addressed is the 
     ability to return a Model Name string.
     
     The document describes same problem the 1394 PWG has identified as a 
     key issue with 1394 devices, namely, a way to enumerate functions 
     independent of protocol.
     
     My feedback was that we had been discussing similar issue in 1394 PWG 
     and were open to ideas on where the functional information should be 
     stored.
     
     The end of the meeting resulted in agreement that this is an issue 
     which should be discussed at 1394 TA architecture meeting.
     
     Please let me know if you have any questions.
     
     Greg LeClair, 1394 PWG Chair
     greg@erc.epson.com
     
     
     
     
     
     
     
     

From gregory_leclair at erc.epson.com  Tue Jul 15 22:22:57 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Results of IEEE MSC Meeting on 7/14
Message-ID: <9706158690.AA869021519@erc.epson.com>

     LATE BREAKING NEWS......
     
     At the IEEE MSC meeting last night, Greg LeClair gave an informal 
     dinner talk about the issues in printing on 1394.
     
     Our PAR was discussed, however, it was decided that the effort to 
     standardize an extension off the root directory for a non-protocol 
     specific method of functional unit discovery would be best handled in 
     the IEEE 1212 working group which is working on the reaffirmation of 
     the original IEEE Std. 1212-1991.
     
     It was agreed that Greg LeClair would chair the group tasked with 
     making a proposal to the IEEE 1212 working group for function unit 
     discovery.
     
     Also, the 1394 PWG study group status was extended by six months to 
     facilitate further investigation into the printing protocol and data 
     format on 1394 serial bus.
     
     If you have any questions, please reply to the list.
     
     
     Thanks,
     Greg LeClair
     
        >>>>>>------------------------------------------->>>>>>
        EPSON IMAGING TECHNOLOGY CENTER      greg@erc.epson.com  
        2833 Junction Ave., Suite 200        408.474.0500.x3610  
        San Jose, CA 95134                   408.474.0511  FAX   
                                                                 
     
     

From atsnaka at cbs.canon.co.jp  Wed Jul 16 21:50:54 1997
From: atsnaka at cbs.canon.co.jp (Atsushi Nakamura)
Date: Wed May  6 14:00:45 2009
Subject: P1394> RE:Results of IEEE MSC Meeting on 7/14
Message-ID: <199707170148.KAA08145@cbs.canon.co.jp>

First, I 'd like to thank Greg and other attendeees from PWG for
the effort at MSC.


Some confirmation for my understanding ;


------------
Since the MSC has agreed to take the function discovery 
issue up at the IEEE1212 revision working group,
does that mean;


1) The MSC sees the function discovery issue as a 
    IEEE1212 problem, not only a IEEE1394 issue?
    (PCI....etc?)


2) The MSC sees the origional intent of the 
    IEEE1212's definition of the unit directory
    IS protocol discovery after all, not function discovery.


OR,
Is this just the beginning of this disscusion?
Was there any technical disscusion to backup the idea 
for the function discovery be incorporated with 1212? 
I am afraid that we will have to start taking other buses 
(using IEEE1212) into consideration.


------------
>      It was agreed that Greg LeClair would chair the group tasked with
>      making a proposal to the IEEE 1212 working group for function unit
>      discovery


This group would be the PWG/PWG-C, not a new group,right?




--------------------------------------------
Atsushi Nakamura
BJ Printing Technology Development 22
Canon Inc.
email: Atsushi_Nakamura@cbj.canon.co.jp

From gregory_leclair at erc.epson.com  Wed Jul 16 22:19:02 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:45 2009
Subject: P1394> RE:Results of IEEE MSC Meeting on 7/14
In-Reply-To: <P1394> RE:Results of IEEE MSC Meeting on 7/14>
Message-ID: <9706168691.AA869107503@erc.epson.com>

Ats Nakamura wrote:
==================  
Since the MSC has agreed to take the function discovery 
issue up at the IEEE1212 revision working group,
does that mean;
     
1) The MSC sees the function discovery issue as a 
    IEEE1212 problem, not only a IEEE1394 issue? 
    (PCI....etc?)
     
2) The MSC sees the origional intent of the 
    IEEE1212's definition of the unit directory
    IS protocol discovery after all, not function discovery.
     


GL>The intent was that some information may fit into 1212.


GL>If it does, it should be proposed within the context of the 1212 spec. 
GL>Since 1212 is up for reaffirmation, this is the time to make requests known.


GL>We need to identify what information, if any, can/should be put into 1212 
GL>space that will solve the function discovery problem.




Is this just the beginning of this disscusion?


GL>Yes


Was there any technical disscusion to backup the idea 
for the function discovery be incorporated with 1212? 


GL>Some


I am afraid that we will have to start taking other buses 
(using IEEE1212) into consideration.


GL>They may feel the same way.
     
This group would be the PWG/PWG-C, not a new group,right?


GL>This is part of the 1212 WG - we're merely a task group. 
GL>My plan is that this will be discussed at PWG meetings.
GL>I can't speak for PWG-C or DSI-WG or 1394 TA.




     Greg LeClair
     
     >>>>>>------------------------------------------->>>>>> 
     EPSON IMAGING TECHNOLOGY CENTER      greg@erc.epson.com  
     2833 Junction Ave., Suite 200        408.474.0500.x3610
     San Jose, CA 95134                   408.474.0511  FAX   
     
     

From atsnaka at cbs.canon.co.jp  Thu Jul 17 04:46:32 1997
From: atsnaka at cbs.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:45 2009
Subject: P1394> RE:Results of IEEE MSC Meeting on 7/14
In-Reply-To: <P1394> RE:Results of IEEE MSC Meeting on 7/14>
Message-ID: <199707170843.RAA03819@cbs.canon.co.jp>

Greg,


Is my understanding right that IF in the course of disscusion,
it turns out that the contents of Function discovery is 
more suitable for the 1394 spec and not 1212, 
the target of our proposal may change ? 
 
I believe that we already have general concensus on what 
information (not yet how....) should be put in the Function
discovery scheme.(In Japan)
 
P.S.
Many PWG-C members would like to know how this Function discovery
turned out to be a 1212 issue, not a 1394 issue.




At 19:19 97/07/16 PDT, gregory_leclair wrote:
> 
> Ats Nakamura wrote:
> ==================  
> Since the MSC has agreed to take the function discovery 
> issue up at the IEEE1212 revision working group,
> does that mean;
>      
> 1) The MSC sees the function discovery issue as a 
>     IEEE1212 problem, not only a IEEE1394 issue? 
>     (PCI....etc?)
>      
> 2) The MSC sees the origional intent of the 
>     IEEE1212's definition of the unit directory
>     IS protocol discovery after all, not function discovery.
>      
> 
> GL>The intent was that some information may fit into 1212.
> 
> GL>If it does, it should be proposed within the context of the 1212 spec. 
> GL>Since 1212 is up for reaffirmation, this is the time to make requests
known.
> 
> GL>We need to identify what information, if any, can/should be put into 1212


> GL>space that will solve the function discovery problem.
>


-----------------------------------------
Atsushi Nakamura
-----------------------------------------
BJ Printing Technology
Develpoment 22,
Canon Inc.
tel:+81-3-5482-8396
fax:+81-3-3756-6052
email-1:Atsushi_Nakamura@cbj.canon.co.jp
email-2:atsnaka@cbs.canon.co.jp
-----------------------------------------

From Ozay_Oktay at cissc.canon.com  Thu Jul 17 18:34:48 1997
From: Ozay_Oktay at cissc.canon.com (Oktay, Ozay)
Date: Wed May  6 14:00:45 2009
Subject: P1394> RE:Results of IEEE MSC Meeting on 7/14
Message-ID: <199707170843.RAA03819@cbs.canon.co.jp>

I agree with Nakamura-san..


The disadvantages of involving another group (ie 1212) will definitely
outweigh the advantages. The Functional Discovery issue should be dealt
with under 1394..


Best Regards
Ozay Oktay


Canon Information Systems
ozay_oktay@cissc.canon.com


>----------
>From: 	Atsushi_Nakamura[SMTP:atsnaka@cbs.canon.co.jp]
>Sent: 	Thursday, July 17, 1997 1:46 AM
>To: 	p1394@pwg.org
>Subject: 	Re: P1394> RE:Results of IEEE MSC Meeting on 7/14
>
>Greg,
>
>Is my understanding right that IF in the course of disscusion,
>it turns out that the contents of Function discovery is 
>more suitable for the 1394 spec and not 1212, 
>the target of our proposal may change ? 
> 
>I believe that we already have general concensus on what 
>information (not yet how....) should be put in the Function
>discovery scheme.(In Japan)
> 
>P.S.
>Many PWG-C members would like to know how this Function discovery
>turned out to be a 1212 issue, not a 1394 issue.
>
>
>At 19:19 97/07/16 PDT, gregory_leclair wrote:
>> 
>> Ats Nakamura wrote:
>> ==================  
>> Since the MSC has agreed to take the function discovery 
>> issue up at the IEEE1212 revision working group,
>> does that mean;
>>      
>> 1) The MSC sees the function discovery issue as a 
>>     IEEE1212 problem, not only a IEEE1394 issue? 
>>     (PCI....etc?)
>>      
>> 2) The MSC sees the origional intent of the 
>>     IEEE1212's definition of the unit directory
>>     IS protocol discovery after all, not function discovery.
>>      
>> 
>> GL>The intent was that some information may fit into 1212.
>> 
>> GL>If it does, it should be proposed within the context of the 1212 spec. 
>> GL>Since 1212 is up for reaffirmation, this is the time to make requests
>known.
>> 
>> GL>We need to identify what information, if any, can/should be put into
>>1212
>
>> GL>space that will solve the function discovery problem.
>>
>
>-----------------------------------------
>Atsushi Nakamura
>-----------------------------------------
>BJ Printing Technology
>Develpoment 22,
>Canon Inc.
>tel:+81-3-5482-8396
>fax:+81-3-3756-6052
>email-1:Atsushi_Nakamura@cbj.canon.co.jp
>email-2:atsnaka@cbs.canon.co.jp
>-----------------------------------------
>

From don at lexmark.com  Thu Jul 17 20:13:16 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> RE:Results of IEEE MSC Meeting on 7/14
Message-ID: <199707180026.AA00754@interlock2.lexmark.com>

At the Nashua meeting, I said that because of where we want function
discovery to operate, i.e. at the ROM level using the directories, etc. as
defined by IEEE Standard 1212, there was a real chance that this would be
perceived as really a part of 1212.  Because 1212 is currently open for
revision (it is 5 years old and there are a handful of things that need to
be updated and fixed) the MSC believed that creating a 1212.x standard
which is effectively a supplement to 1212,  would be rejected by the IEEE
New Standards Committee.  For this same reason, it was the opinion of the
MSC that this is not a 1394 specific standard but should be applied to all
the projects (e.g. FutureBus) which also uses 1212.


The structure of this work was specifically divided to prevent our group
from being loaded down with the base 1212 changes.  The PWG/PWG-C are
considered a task group that are only charged with working on the function
discovery issues.  Our changes and additions will be applied into the
standard by the 1212 editor.  By the way, the 1212 work is on an
accelerated schedule and because we won't have to create an entire standard
from scratch we will probably be able to pull this off faster.
Additionally, because the 1212 chair, David James, is working on this as
well (along with Peter Johansson, and others) we have some built in
advisors to keep us on the right track.


I hope this helps to explain what went on.


Don


**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

From lstein at fapo.com  Fri Jul 18 11:16:52 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:45 2009
Subject: P1394> RE:Results of IEEE MSC Meeting on 7/14
Message-ID: <3.0.32.19970718073512.0072a0fc@pop3.fapo.com>

Hello to all,


Sorry I missed the last meeting.


With regards to this issue of 1212 vs 1394 I have a few comments.
I think that the 1394PWG was well represented at the MSC meeting.  Greg,
Don and I were there for the discussion.  


For the past few 1394PWC/PWG-C meetings we have focused on the 1212
standard as the method to implement the Device and Function Discovery.  A
number of times the question was raised as to whether this is a 1212 or
1394 issue.  This subject was discussed at length at the MSC meeting.  The
committee felt that this was best placed under 1212 for the following reasons:


1- This methodology can be applied to interfaces other than 1394
2- Since the 1212 spec is open for reaffirmation this gives us more 
   flexibility in defining the discovery mechanism.
3- We don't have the overhead of creating a new IEEE committee for this.
   This means we could go to ballot before the end of the year.
   There is a push to have this done by December.  Impossible as a new 
   IEEE committee.
4- There are just a few additional minor 1212 issues.  So there will be very 
   little impact on what we are doing.
5- As the only 1212 "task group", we will meet just as we are now.  No 
   change in our procedure.
6- This doesn't effect the printing protocol part of our discussions.


For these reasons it seems to me that this is a good way to proceed.  If
two months from now we find that we need a separate path then that is still
available.


Thanks,
Larry


and At 03:34 PM 7/17/97 -0700, Oktay, Ozay wrote:
>I agree with Nakamura-san..
>
>The disadvantages of involving another group (ie 1212) will definitely
>outweigh the advantages. The Functional Discovery issue should be dealt
>with under 1394..
>
>Best Regards
>Ozay Oktay
>
>Canon Information Systems
>ozay_oktay@cissc.canon.com
>
>>----------
>>From: 	Atsushi_Nakamura[SMTP:atsnaka@cbs.canon.co.jp]
>>Sent: 	Thursday, July 17, 1997 1:46 AM
>>To: 	p1394@pwg.org
>>Subject: 	Re: P1394> RE:Results of IEEE MSC Meeting on 7/14
>>
>>Greg,
>>
>>Is my understanding right that IF in the course of disscusion,
>>it turns out that the contents of Function discovery is 
>>more suitable for the 1394 spec and not 1212, 
>>the target of our proposal may change ? 
>> 
>>I believe that we already have general concensus on what 
>>information (not yet how....) should be put in the Function
>>discovery scheme.(In Japan)
>> 
>>P.S.
>>Many PWG-C members would like to know how this Function discovery
>>turned out to be a 1212 issue, not a 1394 issue.
>>
>>
>>At 19:19 97/07/16 PDT, gregory_leclair wrote:
>>> 
>>> Ats Nakamura wrote:
>>> ==================  
>>> Since the MSC has agreed to take the function discovery 
>>> issue up at the IEEE1212 revision working group,
>>> does that mean;
>>>      
>>> 1) The MSC sees the function discovery issue as a 
>>>     IEEE1212 problem, not only a IEEE1394 issue? 
>>>     (PCI....etc?)
>>>      
>>> 2) The MSC sees the origional intent of the 
>>>     IEEE1212's definition of the unit directory
>>>     IS protocol discovery after all, not function discovery.
>>>      
>>> 
>>> GL>The intent was that some information may fit into 1212.
>>> 
>>> GL>If it does, it should be proposed within the context of the 1212 spec. 
>>> GL>Since 1212 is up for reaffirmation, this is the time to make requests
>>known.
>>> 
>>> GL>We need to identify what information, if any, can/should be put into
>>>1212
>>
>>> GL>space that will solve the function discovery problem.
>>>
>>
>>-----------------------------------------
>>Atsushi Nakamura
>>-----------------------------------------
>>BJ Printing Technology
>>Develpoment 22,
>>Canon Inc.
>>tel:+81-3-5482-8396
>>fax:+81-3-3756-6052
>>email-1:Atsushi_Nakamura@cbj.canon.co.jp
>>email-2:atsnaka@cbs.canon.co.jp
>>-----------------------------------------
>>
>
*****************************************************************************
Larry A. Stein			Phone: (619)292-2740
Warp Nine Engineering		Fax:	(619)292-8020
					Web: 	http://www.fapo.com
*****************************************************************************

From don at lexmark.com  Fri Jul 18 12:14:51 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Seattle PING
Message-ID: <199707181614.AA11348@interlock2.lexmark.com>

Blank lines to keep the reflector from rejecting this mail...

--

--

--

--

--




Sorry for the cross post but there are still many who do
not subscribe to the PWG administrative reflector.  If you
did not see this post off that reflector, please subscribe
immediately.


Please send me your PING for the Seattle/Redmond meetings
including which meetings you will be attending.  Those of you
who have already done so, there is no need to re-PING.


Don


From don at lexmark.com  Fri Jul 18 18:07:11 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> August PWG meetings
Message-ID: <199707182207.AA22181@interlock2.lexmark.com>

Just a reminder...


The August meetings of the PWG working groups will be held at
Microsoft in Redmond, WA. from August 4th through 8th.  Here
are the details on the meeting times and locations:


Mon/Tue   1394 Printing     9:00AM to 6:00PM
                            Building 27N, Olympic Room
Wed/Thur  IPP               8:30AM to 6:00PM
                            Building 31, Pebble Beach
Fri       JMP/SENSE         8:30AM to 6:00PM
                            Building 31, Pebble Beach


There is a PDF of a map of the Microsoft site on the Chair's
page (http://www.pwg.org/chair/mssite.psf).  The map is a
little hard to read because it fits the whole campus on a
single page but buildings 27N and 31 are marked.


See you in Redmond!!


Don


**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

From fw at hplb.hpl.hp.com  Wed Jul 23 17:21:59 1997
From: fw at hplb.hpl.hp.com (Frederik Willerup)
Date: Wed May  6 14:00:45 2009
Subject: P1394> JetSend
Message-ID: <33D675F7.A6090F18@hplb.hpl.hp.com>

Greetings,


Hewlett-Packard has just annouched a new protocol for peer-to-
peer device interaction called JetSend. It might be of interest
to this group. Please have a look at our web site which contains
white papers as well as a complete protocol specification:


       http://www.jetsend.hp.com


Thanks,




Frederik Willerup


Information Appliance Operation
Hewlett-Packard
email: fw@hplb.hpl.hp.com

From THERESA_RHOADES at HP-Boise-om8.om.hp.com  Thu Jul 24 13:09:52 1997
From: THERESA_RHOADES at HP-Boise-om8.om.hp.com (THERESA_RHOADES@HP-Boise-om8.om.hp.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> August Meeting Agenda
Message-ID: <H00009fe0377aa40@MHS>

     I would be interested in knowing the agenda items planned for the 
     August  p1394 and IPP meetings.  Is there a detailed agenda available 
     somewhere?
     
     
     Thanks,
     
     Theresa Rhoades
     
     Information Appliance Division
     Hewlett-Packard
     Theresa_Rhoades@hp.com

From don at lexmark.com  Fri Jul 25 15:58:21 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> September Meeting in Atlanta
Message-ID: <199707251958.AA18604@interlock2.lexmark.com>

I have finalized the September Meeting in Atlanta.  Here are the details:


When: September 15-19
Where: Atlanta Marriott Suites Midtown
Price: $129 per night
Deadline: August 29th
Reservations: 1-800-228-9290, 1-404-876-8888
Meeting Fee: in the range $35-40 expected


All you Type A people should be able to start making your reservations
on Monday (July 28th).


Don


**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

From gregory_leclair at erc.epson.com  Wed Jul 30 15:42:51 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Redmond Agenda 8/4 & 8/5
Message-ID: <9706308702.AA870293236@erc.epson.com>

     
     Here is a tentative agenda for 1394 PWG Session in Redmond on August 
     4th and 5th. 
     
     I've added a tentative listing for PWG-C as requested and also a slot 
     for someone from HP to present info on JetSend (if their is 
     sufficient interest).
     
     Please reply if you'd like a spot on the agenda. I'd like to provide 
     working agenda back to the list by Friday 8/1.
     
     
     A. Organization Issues
        - Future Meetings 
          - Sept. - Atlanta
          - 1998 PWG Agenda
        - Discovery PAR feedback from MSC
     
     B. Function Discovery Protocol
        - What belongs in IEEE 1212?
        - What belongs in IEEE 1394?
        - What belongs in SBP-2?
        - What belongs in Other?
        - PWG recommendation for each of the above.
     
     C. Nashua Homework Discussions
        - P1394.x Printing Protocol" Requirements doc. (Brian) 
        - Transport: SBP-2 Printer CDBs (Berkema & Ueda)
        - Common Image Data Format (Nakamura & Farrell)
     
     D. Atlanta Homework Assignments
        - 1212 
        - 1394 
        - SBP-2 
        - FCP 
     
     D. Presentations
        (Agenda & Topics - TBD)
     
        - PWG-C (Shinoda - topics TBD)
     
        - HP JetSend (anybody available from HP?)
     
     
     
     Please let me know if you have any comments.
     
     Thanks,
     Greg LeClair
     
     
     *****  Epson Imaging Technology Center   ***** 
     Gregory LeClair    2833 Junction Ave, Ste. 200 
     greg@erc.epson.com          San Jose, CA 95134 
     408.474.0500 x 3610         (FAX) 408.474.0511

From don at lexmark.com  Fri Aug  1 07:18:22 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> October Meeting in Denver
Message-ID: <199708011118.AA01752@interlock2.lexmark.com>

I have had a request that we move the Denver meeting out one week
to Novemebr 3-7 to avoid a conflict with a major UNIX show.  Please
respond to this note only if you have a problem with moving the
meeting.


Additionally, as a part of reviewing the proposed dates and locations
for the 1998 meeting, please compare my proposal against major
shows and other events that could be a problem.


Thanks!


Don


**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

From lstein at fapo.com  Fri Aug  1 10:13:17 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:45 2009
Subject: P1394> October Meeting in Denver
In-Reply-To: <P1394> October Meeting in Denver>
Message-ID: <3.0.32.19970801070650.00738f90@pop3.fapo.com>

That week is bad for me.  We're doing a 2 day 1284 class in Amsterdam that
week.
Thanks,
Larry


At 07:18 AM 8/1/97 -0400, don@lexmark.com wrote:
>
>I have had a request that we move the Denver meeting out one week
>to Novemebr 3-7 to avoid a conflict with a major UNIX show.  Please
>respond to this note only if you have a problem with moving the
>meeting.
>
>Additionally, as a part of reviewing the proposed dates and locations
>for the 1998 meeting, please compare my proposal against major
>shows and other events that could be a problem.
>
>Thanks!
>
>Don
>
>**********************************************
>* Don Wright                 don@lexmark.com *
>* Manager, Strategic Alliances and Standards *
>* Lexmark International                      *
>* 740 New Circle Rd                          *
>* Lexington, Ky 40550                        *
>* 606-232-4808 (phone) 606-232-6740 (fax)    *
>**********************************************
>
>
>
*****************************************************************************
Larry A. Stein			Phone: (619)292-2740
Warp Nine Engineering		Fax:	(619)292-8020
					Web: 	http://www.fapo.com
*****************************************************************************

From szilles at Adobe.COM  Fri Aug  1 12:07:43 1997
From: szilles at Adobe.COM (Steve Zilles)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Re: PWG> October Meeting in Denver
In-Reply-To: <PWG> October Meeting in Denver>
Message-ID: <199708011607.JAA29614@bulletin>

I have a major problem because I will be on vacation that week.
        Steve Z

From gregory_leclair at erc.epson.com  Mon Aug  4 09:59:00 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Last minute update - new docs
Message-ID: <9707048707.AA870705063@erc.epson.com>

     Hi folks,
     
     There is an update of the Function Discovery document and a new 
     proposal for SBP-2 over 1394.
     
     Please check it out on the Documents page on the web site - 
     
     http://www.pwg.org/p1394
     
     
     Remember, the meeting doesn't start until 9:00 AM today!!!!
     
     
     Cheers,
     Greg

From don at lexmark.com  Mon Aug  4 13:56:49 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> October Meeting in Denver
Message-ID: <199708041821.AA18609@interlock2.lexmark.com>

--0__=J1fyLlwlk4CJ4rQRXvyabplBxpHKqyhMRM19KKeYMXpKCZZoojqHNsny
Content-type: text/plain; charset=us-ascii


OK, I had 2 no's on moving the meeting out a week.  What about moving
it in one week to October 20-24?  Only those that can make those dates
should reply.  Remember 1394 Printing on Monday/Tuesday, IPP on
Wednesday/Thursday and JMP, SENSE, etc. on Friday.


Thanks!


Don


**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************


---------------------- Forwarded by Don Wright on 08/04/97 01:54 PM
---------------------------


Don Wright                           Note sent on 08/01/97 07:18 AM
(Embedded image moved to file: PIC31204.PCX)
Manager, Strategic Alliances and Standards
Lexmark International
606-232-4808
606-232-6740 (fax)
don@lexmark.com




To:   pwg@pwg.org, ipp@pwg.org, p1394@pwg.org, jmp@pwg.org
cc:
Subject:  October Meeting in Denver


I have had a request that we move the Denver meeting out one week
to Novemebr 3-7 to avoid a conflict with a major UNIX show.  Please
respond to this note only if you have a problem with moving the
meeting.


Additionally, as a part of reviewing the proposed dates and locations
for the 1998 meeting, please compare my proposal against major
shows and other events that could be a problem.


Thanks!


Don


**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************






--0__=J1fyLlwlk4CJ4rQRXvyabplBxpHKqyhMRM19KKeYMXpKCZZoojqHNsny
Content-type: application/octet-stream; 
	name="PIC31204.PCX"
Content-transfer-encoding: base64


[encoded data, 6468 characters]


--0__=J1fyLlwlk4CJ4rQRXvyabplBxpHKqyhMRM19KKeYMXpKCZZoojqHNsny--

From don at lexmark.com  Mon Aug  4 14:55:31 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Re: PWG> October Meeting in Denver
In-Reply-To: <PWG> October Meeting in Denver>
Message-ID: <199708041907.AA20512@interlock2.lexmark.com>

--0__=eY3KHUZACQ5Ihwv8rrzoFcQLCZDggCv0MIQzBsq1E3josWVQzRUI92F5
Content-type: text/plain; charset=us-ascii


Opps -- only those who CAN NOT make October 20-24 should reply.


Don


**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************










Don_Wright.LEXMARK@lexmta01.notes.lexmark.com
08/04/97 01:56 PM




To:   pwg%pwg.org@interlock.lexmark.com, ipp%pwg.org@interlock.lexmark.com,
      p1394%pwg.org@interlock.lexmark.com,
      jmp%pwg.org@interlock.lexmark.com
cc:    (bcc: Don Wright)
Subject:  PWG> October Meeting in Denver








OK, I had 2 no's on moving the meeting out a week.  What about moving
it in one week to October 20-24?  Only those that can make those dates
should reply.  Remember 1394 Printing on Monday/Tuesday, IPP on
Wednesday/Thursday and JMP, SENSE, etc. on Friday.
Thanks!
Don
**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************
---------------------- Forwarded by Don Wright on 08/04/97 01:54 PM
---------------------------
Don Wright                           Note sent on 08/01/97 07:18 AM
(Embedded image moved to file: PIC31204.PCX)
Manager, Strategic Alliances and Standards
Lexmark International
606-232-4808
606-232-6740 (fax)
don@lexmark.com


To:   pwg@pwg.org, ipp@pwg.org, p1394@pwg.org, jmp@pwg.org
cc:
Subject:  October Meeting in Denver
I have had a request that we move the Denver meeting out one week
to Novemebr 3-7 to avoid a conflict with a major UNIX show.  Please
respond to this note only if you have a problem with moving the
meeting.
Additionally, as a part of reviewing the proposed dates and locations
for the 1998 meeting, please compare my proposal against major
shows and other events that could be a problem.
Thanks!
Don
**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************








--0__=eY3KHUZACQ5Ihwv8rrzoFcQLCZDggCv0MIQzBsq1E3josWVQzRUI92F5
Content-type: application/octet-stream; 
	name="PIC31204.PCX"
Content-transfer-encoding: base64


[encoded data, 6468 characters]


--0__=eY3KHUZACQ5Ihwv8rrzoFcQLCZDggCv0MIQzBsq1E3josWVQzRUI92F5--

From don at lexmark.com  Tue Aug  5 14:27:53 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> October Meeting
Message-ID: <199708051832.AA29656@interlock2.lexmark.com>

Well, I'm stuck between a rock and a hard place.  I have three who
cannot make it the week of Nov 3rd, two that can't make it the
announced week of October 27th and two that can't make it the
week of October 20th.  Unless someone has a solution to this
problem, I can't see any justification to move the meeting.


Don


**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

From gregory_leclair at erc.epson.com  Wed Aug  6 09:29:21 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Updates to PWG site
Message-ID: <9707068708.AA870876553@erc.epson.com>

     Hi folks,
     
     I mistakenly left off the updated presentation for the Function 
     Discovery Protocol proposal. 
     
     Also, there was a minor update to the SBP-2 printing protocol 
     proposal. The latest version is now 0.3d.
     
     All presenters at 1394 PWG meeting can send Powerpoint or PDF files to 
     me for posting on the site.
     
     Regards,
     
     Greg
      

From don at lexmark.com  Mon Aug 11 02:59:40 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Atlanta Ping
Message-ID: <199708110703.AA11063@interlock2.lexmark.com>

The time has come to ping me to let me know what meetings you
will be attending in Atlanta.  Please include the following:


Name
Arrival date
Meetings attending
Departure date


Remember, the deadline for making reservations at the Atlanta
Midtown Suites hotel is August 29th.


Don


**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

From don at lexmark.com  Tue Aug 26 10:31:44 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Last Reminder: September Meeting in Atlanta
Message-ID: <199708261431.AA16627@interlock2.lexmark.com>

--0__=fk5msamZns7sqhSdMCxTr9IINfgXx08DtHk3ZjBJwM0P2lhopQ8jZeX5
Content-type: text/plain; charset=us-ascii


Don't forget to make your reservations for the
Atlanta meeting.  The deadline is this Friday - 8/29.
While you are at it --- drop me a ping if you haven't
already!


Don


**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************




---------------------- Forwarded by Don Wright on 08/26/97 10:31 AM
---------------------------


Don Wright                           Note sent on 07/25/97 03:58 PM
(Embedded image moved to file: PIC32704.PCX)
Manager, Strategic Alliances and Standards
Lexmark International
606-232-4808
606-232-6740 (fax)
don@lexmark.com




To:   IPP, P1394, JMP, pwg@pwg.org
cc:
Subject:  September Meeting in Atlanta


I have finalized the September Meeting in Atlanta.  Here are the details:


When: September 15-19
Where: Atlanta Marriott Suites Midtown
Price: $129 per night
Deadline: August 29th
Reservations: 1-800-228-9290, 1-404-876-8888
Meeting Fee: in the range $35-40 expected


All you Type A people should be able to start making your reservations
on Monday (July 28th).


Don


**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************




--0__=fk5msamZns7sqhSdMCxTr9IINfgXx08DtHk3ZjBJwM0P2lhopQ8jZeX5
Content-type: application/octet-stream; 
	name="PIC32704.PCX"
Content-transfer-encoding: base64


[encoded data, 6468 characters]


--0__=fk5msamZns7sqhSdMCxTr9IINfgXx08DtHk3ZjBJwM0P2lhopQ8jZeX5--

From hirata at vip.iwa.fujixerox.co.jp  Tue Sep  2 00:26:29 1997
From: hirata at vip.iwa.fujixerox.co.jp (Kazuhiro HiRATA)
Date: Wed May  6 14:00:45 2009
Subject: P1394> redmond minutes
Message-ID: <199709020426.NAA03933@goudy.vip.iwa.fujixerox.co.jp>

Hi, PWG1394 folks.


I've searched a minutes of PWG at Redmond, but it seems no document comes 
on anywhere.  Please upload the authorized minutes to determine our status.


I want to confirm what,who and how to discuss the function discovery and 
the printer unit architecture (this is also new word from Redmond).  
Since I'm volunteer of FDS group but I will not attend next PWG meeting, 
I need talk with Nakamura@Canon further FDS scheme before he will 
departure from Narita.


The authorized minutes will help us to start the discussion.  I don't 
want to make the redmond meeting be "past dream".


I hope to upload the minutes in a cople of days.  Thanks for any helps.


//HiRATA@Sep.2'97

From don at lexmark.com  Mon Sep  8 18:53:41 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Atlanta Ping List
Message-ID: <199709082258.AA27950@interlock2.lexmark.com>

I have created a list on the Web site of those who have pinged
for the Atlanta meeting.  It is available off the Atlanta meeting
page or directly at http://www.pwg.org/chair/atl-ping.html.


If you didn't ping me and show up --- well I'll figure out what the
penalty is later.  Conversely, if you pinged me and no show, the
price is your share of the meeting cost anyway!!!


Don


**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

From ueda at pure.cpdc.canon.co.jp  Thu Sep 11 21:11:31 1997
From: ueda at pure.cpdc.canon.co.jp (Shigeru Ueda)
Date: Wed May  6 14:00:45 2009
Subject: P1394> I put the High Performance Transport Rev0.3e
Message-ID: <199709120111.KAA06397@slant1.pure.cpdc.canon.co.jp>

Hello folks,


This is Shigeru Ueda of Canon.


As reported at the last PWG 1394 meeting in Redmond,my stuff have
completed writtening the document of the specification of "High Performance
Transport Rev0.3e" ,and put it to the PWG-C ftp site.


The URL is,


ftp://ftp.tokyoweb.or.jp/pwgc1394/pub/proposals/canon/HPT03E.pdf


Though the agenda of the coming PWG 1394 Atlanta meeting on September 15,
16 is not delivered yet,My stuff would like to explain the above
specification at that meeting if possible.




Best Regards.


Shigeru Ueda.


----------------------------------------------------------
               $B%-%d%N%s3t<02q<R!J(B Canon inc .)
               $B1GA|;vL35!#3#1#3@_7W<<!J(B Office Design Dept.313 $B!K(B


                       $B>eED(B $BLP(B ( Sigeru Ueda )


              $BEEOC!J(BTEL$B!K(B 044-549-5111(+81-44-549-5111)
               E-mail : ueda@pure.cpdc.canon.co.jp
-----------------------------------------------------------

From atsnaka at cbs.canon.co.jp  Sat Sep 13 04:20:51 1997
From: atsnaka at cbs.canon.co.jp (Atsushi Nakamura)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Function Discovery PWG-C Proposal
Message-ID: <199709130822.RAA24950@meshsv02.tk.mesh.ad.jp>

The latest version of 
The IEEE1212/IEEE1394 Function Discovery Proposal
by PWG-C (based on Canon's Proposal)
can be obtained at:


ftp://ftp.tokyoweb.or.jp/pwgc1394/pub/proposals/sub-WG/Fds05.pdf


It will be on the PWG site also soon.


The PWG-C is plans to do a presentation on this document
at the Atlanta mtg.






Atsushi Naqkamura
BJ Printing Technology Development 22
Canon Inc.
------------------------------------
 Atsushi_Nakamura@cbj.canon.co.jp
 atsnaka@mxa.meshnet.or.jp

From gregory_leclair at erc.epson.com  Sun Sep 14 06:01:00 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:45 2009
Subject: P1394> 1394 PWG site update
Message-ID: <9708148742.AA874231559@erc.epson.com>

     All files submitted to me for posting by 9/13 were posted. Check out the 
     documents page.
     
     Sorry for the delay folks.
     
     
     Greg

From gregory_leclair at erc.epson.com  Mon Sep 15 07:42:50 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Agenda
Message-ID: <9708158743.AA874324255@erc.epson.com>

     1394 Printer Working Group
     Atlanta Meeting - 9/15 & 9/16
     
     
     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)
     
     

From don at lexmark.com  Mon Sep 15 21:55:05 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> October PWG Meeting Details
Message-ID: <199709160203.AA05599@interlock2.lexmark.com>

Here are the details on the October Meeting...


October 27-31
"Hotel Boulderado"
2115 13th St.
Boulder, CO 80302
Phone - (303) 442-4344
Fax -   (303) 443-7035
Reservations - 1-800-433-4344


Deadline:  October 3rd.
Rates - $104 (Standard - 1 Queen bed)
        $114 (Deluxe - 2 Queen or 1 King)
Meeting Room charges are estimated at $35-40 per person per day.
Participants responsible for making their own reservations. Be sure to
reference the PWG or IBM meeting to acquire the preferred rate. Limited
numbers
of Standard and Deluxe rooms are available. Early callers will get the
Standard
room/rate until this block is exhausted unless you specifically request
Deluxe.
The Hotel Boulderado, established in 1909, is a historic landmark with a
"historic" section and a more modern wing. You may want to request your
preference although I can't guarantee it will be available. Standard rooms
tend
to be a tad smaller in "historic" but each is unique. Deluxe rooms in the
historic section are quite nice.
Boulder is located appx. 50 minutes from the Denver International Airport.
Free
parking is available at the Boulderado for guests.   From DIA, take Pena
Blvd
south 12 miles and merge right onto I-70 West. Take I-70 to I-270 (right)
and
head northwest to US 36 (right). When you reach Boulder proceed left onto
Canyon Blvd (3rd light). Take Canyon to 13th (5th light) and turn right
(north). Hotel Boulderado is at the corner of 13th and Spruce.
You can also catch a shuttle called the "Airporter"  which leaves on the
hour
from DIA. $14 one way - no reservation necessary. Check in with baggage, on
DIA
baggage level 5 across from the Hertz counter. It leaves every hr. on the
1/2
hr from the hotel for the return. Reservations recommended but not
necessary.
The Boulderado is a major stop. Travel time via shuttle is appx 70 minutes.
The Boulderado is located in the heart of Boulder one block from "Pearl
Street", an outdoor mall with shops, restaurants, etc.
 Forgoing the automobile is quite feasible.
For more information on getting from DIA to Boulder visit
http://amath-www.colorado.edu/appm/department/limos.html


Don


**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

From gregory_leclair at erc.epson.com  Mon Sep 15 17:25:31 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:45 2009
Subject: P1394> October Hotel Reservations
Message-ID: <9708168744.AA874412299@erc.epson.com>

     Soory if this is a double copy. I thought everyone on 1394 PWG list 
     might want to know about this approaching deadline for the next TA 
     quarterly meeting.
     
     Greg
      




______________________________ Forward Header __________________________________
Subject: October Hotel Reservations 
Author:  <toni@skipstone.com > at xInternet
Date:    9/15/97 3:11 PM




Hi Everyone!
Another Reminder.  You only have until the end of this week to make your 
hotel reservations for the  TA meeting in October to get the discounted rate. 
Discount expires on the 19th. After that date, you will be required to pay 
the regular hotel rate. 
Don't forget to mention the "1394 Trade Association" when making your 
reservations!
Check out the web site for details.
     
toni
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
Toni Tappan
1394 TA Administrator
512-305-0203(1394 Trade Association) 
512-305-0212(Fax)
toni@skipstone.com
www.1394ta.org(TA Web Site)
1394 Trade Association
c/o Adaptec
3925 W. Braker Ln., Ste. 425
Austin, TX  78759
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
Toni Tappan
1394 TA Administrator
512-305-0203(1394 Trade Association) 
512-305-0212(Fax)
toni@skipstone.com
www.1394ta.org(TA Web Site)
1394 Trade Association
c/o Adaptec
3925 W. Braker Ln., Ste. 425
Austin, TX  78759
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     

From gregory_leclair at erc.epson.com  Wed Sep 17 02:53:33 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Some files posted to web site
Message-ID: <9708168744.AA874479476@erc.epson.com>

     Hi all,
     
     The DFA proposal, FDS presentation and HPT presentation have been 
     posted.
     
     As I get the other files, they will be posted. Minutes will be posted 
     after the FDS sub-group meeting on Wed. 9/17.  
     
     Greg

From harryl at us.ibm.com  Mon Sep 22 18:42:10 1997
From: harryl at us.ibm.com (Harry Lewis)
Date: Wed May  6 14:00:45 2009
Subject: P1394> October PING
Message-ID: <9708168744.AA874479476@erc.epson.com>

Since Don will not be able to make the October meeting, please PING me (Harry
Lewis) at harryl@us.ibm.com regarding your attendance to the October meeting in
Boulder. Please let me know the meetings your will attend (p1394 Monday/Tuesday;
IPP Wednesday/Thursday; and JMP/FIN Friday), and whether or not you are staying
at the Boulderado.


Please remember to make your reservations at the Boulderado before 10/3!


October 27-31
"Hotel Boulderado"
2115 13th St.
Boulder, CO 80302
Phone - (303) 442-4344
Fax -   (303) 443-7035
Reservations - 1-800-433-4344


Deadline:  October 3rd.
Rates - $104 (Standard - 1 Queen bed)
        $114 (Deluxe - 2 Queen or 1 King)


Harry Lewis - IBM Printing Systems

From gregory_leclair at erc.epson.com  Tue Sep 23 12:40:56 1997
From: gregory_leclair at erc.epson.com (gregory leclair)
Date: Wed May  6 14:00:45 2009
Subject: P1394> September Meeting Minutes
Message-ID: <9708238750.AA875039679@erc.epson.com>

     
     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
             lstein@fapo.com
      and 
          Greg LeClair
             EPSON Imaging Technology Center
             greg@erc.epson.com
     

From harryl at us.ibm.com  Thu Oct  2 12:45:50 1997
From: harryl at us.ibm.com (Harry Lewis)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Final chance for October reservations
Message-ID: <9708238750.AA875039679@erc.epson.com>

Reminder... tomorrow (Friday 10/3) is the last day the Hotel Boulderado=
 will
accept reservations for the PWG meeting at the preferred IBM rate. Plea=
se make
your reservations now, if you haven't yet, and please Ping me also, if =
you
haven't yet done so.


Harry Lewis - IBM Printing Systems
=

From PJohansson at aol.com  Mon Oct  6 18:08:35 1997
From: PJohansson at aol.com (PJohansson@aol.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> SBP-2 Bidirectional ORB
Message-ID: <9708238750.AA875039679@erc.epson.com>

Document 97-244r0.pdf, available from
ftp://ftp.symbios.com/pub/standards/io/t10/document.97, proposes an
additional ORB format for SBP-2 devices.


SBP-2 requests are well suited to devices for which, on a command by command
basis, the principal data flow is either to or from the target. Disk READ and
WRITE commands are the most obvious example.


This model is less suitable for devices that may have substantial amounts of
data to be exchanged, in both directions, as the result of a single command.
Examples include printers, FAX and scanners.


The proposal would add a new ORB type more appropriate for this type of
device.


In addition to the discussion scheduled for the October 7, 1997, SBP-2
meeting in Irvine, CA, comments are solicited from any interested party.


Peter Johansson


Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602


(510) 531-5472
(510) 531-2942 FAX


pjohansson@aol.com

From ewa at apple.com  Mon Oct  6 21:02:38 1997
From: ewa at apple.com (Eric W. Anderson)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Re: SBP-2 Bidirectional ORB
In-Reply-To: <SBP-2 Bidirectional ORB>
Message-ID: <B05ED841-DA96E@17.216.20.62>

I saw this posted to several lists, so I will attempt to collect
all of the replies here.


My own comments are twofold:


1. I agree with David's observation that two ORBs (one read, one
   write) can be used instead of a bidirectional ORB.  A device
   is free to fetch both ORBs and execute them in whatever order
   it likes, including simultaneously.  A device or device class
   can mandate that such ORB pairs be provided, even though SBP-2
   does not require it.


2. I agree with John that the bidirectional ORB will be difficult
   to deal with in software.  Even though the SBP-2 layer is thin,
   there are complex virtual memory issues, and having a special
   ORB with two payloads will complicate that.


I am not *opposed* to bidirectional ORBs, I just think they are not
the best solution.  I think SBP-2 can be used as-is to solve the
problem at hand.  I think that using two ORBs is simpler and leads
to less complicated consequences.  However, I'd be interested to
hear from Peter why the single bidirectional ORB might be preferable.
If there's an advantage I've overlooked, I'd certainly reconsider.


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------


>In a message dated 97-10-06 17:55:15 EDT, jfuller@MICROSOFT.com writes:
>
><<I think that there are way too many differences between this and the
>unidirectional ORB.  They will make it impossible to write one SBP-2
driver
>that can handle both unidirectional and bi-directional devices.>>
>
>From what I understand in conversation with you, John, is that SBP-2 is
>*so* lightweight that no stand-alone SBP-2 driver is anticipated in your
>operating systems---only very thin SBP-2 layers at the bottom edges of
>device class drivers.
>
>The format I proposed is not the last word but a starting point. There was
>some reason to the choices, for example, a larger data_length field to
>handle unpaged transfers greater than 64 Kb. If you've got improvements
>to suggest I'm open to them.
>
>Peter Johansson


>David Wooten Writes:
>The idea is that the target knows that these things can come in pairs 
>and doesn't reorder dependent things.
>
>David
>
>-----Original Message-----
>From:	PJohansson@aol.com [SMTP:PJohansson@aol.com]
>Sent:	Monday, October 06, 1997 4:16 PM
>To:	Multiple recipients of list 1394-architecture
>Subject:	Re: SBP-2 Bidirectional ORB
>
>In a message dated 97-10-06 14:53:37 EDT, David.Wooten@COMPAQ.com 
>writes:

From PJohansson at aol.com  Mon Oct  6 23:46:17 1997
From: PJohansson at aol.com (PJohansson@aol.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Re: SBP-2 Bidirectional ORB
In-Reply-To: <SBP-2 Bidirectional ORB>
Message-ID: <B05ED841-DA96E@17.216.20.62>

In a message dated 97-10-06 22:13:42 EDT, ewa@apple.com writes:


<<1. I agree with David's observation that two ORBs (one read, one write) can
be used instead of a bidirectional ORB.  A device is free to fetch both ORBs
and execute them in whatever order it likes, including simultaneously.  A
device or device class can mandate that such ORB pairs be provided, even
though SBP-2 does not require it.>>


It seems to me that the use of unidirectional ORB's is essentially a
hold-over from SCSI habits of DATA IN or DATA OUT on a single command. It's
not surprising that SBP-2, thus far, addresses this model well---but perhaps
we should move forward.


Two coordinated ORBs is little more than a 64-byte bidirectional ORB that
takes two Serial Bus transactions to fetch! Given the lack of scalability for
arbitration times at faster and faster speeds ('specially for small packets)
I think we ought to avoid the unnecessary fetch.


<<2. I agree with John that the bidirectional ORB will be difficult to deal
with in software.  Even though the SBP-2 layer is thin, there are complex
virtual memory issues, and having a special ORB with two payloads will
complicate that.>>


This is not some Pandora's box that is being opened, with n-directional ORBs
in our future. "Complex virtual memory issues?" Are you suggesting that
operating systems today have *no* API's in which more than one user buffer is
presented and must be locked down? I think the bidirectional ORB is
*different* to deal with in software and not all that difficult. The problems
of coordinating two-in-one ORBs (the paired ORBs David mentions) may be more
difficult than those of dealing with two buffers.


Peter Johansson

From lstein at fapo.com  Thu Oct 16 19:08:38 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Meeting Notice: January Joint PWG/PWG-C Meeting
Message-ID: <3.0.32.19971016160826.00824e10@pop3.fapo.com>

Hello all,


Sorry for the duplicate lists.  This is an advance meeting notice and
request for the January 1998 PWG/PWG-C meeting in Hawaii.  The hotel in
Hawaii is not quite as flexible as one in Witchita, so I need to get some
quick expectation as to how many people will be attending which meetings.


Place:  	Maui Marriott on Kaanapali Beach
When: 	Week of January 26-30, 1998
Schedule:	1/26-27 	Joint 1394PWG/PWG-C meeting
		1/28	PWG
		1/29	TBD
		1/30	TBD


Room rate:	$179 double, $25 per person to four people	
		plus meeting charge TBD


I have rooms set aside from Friday, 1/23 through Sunday, 2/1.  In order to
make this a smooth meeting setup I need to get a good idea of who is coming
when, for how long and if there will be others coming.  The facility has
day programs for kids.


We are going to try to plan something for Tuesday night.  Please let me
know if you want to attend (whatever it may be?).


I realize that this is quite advance notice but please provide me with the
following information as soon as possible:


Name:
Date arrival:
Date checkout:
What meetings:
# Adults:
# Kids:
Tuesday night:	y/n


Thanks,
Larry
***************************************************************
Larry A. Stein			Phone: 	(619)292-2742
Warp Nine Engineering		Fax:	(619)292-8020
				Web: 	http://www.fapo.com
***************************************************************

From brianb at vcd.hp.com  Fri Oct 17 19:36:51 1997
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:45 2009
Subject: P1394> 1394PWG Thick Transport Stack Requirements
Message-ID: <3.0.2.32.19971017163651.0088cbc0@popmail1.vcd.hp.com>

1394PWG - Client Requirements for Our Thick Transport Stack 
-----------------------------------------------------------
The following is a list of requirements the client places on the thick
transport stack.  The requirements are split into two sections: musts and
wants.  They are intentionally brief, with definitions of terms following
each requirement.  


Musts
-----
* Support multiple, concurrent, independent, symmetrical connections
     Multiple, concurrent - Allows for more than one connection at a time.
     Independent - Activity on one connection has no effect on other
                   connections.
     Symmetrical - Either endpoint can open and close the connection, and 
                   send data.
     Connection - well-bounded communication path between two endpoints.
                  The endpoints can be on the same device or on different 
                  devices.
* Provide in-order, byte-stream and in-order, buffer (datagram?) services
     In-order - Data is delivered to the receiving endpoint in the same
                order as it was presented by the sending endpoint.
     Byte-stream - Data is delivered as a stream of bytes.  The stream of
                   bytes is not guaranteed to be delivered to the 
                   receiving endpoint in the same form as it was 
                   presented by the sending endpoint.  For example, a 
                   stream of 80 bytes of data may be presented as 4-20 
                   byte buffers, but delivered as 2-40 byte buffers.
     Buffer (datagram?) - Data is guaranteed to be delivered to the
                          receiving endpoint in the same form as it was
                          presented by the sending endpoint.
                          For example, if data is presented in a buffer of
                          30 bytes, it must be delivered in a buffer of 30 
                          bytes.  The transport stack may limit the size of 
                          buffers.  It does not have to support segmentation 
                          and reassembly.
* Provide a directory service
     Endpoints on a specific device may be referenced by their service name.
     This allows connections to be opened without any knowledge of the 
     underlying layer's implementation of sockets, etc.
* Transparently handle transient link interruptions
     The transport stack shall handle transient link interruptions without
     affecting the endpoints.  These link interruptions include: temporary 
     cable disconnect, 1394 bus reset, etc.  Do we want to provide a service 
     to optionally notify clients when there is a link interruption?
* Reliability
     What level of reliability is required by the clients?


Wants
-----
* Connectionless service
     A non-bounded communication path between two endpoints.  Data may be 
     sent without "opening" a connection.
* Multi-casting
     Simultaneously sending data from one endpoint to multiple endpoints.  
     Does this need to be bidirectional?  Does it need to be reliable?
* Data tagging
     Data can be tagged as "special data" by the sending endpoint.  The 
     transport will indicate to the receiving endpoint that the data is
     tagged.  This is also known as out-of-band data.
* Provide endpoints with fair access to other endpoints
     The transport will prevent endpoints from monopolizing the link and 
     preventing other endpoints from access.
* Selectable quality of service
     The ability to adjust various quality of service parameters, including:
         Isochronous delivery
         Priority
         Propagation Delay
         Rate of transfer (bandwidth)




Internal Thick Transport Stack Requirements
-------------------------------------------
The following are the requirements the transport stack places on itself.


Musts
-----
* Be data, application and O/S independent
     The transport stack shall not put any requirements on the format of 
     the data, nor shall it interpret the data in any way.  The transport
     stack shall work with any application that correctly uses the 
     appropriate interfaces.  The transport shall be implementable under
     any operating system.
* Do not preclude concurrent operation of other protocol stacks
     Devices may implement and use other protocol stacks concurrently with
     this transport stack.  
* Provide efficient data transmission
     Prevent unnecessary bus traffic (e.g. retransmissions) by not 
     transferring data until that data can be handled by the receiving 
     device.  Balance bus traffic with protocol overhead.


Wants
-----
* Bus-independent transport layer
     The transport layer may be used on other busses.
* Reuse existing protocols
     Save time by reusing existing protocols, rather than inventing new ones.


Brian Batchelder
Greg Shue


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227

From don at lexmark.com  Mon Oct 20 16:12:15 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Boulder PWG Schedule / LA Meeting Details
Message-ID: <199710202012.AA00130@interlock2.lexmark.com>

Unfortunately, I will not be in attendance at the October PWG meetings in
Boulder.
(First one I have ever missed -- there goes my record.)  Below is the
schedule for
the meetings.  Please read this very close as there are a couple of new
things
and some new starting times.




October 27, 1997
     8:30 - 5:30          1394 Printing - Greg LeClair


October 28, 1997
     8:30 - 5:30          1394 Printing - Greg LeClair


October 29, 1997
     8:00 - 8:30          Printer MIB Update - Lloyd Young
     8:30 - 5:30          IPP - Carl-Uno Manros


October 30, 1997
     8:30 - 12:00         IPP - Carl-Uno Manros
     1:00 - 6:00          Sense - JK Martin


October 31, 1997
     8:30 - 12:00         Finisher MIB - Harry Lewis
     1:00 - 5:30          Job MIB - Ron Bergman




If appropriate, more detailed agendas for each working group will be
posted to the appropriate mailing list by the designated chairman.


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


The details on the LA Meeting are as follows:


Crown Plaza Hotel
Los Angeles Airport
5985 W. Century Blvd.
Los Angeles, CA  90045
PH: 310-642-7500
FAX: 310-216-6646
Room rate: $79.00 per night
Parking:   $6.00 per day
Meeting room etc. about $30.00 - 35.00 per person per day
The registration is in the name of:      Xerox
Deadline for the special room rate:      November 7, 1997
This is at the airport, so you do not really need a car.
The hotel has shuttles from the airport.


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


Enjoy!


Don Wright
PWG Chair


**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

From harryl at us.ibm.com  Wed Oct 22 21:14:20 1997
From: harryl at us.ibm.com (Harry Lewis)
Date: Wed May  6 14:00:45 2009
Subject: P1394> October PING list
Message-ID: <199710202012.AA00130@interlock2.lexmark.com>

Here's what I've got for a PING list. Please send any corrections ASAP.=




My estimates were based on the larger attendance we had in the past. Sp=
reading
fixed costs (like the room, AV etc) across a smaller group, the meeting=
 cost
has ended up at $42 per day. The hotel is not collecting fees, I am hav=
ing to
do this, myself. Please be prepared, with a company or personal check m=
ade out
to Harry Lewis for $42 for each day that you attend. I will provide a r=
eceipt.




P1394 (Monday/Tuesday)
-----
Brian Batchelder - HP
Alan Berkema - HP
Dan Bye - SGS-Thomson (Monday)
Dave Doman - Motorola
Lee Farrell - Canon
Osamu Hirata - Canon
Greg LeClair - Epson
Kerry Lee
Harry Lewis - IBM
Fumio Nagasaka - Epson
Akihiro Shimura - Canon
Greg Shue - HP
Jerry Thrasher - Lexmark
Atsushi Uchino - Seiko-Epson




IPP (Wednesday/Thursday)

---
Lee Farrell - Canon
Steve Gebert - IBM
Tom Hastings - Xerox
Scott Isaacson - Novell
David Kellerman - Northlake Software
Carl Kugler - IBM
Kerry Lee
Harry Lewis - IBM
Carl-Uno Manros - Xerox
Jay Martin - Underscore
Bob Pentecost - HP
Jerry Podojil - Genicom (Thursday)
Stuart Rowley - Kyocera
Roberto Sannino - SGS-Thomson (Thursday)
Yuji Sasaki - Japan Computer Industry
Atsushi Uchino - Seiko-Epson
Dale Wick - TrueSpectra
Lloyd Young - Lexmark
Peter Zehler - Xerox




JMP/FIN (Friday)
-------
Carlos Cantu - IBM
Dennis Carney - IBM
Lee Farrell - Canon
Tom Hastings - Xerox
David Kellerman - Northlake Software
Harry Lewis - IBM
Jay Martin - Underscore
Kathy Melton - IBM
Lisa Morgan - IBM
Bob Pentecost - HP
Jerry Podojil - Genicom
Stuart Rowley - Kyocera
Roberto Sannino - SGS-Thomson
Lloyd Young - Lexmark






Harry Lewis
=


From ueda at tansu.slab.tnr.sharp.co.jp  Fri Oct 24 08:54:11 1997
From: ueda at tansu.slab.tnr.sharp.co.jp (Toru Ueda)
Date: Wed May  6 14:00:45 2009
Subject: P1394> 1394PWG Thick Transport Stack Requirements
In-Reply-To: <3.0.2.32.19971017163651.0088cbc0@popmail1.vcd.hp.com>
Message-ID: <9710241254.AA15635@tansu.slab.tnr.sharp.co.jp>

Brian,


Thank you for forwarding your client requirements for thick
transport stack document.


I have one question about thick "MUST".


I don't understand how to use buffer service.
Why must thick transport have buffer service ?


My understanding is the transport will handle the
differences of physical buffer sizes of sending and
receiving endpoints.


I assume that the indication of receiving the 30bytes packet
to upper layer will issue when 30bytes data receives whether
this packet is divided into 2-15 bytes or 3-10 bytes data if 
the transport packet size is 30 bytes.


But buffer service allows to send only fixed(30bytes in this 
case) data. 


Does this help to write application ?
I misunderstand buffer service ?




  >>* Provide in-order, byte-stream and in-order, buffer (datagram?) services


  >>     Buffer (datagram?) - Data is guaranteed to be delivered to the
  >>                          receiving endpoint in the same form as it was
  >>                          presented by the sending endpoint.
  >>                          For example, if data is presented in a buffer of
  >>                          30 bytes, it must be delivered in a buffer of 30 
  >>                          bytes.  The transport stack may limit the size of 
  >>                          buffers.  It does not have to support segmentation 
  >>                          and reassembly.




  >>To: 1394 PWG <p1394@pwg.org>, PWG-C <pp1394@cpdc.canon.co.jp>
  >>From: Brian Batchelder <brianb@vcd.hp.com>
  >>Subject: P1394> 1394PWG Thick Transport Stack Requirements
  >>Mime-Version: 1.0
  >>Content-Type: text/plain; charset="us-ascii"
  >>Sender: p1394-owner@pwg.org
  >>
  >>1394PWG - Client Requirements for Our Thick Transport Stack 
  >>-----------------------------------------------------------
  >>The following is a list of requirements the client places on the thick
  >>transport stack.  The requirements are split into two sections: musts and
  >>wants.  They are intentionally brief, with definitions of terms following
  >>each requirement.  
  >>
  >>Musts
  >>-----
  >>* Support multiple, concurrent, independent, symmetrical connections
  >>     Multiple, concurrent - Allows for more than one connection at a time.
  >>     Independent - Activity on one connection has no effect on other
  >>                   connections.
  >>     Symmetrical - Either endpoint can open and close the connection, and 
  >>                   send data.
  >>     Connection - well-bounded communication path between two endpoints.
  >>                  The endpoints can be on the same device or on different 
  >>                  devices.
  >>* Provide in-order, byte-stream and in-order, buffer (datagram?) services
  >>     In-order - Data is delivered to the receiving endpoint in the same
  >>                order as it was presented by the sending endpoint.
  >>     Byte-stream - Data is delivered as a stream of bytes.  The stream of
  >>                   bytes is not guaranteed to be delivered to the 
  >>                   receiving endpoint in the same form as it was 
  >>                   presented by the sending endpoint.  For example, a 
  >>                   stream of 80 bytes of data may be presented as 4-20 
  >>                   byte buffers, but delivered as 2-40 byte buffers.
  >>     Buffer (datagram?) - Data is guaranteed to be delivered to the
  >>                          receiving endpoint in the same form as it was
  >>                          presented by the sending endpoint.
  >>                          For example, if data is presented in a buffer of
  >>                          30 bytes, it must be delivered in a buffer of 30 
  >>                          bytes.  The transport stack may limit the size of 
  >>                          buffers.  It does not have to support segmentation 
  >>                          and reassembly.
  >>* Provide a directory service
  >>     Endpoints on a specific device may be referenced by their service name.
  >>     This allows connections to be opened without any knowledge of the 
  >>     underlying layer's implementation of sockets, etc.
  >>* Transparently handle transient link interruptions
  >>     The transport stack shall handle transient link interruptions without
  >>     affecting the endpoints.  These link interruptions include: temporary 
  >>     cable disconnect, 1394 bus reset, etc.  Do we want to provide a service 
  >>     to optionally notify clients when there is a link interruption?
  >>* Reliability
  >>     What level of reliability is required by the clients?
  >>
  >>Wants
  >>-----
  >>* Connectionless service
  >>     A non-bounded communication path between two endpoints.  Data may be 
  >>     sent without "opening" a connection.
  >>* Multi-casting
  >>     Simultaneously sending data from one endpoint to multiple endpoints.  
  >>     Does this need to be bidirectional?  Does it need to be reliable?
  >>* Data tagging
  >>     Data can be tagged as "special data" by the sending endpoint.  The 
  >>     transport will indicate to the receiving endpoint that the data is
  >>     tagged.  This is also known as out-of-band data.
  >>* Provide endpoints with fair access to other endpoints
  >>     The transport will prevent endpoints from monopolizing the link and 
  >>     preventing other endpoints from access.
  >>* Selectable quality of service
  >>     The ability to adjust various quality of service parameters, including:
  >>         Isochronous delivery
  >>         Priority
  >>         Propagation Delay
  >>         Rate of transfer (bandwidth)
  >>
  >>
  >>Internal Thick Transport Stack Requirements
  >>-------------------------------------------
  >>The following are the requirements the transport stack places on itself.
  >>
  >>Musts
  >>-----
  >>* Be data, application and O/S independent
  >>     The transport stack shall not put any requirements on the format of 
  >>     the data, nor shall it interpret the data in any way.  The transport
  >>     stack shall work with any application that correctly uses the 
  >>     appropriate interfaces.  The transport shall be implementable under
  >>     any operating system.
  >>* Do not preclude concurrent operation of other protocol stacks
  >>     Devices may implement and use other protocol stacks concurrently with
  >>     this transport stack.  
  >>* Provide efficient data transmission
  >>     Prevent unnecessary bus traffic (e.g. retransmissions) by not 
  >>     transferring data until that data can be handled by the receiving 
  >>     device.  Balance bus traffic with protocol overhead.
  >>
  >>Wants
  >>-----
  >>* Bus-independent transport layer
  >>     The transport layer may be used on other busses.
  >>* Reuse existing protocols
  >>     Save time by reusing existing protocols, rather than inventing new ones.
  >>
  >>Brian Batchelder
  >>Greg Shue
  >>
  >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  >>Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
  >>Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
  >>DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227
  >>


Toru Ueda
Sharp Corp
Software labs.

From brianb at vcd.hp.com  Fri Oct 24 15:48:52 1997
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:45 2009
Subject: P1394> 1394PWG Thick Transport Stack Requirements
In-Reply-To: <9710241254.AA15635@tansu.slab.tnr.sharp.co.jp>
Message-ID: <3.0.3.32.19971024124852.008f0ba0@popmail1.vcd.hp.com>

At 09:54 PM 10/24/97 +0900, Toru Ueda wrote:
>
>Brian,
>
>Thank you for forwarding your client requirements for thick
>transport stack document.
>
>I have one question about thick "MUST".
>
>I don't understand how to use buffer service.
>Why must thick transport have buffer service ?


The buffer service is used by clients who need to have data delivered with
well-defined starting and ending points.  For example, this data might be a
message that needs to be delivered whole.  If a byte stream service is
used, the message might be broken into multiple buffers, or if might have
other data appended to it.   This might make the message impossible to
interpret by the receiving service.


>My understanding is the transport will handle the
>differences of physical buffer sizes of sending and
>receiving endpoints.


Yes, the transport must handle varying buffer sizes in each direction.  For
the byte stream service it must be able to break up a large request buffer
into multiple send buffers.  For the buffer service it must either be able
to somehow ommunicate to the client the largest buffer that can be sent or
provide buffer segmentation and reassembly services.  Maybe this should be
added to the requirements?


>I assume that the indication of receiving the 30bytes packet
>to upper layer will issue when 30bytes data receives whether
>this packet is divided into 2-15 bytes or 3-10 bytes data if 
>the transport packet size is 30 bytes.


I think the requirement is that the 30 bytes be delivered as a buffer if
the transmitted buffer is 30 bytes and there is some indication that it
should be delivered as a single, whole buffer.  I don't think it is a
requirement that the smaller packets be reassembled into one larger buffer
(in other words, that a reassembly service be provided).


>But buffer service allows to send only fixed(30bytes in this 
>case) data. 


The buffer service would allow UP TO 30 bytes of data to be delivered as a
single, whole buffer.  A buffer of less than 30 bytes could also be
transmitted.


>Does this help to write application ?


It does help some applications that want to send messages without those
messages  inherently providing some way to be extracted from a byte stream.


>I misunderstand buffer service ?


I think that the requirements document is not complete.  For now, we
probably have many interpretations of the requirements.  Our challenge is
to refine the requirements list until we all agree on them.


Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227

From gregory_leclair_at_ercipd at erc.epson.com  Fri Oct 24 22:51:00 1997
From: gregory_leclair_at_ercipd at erc.epson.com (gregory_leclair_at_ercipd@erc.epson.com)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Denver Meeting Agenda
Message-ID: <9710248777.AA877744403@erc.epson.com>

     Following is Draft Agenda for 1394 PWG Meeting on 
     Mon./Tues. in Boulder. 
     
     1394 Administrivia
        1394 TA Review
        1284.x Mtg. Review
        LA Meeting - Dec.
        HI Meeting - Jan.
     1394 PWG Printer Protocol Requirements 
        Requirements
        Proposal Review
        Discussion
        IEEE xxxx Working Group effort
        Action Items
     1394 PWG Printer Installation Requirements
        Review of FDS / SDD / IEEE-1212 WG
        Requirements
        Proposal Review
        Discussion
        IEEE 1212 Working Group effort
        Action Items
     
     
     Please advise if you have materials 
     you would like to present.
     
     Regards,
     
     Greg LeClair
     greg@erc.epson.com
     
     

From atsnaka at mxa.meshnet.or.jp  Sat Oct 25 12:07:06 1997
From: atsnaka at mxa.meshnet.or.jp (Atsushi Nakamura)
Date: Wed May  6 14:00:45 2009
Subject: P1394> Function Discovery FDS
Message-ID: <199710251608.BAA25321@meshsv02.tk.mesh.ad.jp>

P1394 members,


I am sorry I will not be making the Denver meeting.


I have attended the October 1394TA meeting in 
Phoenix (This is why I can't attend ; our travel budget
doesn't allow 2 internationall trips in 1 month. )
I think FDS was well presented to address
the topic of Function Discovery, along with SDD.
As the result of discussions with the Sony people,
the SDD proposal was presented in a way that it will use 
FDS for it's function discovery portion. 


It was decided that the 1212 work will start off with
a meeting in November, and function discovery
will be discussed there.
Even though I have recieved some opinions on
FDS version 0.6 already at the TA,
the November 1212 meeting will be the first meeting 
outside PWG/PWG-C that this will really be 
discussed in detail.


I suggest FDS06 should be kept as it is until the 
November 1212 meeting,


Of course, I feel some changes seem apparent,
deletion of CONFIG_CHANGE_IDENTIFIER and
P_LENGTH to be specific, but  I feel the rest
should be OK as is for now.
Since both the PWG and PWG-C has voted in favor 
for FDS0.6(0.5), so we should be confident to stick
with the current content, and not be in 
too much of a hurry to make unnecessary
changes, affected by opinions of few individuals.
I think the direction on where we should (or should not)
make changes will become clear only after the
November meeting (which I hope to attend).


Also,
In case we do decide to make changes,
it will have to be approved by both PWG and PWG-C.


Regards,
Ats


P.S. : 
What we Do need to do , is to come up with a function
class list proposal.




***********************************
Atsushi Nakamura
Canon Inc.
atsnaka@bsd.canon.co.jp
atsnaka@mxa.meshnet.or.jp
***********************************

From atsnaka at bsd.canon.co.jp  Sat Oct 25 23:28:03 1997
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Function Discovery FDS part 2
Message-ID: <199710260328.MAA22341@bsdmail.bsd.canon.co.jp>

--=====================_877898032==_
Content-Type: text/plain; charset="ISO-2022-JP"




Attached is a diagram I drew up of (an example)
how the current SDD and FDS can fit in the 
1212 configuration ROM.
Please refer to it in the discussions.
(I have left out CONFIG_CHANGE IDENTIFIER and P_LENGTH)


We (PWG/PWG-C) will have to assume there will be other
ideas and opinions on function discovery once this
issue goes up to 1212 work(outside PWG/PWG-C),
and FDS+SDD may not be the ONLY proposal on function
discovery,
but I think that this diagram generally shows what 
PWG/PWG-C (+ SONY?) would like to have as a function
discovery solution.






 
 
 


--=====================_877898032==_
Content-Type: application/pdf; name="fdssdd.PDF"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="fdssdd.PDF"


[encoded data, 19404 characters]
YmNhOTg+XQ0KPj4NCnN0YXJ0eHJlZg0KMTM5MzYNCiUlRU9GDQo=
--=====================_877898032==_
Content-Type: text/plain; charset="ISO-2022-JP"




-----------------------------------------
Atsushi Nakamura
-----------------------------------------
**************!! NOTICE !!*****************
*TEL,FAX,and EMAIL(2) has changed         * 
*from Sept.8,1997                         *
*******************************************


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):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------
--=====================_877898032==_--

From don at lexmark.com  Sun Oct 26 08:50:26 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Denver weather - yuck!!
Message-ID: <199710261351.AA24550@interlock2.lexmark.com>

4 feet of snow!!!!!!


Considering how much I hate snow, I couldn't have picked a better
meeting to miss.


Its sunny and mid 50's here in Paris.  Ah, the Marriott on the
Champs-Elysees is really excellent.


See you all in LA! (No snow, OK Carl-uno!!)


Don


**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

From brianb at vcd.hp.com  Sun Oct 26 15:55:29 1997
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Boulder Meeting
Message-ID: <3.0.3.32.19971026125529.008d6d80@popmail1.vcd.hp.com>

Due to the the bad weather in Colorado and a lingering cold/flu, I've
decided to skip this week's meeting.  If the rest of you manage to make it,
and you need to get in touch with me for some reason, all of the regular
phone numbers will apply.


Brian


BTW - All flights from Portland to Denver are cancelled through at least
Sunday night.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227

From shimura at pure.cpdc.canon.co.jp  Sun Oct 26 20:10:14 1997
From: shimura at pure.cpdc.canon.co.jp (Akihiro Shimura)
Date: Wed May  6 14:00:46 2009
Subject: P1394> October PING list
In-Reply-To: <5030300012781291000002L012*@MHS>
Message-ID: <199710270110.KAA14170@slant1.pure.cpdc.canon.co.jp>

Hello,


Will the pwg meeting at Boulder be held as scheduled?


Anyway, I've decided not to attend the p1394 meeting at Boulder
because today's flight to Denver was canceled due to the snow.



--
 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3
 CANON INC.


From harryl at us.ibm.com  Sun Oct 26 22:31:45 1997
From: harryl at us.ibm.com (Harry Lewis)
Date: Wed May  6 14:00:46 2009
Subject: P1394> FIN> Boulder Weather
Message-ID: <3.0.3.32.19971026193145.008d5480@popmail1.vcd.hp.com>

I've had a few questions about the weather. Anyone trying to arrive Saturday
probably had quite a difficult time. Two feet of snow fell in most parts.
Today
(Sunday) is warm and sunny. Roads are clear. Forecast is high's in the 50's,
lows in the 20's all week. Should be a great week!


Harry Lewis - IBM Printing Systems

From gregoryl at spider.epson.com  Mon Oct 27 09:26:43 1997
From: gregoryl at spider.epson.com (Gregory LeClair)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Will you be in Denver?
Message-ID: <01BCE2A4.04EA2920@DHCP053.erc.epson.com>

Hi folks,


Yes there was monster snow this weekend. After a few hours of delays, we were finally able to make it in to Denver about midnight.


I already saw a note from Brian and Shimura-san that they wouldn't make it. If anyone else will not be in Denver, please advise.


Thanks,
Greg LeClair
greg@erc.epson.com

From gregs at sdd.hp.com  Mon Oct 27 11:57:42 1997
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Will you be in Denver?
In-Reply-To: <01BCE2A4.04EA2920@DHCP053.erc.epson.com>
Message-ID: <199710271657.IAA14786@hpsdlgj1.sdd.hp.com>

The weather at Denver stunk on Sunday also.  Earliest
non-cancelled flight out of San Diego was thought to be 3:30 (@
10 a.m.).  If the weather is so bad as to probably not land in
Denver, then I'll never be able to drive up to Boulder.  I'm out
for this trip.


> 
> Hi folks,
> 
> Yes there was monster snow this weekend. After a few hours of delays, we were finally able to make it in to Denver about midnight.
> 
> I already saw a note from Brian and Shimura-san that they wouldn't make it. If anyone else will not be in Denver, please advise.
> 
> Thanks,
> Greg LeClair
> greg@erc.epson.com
> 





-- 
Greg Shue
Hewlett-Packard Company
Office Products Division			gregs@sdd.hp.com
----------------------------------------------------------------


From Ozay_Oktay at cissc.canon.com  Mon Oct 27 13:40:38 1997
From: Ozay_Oktay at cissc.canon.com (Oktay, Ozay)
Date: Wed May  6 14:00:46 2009
Subject: P1394> FIN> Boulder Weather
Message-ID: <199710271657.IAA14786@hpsdlgj1.sdd.hp.com>

Why schedule a meeting at a cold place in Fall and Winter when there is
Ft.Lauderdale, Orlando, New Orleans, Irvine, San Diego ?????


Best Regards
ozay oktay


> ----------
> From: 	Harry Lewis[SMTP:harryl@us.ibm.com]
> Sent: 	Sunday, October 26, 1997 7:31 PM
> To: 	p1394@pwg.org
> Subject: 	P1394> FIN> Boulder Weather
> 
> I've had a few questions about the weather. Anyone trying to arrive
> Saturday
> probably had quite a difficult time. Two feet of snow fell in most
> parts.
> Today
> (Sunday) is warm and sunny. Roads are clear. Forecast is high's in the
> 50's,
> lows in the 20's all week. Should be a great week!
> 
> Harry Lewis - IBM Printing Systems
> 
> 

From ueda at tansu.slab.tnr.sharp.co.jp  Wed Oct 29 07:16:08 1997
From: ueda at tansu.slab.tnr.sharp.co.jp (Toru Ueda)
Date: Wed May  6 14:00:46 2009
Subject: P1394> 1394PWG Thick Transport Stack Requirements
In-Reply-To: <3.0.3.32.19971024124852.008f0ba0@popmail1.vcd.hp.com>
Message-ID: <9710291216.AA02303@tansu.slab.tnr.sharp.co.jp>

Hi Brian,


I understand the meaning of buffer service. 


If the buffer service provides segmentaion and reassembly,
it may be more useful.
(This might sucrifice the simplicity of buffer service.)


Because IEEE1394 has maximum packet size(512 bytes for S100), 
segmentaion and reassembly service may be required if buffer
service treats more than 512 bytes.


Toru Ueda
Software Labs.
Sharp Corporation




  >>At 09:54 PM 10/24/97 +0900, Toru Ueda wrote:
  >>--
  >>--Brian,
  >>--
  >>--Thank you for forwarding your client requirements for thick
  >>--transport stack document.
  >>--
  >>--I have one question about thick "MUST".
  >>--
  >>--I don't understand how to use buffer service.
  >>--Why must thick transport have buffer service ?
  >>
  >>The buffer service is used by clients who need to have data delivered with
  >>well-defined starting and ending points.  For example, this data might be a
  >>message that needs to be delivered whole.  If a byte stream service is
  >>used, the message might be broken into multiple buffers, or if might have
  >>other data appended to it.   This might make the message impossible to
  >>interpret by the receiving service.
  >>--My understanding is the transport will handle the
  >>--differences of physical buffer sizes of sending and
  >>--receiving endpoints.
  >>
  >>Yes, the transport must handle varying buffer sizes in each direction.  For
  >>the byte stream service it must be able to break up a large request buffer
  >>into multiple send buffers.  For the buffer service it must either be able
  >>to somehow ommunicate to the client the largest buffer that can be sent or
  >>provide buffer segmentation and reassembly services.  Maybe this should be
  >>added to the requirements?
  >>--I assume that the indication of receiving the 30bytes packet
  >>--to upper layer will issue when 30bytes data receives whether
  >>--this packet is divided into 2-15 bytes or 3-10 bytes data if 
  >>--the transport packet size is 30 bytes.
  >>
  >>I think the requirement is that the 30 bytes be delivered as a buffer if
  >>the transmitted buffer is 30 bytes and there is some indication that it
  >>should be delivered as a single, whole buffer.  I don't think it is a
  >>requirement that the smaller packets be reassembled into one larger buffer
  >>(in other words, that a reassembly service be provided).
  >>
  >>--But buffer service allows to send only fixed(30bytes in this 
  >>--case) data. 
  >>
  >>The buffer service would allow UP TO 30 bytes of data to be delivered as a
  >>single, whole buffer.  A buffer of less than 30 bytes could also be
  >>transmitted.
  >>
  >>--Does this help to write application ?
  >>
  >>It does help some applications that want to send messages without those
  >>messages  inherently providing some way to be extracted from a byte stream.
  >>
  >>--I misunderstand buffer service ?
  >>
  >>I think that the requirements document is not complete.  For now, we
  >>probably have many interpretations of the requirements.  Our challenge is
  >>to refine the requirements list until we all agree on them.
  >>
  >>Brian
  >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  >>Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
  >>Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
  >>DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227
  >>

From lstein at fapo.com  Thu Oct 30 13:59:33 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Meeting Notice: January Joint PWG/PWG-C Meeting
Message-ID: <3.0.32.19971030105923.00860ac0@pop3.fapo.com>

Hello all,


I have not received many RSVPs for this meeting yet.  I know it's early
notice but I really need a good idea on the room reservations.  Please let
me know if you even think you will be attending.


Thanks,
Larry


**********
Original message:


Sorry for the duplicate lists.  This is an advance meeting notice and
request for the January 1998 PWG/PWG-C meeting in Hawaii.  The hotel in
Hawaii is not quite as flexible as one in Witchita, so I need to get some
quick expectation as to how many people will be attending which meetings.


Place:  	Maui Marriott on Kaanapali Beach
When: 	Week of January 26-30, 1998
Schedule:	1/26-27 	Joint 1394PWG/PWG-C meeting
		1/28	PWG
		1/29	TBD
		1/30	TBD


Room rate:	$179 double, $25 per person to four people	
		plus meeting charge TBD


I have rooms set aside from Friday, 1/23 through Sunday, 2/1.  In order to
make this a smooth meeting setup I need to get a good idea of who is coming
when, for how long and if there will be others coming.  The facility has
day programs for kids.


We are going to try to plan something for Tuesday night.  Please let me
know if you want to attend (whatever it may be?).


I realize that this is quite advance notice but please provide me with the
following information as soon as possible:


Name:
Date arrival:
Date checkout:
What meetings:
# Adults:
# Kids:
Tuesday night:	y/n


Thanks,
Larry
***************************************************************
Larry A. Stein			Phone: 	(619)292-2742
Warp Nine Engineering		Fax:	(619)292-8020
				Web: 	http://www.fapo.com
***************************************************************

From cmanros at cp10.es.xerox.com  Fri Oct 31 18:12:02 1997
From: cmanros at cp10.es.xerox.com (Carl-Uno Manros)
Date: Wed May  6 14:00:46 2009
Subject: P1394> PING for Los Angeles Meeting December 1-5
Message-ID: <3.0.1.32.19971031151202.00b8cc60@garfield>

Hi,


As host for the LA Meeting on December 1 - 5, 1997 I would like to know if
you are planning to attend. Please make your own booking with the hotel,
the deadline is:


	 November 7th 


It is a very favorable rate for this class of hotel, so you do not want to
miss the deadline.


But please also send me a mail note with the following information:


1) The dates that you will stay at the Crown Plaza Hotel
2) The dates that you plan to attend meetings 


The details on the LA Meeting are as follows:


Crown Plaza Hotel
Los Angeles Airport
5985 W. Century Blvd.
Los Angeles, CA  90045
PH: 310-642-7500
FAX: 310-216-6646
Room rate: $79.00 per night
Parking:   $6.00 per day
Meeting room etc. about $30.00 - 35.00 per person per day


The registration is in the name of:      Xerox
Deadline for the special room rate:      November 7, 1997
Hotel contact:				Helen McCaughan


This is at the airport, so you do not really need a car.
The hotel has shuttles from the airport.


Welcome to LA. If you need any help with planning your visit,
you can either look things up on the Web at:


	http://www.at-la.com./


or contact me.


Regards,


Carl-Uno


Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros@cp10.es.xerox.com

From Nagasaka.Fumio at exc.epson.co.jp  Mon Nov  3 08:07:51 1997
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:46 2009
Subject: P1394> 1394PWG Thick Transport Stack Requirements
Message-ID: <3.0.1.32.19971031151202.00b8cc60@garfield>

Toru Ueda wrote:
> If the buffer service provides segmentaion and reassembly,
> it may be more useful.
> (This might sucrifice the simplicity of buffer service.)


I don't think so. If the buffer service provides segmentaion and
reassembly,
it makes a transport architecture more complex. Actually segmentation
and reassembly is required due to limit of bus specification. However
any
requirements caused by bus specification shall be resolved in a data
link
layer such as IEEE 1284.3. And transport protocol shall be abstracted
from
any bus-specific requirements.


Toru, Brian, I am so sorry for my interruption for your discussion. Your
discussion bring us produvtive result. Thank you.


Fumio Nagasaka




>-----Original Message-----
>From:	Toru Ueda [SMTP:ueda@tansu.slab.tnr.sharp.co.jp]
>Sent:	Wednesday, October 29, 1997 9:16 PM
>To:	Brian Batchelder
>Cc:	1394 PWG; PWG-C
>Subject:	Re: P1394> 1394PWG Thick Transport Stack Requirements 
>
>
>Hi Brian,
>
>I understand the meaning of buffer service. 
>
>If the buffer service provides segmentaion and reassembly,
>it may be more useful.
>(This might sucrifice the simplicity of buffer service.)
>
>Because IEEE1394 has maximum packet size(512 bytes for S100), 
>segmentaion and reassembly service may be required if buffer
>service treats more than 512 bytes.
>
>Toru Ueda
>Software Labs.
>Sharp Corporation
>
>
>  >>At 09:54 PM 10/24/97 +0900, Toru Ueda wrote:
>  >>--
>  >>--Brian,
>  >>--
>  >>--Thank you for forwarding your client requirements for thick
>  >>--transport stack document.
>  >>--
>  >>--I have one question about thick "MUST".
>  >>--
>  >>--I don't understand how to use buffer service.
>  >>--Why must thick transport have buffer service ?
>  >>
>  >>The buffer service is used by clients who need to have data delivered
>with
>  >>well-defined starting and ending points.  For example, this data might be
>a
>  >>message that needs to be delivered whole.  If a byte stream service is
>  >>used, the message might be broken into multiple buffers, or if might have
>  >>other data appended to it.   This might make the message impossible to
>  >>interpret by the receiving service.
>  >>--My understanding is the transport will handle the
>  >>--differences of physical buffer sizes of sending and
>  >>--receiving endpoints.
>  >>
>  >>Yes, the transport must handle varying buffer sizes in each direction.
>For
>  >>the byte stream service it must be able to break up a large request
>buffer
>  >>into multiple send buffers.  For the buffer service it must either be
>able
>  >>to somehow ommunicate to the client the largest buffer that can be sent
>or
>  >>provide buffer segmentation and reassembly services.  Maybe this should
>be
>  >>added to the requirements?
>  >>--I assume that the indication of receiving the 30bytes packet
>  >>--to upper layer will issue when 30bytes data receives whether
>  >>--this packet is divided into 2-15 bytes or 3-10 bytes data if 
>  >>--the transport packet size is 30 bytes.
>  >>
>  >>I think the requirement is that the 30 bytes be delivered as a buffer if
>  >>the transmitted buffer is 30 bytes and there is some indication that it
>  >>should be delivered as a single, whole buffer.  I don't think it is a
>  >>requirement that the smaller packets be reassembled into one larger
>buffer
>  >>(in other words, that a reassembly service be provided).
>  >>
>  >>--But buffer service allows to send only fixed(30bytes in this 
>  >>--case) data. 
>  >>
>  >>The buffer service would allow UP TO 30 bytes of data to be delivered as
>a
>  >>single, whole buffer.  A buffer of less than 30 bytes could also be
>  >>transmitted.
>  >>
>  >>--Does this help to write application ?
>  >>
>  >>It does help some applications that want to send messages without those
>  >>messages  inherently providing some way to be extracted from a byte
>stream.
>  >>
>  >>--I misunderstand buffer service ?
>  >>
>  >>I think that the requirements document is not complete.  For now, we
>  >>probably have many interpretations of the requirements.  Our challenge is
>  >>to refine the requirements list until we all agree on them.
>  >>
>  >>Brian
>  >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  >>Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
>  >>Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
>  >>DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227
>  >>
>
>
>
>
>

From don at lexmark.com  Mon Nov  3 16:02:50 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:46 2009
Subject: P1394> December Meeting in LA
Message-ID: <199711032102.AA28468@interlock2.lexmark.com>

Based upon the progress of work on JMP, IPP, etc. at the Boulder meeting,
here's
my first pass at a meeting schedule for the December meeting.


Dec 1, 2    -  1394 Printing
Dec 3        -  IPP
Dec 4       - SENSE
Dec 5       - FIN


I will issue a final agenda on or about November 24th.


Don


**********************************************
* Don Wright                 don@lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

From gregory_leclair at erc.epson.com  Fri Nov  7 02:09:47 1997
From: gregory_leclair at erc.epson.com (gregory_leclair@erc.epson.com)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Attendance at the 1212 meeting?
Message-ID: <9711068788.AA878886855@epson.com>

     Hi all,
     
     Here is the first info about the 1212 meeting that I mentioned in 
     Boulder.
     
     FYI - SONY's main building here is off of North First Street in San 
     Jose. 
     
     If you plan on attending:
     
     Contact: 
        Aaron Ludtke - aaronl@lsi.sel.sony.com
     
     Accomodations:
        Doubletree Hotel near San Jose Airport
        Hyatt on 1st street
        Marriott in Santa Clara
        Embassy Suites in Santa Clara
     
     Look forward to seeing you.
     
     Regards,
     Greg LeClair
     
     
     
     
     
     
     




______________________________ Forward Header __________________________________
Subject: Attendance at the 1212 meeting? 
Author:  <aaronl@lsi.sel.sony.com > at xInternet
Date:    11/6/97 8:56 AM




Hello,
     
As many of you may know, we are planning to hold the first IEEE 1212 
Reaffirmation meeting on Nov. 11-12 here in the S.F. Bay Area. In order 
to get things moving, Sony will host this first meeting, but we need to 
know how many people will attend. This is necessary for renting  meeting 
space, etc.
     
I request that you PLEASE respond to me (NOT TO THE REFLECTORS!!!) with 
your plans to attend. If you do NOT plan to attend, please do not respond.
     
PLEASE get your response back to me NO LATER than the end of your Friday 
(wherever you may be in the world...) Nov. 7. An earlier response will 
help us get the necessary space sooner. There is the possibility that 
meeting space might NOT be found if we wait too long.
     
If you know of someone who will be attending but who can't respond by 
Friday, please let me know about them as well.
     
I apologize for duplicate messages, but I need to cover as many 
reflectors as possible. Please pass this along to people outside the 1394 
TA reflectors who may be interested in the IEEE 1212 work.
     
Thanks very much,
     
Aaron
     

From gregory_leclair at erc.epson.com  Mon Nov 10 16:26:24 1997
From: gregory_leclair at erc.epson.com (gregory_leclair@erc.epson.com)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Minutes Posted
Message-ID: <9711108791.AA879197871@epson.com>

     The minutes from Boulder on 10/27 and 10/28 have been posted.
     
     
     Greg

From atsnaka at cbs.canon.co.jp  Tue Nov 11 02:51:33 1997
From: atsnaka at cbs.canon.co.jp (Atsushi Nakamura)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Minutes Posted
Message-ID: <199711110754.QAA24809@meshsv02.tk.mesh.ad.jp>

I apologize for not attending the Denver PWG meeting.


I would like to clarify understanding of the current FDS06 proposal.
(FDS06 is just re-wording of FDS05. Nothing has changed contents-wise.)


The 3 contents of FDS is as follows;


1: A function class list (1 function class entry per function)
2: A supported-protocol list (Information on protocolS supported by EACH function.)
3: A pointerand/or location for further function information 
   (ex. function model ID etc...)


Corresponding directories in FDS06 is as follows;


1. =>Function Class Directory
2. =>Function Descriptor Directory
3. =>Function Unit Info Block (Directory)


   2; A supported-protocol-list =>Function Descriptor Dir
has been neglected, and the 
Function Unit Info Block has been renamed the
Function Descriptor Dir..   


All entries of this protocol list,
 which includes a unit(funct.)_spec_id and 
 unit(funct.)_sw_ver, and the pointer to corresponding unit directory
 for EACH protocol supported by the function,
is necessary because;


This directory, with the Unit(funct.)_spec_id and
Unit(funct.)_sw_ver entries of all the supported protocols
included will inform ALL of the protocols supported by the function
IN A SINGLE BLOCK READ (and the pointer to the unit directory,
in case you find the matching protocol).
This will be VERY EFFICIENT in reading out the ROM, and will make full
use of block reads, which was suggested for ROM read-out at the 
1394TA. 


Just pointers will require you to read each individual unit directories
until you find the matching protocol.


We all are assuming by now that printers will support at least 2 protocols,
and the block read will be efficient.


If the function descriptor directory exists as it was origionally define 
(as above), it is unnatural to point to it from the unit directories, it should be the
function unit info block that has possiblilty to be pointed from the unit diorectory,
and this is for discussion.


One last item, SDD defines a entry for model vendor and model ID.
Would it be wise to define the same contents in the unit directory ?




p.s. My personal impression of the TA on the subject of FDS,
     There was no "TA feedback", the presentation was just informative,
     and the opinions were personal, as far as I know


Atsushi Nakamura
BJ Printing Technology Development 22
Canon Inc.
------------------------------------
 Atsushi_Nakamura@cbj.canon.co.jp
 atsnaka@mxa.meshnet.or.jp


----------
> �·�o�l : gregory_leclair@erc.epson.com
> ˆ¶�æ : p1394@pwg.org
> Œ�–¼ : P1394> Minutes Posted
> ‘—�M“úŽž : 1997”N11ŒŽ11“ú 6:26
> 
> 
>      The minutes from Boulder on 10/27 and 10/28 have been posted.
>      
>      
>      Greg
> 
> 

From cmanros at cp10.es.xerox.com  Mon Nov 17 15:23:13 1997
From: cmanros at cp10.es.xerox.com (Carl-Uno Manros)
Date: Wed May  6 14:00:46 2009
Subject: P1394> ADM - PWG Meeting in LA, December 1 - 5
Message-ID: <3.0.1.32.19971117122313.009d8d80@garfield>

Hi all,


I have just spoken to the hotel about availability of rooms at the Xerox
room rate. They have graciously extended the booking period until the end
of November, so you can still take advantage of it. To make sure you get
the special rate, please contact the hotel directly - your travel agent may
not be able to get the Xerox rate for you.


Here is the information again:


Crown Plaza Hotel
Los Angeles Airport
5985 W. Century Blvd.
Los Angeles, CA  90045
PH: 310-642-7500
FAX: 310-216-6646


Room rate: $79.00 per night 
Parking:   $6.00 per day
Meeting room etc. about $30.00 - 35.00 per person per day


The registration is in the name of: 	Xerox
Deadline for the special room rate:	November 30, 1997


Carl-Uno






Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros@cp10.es.xerox.com

From gregoryl at spider.epson.com  Wed Nov 19 19:20:49 1997
From: gregoryl at spider.epson.com (Gregory LeClair)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Meeting agenda items for 12/1 and 12/2
Message-ID: <01BCF507.2336C760@p133>

The agenda for 12/1 and 12/2 will focus on the following items:


1212 WG Summary


Function Discovery
- Issues raised in 1212 WG meeting
- Items defined by new 1212 revision
- Items to be defined in 1394 Printer Profile


Printing Profile
- Review of draft proposal


IEEE PAR requirement


=========================================
NOTICE on 1212 MEETING


FYI - the next 1212 WG meeting is in Fort Lauderdale, FL on 
12/3. I will be leaving early on 12/2 to fly to Florida for the 1212 
meeting.


For those of you who are interested:
1212 WG meeting is on 12/3 at the 
Marriott North
6650 North Andrews Ave.
95771-0440


The cutoff for the $119 room rate was 11/15 - I was able to get a 
$129 rate - perhaps you can....




Let me know if you have any questions,


Greg LeClair

From lstein at fapo.com  Thu Nov 20 15:26:58 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:46 2009
Subject: P1394> January Meeting Notice
Message-ID: <3.0.32.19971120122644.0085f510@pop3.fapo.com>

Hello,


This is the official meeting notice for the January meeting of the Printer
Working Group.
(Sorry in advance for multiple posting)


This meeting is the semi-annual joint meeting of the PWG and the PWG-Japan.
 Rather than have this meeting in Japan it was decided that it would be
fairer to meet half way.  Alaska is to cold and dark in January, so we
thought that Hawaii was a better choice.


The particulars:


Where:		Maui Marriott on Kaanapali Beach
When:		January 26, 1998 to January 30, 1998
Rate:		$179.00 double, $25 per additional
		Plus meeting charges


Reservation #:	1-800-763-1333
		1-808-667-1200
Group Name:	Printer Working Group


DEADLINE:	DECEMBER 23, 1997


This was a difficult meeting to setup.  I held rooms based upon the
responses from the previous ping request.  Space is limited so please make
your reservations as soon as possible.   You should be able to make
reservations by Monday, November 24.  Be sure to mention the group name.


PLEASE SEND ME A RSVP ONCE YOU HAVE CONFIRMED YOUR RESERVATION.  EVEN IF
YOU PINGED BEFORE.  I need to know:


check in date:
Meetings attending:
check out date:


There will be a group function on Tuesday night.  Please let me know if you
would like to attend and how many people (spouse, kids,....)


Agenda (subject to change):


	Monday		1/26	Joint 1394 Printer Working Group meeting
	Tuesday 	1/17	Joint 1394 Printer Working Group meeting
	Wednesday	1/28	Printer Working Group -- IPP
	Thursday	1/29	Printer Working Group -- SENSE
	Friday		1/30	Printer Working Group -- FIN


All meetings will run from 8:30 AM to 5:00 PM.  There will be coffee and
break included.		


Thanks,
Larry Stein
***************************************************************
Larry A. Stein			Phone: 	(619)292-2742
Warp Nine Engineering		Fax:	(619)292-8020
				Web: 	http://www.fapo.com
***************************************************************

From don at lexmark.com  Mon Nov 24 15:59:11 1997
From: don at lexmark.com (don@lexmark.com)
Date: Wed May  6 14:00:46 2009
Subject: P1394> LA Schedule
Message-ID: <199711242107.AA29754@interlock2.lexmark.com>

Given that Jay will not be able to attend the LA meeting, the following
is the schedule for the week.  Changes are only to Thursday and
Friday.


Mon/Tues      1394 Printing
Wednesday     IPP
Thursday      Finisher MIB
Friday        Job MIB


**********************************************
* Don Wright                 don@lexmark.com *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

From lstein at fapo.com  Tue Nov 25 20:28:05 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Booking January Meeting
Message-ID: <3.0.32.19971125172747.00846df0@pop3.fapo.com>

Hello,


There are rooms reserved from 1/23 through 2/1 for the January meeting in
Maui.  If you need reservations outside of that time, be sure to tell them
you're with the "Printer Working Group".


If you should have any problems then you can speak to Mark Cunningham at
the Maui Marriott.


Thanks,
Larry
***************************************************************
Larry A. Stein			Phone: 	(619)292-2742
Warp Nine Engineering		Fax:	(619)292-8020
				Web: 	http://www.fapo.com
***************************************************************

From gleclair at agentz.com  Sun Nov 30 11:08:14 1997
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Site Update - Profile published
Message-ID: <3.0.32.19971125172747.00846df0@pop3.fapo.com>

The Imaging Device Profile has been posted .


Greg

From gleclair at agentz.com  Wed Dec  3 04:34:57 1997
From: gleclair at agentz.com (Gregory LeClair)
Date: Wed May  6 14:00:46 2009
Subject: P1394> 1212 Revision Reflector has been setup
Message-ID: <3.0.32.19971125172747.00846df0@pop3.fapo.com>

Hi all,


See following if you're interested.


Greg


-----Original Message-----
From:	Aaron Ludtke [SMTP:aaronl@lsi.sel.sony.com]
Sent:	Monday, December 01, 1997 5:46 PM
To:	1212 Reflector
Subject:	Let the games begin...


Hey people,


The 1212 Reaffirmation Project reflector is up and running. This message 
is going to the reflector...if you got it, then you've already been 
subscribed (I signed up the people who were at the first meeting, and a 
couple of others who I know are interested).


As you will note in your email message header, the reflector is:


p1212r@zayante.com




The web site is:


http://www.zayante.com/p1212r




On the web page are instructions for how to subscribe/unsubscribe to the 
reflector, so pass it along.


There is an ftp site at: ftp.zayante.com


Remember, Zayante is hosting this for us, so give them a big high-five 
the next time you see them.


Aaron




[ To receive daily digests of this list send the one line message: ]
[     "subscribe digest p1212r" to requests@zayante.com            ]
[ To stop receiving messages send the one line message:            ]
[     "unsubscribe p1212r" to requests@zayante.com                 ]

From fumiona at venus.dtinet.or.jp  Sun Dec  7 03:34:39 1997
From: fumiona at venus.dtinet.or.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Re: SBP-2 Bidirectional ORB
In-Reply-To: <SBP-2 Bidirectional ORB>
Message-ID: <3.0.32.19971125172747.00846df0@pop3.fapo.com>

------ =_NextPart_000_01BD0339.54CBBF20
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit


Through the 1394 PWG discussion, I *was* thinking "in order execution" for
linked list of ORBs is required for printing application. Now I think the target
may skip ORB execution in some case, even in a printing application, utilizing
multiple logical channel.


PJohansson@aol.com  writes:
* Well, how does the initiator *know* that the target has no data? Use a
* timeout? No, I think that this would be an ill-advised strategy---very
* inefficient, too.


I don't think the initiator knows the target has no data. And I do not think
the application layer in the target device know the transport layer received
IN-ORB request from the initiator. Thus if there is an input request between
other ORBs and the target does not have any data to reply, SBP-2 transport
layer would not decide whether the application is going to send data just
10 msec later or after 10 minutes hard working.


We at 1394 PWG found the higher layer in the protocol stack in the target
shall service multiple logical channels. Then, the target agent may fetch
ORBs and distribute them into each logical channel. Please see an attached
figure:


 
Each logical channel shall consume ORBs in the queue. Even if a logical
channel received an ORB which is not executable, other logical channels
would be available.


Actually when paper out, the printer does not print and it does not consume
PCL commands. Then any ORB which is pointing print data will be stalled.
However the initiator may send status request through an available logical
channel. The initiator can get reason why the ORB is stalled. And if the
trouble is unrecoverable, then it may send *TASK_ABORT* to the target.


The PWG printer profile for SBP-2 is defining logical channel field in command
block of the "Normal command block ORB" data structure.
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


-----Original Message-----
From:	PJohansson [SMTP:PJohansson@aol.com]
Sent:	Thursday, December 04, 1997 11:17 AM
To:	fumiona@venus.dtinet.or.jp; 1394-architecture@1394ta.org
Subject:	Re: P1394> Re: SBP-2 Bidirectional ORB


In a message dated 97-11-21 12:18:06 EST, fumiona@venus.dtinet.or.jp writes:


<<If the target device does not have any data to reply, when the initiator is
keeping Out-ORB, In-ORB and Out-ORB, the target fetch agent will be stalled at
second ORB and third ORB will not be consumed.>>


This is a true statement ONLY if the target reports in-order execution in its
configuration ROM. To keep things in perspective, all of the discussions of
printers (of which I am aware) have assumed in-order execution.


<<In this case, "AGENT_STATE" shall be ACTIVE at this moment. Thus if the
initiator try to ping DOORBELL, this write-transaction for DOORBELL is
redundant. To overcome this state, the initiator need to write a value to
AGENT_RESET register to force "AGENT_STATE" to turn RESET state. Is this a
normal job for this purpose?>>


Well, how does the initiator *know* that the target has no data? Use a
timeout? No, I think that this would be an ill-advised strategy---very
inefficient, too.


Better for the target to complete the second ORB in the example above and
indicate zero data transfer. It's then free to go on the the third ORB.


Peter Johansson


Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602


(510) 531-5472
(510) 531-2942 FAX


pjohansson@aol.com




------ =_NextPart_000_01BD0339.54CBBF20
Content-Type: application/pdf; name="InOrbStalled.PDF"
Content-Transfer-Encoding: base64


[encoded data, 25179 characters]
YmU5MGQ1ZD5dDQo+Pg0Kc3RhcnR4cmVmDQoxNzczMw0KJSVFT0YNCg==


------ =_NextPart_000_01BD0339.54CBBF20--

From rturner at sharplabs.com  Sun Dec  7 08:02:06 1997
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Re: SBP-2 Bidirectional ORB
In-Reply-To: <P1394> Re: SBP-2 Bidirectional ORB>
Message-ID: <3.0.32.19971125172747.00846df0@pop3.fapo.com>

When you implement 1284.4 on top of SBP-2, the 1284.4
layer will multiplex multiple independent logical channels
over a single SBP-2 login session. For each logical
channel that is managed over a particular SBP-2 login session,
"outbound" ORBs must be processed in FIFO order, and
"inbound" ORBs must be processed in FIFO order. These
requirements are necessary since 1284.4 contains no
sequence space or any other capability that would allow
it to reorder packets.


One problem with this requirement is that it was assumed
that the particular SBP-2 implementation to be used
would not have any information about 1284.4 - specific
requirements for FIFO processing of outbound/inbound
ORBs. Unless the SBP-2 layer software interface allows
this type of option to be specified for a particular login.


This may not be a problem for a target if the target-side
1284.4 implementation provides its own SBP-2 fetch
agent. I am not familiar with how SBP-2 implementations
are being designed; whether they implement "internal"
fetch agents, or do they support "external" fetch agents
for clients with special ORB processing requirements?




Randy




>  -----Original Message-----
> From:	Fumio Nagasaka [SMTP:fumiona@venus.dtinet.or.jp]
> Sent:	Sunday, December 07, 1997 12:35 AM
> To:	'1394-architecture@1394ta.org'; 'p1394@pwg.org'
> Cc:	'PJohansson'
> Subject:	P1394> Re: SBP-2 Bidirectional ORB
> 
> Through the 1394 PWG discussion, I *was* thinking "in order execution"
> for
> linked list of ORBs is required for printing application. Now I think
> the target
> may skip ORB execution in some case, even in a printing application,
> utilizing
> multiple logical channel.
> 
> PJohansson@aol.com  writes:
> * Well, how does the initiator *know* that the target has no data? Use
> a
> * timeout? No, I think that this would be an ill-advised
> strategy---very
> * inefficient, too.
> 
> I don't think the initiator knows the target has no data. And I do not
> think
> the application layer in the target device know the transport layer
> received
> IN-ORB request from the initiator. Thus if there is an input request
> between
> other ORBs and the target does not have any data to reply, SBP-2
> transport
> layer would not decide whether the application is going to send data
> just
> 10 msec later or after 10 minutes hard working.
> 
> We at 1394 PWG found the higher layer in the protocol stack in the
> target
> shall service multiple logical channels. Then, the target agent may
> fetch
> ORBs and distribute them into each logical channel. Please see an
> attached
> figure:
> 
>  
> Each logical channel shall consume ORBs in the queue. Even if a
> logical
> channel received an ORB which is not executable, other logical
> channels
> would be available.
> 
> Actually when paper out, the printer does not print and it does not
> consume
> PCL commands. Then any ORB which is pointing print data will be
> stalled.
> However the initiator may send status request through an available
> logical
> channel. The initiator can get reason why the ORB is stalled. And if
> the
> trouble is unrecoverable, then it may send *TASK_ABORT* to the target.
> 
> The PWG printer profile for SBP-2 is defining logical channel field in
> command
> block of the "Normal command block ORB" data structure.
> --------------------------------------------
> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
> 
> -----Original Message-----
> From:	PJohansson [SMTP:PJohansson@aol.com]
> Sent:	Thursday, December 04, 1997 11:17 AM
> To:	fumiona@venus.dtinet.or.jp; 1394-architecture@1394ta.org
> Subject:	Re: P1394> Re: SBP-2 Bidirectional ORB
> 
> In a message dated 97-11-21 12:18:06 EST, fumiona@venus.dtinet.or.jp
> writes:
> 
> <<If the target device does not have any data to reply, when the
> initiator is
> keeping Out-ORB, In-ORB and Out-ORB, the target fetch agent will be
> stalled at
> second ORB and third ORB will not be consumed.>>
> 
> This is a true statement ONLY if the target reports in-order execution
> in its
> configuration ROM. To keep things in perspective, all of the
> discussions of
> printers (of which I am aware) have assumed in-order execution.
> 
> <<In this case, "AGENT_STATE" shall be ACTIVE at this moment. Thus if
> the
> initiator try to ping DOORBELL, this write-transaction for DOORBELL is
> redundant. To overcome this state, the initiator need to write a value
> to
> AGENT_RESET register to force "AGENT_STATE" to turn RESET state. Is
> this a
> normal job for this purpose?>>
> 
> Well, how does the initiator *know* that the target has no data? Use a
> timeout? No, I think that this would be an ill-advised strategy---very
> inefficient, too.
> 
> Better for the target to complete the second ORB in the example above
> and
> indicate zero data transfer. It's then free to go on the the third
> ORB.
> 
> Peter Johansson
> 
> Congruent Software, Inc.
> 3998 Whittle Avenue
> Oakland, CA  94602
> 
> (510) 531-5472
> (510) 531-2942 FAX
> 
> pjohansson@aol.com
>  << File: InOrbStalled.PDF >> 

From fumiona at venus.dtinet.or.jp  Mon Dec  8 09:59:46 1997
From: fumiona at venus.dtinet.or.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Re: SBP-2 Bidirectional ORB
In-Reply-To: <P1394> Re: SBP-2 Bidirectional ORB>
Message-ID: <3.0.32.19971125172747.00846df0@pop3.fapo.com>

Randy Turner writes:
>One problem with this requirement is that it was assumed
>that the particular SBP-2 implementation to be used
>would not have any information about 1284.4 - specific
>requirements for FIFO processing of outbound/inbound
>ORBs.


According to SBP-2 specification "7.4.8. Logical_Unit_Characteristics entry",
we may specify characteristics of the target implementation. If our target
agent is required to execute ORBs in order, then the order bit shall be one.


Randy Turner writes:
>This may not be a problem for a target if the target-side
>1284.4 implementation provides its own SBP-2 fetch
>agent.


I think a normal target agent can do it.
The target agent may not fetch ORBs in order. The target may fetch
some special ORBs before it fetches other ORBs. Thus if client layer
for SBP-2 stack informs SBP-2 that a channel is stalled, then the
fetch agent may skip any ORBs for this channel. Alan described a
command bock of each normal command block ORB shall have PSID
and SSID. So the target agent will be able to find a channel ID from
each ORB and may skip ORBs delivered to the channel which has
trouble.


After few moments, when the stalled queue turns to be available,
the higher layer protocol stack (1284.4 layer) shall inform SBP-2 that
the channel is recovered. Then the target agent may fetch and deiver
ORBs for this channel.


Randy, am I understanding your point? 
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


-----Original Message-----
From:	Turner, Randy [SMTP:rturner@sharplabs.com]
Sent:	Sunday, December 07, 1997 10:02 PM
To:	'Fumio Nagasaka'; '1394-architecture@1394ta.org'; 'p1394@pwg.org'
Cc:	'PJohansson'
Subject:	RE: P1394> Re: SBP-2 Bidirectional ORB






When you implement 1284.4 on top of SBP-2, the 1284.4
layer will multiplex multiple independent logical channels
over a single SBP-2 login session. For each logical
channel that is managed over a particular SBP-2 login session,
"outbound" ORBs must be processed in FIFO order, and
"inbound" ORBs must be processed in FIFO order. These
requirements are necessary since 1284.4 contains no
sequence space or any other capability that would allow
it to reorder packets.


One problem with this requirement is that it was assumed
that the particular SBP-2 implementation to be used
would not have any information about 1284.4 - specific
requirements for FIFO processing of outbound/inbound
ORBs. Unless the SBP-2 layer software interface allows
this type of option to be specified for a particular login.


This may not be a problem for a target if the target-side
1284.4 implementation provides its own SBP-2 fetch
agent. I am not familiar with how SBP-2 implementations
are being designed; whether they implement "internal"
fetch agents, or do they support "external" fetch agents
for clients with special ORB processing requirements?




Randy




>  -----Original Message-----
> From:	Fumio Nagasaka [SMTP:fumiona@venus.dtinet.or.jp]
> Sent:	Sunday, December 07, 1997 12:35 AM
> To:	'1394-architecture@1394ta.org'; 'p1394@pwg.org'
> Cc:	'PJohansson'
> Subject:	P1394> Re: SBP-2 Bidirectional ORB
> 
> Through the 1394 PWG discussion, I *was* thinking "in order execution"
> for
> linked list of ORBs is required for printing application. Now I think
> the target
> may skip ORB execution in some case, even in a printing application,
> utilizing
> multiple logical channel.
> 
> PJohansson@aol.com  writes:
> * Well, how does the initiator *know* that the target has no data? Use
> a
> * timeout? No, I think that this would be an ill-advised
> strategy---very
> * inefficient, too.
> 
> I don't think the initiator knows the target has no data. And I do not
> think
> the application layer in the target device know the transport layer
> received
> IN-ORB request from the initiator. Thus if there is an input request
> between
> other ORBs and the target does not have any data to reply, SBP-2
> transport
> layer would not decide whether the application is going to send data
> just
> 10 msec later or after 10 minutes hard working.
> 
> We at 1394 PWG found the higher layer in the protocol stack in the
> target
> shall service multiple logical channels. Then, the target agent may
> fetch
> ORBs and distribute them into each logical channel. Please see an
> attached
> figure:
> 
>  
> Each logical channel shall consume ORBs in the queue. Even if a
> logical
> channel received an ORB which is not executable, other logical
> channels
> would be available.
> 
> Actually when paper out, the printer does not print and it does not
> consume
> PCL commands. Then any ORB which is pointing print data will be
> stalled.
> However the initiator may send status request through an available
> logical
> channel. The initiator can get reason why the ORB is stalled. And if
> the
> trouble is unrecoverable, then it may send *TASK_ABORT* to the target.
> 
> The PWG printer profile for SBP-2 is defining logical channel field in
> command
> block of the "Normal command block ORB" data structure.
> --------------------------------------------
> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
> 
> -----Original Message-----
> From:	PJohansson [SMTP:PJohansson@aol.com]
> Sent:	Thursday, December 04, 1997 11:17 AM
> To:	fumiona@venus.dtinet.or.jp; 1394-architecture@1394ta.org
> Subject:	Re: P1394> Re: SBP-2 Bidirectional ORB
> 
> In a message dated 97-11-21 12:18:06 EST, fumiona@venus.dtinet.or.jp
> writes:
> 
> <<If the target device does not have any data to reply, when the
> initiator is
> keeping Out-ORB, In-ORB and Out-ORB, the target fetch agent will be
> stalled at
> second ORB and third ORB will not be consumed.>>
> 
> This is a true statement ONLY if the target reports in-order execution
> in its
> configuration ROM. To keep things in perspective, all of the
> discussions of
> printers (of which I am aware) have assumed in-order execution.
> 
> <<In this case, "AGENT_STATE" shall be ACTIVE at this moment. Thus if
> the
> initiator try to ping DOORBELL, this write-transaction for DOORBELL is
> redundant. To overcome this state, the initiator need to write a value
> to
> AGENT_RESET register to force "AGENT_STATE" to turn RESET state. Is
> this a
> normal job for this purpose?>>
> 
> Well, how does the initiator *know* that the target has no data? Use a
> timeout? No, I think that this would be an ill-advised strategy---very
> inefficient, too.
> 
> Better for the target to complete the second ORB in the example above
> and
> indicate zero data transfer. It's then free to go on the the third
> ORB.
> 
> Peter Johansson
> 
> Congruent Software, Inc.
> 3998 Whittle Avenue
> Oakland, CA  94602
> 
> (510) 531-5472
> (510) 531-2942 FAX
> 
> pjohansson@aol.com
>  << File: InOrbStalled.PDF >> 

From lstein at fapo.com  Fri Dec 12 10:48:28 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:46 2009
Subject: P1394> January Meeting Notice
Message-ID: <3.0.32.19971212074811.00890ba0@pop3.fapo.com>

Hello,




This is a reminder for the January meeting of the Printer Working 
Group.


(Sorry in advance for multiple posting).  The deadline is coming up.




Be sure to RSVP to me (lstein@fapo.com) after you make your
reservations.


Thanks,


Larry




*********************************************************




The particulars:




Where:		Maui Marriott on Kaanapali Beach


When:		January 26, 1998 to January 30, 1998


Rate:		$179.00 double, $25 per additional


		Plus meeting charges




Reservation #:	1-800-763-1333


		1-808-667-1200


Group Name:	Printer Working Group




DEADLINE:	<bold>DECEMBER 23, 1997


</bold>


This was a difficult meeting to setup.  I held rooms based upon the
responses from the previous ping request.  Space is limited so please
make your reservations as soon as possible.   You should be able to make
reservations by Monday, November 24.  Be sure to mention the group 
name.




<bold>PLEASE SEND ME A RSVP ONCE YOU HAVE CONFIRMED YOUR RESERVATION. 
EVEN IF YOU PINGED BEFORE.  I need to know:


</bold>


check in date:


Meetings attending:


check out date:




There will be a group function on Tuesday night.  Please let me know if
you would like to attend and how many people (spouse, kids,....)




Agenda (subject to change):




	Monday		1/26	Joint 1394 Printer Working Group meeting


	Tuesday 	1/17	Joint 1394 Printer Working Group meeting


	Wednesday	1/28	Printer Working Group -- IPP


	Thursday	1/29	Printer Working Group -- SENSE


	Friday		1/30	Printer Working Group -- FIN




All meetings will run from 8:30 AM to 5:00 PM.  There will be coffee and
break included.		




Thanks,


Larry Stein


***************************************************************


Larry A. Stein			Phone: 	(619)292-2742


Warp Nine Engineering		Fax:	(619)292-8020


				Web: 	http://www.fapo.com


***************************************************************

From rturner at sharplabs.com  Fri Dec 12 19:21:18 1997
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Conference call
Message-ID: <3.0.32.19971212074811.00890ba0@pop3.fapo.com>

There will be a conference call for the sub-committee
of participants decided at the Los Angeles meeting.
(You know who you are)
The conference call is setup for a maximum of 10
people, so please do not call in unless you were
on the list of participants from the last meeting.


The call details are:


Time:	Monday, December 15th at 1 PM PST (4 PM EST)


Number: 1-800-403-1032  when prompted, 
			enter access code 325183

From lstein at fapo.com  Fri Dec 12 20:24:28 1997
From: lstein at fapo.com (Larry Stein)
Date: Wed May  6 14:00:46 2009
Subject: P1394> December Meeting Minutes
Message-ID: <3.0.32.19971212172419.0084ea40@pop3.fapo.com>

--=====================_882005068==_
Content-Type: text/plain; charset="us-ascii"


I've attached the minutes from the December meeting.  Sorry for the delay.


Thanks,
Larry
--=====================_882005068==_
Content-Type: application/pdf; name="1394min_9712.PDF"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="1394min_9712.PDF"


[encoded data, 45876 characters]
--=====================_882005068==_
Content-Type: text/plain; charset="us-ascii"




***************************************************************
Larry A. Stein			Phone: 	(619)292-2742
Warp Nine Engineering		Fax:	(619)292-8020
				Web: 	http://www.fapo.com
***************************************************************
--=====================_882005068==_--

From Nagasaka.Fumio at exc.epson.co.jp  Mon Dec 15 06:13:13 1997
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:46 2009
Subject: P1394> RE: TEL-Conference
Message-ID: <3.0.32.19971212172419.0084ea40@pop3.fapo.com>

I'm sorry for inconvenience for multiple copy of this mail through the 
mailing list.


I have some comments for PWG-printing profile.


1. Login/Logout


Some consumer operating systems invoke "login" at boot time, and never 
logout
until shut down. This scheme was designed intended to support SBP-2 
HDD as
a boot device. However this scheme is not smart to support PWG 
printer.


Actually on a consumer PC operating system platform designed in north 
California,
our driver may invoke "login" at any time.


May be, "login" and "logout" shall be associated with DL_register and 
DL_unrgister.
Thus I feel PWG-profile shall specify the timing for login/logout. 
These facilities
ought to be implemented in Data Link stuff 
(DL_register/DL_unregister).


2. Login waiting time


IEEE 1394 provides network-like platform for PCs.


-	PC A is printing a document using Printer X.
-	PC B is waiting to start printing while 10 seconds.
-	PC C is waiting to start printing while 10 minutes.


Then PC C shall be allowed to start printing session earlier than PC 
B.
I felt current PWG protocol stack does not provide any answer to solve 
this issue.
Because PC B or PC C may invoke login while PC A is printing. When PC 
A
is printing, the data channel shall be busy, so IEEE 1284.4 transport 
replies busy
status if PC B or PC C try to open this channel. But after PC A closed 
this
data channel, IEEE 1284.4 allows a PC which ever calls OpenChannel 
earlier than
other PC to open this data channel.


To solve this problem, we need to introduce "OpenChannel_solicitation" 
which is
an unsolicited status to inform PC C that PC A closed printing session 
and now you
may call OpenChannel.


Alan's document is describing two "status_code" shown below,...
0x01	data transfer complete
0x02	target to initiator transfer request


I would like to suggest third "status_code",
0x03	target allows initiator to open 1284.4 data channel


PC C may login at any time, however while PC A is printing PC C is 
not
allowed to use same data channel with PC A. The target device allows
the initiator which invokes "login" earlier than other initiator, to 
open data
channel, after previous data session had been closed.


And may be we need to provide other message to say,
__ttt__	initiator allows target to open channel
As you know this function shall be provided utilizing ORB, because it 
might
be a solicitation from an initiator to the specified target. Then can 
PWG profile
use normal command block ORB?


Someone, could you kindly suggest tel-conference agenda if you have 
spare
time in Monday morning? ( I will go to sleep, as tel-conference starts 
from
Tuesday morning at 6:00 AM in Japan)


Thank you, best regard.
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


-----Original Message-----
From:	Fumio Nagasaka [SMTP:fumiona@venus.dtinet.or.jp]
Sent:	Saturday, December 13, 1997 10:46 AM
To:	'Randy Turner'
Cc:	'brianb@vcd.hp.com'; 'alan_berkema@hp.com'; 
'brianb@hp-vcd.vcd.hp.com'; 'gregory_leclair@erc.epson.com'; 
'shimura@pure.cpdc.canon.co.jp'; 'Greg Shue'
Subject:	RE: TEL-Conference


Hi Randy,


We ware discussing some points through e-mail. I was so sorry, I 
forgot who
was the organizer for this telephone conference. Thus I sent e-mail to 
several
persons who I expect to be a correct person.


At 01:53 AM 12/13/97 +0900, Fumio Nagasaka wrote:
>Hi there,
>
>May I confirm schedule and phone number for the tel-conference
>on December 15 at 4:00 PM?
>Do I need to make a phone-call to your phone number? Or can I
>wait your phone call in my office?
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


-----Original Message-----
From:	Greg Shue [SMTP:gregs@sdd.hp.com]
Sent:	Saturday, December 13, 1997 9:08 AM
To:	Fumio Nagasaka
Cc:	gregs@sdd.hp.com; brianb@vcd.hp.com; alan_berkema@hp.com; 
brianb@hp-vcd.vcd.hp.com; gregory_leclair@erc.epson.com; 
shimura@pure.cpdc.canon.co.jp
Subject:	Re: TEL-Conference


> Greg writes;
> >Personally, I prefer putting the 1284.4 command packet within the
> >data block of the ORB.  This means that the CDB needs to contain
> >the commands that:
> >  SENDMSG (?) - transfer all data to the target
> >  RECEIVEMSG (?) - receive <= blocksize bytes from the target (msg 
> boundary)
> >  RECEIVEBLOCK (?) - receive exactly blocksize bytes from the 
target
>
> The direction bit in a "Normal command block ORB" shall specify 
read/write
> direction from the initiator. These commands seem to have some 
redundancy.
> Greg do you have any special reason to have these commands ?


I have no special reason other than to distinguish the RECEIVEMSG
request from the RECEIVEBLOCK request.  Even that may not matter.


Looking at the Simple Hrd Disk Drive Profile, they support the
following (SCSI) commands:


  MODE_SELECT (10)
  MODE_SENSE  (10)
  READ        (10)
  START/STOP UNIT
  SYNCHONIZE CACHE
  TEST UNIT READY
  WRITE       (10)
  WRITE AND VERIFY (10)
  WRITE BUFFER, Mode (101b) (Download Microcode and Save)


As for a general protocol, I can see value in specifying Read
and Write commands simply to reserve space for other commands
we might want for testability or general functionality.  Or, if
we need to specify a command which has both a data payload for
each direction.  (Yes, I know this is the infamous bi-di ORB
which was rejected as a standard part of SBP-2.  I have no idea
how or why we would use something like that, but I would not
want to preclude it's availability).




> I suppose we can discuss through the e-mail. Thus we don't need to 
have
> telephone conference. Alan, could you please inform us your plan?


Now that there is some discussion going on, I would prefer to keep it
in e-mail.


> -------------------------------
> Fumio Nagasaka

--
Greg Shue
Hewlett-Packard Company
Office Products Division			gregs@sdd.hp.com
----------------------------------------------------------------


From rturner at sharplabs.com  Mon Dec 15 09:09:52 1997
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:46 2009
Subject: P1394> RE: TEL-Conference
Message-ID: <3.0.32.19971212172419.0084ea40@pop3.fapo.com>

I'm sorry about the inconvenient teleconference time
for Japan. The call was setup by another division
because I wanted folks to be able to call in
toll free. I will try and change it to 4 PM PST as
requested by our Japan partcipants. If I am 
successful at changing the time, I will post the
list. Until I can confirm the change, the telecon
time will be 1 PM PST, with the details I sent
out earlier.


Randy
>  

From rturner at sharplabs.com  Mon Dec 15 09:28:03 1997
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:46 2009
Subject: P1394> RE: TEL-Conference
Message-ID: <3.0.32.19971212172419.0084ea40@pop3.fapo.com>

See my comments below...


Randy


> -----Original Message-----
> From:	Nagasaka Fumio [SMTP:Nagasaka.Fumio@exc.epson.co.jp]
> Sent:	Monday, December 15, 1997 3:13 AM
> To:	'p1394@pwg.org'
> Cc:	'brianb@vcd.hp.com'; 'alan_berkema@hp.com';
> 'brianb@hp-vcd.vcd.hp.com'; 'gregory_leclair@erc.epson.com';
> 'shimura@pure.cpdc.canon.co.jp'; 'Greg Shue'; 'Randy Turner'
> Subject:	P1394> RE: TEL-Conference
> 
> I'm sorry for inconvenience for multiple copy of this mail through the
> 
> mailing list.
> 
> I have some comments for PWG-printing profile.
> 
> 1. Login/Logout
> 
> Some consumer operating systems invoke "login" at boot time, and never
> 
> logout
> until shut down. This scheme was designed intended to support SBP-2 
> HDD as
> a boot device. However this scheme is not smart to support PWG 
> printer.
	[Turner, Randy]  I agree, automatic login at boot time should
not be
	required to support printing. But plug'n play may require this
feature,
	and its not clear whether or not this causes a problem yet for
1284.4
	printing. 




> Actually on a consumer PC operating system platform designed in north 
> California,
> our driver may invoke "login" at any time.
> 
> May be, "login" and "logout" shall be associated with DL_register and 
> DL_unrgister.
> Thus I feel PWG-profile shall specify the timing for login/logout. 
> These facilities
> ought to be implemented in Data Link stuff 
> (DL_register/DL_unregister).
	[Turner, Randy]  I like this idea. The DL_register and
DL_unregister
	entry points for the 1394-based DL would translate these calls
	into login and logout calls. It seems to make sense for how
these
	entry points were originally designed to work. 




> 2. Login waiting time
> 
> IEEE 1394 provides network-like platform for PCs.
> 
> -	PC A is printing a document using Printer X.
> -	PC B is waiting to start printing while 10 seconds.
> -	PC C is waiting to start printing while 10 minutes.
> 
> Then PC C shall be allowed to start printing session earlier than PC 
> B.
> I felt current PWG protocol stack does not provide any answer to solve
> 
> this issue.
> Because PC B or PC C may invoke login while PC A is printing. When PC 
> A
> is printing, the data channel shall be busy, so IEEE 1284.4 transport 
> replies busy
> status if PC B or PC C try to open this channel. But after PC A closed
> 
> this
> data channel, IEEE 1284.4 allows a PC which ever calls OpenChannel 
> earlier than
> other PC to open this data channel.
	[Turner, Randy]  The description of this "problem" is really an
	implementation issue. This scenario says that the 1284.4
	printer would return "busy" if an OpenChannel was attempted
	while the printer was printing over a previously opened
	connection. However, the printer may elect to accept an
	OpenChannel from as many potential clients as possible,
	and only accept data from the first connection. The other
	open channels would be processed in some order, as
	each printing session completes. The other connections would
	be flow controlled until the printer is ready to accept 
	data on each channel.


	Basically, the policy that is used for printing arbitration
	is not defined by 1284.4. It is defined by the application
	using the 1284.4 transport. Therefore, I don't think the
	proposal for an OpenChannel_solicitation is necessary.
	If this type of functionality is needed, it would be an
	application function, not a transport function.


	Randy


> To solve this problem, we need to introduce "OpenChannel_solicitation"
> 
> which is
> an unsolicited status to inform PC C that PC A closed printing session
> 
> and now you
> may call OpenChannel.
> 
> Alan's document is describing two "status_code" shown below,...
> 0x01	data transfer complete
> 0x02	target to initiator transfer request
> 
> I would like to suggest third "status_code",
> 0x03	target allows initiator to open 1284.4 data channel
> 
> PC C may login at any time, however while PC A is printing PC C is 
> not
> allowed to use same data channel with PC A. The target device allows
> the initiator which invokes "login" earlier than other initiator, to 
> open data
> channel, after previous data session had been closed.
> 
> And may be we need to provide other message to say,
> __ttt__	initiator allows target to open channel
> As you know this function shall be provided utilizing ORB, because it 
> might
> be a solicitation from an initiator to the specified target. Then can 
> PWG profile
> use normal command block ORB?
> 
> Someone, could you kindly suggest tel-conference agenda if you have 
> spare
> time in Monday morning? ( I will go to sleep, as tel-conference starts
> 
> from
> Tuesday morning at 6:00 AM in Japan)
> 
> Thank you, best regard.
> --------------------------------------------
> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
> 
> -----Original Message-----
> From:	Fumio Nagasaka [SMTP:fumiona@venus.dtinet.or.jp]
> Sent:	Saturday, December 13, 1997 10:46 AM
> To:	'Randy Turner'
> Cc:	'brianb@vcd.hp.com'; 'alan_berkema@hp.com'; 
> 'brianb@hp-vcd.vcd.hp.com'; 'gregory_leclair@erc.epson.com'; 
> 'shimura@pure.cpdc.canon.co.jp'; 'Greg Shue'
> Subject:	RE: TEL-Conference
> 
> Hi Randy,
> 
> We ware discussing some points through e-mail. I was so sorry, I 
> forgot who
> was the organizer for this telephone conference. Thus I sent e-mail to
> 
> several
> persons who I expect to be a correct person.
> 
> At 01:53 AM 12/13/97 +0900, Fumio Nagasaka wrote:
> >Hi there,
> >
> >May I confirm schedule and phone number for the tel-conference
> >on December 15 at 4:00 PM?
> >Do I need to make a phone-call to your phone number? Or can I
> >wait your phone call in my office?
> --------------------------------------------
> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
> 
> -----Original Message-----
> From:	Greg Shue [SMTP:gregs@sdd.hp.com]
> Sent:	Saturday, December 13, 1997 9:08 AM
> To:	Fumio Nagasaka
> Cc:	gregs@sdd.hp.com; brianb@vcd.hp.com; alan_berkema@hp.com; 
> brianb@hp-vcd.vcd.hp.com; gregory_leclair@erc.epson.com; 
> shimura@pure.cpdc.canon.co.jp
> Subject:	Re: TEL-Conference
> 
> > Greg writes;
> > >Personally, I prefer putting the 1284.4 command packet within the
> > >data block of the ORB.  This means that the CDB needs to contain
> > >the commands that:
> > >  SENDMSG (?) - transfer all data to the target
> > >  RECEIVEMSG (?) - receive <= blocksize bytes from the target (msg 
> > boundary)
> > >  RECEIVEBLOCK (?) - receive exactly blocksize bytes from the 
> target
> >
> > The direction bit in a "Normal command block ORB" shall specify 
> read/write
> > direction from the initiator. These commands seem to have some 
> redundancy.
> > Greg do you have any special reason to have these commands ?
> 
> I have no special reason other than to distinguish the RECEIVEMSG
> request from the RECEIVEBLOCK request.  Even that may not matter.
> 
> Looking at the Simple Hrd Disk Drive Profile, they support the
> following (SCSI) commands:
> 
>   MODE_SELECT (10)
>   MODE_SENSE  (10)
>   READ        (10)
>   START/STOP UNIT
>   SYNCHONIZE CACHE
>   TEST UNIT READY
>   WRITE       (10)
>   WRITE AND VERIFY (10)
>   WRITE BUFFER, Mode (101b) (Download Microcode and Save)
> 
> As for a general protocol, I can see value in specifying Read
> and Write commands simply to reserve space for other commands
> we might want for testability or general functionality.  Or, if
> we need to specify a command which has both a data payload for
> each direction.  (Yes, I know this is the infamous bi-di ORB
> which was rejected as a standard part of SBP-2.  I have no idea
> how or why we would use something like that, but I would not
> want to preclude it's availability).
> 
> 
> > I suppose we can discuss through the e-mail. Thus we don't need to 
> have
> > telephone conference. Alan, could you please inform us your plan?
> 
> Now that there is some discussion going on, I would prefer to keep it
> in e-mail.
> 
> > -------------------------------
> > Fumio Nagasaka
> --
> Greg Shue
> Hewlett-Packard Company
> Office Products Division			gregs@sdd.hp.com
> ----------------------------------------------------------------

From gregs at sdd.hp.com  Mon Dec 15 14:04:25 1997
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:46 2009
Subject: P1394> RE: TEL-Conference
In-Reply-To: <D10983CAC30DD111B41400805FA6A1C1026D96@admsrvnt02.enet.sharplabs.com>
Message-ID: <199712151904.LAA11997@hpsdlgj1.sdd.hp.com>

"See my comments below..."  :-)


-- Greg S.


> See my comments below...
> 
> Randy
> 
> > -----Original Message-----
> > From:	Nagasaka Fumio [SMTP:Nagasaka.Fumio@exc.epson.co.jp]
> > Sent:	Monday, December 15, 1997 3:13 AM
> > To:	'p1394@pwg.org'
> > Cc:	'brianb@vcd.hp.com'; 'alan_berkema@hp.com';
> > 'brianb@hp-vcd.vcd.hp.com'; 'gregory_leclair@erc.epson.com';
> > 'shimura@pure.cpdc.canon.co.jp'; 'Greg Shue'; 'Randy Turner'
> > Subject:	P1394> RE: TEL-Conference
> > 
> > I'm sorry for inconvenience for multiple copy of this mail through the
> > 
> > mailing list.
> > 
> > I have some comments for PWG-printing profile.
> > 
> > 1. Login/Logout
> > 
> > Some consumer operating systems invoke "login" at boot time, and never
> > 
> > logout
> > until shut down. This scheme was designed intended to support SBP-2 
> > HDD as
> > a boot device. However this scheme is not smart to support PWG 
> > printer.
> 	[Turner, Randy]  I agree, automatic login at boot time should
> not be
> 	required to support printing. But plug'n play may require this
> feature,
> 	and its not clear whether or not this causes a problem yet for
> 1284.4
> 	printing. 


A similar issue may still exist:


  Does PnP of 1284.4 devices automatically open a channel at
  boot time to all the services found?


No matter what, we need to define the policy and behavior of the
initiator when more initiators are trying to interact with our device
than the our device has resources to support.


  Exactly which initiators don't get access to the device?
  Does this policy give the customer a predictable mapping?




> > May be, "login" and "logout" shall be associated with DL_register and 
> > DL_unrgister.
> > Thus I feel PWG-profile shall specify the timing for login/logout. 
> > These facilities
> > ought to be implemented in Data Link stuff 
> > (DL_register/DL_unregister).
> 	[Turner, Randy]  I like this idea. The DL_register and
> DL_unregister
> 	entry points for the 1394-based DL would translate these calls
> 	into login and logout calls. It seems to make sense for how
> these
> 	entry points were originally designed to work. 


So how does this fit in with "transient cable disruptions"
which last more than 1 second?  What takes care of the disruptions?


> 
> > 2. Login waiting time
> > 
> > IEEE 1394 provides network-like platform for PCs.
> > 
> > -	PC A is printing a document using Printer X.
> > -	PC B is waiting to start printing while 10 seconds.
> > -	PC C is waiting to start printing while 10 minutes.
> > 
> > Then PC C shall be allowed to start printing session earlier than PC 
> > B.
> > I felt current PWG protocol stack does not provide any answer to solve
> > 
> > this issue.
> > Because PC B or PC C may invoke login while PC A is printing. When PC 
> > A
> > is printing, the data channel shall be busy, so IEEE 1284.4 transport 
> > replies busy
> > status if PC B or PC C try to open this channel. But after PC A closed
> > 
> > this
> > data channel, IEEE 1284.4 allows a PC which ever calls OpenChannel 
> > earlier than
> > other PC to open this data channel.


> 	[Turner, Randy]  The description of this "problem" is really an
> 	implementation issue. This scenario says that the 1284.4
> 	printer would return "busy" if an OpenChannel was attempted
> 	while the printer was printing over a previously opened
> 	connection. However, the printer may elect to accept an
> 	OpenChannel from as many potential clients as possible,
> 	and only accept data from the first connection. The other
> 	open channels would be processed in some order, as
> 	each printing session completes. The other connections would
> 	be flow controlled until the printer is ready to accept 
> 	data on each channel.
> 
> 	Basically, the policy that is used for printing arbitration
> 	is not defined by 1284.4. It is defined by the application
> 	using the 1284.4 transport. Therefore, I don't think the
> 	proposal for an OpenChannel_solicitation is necessary.
> 	If this type of functionality is needed, it would be an
> 	application function, not a transport function.
> 
> 	Randy


Randy's reasoning sounds good.  The more I think about it, though,
the more I think the device sharing solution goes beyond our control.
PC A may have 10 more jobs in it's spooler that are 3 hours old, and
PC C's job may be only 10 minutes old.  We don't have enough knowledge
to make a completely fair choice from the users' perspective.


The application can determine policy for arbitrating between all the
requests it can maintain at once, but we have to define (or acknowledge)
what happens when it the application refuses additional requests.




> > To solve this problem, we need to introduce "OpenChannel_solicitation"
> > 
> > which is
> > an unsolicited status to inform PC C that PC A closed printing session
> > 
> > and now you
> > may call OpenChannel.
> > 
> > Alan's document is describing two "status_code" shown below,...
> > 0x01	data transfer complete
> > 0x02	target to initiator transfer request
> > 
> > I would like to suggest third "status_code",
> > 0x03	target allows initiator to open 1284.4 data channel
> > 
> > PC C may login at any time, however while PC A is printing PC C is 
> > not
> > allowed to use same data channel with PC A. The target device allows
> > the initiator which invokes "login" earlier than other initiator, to 
> > open data
> > channel, after previous data session had been closed.
> > 
> > And may be we need to provide other message to say,
> > __ttt__	initiator allows target to open channel
> > As you know this function shall be provided utilizing ORB, because it 
> > might
> > be a solicitation from an initiator to the specified target. Then can 
> > PWG profile
> > use normal command block ORB?
> > 
> > Someone, could you kindly suggest tel-conference agenda if you have 
> > spare
> > time in Monday morning? ( I will go to sleep, as tel-conference starts
> > 
> > from
> > Tuesday morning at 6:00 AM in Japan)
> > 
> > Thank you, best regard.
> > --------------------------------------------
> > -------------------------------
> > Fumio Nagasaka
> > Epson Software Development Laboratory Inc.
> > Tel +81 268 25 4111,  Fax +81 268 25 4627
> > E-mail to nagasaka.fumio@exc.epson.co.jp
> > 

-- 
Greg Shue
Hewlett-Packard Company
Office Products Division			gregs@sdd.hp.com
----------------------------------------------------------------


From rturner at sharplabs.com  Mon Dec 15 14:33:25 1997
From: rturner at sharplabs.com (Turner, Randy)
Date: Wed May  6 14:00:46 2009
Subject: P1394> RE: TEL-Conference
Message-ID: <199712151904.LAA11997@hpsdlgj1.sdd.hp.com>

See my comments to your comments....;)


Randy


> -----Original Message-----
> From:	Greg Shue [SMTP:gregs@sdd.hp.com]
> Sent:	Monday, December 15, 1997 11:04 AM
> To:	rturner@sharplabs.com
> Cc:	Nagasaka.Fumio@exc.epson.co.jp; p1394@pwg.org;
> brianb@vcd.hp.com; alan_berkema@hp.com; brianb@hp-vcd.vcd.hp.com;
> gregory_leclair@erc.epson.com; shimura@pure.cpdc.canon.co.jp;
> gregs@sdd.hp.com; rturner@sharplabs.com
> Subject:	Re: P1394> RE: TEL-Conference
> 
> 
> "See my comments below..."  :-)
> 
> -- Greg S.
> 
> > See my comments below...
> > 
> > Randy
> > 
> > > -----Original Message-----
> > > From:	Nagasaka Fumio [SMTP:Nagasaka.Fumio@exc.epson.co.jp]
> > > Sent:	Monday, December 15, 1997 3:13 AM
> > > To:	'p1394@pwg.org'
> > > Cc:	'brianb@vcd.hp.com'; 'alan_berkema@hp.com';
> > > 'brianb@hp-vcd.vcd.hp.com'; 'gregory_leclair@erc.epson.com';
> > > 'shimura@pure.cpdc.canon.co.jp'; 'Greg Shue'; 'Randy Turner'
> > > Subject:	P1394> RE: TEL-Conference
> > > 
> > > I'm sorry for inconvenience for multiple copy of this mail through
> the
> > > 
> > > mailing list.
> > > 
> > > I have some comments for PWG-printing profile.
> > > 
> > > 1. Login/Logout
> > > 
> > > Some consumer operating systems invoke "login" at boot time, and
> never
> > > 
> > > logout
> > > until shut down. This scheme was designed intended to support
> SBP-2 
> > > HDD as
> > > a boot device. However this scheme is not smart to support PWG 
> > > printer.
> > 	[Turner, Randy]  I agree, automatic login at boot time should
> > not be
> > 	required to support printing. But plug'n play may require this
> > feature,
> > 	and its not clear whether or not this causes a problem yet for
> > 1284.4
> > 	printing. 
> 
> A similar issue may still exist:
> 
>   Does PnP of 1284.4 devices automatically open a channel at
>   boot time to all the services found?
> 
> No matter what, we need to define the policy and behavior of the
> initiator when more initiators are trying to interact with our device
> than the our device has resources to support.
> 
>   Exactly which initiators don't get access to the device?
>   Does this policy give the customer a predictable mapping?
	[Turner, Randy]  
	[Turner, Randy]   
	In either case, I think this is an application issue. I do agree


	however, that performing PnP of 1284.4 devices would be
	a bad implementation for potential clients, but it would not
	impact a server's ability to handle multiple inbound
	connections, at least as far as the 1284.4 layer is concerned.






> > > May be, "login" and "logout" shall be associated with DL_register
> and 
> > > DL_unrgister.
> > > Thus I feel PWG-profile shall specify the timing for login/logout.
> 
> > > These facilities
> > > ought to be implemented in Data Link stuff 
> > > (DL_register/DL_unregister).
> > 	[Turner, Randy]  I like this idea. The DL_register and
> > DL_unregister
> > 	entry points for the 1394-based DL would translate these calls
> > 	into login and logout calls. It seems to make sense for how
> > these
> > 	entry points were originally designed to work. 
> 
> So how does this fit in with "transient cable disruptions"
> which last more than 1 second?  What takes care of the disruptions?
	[Turner, Randy]  


	Any link-specific error conditions should be transmitted to
	link-layer clients through the DL_INDICATION or DL_NOTIFY
	type of entry point. It is up to the link-specific code to
	determine whether or not a particular link-layer event should
	cause any or all connections over a particular link to be
	closed.






> > 
> > > 2. Login waiting time
> > > 
> > > IEEE 1394 provides network-like platform for PCs.
> > > 
> > > -	PC A is printing a document using Printer X.
> > > -	PC B is waiting to start printing while 10 seconds.
> > > -	PC C is waiting to start printing while 10 minutes.
> > > 
> > > Then PC C shall be allowed to start printing session earlier than
> PC 
> > > B.
> > > I felt current PWG protocol stack does not provide any answer to
> solve
> > > 
> > > this issue.
> > > Because PC B or PC C may invoke login while PC A is printing. When
> PC 
> > > A
> > > is printing, the data channel shall be busy, so IEEE 1284.4
> transport 
> > > replies busy
> > > status if PC B or PC C try to open this channel. But after PC A
> closed
> > > 
> > > this
> > > data channel, IEEE 1284.4 allows a PC which ever calls OpenChannel
> 
> > > earlier than
> > > other PC to open this data channel.
> 
> > 	[Turner, Randy]  The description of this "problem" is really an
> > 	implementation issue. This scenario says that the 1284.4
> > 	printer would return "busy" if an OpenChannel was attempted
> > 	while the printer was printing over a previously opened
> > 	connection. However, the printer may elect to accept an
> > 	OpenChannel from as many potential clients as possible,
> > 	and only accept data from the first connection. The other
> > 	open channels would be processed in some order, as
> > 	each printing session completes. The other connections would
> > 	be flow controlled until the printer is ready to accept 
> > 	data on each channel.
> > 
> > 	Basically, the policy that is used for printing arbitration
> > 	is not defined by 1284.4. It is defined by the application
> > 	using the 1284.4 transport. Therefore, I don't think the
> > 	proposal for an OpenChannel_solicitation is necessary.
> > 	If this type of functionality is needed, it would be an
> > 	application function, not a transport function.
> > 
> > 	Randy
> 
> Randy's reasoning sounds good.  The more I think about it, though,
> the more I think the device sharing solution goes beyond our control.
> PC A may have 10 more jobs in it's spooler that are 3 hours old, and
> PC C's job may be only 10 minutes old.  We don't have enough knowledge
> to make a completely fair choice from the users' perspective.
> 
> The application can determine policy for arbitrating between all the
> requests it can maintain at once, but we have to define (or
> acknowledge)
> what happens when it the application refuses additional requests.
	[Turner, Randy]  


	If we have to recognize application policy, then this would not
	be a normative part of a potential standard; rather, it would be
	included as a part of some informational appendix to a 
	document.


	Randy






> > > To solve this problem, we need to introduce
> "OpenChannel_solicitation"
> > > 
> > > which is
> > > an unsolicited status to inform PC C that PC A closed printing
> session
> > > 
> > > and now you
> > > may call OpenChannel.
> > > 
> > > Alan's document is describing two "status_code" shown below,...
> > > 0x01	data transfer complete
> > > 0x02	target to initiator transfer request
> > > 
> > > I would like to suggest third "status_code",
> > > 0x03	target allows initiator to open 1284.4 data channel
> > > 
> > > PC C may login at any time, however while PC A is printing PC C is
> 
> > > not
> > > allowed to use same data channel with PC A. The target device
> allows
> > > the initiator which invokes "login" earlier than other initiator,
> to 
> > > open data
> > > channel, after previous data session had been closed.
> > > 
> > > And may be we need to provide other message to say,
> > > __ttt__	initiator allows target to open channel
> > > As you know this function shall be provided utilizing ORB, because
> it 
> > > might
> > > be a solicitation from an initiator to the specified target. Then
> can 
> > > PWG profile
> > > use normal command block ORB?
> > > 
> > > Someone, could you kindly suggest tel-conference agenda if you
> have 
> > > spare
> > > time in Monday morning? ( I will go to sleep, as tel-conference
> starts
> > > 
> > > from
> > > Tuesday morning at 6:00 AM in Japan)
> > > 
> > > Thank you, best regard.
> > > --------------------------------------------
> > > -------------------------------
> > > Fumio Nagasaka
> > > Epson Software Development Laboratory Inc.
> > > Tel +81 268 25 4111,  Fax +81 268 25 4627
> > > E-mail to nagasaka.fumio@exc.epson.co.jp
> > > 
> -- 
> Greg Shue
> Hewlett-Packard Company
> Office Products Division			gregs@sdd.hp.com
> ----------------------------------------------------------------

From brianb at vcd.hp.com  Mon Dec 15 14:56:24 1997
From: brianb at vcd.hp.com (Brian Batchelder)
Date: Wed May  6 14:00:46 2009
Subject: P1394> RE: TEL-Conference
In-Reply-To: <199712151904.LAA11997@hpsdlgj1.sdd.hp.com>
Message-ID: <3.0.2.32.19971215115624.0096a100@popmail1.vcd.hp.com>

More comments...


Brian


At 11:04 AM 12/15/97 -0800, Greg Shue wrote:
>
>"See my comments below..."  :-)
>
>-- Greg S.
>
>> See my comments below...
>> 
>> Randy
>> 
>> > -----Original Message-----
>> > From:	Nagasaka Fumio [SMTP:Nagasaka.Fumio@exc.epson.co.jp]
>> > 1. Login/Logout
>> > 
>> > Some consumer operating systems invoke "login" at boot time, and never
>> > 
>> > logout
>> > until shut down. This scheme was designed intended to support SBP-2 
>> > HDD as
>> > a boot device. However this scheme is not smart to support PWG 
>> > printer.
>> 	[Turner, Randy]  I agree, automatic login at boot time should
>> not be
>> 	required to support printing. But plug'n play may require this
>> feature,
>> 	and its not clear whether or not this causes a problem yet for
>> 1284.4
>> 	printing. 
>
>A similar issue may still exist:
>
>  Does PnP of 1284.4 devices automatically open a channel at
>  boot time to all the services found?


[Brian] We don't want PnP to "bring-up" the I/O stack, except where
required to enumerate the devices, functions, services and the I/O stack
itself.  Once enumeration is complete, all I/O connections should be
closed.  Later, when the first application requests access to a service,
the appropriate I/O stack is loaded and a connection is established to the
device.  When all applications requesting access to services have
"completed" their work (whatever that means), the connections are closed.
We cannot allow PCs to dominate access to devices in the interconnected
world of 1394.


>No matter what, we need to define the policy and behavior of the
>initiator when more initiators are trying to interact with our device
>than the our device has resources to support.
>
>  Exactly which initiators don't get access to the device?
>  Does this policy give the customer a predictable mapping?


[Brian]The simplest way to implement this is as a FIFO.  Whoever asks first
gets access.  Note that the device MUST be released when the initiator has
finished using it.


>> > May be, "login" and "logout" shall be associated with DL_register and 
>> > DL_unrgister.
>> > Thus I feel PWG-profile shall specify the timing for login/logout. 
>> > These facilities
>> > ought to be implemented in Data Link stuff 
>> > (DL_register/DL_unregister).
>> 	[Turner, Randy]  I like this idea. The DL_register and
>> DL_unregister
>> 	entry points for the 1394-based DL would translate these calls
>> 	into login and logout calls. It seems to make sense for how
>> these
>> 	entry points were originally designed to work. 
>
>So how does this fit in with "transient cable disruptions"
>which last more than 1 second?  What takes care of the disruptions?


[Brian} The data link should hide all disruptions that we wish to make
transparent.  The transport should be notified when the link is disrupted
for a longer time.


>> > 2. Login waiting time
>> > 
>> > IEEE 1394 provides network-like platform for PCs.
>> > 
>> > -	PC A is printing a document using Printer X.
>> > -	PC B is waiting to start printing while 10 seconds.
>> > -	PC C is waiting to start printing while 10 minutes.
>> > 
>> > Then PC C shall be allowed to start printing session earlier than PC 
>> > B.
>> > I felt current PWG protocol stack does not provide any answer to solve
>> > 
>> > this issue.
>> > Because PC B or PC C may invoke login while PC A is printing. When PC 
>> > A
>> > is printing, the data channel shall be busy, so IEEE 1284.4 transport 
>> > replies busy
>> > status if PC B or PC C try to open this channel. But after PC A closed
>> > 
>> > this
>> > data channel, IEEE 1284.4 allows a PC which ever calls OpenChannel 
>> > earlier than
>> > other PC to open this data channel.
>
>> 	[Turner, Randy]  The description of this "problem" is really an
>> 	implementation issue. This scenario says that the 1284.4
>> 	printer would return "busy" if an OpenChannel was attempted
>> 	while the printer was printing over a previously opened
>> 	connection. However, the printer may elect to accept an
>> 	OpenChannel from as many potential clients as possible,
>> 	and only accept data from the first connection. The other
>> 	open channels would be processed in some order, as
>> 	each printing session completes. The other connections would
>> 	be flow controlled until the printer is ready to accept 
>> 	data on each channel.
>> 
>> 	Basically, the policy that is used for printing arbitration
>> 	is not defined by 1284.4. It is defined by the application
>> 	using the 1284.4 transport. Therefore, I don't think the
>> 	proposal for an OpenChannel_solicitation is necessary.
>> 	If this type of functionality is needed, it would be an
>> 	application function, not a transport function.
>> 
>> 	Randy
>
>Randy's reasoning sounds good.  The more I think about it, though,
>the more I think the device sharing solution goes beyond our control.
>PC A may have 10 more jobs in it's spooler that are 3 hours old, and
>PC C's job may be only 10 minutes old.  We don't have enough knowledge
>to make a completely fair choice from the users' perspective.
>
>The application can determine policy for arbitrating between all the
>requests it can maintain at once, but we have to define (or acknowledge)
>what happens when it the application refuses additional requests.


[Brian] I also like Randy's idea.  Our transport needs to be symmetric,
therefore it must have facilities that allow the server to switch between
clients.  How it decides to switch between them may be an implementation
issue or we may have to standardize some of it.  Isn't there a model in the
network world for this?  Shouldn't we look at that model?


Brian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder      | Hewlett-Packard      | mailto:brianb@vcd.hp.com  
Connectivity Futurist | 1115 SE 164th Ave.   | Phone: (360) 212-4107  
DeskJet Printers      | Vancouver, WA  98684 | Fax:   (360) 212-4227

From fumiona at venus.dtinet.or.jp  Mon Dec 15 15:55:48 1997
From: fumiona at venus.dtinet.or.jp (Fumio Nagasaka)
Date: Wed May  6 14:00:46 2009
Subject: P1394> RE: TEL-Conference
Message-ID: <3.0.2.32.19971215115624.0096a100@popmail1.vcd.hp.com>

> [Turner, Randy]  I agree, automatic login at boot time should not be
> required to support printing. But plug'n play may require this feature,
> and its not clear whether or not this causes a problem yet for 1284.4
> printing.


[Fumio Nagasaka] OS may read Configuration ROM to perform Plug & Play
steps. OS must enumerate any PC peripheral device, even if it speaks AV/C,
IP/1394 or IP/1394. Thus PnP shall be independent from transport layer.


--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


-----Original Message-----
From:	Turner, Randy [SMTP:rturner@sharplabs.com]
Sent:	Monday, December 15, 1997 11:28 PM
To:	'Nagasaka Fumio'; 'p1394@pwg.org'
Cc:	'brianb@vcd.hp.com'; 'alan_berkema@hp.com'; 'brianb@hp-vcd.vcd.hp.com'; 
'gregory_leclair@erc.epson.com'; 'shimura@pure.cpdc.canon.co.jp'; 'Greg 
Shue'; 'Randy Turner'
Subject:	RE: P1394> RE: TEL-Conference




See my comments below...


Randy


> -----Original Message-----
> From:	Nagasaka Fumio [SMTP:Nagasaka.Fumio@exc.epson.co.jp]
> Sent:	Monday, December 15, 1997 3:13 AM
> To:	'p1394@pwg.org'
> Cc:	'brianb@vcd.hp.com'; 'alan_berkema@hp.com';
> 'brianb@hp-vcd.vcd.hp.com'; 'gregory_leclair@erc.epson.com';
> 'shimura@pure.cpdc.canon.co.jp'; 'Greg Shue'; 'Randy Turner'
> Subject:	P1394> RE: TEL-Conference
>
> I'm sorry for inconvenience for multiple copy of this mail through the
>
> mailing list.
>
> I have some comments for PWG-printing profile.
>
> 1. Login/Logout
>
> Some consumer operating systems invoke "login" at boot time, and never
>
> logout
> until shut down. This scheme was designed intended to support SBP-2
> HDD as
> a boot device. However this scheme is not smart to support PWG
> printer.
	[Turner, Randy]  I agree, automatic login at boot time should
not be
	required to support printing. But plug'n play may require this
feature,
	and its not clear whether or not this causes a problem yet for
1284.4
	printing.




> Actually on a consumer PC operating system platform designed in north
> California,
> our driver may invoke "login" at any time.
>
> May be, "login" and "logout" shall be associated with DL_register and
> DL_unrgister.
> Thus I feel PWG-profile shall specify the timing for login/logout.
> These facilities
> ought to be implemented in Data Link stuff
> (DL_register/DL_unregister).
	[Turner, Randy]  I like this idea. The DL_register and
DL_unregister
	entry points for the 1394-based DL would translate these calls
	into login and logout calls. It seems to make sense for how
these
	entry points were originally designed to work.




> 2. Login waiting time
>
> IEEE 1394 provides network-like platform for PCs.
>
> -	PC A is printing a document using Printer X.
> -	PC B is waiting to start printing while 10 seconds.
> -	PC C is waiting to start printing while 10 minutes.
>
> Then PC C shall be allowed to start printing session earlier than PC
> B.
> I felt current PWG protocol stack does not provide any answer to solve
>
> this issue.
> Because PC B or PC C may invoke login while PC A is printing. When PC
> A
> is printing, the data channel shall be busy, so IEEE 1284.4 transport
> replies busy
> status if PC B or PC C try to open this channel. But after PC A closed
>
> this
> data channel, IEEE 1284.4 allows a PC which ever calls OpenChannel
> earlier than
> other PC to open this data channel.
	[Turner, Randy]  The description of this "problem" is really an
	implementation issue. This scenario says that the 1284.4
	printer would return "busy" if an OpenChannel was attempted
	while the printer was printing over a previously opened
	connection. However, the printer may elect to accept an
	OpenChannel from as many potential clients as possible,
	and only accept data from the first connection. The other
	open channels would be processed in some order, as
	each printing session completes. The other connections would
	be flow controlled until the printer is ready to accept
	data on each channel.


	Basically, the policy that is used for printing arbitration
	is not defined by 1284.4. It is defined by the application
	using the 1284.4 transport. Therefore, I don't think the
	proposal for an OpenChannel_solicitation is necessary.
	If this type of functionality is needed, it would be an
	application function, not a transport function.


	Randy


> To solve this problem, we need to introduce "OpenChannel_solicitation"
>
> which is
> an unsolicited status to inform PC C that PC A closed printing session
>
> and now you
> may call OpenChannel.
>
> Alan's document is describing two "status_code" shown below,...
> 0x01	data transfer complete
> 0x02	target to initiator transfer request
>
> I would like to suggest third "status_code",
> 0x03	target allows initiator to open 1284.4 data channel
>
> PC C may login at any time, however while PC A is printing PC C is
> not
> allowed to use same data channel with PC A. The target device allows
> the initiator which invokes "login" earlier than other initiator, to
> open data
> channel, after previous data session had been closed.
>
> And may be we need to provide other message to say,
> __ttt__	initiator allows target to open channel
> As you know this function shall be provided utilizing ORB, because it
> might
> be a solicitation from an initiator to the specified target. Then can
> PWG profile
> use normal command block ORB?
>
> Someone, could you kindly suggest tel-conference agenda if you have
> spare
> time in Monday morning? ( I will go to sleep, as tel-conference starts
>
> from
> Tuesday morning at 6:00 AM in Japan)
>
> Thank you, best regard.
> --------------------------------------------
> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
>
> -----Original Message-----
> From:	Fumio Nagasaka [SMTP:fumiona@venus.dtinet.or.jp]
> Sent:	Saturday, December 13, 1997 10:46 AM
> To:	'Randy Turner'
> Cc:	'brianb@vcd.hp.com'; 'alan_berkema@hp.com';
> 'brianb@hp-vcd.vcd.hp.com'; 'gregory_leclair@erc.epson.com';
> 'shimura@pure.cpdc.canon.co.jp'; 'Greg Shue'
> Subject:	RE: TEL-Conference
>
> Hi Randy,
>
> We ware discussing some points through e-mail. I was so sorry, I
> forgot who
> was the organizer for this telephone conference. Thus I sent e-mail to
>
> several
> persons who I expect to be a correct person.
>
> At 01:53 AM 12/13/97 +0900, Fumio Nagasaka wrote:
> >Hi there,
> >
> >May I confirm schedule and phone number for the tel-conference
> >on December 15 at 4:00 PM?
> >Do I need to make a phone-call to your phone number? Or can I
> >wait your phone call in my office?
> --------------------------------------------
> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111,  Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
>
> -----Original Message-----
> From:	Greg Shue [SMTP:gregs@sdd.hp.com]
> Sent:	Saturday, December 13, 1997 9:08 AM
> To:	Fumio Nagasaka
> Cc:	gregs@sdd.hp.com; brianb@vcd.hp.com; alan_berkema@hp.com;
> brianb@hp-vcd.vcd.hp.com; gregory_leclair@erc.epson.com;
> shimura@pure.cpdc.canon.co.jp
> Subject:	Re: TEL-Conference
>
> > Greg writes;
> > >Personally, I prefer putting the 1284.4 command packet within the
> > >data block of the ORB.  This means that the CDB needs to contain
> > >the commands that:
> > >  SENDMSG (?) - transfer all data to the target
> > >  RECEIVEMSG (?) - receive <= blocksize bytes from the target (msg
> > boundary)
> > >  RECEIVEBLOCK (?) - receive exactly blocksize bytes from the
> target
> >
> > The direction bit in a "Normal command block ORB" shall specify
> read/write
> > direction from the initiator. These commands seem to have some
> redundancy.
> > Greg do you have any special reason to have these commands ?
>
> I have no special reason other than to distinguish the RECEIVEMSG
> request from the RECEIVEBLOCK request.  Even that may not matter.
>
> Looking at the Simple Hrd Disk Drive Profile, they support the
> following (SCSI) commands:
>
>   MODE_SELECT (10)
>   MODE_SENSE  (10)
>   READ        (10)
>   START/STOP UNIT
>   SYNCHONIZE CACHE
>   TEST UNIT READY
>   WRITE       (10)
>   WRITE AND VERIFY (10)
>   WRITE BUFFER, Mode (101b) (Download Microcode and Save)
>
> As for a general protocol, I can see value in specifying Read
> and Write commands simply to reserve space for other commands
> we might want for testability or general functionality.  Or, if
> we need to specify a command which has both a data payload for
> each direction.  (Yes, I know this is the infamous bi-di ORB
> which was rejected as a standard part of SBP-2.  I have no idea
> how or why we would use something like that, but I would not
> want to preclude it's availability).
>
>
> > I suppose we can discuss through the e-mail. Thus we don't need to
> have
> > telephone conference. Alan, could you please inform us your plan?
>
> Now that there is some discussion going on, I would prefer to keep it
> in e-mail.
>
> > -------------------------------
> > Fumio Nagasaka
> --
> Greg Shue
> Hewlett-Packard Company
> Office Products Division			gregs@sdd.hp.com
> ----------------------------------------------------------------

From atsnaka at bsd.canon.co.jp  Wed Dec 17 04:22:02 1997
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:46 2009
Subject: P1394> PWG printer profile impression
Message-ID: <199712170904.SAA17123@bsdmail.bsd.canon.co.jp>

I have been reviewing the PWG printing profile,and 
also was fortunate to hear a little about the 
discussion that went on in the telephone
conference.


I think the work is becoming productive,and that is good.
However,I do have one concern about the scope of the profile (spec.)


It is written in the PWG profile document that the profile
document:


 "will provide requirements for the implementation of IEEE1394
 communications for printers, scanners, digital still cameras,
 and other imageing devices.
 Communications will include traditional computer host to
 these devices AS WELL AS DIRECT PEER TO PEER COMMUNICATION"


The scope, excluding 1284.4 overlaps with the direct print protocol
work done in PWG-C. 


Of course it would be an ideal solution if only 1 protocol
exists in the 1394 printing world, which covers ANY printing
application, and I assume everyone has persued this idea 
in the beginning.
However, the reality is that the priority of requirements
differ among printing applications (PC printing, direct printing)
and some protocol features which are necessary in 1 solution
may not be needed in others.


Coming up with 1 printing profile wich covers both PC printing
and direct printing may be a difficult task, and may end up as
an incomplete solution for both printing applications.
One example may be connection-less service. "IF" it is decided that
the PC printing solution does not need this feature, I do not feel
it is necessary to keep it just to support an incomplete direct-print. 
(I'm not saying that PC printing doesn't need connection-less. )


I think the concensus we had till a while ago ,that 
there would be a "thick" stack and a "thin" stack still lives.
The idea was that there may(will) be more than 1 stack for printers,
and FDS is intended to be a solution to "tie" the physical
functionality, "the printer" whatever the stack may be. 


The current activity, that PWG works on an ideal PC 
printing solution (PWG profile) while the PWG-C works on an
ideal direct print solution (Direct-print protocol)is a
very realistic idea.
The first priority for both groups is for each to come up with 
a good solution for their initial scope,
and don't become too generic from the beginning.




"Should the PWG profile proposal be considered as a 
 counter-proposal to the PWG-C Direct-Print Protocol
 proposal?"    


I think it is very good work, and hope to participate in it,
but I was just curious that PWG and PWG-C may be working on
2 of the same things. 


FYI: The direct-print market in Japan, though not as big as   
     the PC printer market is an area that cannot be ignored,
     with direct print capable printers from Panasonic, Casio,
     Epson,Sharp and most digital camera vendors. 
     Direct printing is somewhat a trend in Japan,becoming more
     than a niche market.
     I think this comes from the difference in the number of PCs
     inside the homes, between the US and Japan. 




















 


-----------------------------------------
Atsushi Nakamura
-----------------------------------------
**************!! NOTICE !!*****************
*TEL,FAX,and EMAIL(2) has changed         * 
*from Sept.8,1997                         *
*******************************************


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):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------

From rturner at sharplabs.com  Wed Dec 17 09:12:59 1997
From: rturner at sharplabs.com (Randy Turner)
Date: Wed May  6 14:00:46 2009
Subject: P1394> PWG printer profile impression
In-Reply-To: <P1394> PWG printer profile impression>
Message-ID: <199712170904.SAA17123@bsdmail.bsd.canon.co.jp>

To my knowledge, we haven't talked about
application layer protocols yet (printing or
anything else). I don't think we know how
"thick" or "thin" the printing profile
document will be. Until we specify the
application layer, we don't have an
interoperable specification for any
application.


I *do* think that what we have specified
so far could easily be employed by any
1394 device, no matter how small and
simple. But there is much work to be done.


Randy




Atsushi_Nakamura wrote:
> 
> I have been reviewing the PWG printing profile,and
> also was fortunate to hear a little about the
> discussion that went on in the telephone
> conference.
> 
> I think the work is becoming productive,and that is good.
> However,I do have one concern about the scope of the profile (spec.)
> 
> It is written in the PWG profile document that the profile
> document:
> 
>  "will provide requirements for the implementation of IEEE1394
>  communications for printers, scanners, digital still cameras,
>  and other imageing devices.
>  Communications will include traditional computer host to
>  these devices AS WELL AS DIRECT PEER TO PEER COMMUNICATION"
> 
> The scope, excluding 1284.4 overlaps with the direct print protocol
> work done in PWG-C.
> 
> Of course it would be an ideal solution if only 1 protocol
> exists in the 1394 printing world, which covers ANY printing
> application, and I assume everyone has persued this idea
> in the beginning.
> However, the reality is that the priority of requirements
> differ among printing applications (PC printing, direct printing)
> and some protocol features which are necessary in 1 solution
> may not be needed in others.
> 
> Coming up with 1 printing profile wich covers both PC printing
> and direct printing may be a difficult task, and may end up as
> an incomplete solution for both printing applications.
> One example may be connection-less service. "IF" it is decided that
> the PC printing solution does not need this feature, I do not feel
> it is necessary to keep it just to support an incomplete direct-print.
> (I'm not saying that PC printing doesn't need connection-less. )
> 
> I think the concensus we had till a while ago ,that
> there would be a "thick" stack and a "thin" stack still lives.
> The idea was that there may(will) be more than 1 stack for printers,
> and FDS is intended to be a solution to "tie" the physical
> functionality, "the printer" whatever the stack may be.
> 
> The current activity, that PWG works on an ideal PC
> printing solution (PWG profile) while the PWG-C works on an
> ideal direct print solution (Direct-print protocol)is a
> very realistic idea.
> The first priority for both groups is for each to come up with
> a good solution for their initial scope,
> and don't become too generic from the beginning.
> 
> >From this point of view, my frank question would be;
> 
> "Should the PWG profile proposal be considered as a
>  counter-proposal to the PWG-C Direct-Print Protocol
>  proposal?"
> 
> I think it is very good work, and hope to participate in it,
> but I was just curious that PWG and PWG-C may be working on
> 2 of the same things.
> 
> FYI: The direct-print market in Japan, though not as big as
>      the PC printer market is an area that cannot be ignored,
>      with direct print capable printers from Panasonic, Casio,
>      Epson,Sharp and most digital camera vendors.
>      Direct printing is somewhat a trend in Japan,becoming more
>      than a niche market.
>      I think this comes from the difference in the number of PCs
>      inside the homes, between the US and Japan.
> 
> 
> 
> -----------------------------------------
> Atsushi Nakamura
> -----------------------------------------
> **************!! NOTICE !!*****************
> *TEL,FAX,and EMAIL(2) has changed         *
> *from Sept.8,1997                         *
> *******************************************
> 
> 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):Atsushi_Nakamura@cbj.canon.co.jp
> email(2):atsnaka@bsd.canon.co.jp
> -----------------------------------------

From erik at hp-vcd.vcd.hp.com  Wed Dec 17 11:27:14 1997
From: erik at hp-vcd.vcd.hp.com (Erik Kilk)
Date: Wed May  6 14:00:46 2009
Subject: P1394> Someone, please remove me from this list.
Message-ID: <l0311070db0bdacf2594a@[15.7.74.44]>

Sorry for this message, but I've been trying
unsuccessfully to remove my name from this
distribution list for several months. Several of you
have helped -- but so far nothing has worked.


Again, PLEASE, could someone who can administer this
list remove my name from whatever file it must be in. None of the automatic
methods have worked.


Thanks,


Erik Kilk


erik@hp-vcd.vcd.hp.com

From atsnaka at bsd.canon.co.jp  Wed Dec 17 20:02:18 1997
From: atsnaka at bsd.canon.co.jp (Atsushi_Nakamura)
Date: Wed May  6 14:00:46 2009
Subject: P1394> PWG printer profile impression
In-Reply-To: <P1394> PWG printer profile impression>
Message-ID: <199712180044.JAA22912@bsdmail.bsd.canon.co.jp>

I apologize that I may not have made my point clear.
I also apologize that I am thinking out loud.


I understand that the application layer protocols
have not been spoken about.
 
My understanding (and from the document),
the printer profile document
proposes using SBP-2 for "image communication",
and the current discussion is 
about a "glue" to interface SBP-2 and whatever layer
comes above it ( which 1 of them is 1284.4.)


Of course the "glue" itself may be easy to 
employ,
but by saying that this glue will be
generic (not just for 1284.4 interfacing)
and applied to all printers,
you are stating that all printing shall use SBP-2.


This discussion had been going on for a while,    
but the current PWG-C proposal
(which defines the transport, as well as application
protocols).
has decided NOT to use SBP-2 for direct-print,


This is why I(PWG-C) am concerned about the scope of 
this "glue"(and profile), and PWG-C work.
I just wanted to clarify the relationship between 
PWG work and PWG-C work


> I *do* think that what we have specified
> so far could easily be employed by any
> 1394 device, no matter how small and
> simple. But there is much work to be done


I may be missing something, but my understanding
is the only things specified (proposed)
so far (from the document and discussion)
is usage of SBP-2, the need to define contents of 
the CDB, and that this CDB should be generic.
(not 1284.4 specific) 


While speaking about CDBs,
once the CDB definition become generic,
there wil have to be some mechanism to distingush
the layer above it.


1) decoding a defined header at the beginning of the CDB
2) preparing differnt login entry points for each session
others....


If the CDB definition is 1284.4 specific, of course
it will not be necessary.
Does this "glue" really need to support anything 
other than 1284.4 ?


Am I missing something ?


Ats


At 06:12 97/12/17 -0800, you wrote:
> To my knowledge, we haven't talked about
> application layer protocols yet (printing or
> anything else). I don't think we know how
> "thick" or "thin" the printing profile
> document will be. Until we specify the
> application layer, we don't have an
> interoperable specification for any
> application.
> 
> I *do* think that what we have specified
> so far could easily be employed by any
> 1394 device, no matter how small and
> simple. But there is much work to be done.
> 
> Randy
> 
> 
> Atsushi_Nakamura wrote:
> > 
> > I have been reviewing the PWG printing profile,and
> > also was fortunate to hear a little about the
> > discussion that went on in the telephone
> > conference.
> > 
> > I think the work is becoming productive,and that is good.
> > However,I do have one concern about the scope of the profile (spec.)
> > 
> > It is written in the PWG profile document that the profile
> > document:
> > 
> >  "will provide requirements for the implementation of IEEE1394
> >  communications for printers, scanners, digital still cameras,
> >  and other imageing devices.
> >  Communications will include traditional computer host to
> >  these devices AS WELL AS DIRECT PEER TO PEER COMMUNICATION"
> > 
> > The scope, excluding 1284.4 overlaps with the direct print protocol
> > work done in PWG-C.
> > 
> > Of course it would be an ideal solution if only 1 protocol
> > exists in the 1394 printing world, which covers ANY printing
> > application, and I assume everyone has persued this idea
> > in the beginning.
> > However, the reality is that the priority of requirements
> > differ among printing applications (PC printing, direct printing)
> > and some protocol features which are necessary in 1 solution
> > may not be needed in others.
> > 
> > Coming up with 1 printing profile wich covers both PC printing
> > and direct printing may be a difficult task, and may end up as
> > an incomplete solution for both printing applications.
> > One example may be connection-less service. "IF" it is decided that
> > the PC printing solution does not need this feature, I do not feel
> > it is necessary to keep it just to support an incomplete direct-print.
> > (I'm not saying that PC printing doesn't need connection-less. )
> > 
> > I think the concensus we had till a while ago ,that
> > there would be a "thick" stack and a "thin" stack still lives.
> > The idea was that there may(will) be more than 1 stack for printers,
> > and FDS is intended to be a solution to "tie" the physical
> > functionality, "the printer" whatever the stack may be.
> > 
> > The current activity, that PWG works on an ideal PC
> > printing solution (PWG profile) while the PWG-C works on an
> > ideal direct print solution (Direct-print protocol)is a
> > very realistic idea.
> > The first priority for both groups is for each to come up with
> > a good solution for their initial scope,
> > and don't become too generic from the beginning.
> > 
> > >From this point of view, my frank question would be;
> > 
> > "Should the PWG profile proposal be considered as a
> >  counter-proposal to the PWG-C Direct-Print Protocol
> >  proposal?"
> > 
> > I think it is very good work, and hope to participate in it,
> > but I was just curious that PWG and PWG-C may be working on
> > 2 of the same things.
> > 
> > FYI: The direct-print market in Japan, though not as big as
> >      the PC printer market is an area that cannot be ignored,
> >      with direct print capable printers from Panasonic, Casio,
> >      Epson,Sharp and most digital camera vendors.
> >      Direct printing is somewhat a trend in Japan,becoming more
> >      than a niche market.
> >      I think this comes from the difference in the number of PCs
> >      inside the homes, between the US and Japan.
> > 
> > 
> > 
> > -----------------------------------------
> > Atsushi Nakamura
> > -----------------------------------------
> > **************!! NOTICE !!*****************
> > *TEL,FAX,and EMAIL(2) has changed         *
> > *from Sept.8,1997                         *
> > *******************************************
> > 
> > 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):Atsushi_Nakamura@cbj.canon.co.jp
> > email(2):atsnaka@bsd.canon.co.jp
> > -----------------------------------------
> 
> 


-----------------------------------------
Atsushi Nakamura
-----------------------------------------
**************!! NOTICE !!*****************
*TEL,FAX,and EMAIL(2) has changed         * 
*from Sept.8,1997                         *
*******************************************


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):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------

From gregs at sdd.hp.com  Wed Dec 17 20:01:30 1997
From: gregs at sdd.hp.com (Greg Shue)
Date: Wed May  6 14:00:46 2009
Subject: P1394> PWG printer profile impression
In-Reply-To: <199712180044.JAA22912@bsdmail.bsd.canon.co.jp>
Message-ID: <199712180101.RAA16592@hpsdlgj1.sdd.hp.com>

Ats says:
> This is why I(PWG-C) am concerned about the scope of 
> this "glue"(and profile), and PWG-C work.
> I just wanted to clarify the relationship between 
> PWG work and PWG-C work
> 
> > I *do* think that what we have specified
> > so far could easily be employed by any
> > 1394 device, no matter how small and
> > simple. But there is much work to be done
> 
> I may be missing something, but my understanding
> is the only things specified (proposed)
> so far (from the document and discussion)
> is usage of SBP-2, the need to define contents of 
> the CDB, and that this CDB should be generic.
> (not 1284.4 specific) 


[Greg S]
I don't think you are missing anything.
I also think you have a valid concern.
The decision was already made that the PWG 1394 subcommittee
would not try to solve the direct-print protocol,
but that it would be left to the PWG-C.


Randy's observation about weight of what is defined
so far may be valid.  With respect to what to use
for the direct-print protocol, though, it is
simply an option which the PWG-C has available
to them.


Ats says:
> While speaking about CDBs,
> once the CDB definition become generic,
> there wil have to be some mechanism to distingush
> the layer above it.
> 
> 1) decoding a defined header at the beginning of the CDB
> 2) preparing differnt login entry points for each session
> others....


[Greg S]
Yes, The decoding is routing information to go to the appropriate
transport.


On the phone conference we have already defined that
each transport stack requires it's own (data-link layer) login.
I'm not sure whether that applies to each instance of a
transport protocol, or simply to each type of transport
protocol.


> If the CDB definition is 1284.4 specific, of course
> it will not be necessary.
> Does this "glue" really need to support anything 
> other than 1284.4 ?


[Greg S]
It's not required to support anything else at this point,
but further discussion is needed to understand the need
behind a connectionless transport.  If a connectionless
transport were built upon the same SBP-2 behavior, then
routing would be needed.


> Am I missing something ?
> 
> Ats



-- 
Greg Shue
Hewlett-Packard Company
Office Products Division			gregs@sdd.hp.com
----------------------------------------------------------------


From Nagasaka.Fumio at exc.epson.co.jp  Tue Dec 23 07:09:06 1997
From: Nagasaka.Fumio at exc.epson.co.jp (Nagasaka Fumio)
Date: Wed May  6 14:00:46 2009
Subject: P1394> PWG printer profile impression
Message-ID: <199712180101.RAA16592@hpsdlgj1.sdd.hp.com>

Atsushi writes:
> you are stating that all printing shall use SBP-2.


In this case
..... "all 1394 PWG-profile supportive printer shall use SBP-2" , ...
might be suitable. However I think terminology issue is less prior 
than
frame work for 1394 printing protocol itself. I personally think that
PWG-C profile supportive printer does not speak SBP-2 is also good
solution.


I also think 1394/SBP-2 storage profile supportive image scanner/fax 
may
talk to SBP-2 target capable printer directly. This could be also 
"direct-print".
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp


-----Original Message-----
From:	Atsushi_Nakamura [SMTP:atsnaka@bsd.canon.co.jp]
Sent:	Thursday, December 18, 1997 10:02 AM
To:	Randy Turner
Cc:	P1394@pwg.org; shinoda@bsd.canon.co.jp
Subject:	Re: P1394> PWG printer profile impression


I apologize that I may not have made my point clear.
I also apologize that I am thinking out loud.


I understand that the application layer protocols
have not been spoken about.


My understanding (and from the document),
the printer profile document
proposes using SBP-2 for "image communication",
and the current discussion is
about a "glue" to interface SBP-2 and whatever layer
comes above it ( which 1 of them is 1284.4.)


Of course the "glue" itself may be easy to
employ,
but by saying that this glue will be
generic (not just for 1284.4 interfacing)
and applied to all printers,
you are stating that all printing shall use SBP-2.


This discussion had been going on for a while,
but the current PWG-C proposal
(which defines the transport, as well as application
protocols).
has decided NOT to use SBP-2 for direct-print,


This is why I(PWG-C) am concerned about the scope of
this "glue"(and profile), and PWG-C work.
I just wanted to clarify the relationship between
PWG work and PWG-C work


> I *do* think that what we have specified
> so far could easily be employed by any
> 1394 device, no matter how small and
> simple. But there is much work to be done


I may be missing something, but my understanding
is the only things specified (proposed)
so far (from the document and discussion)
is usage of SBP-2, the need to define contents of
the CDB, and that this CDB should be generic.
(not 1284.4 specific)


While speaking about CDBs,
once the CDB definition become generic,
there wil have to be some mechanism to distingush
the layer above it.


1) decoding a defined header at the beginning of the CDB
2) preparing differnt login entry points for each session
others....


If the CDB definition is 1284.4 specific, of course
it will not be necessary.
Does this "glue" really need to support anything
other than 1284.4 ?


Am I missing something ?


Ats


At 06:12 97/12/17 -0800, you wrote:
> To my knowledge, we haven't talked about
> application layer protocols yet (printing or
> anything else). I don't think we know how
> "thick" or "thin" the printing profile
> document will be. Until we specify the
> application layer, we don't have an
> interoperable specification for any
> application.
>
> I *do* think that what we have specified
> so far could easily be employed by any
> 1394 device, no matter how small and
> simple. But there is much work to be done.
>
> Randy
>
>
> Atsushi_Nakamura wrote:
> >
> > I have been reviewing the PWG printing profile,and
> > also was fortunate to hear a little about the
> > discussion that went on in the telephone
> > conference.
> >
> > I think the work is becoming productive,and that is good.
> > However,I do have one concern about the scope of the profile 
(spec.)
> >
> > It is written in the PWG profile document that the profile
> > document:
> >
> >  "will provide requirements for the implementation of IEEE1394
> >  communications for printers, scanners, digital still cameras,
> >  and other imageing devices.
> >  Communications will include traditional computer host to
> >  these devices AS WELL AS DIRECT PEER TO PEER COMMUNICATION"
> >
> > The scope, excluding 1284.4 overlaps with the direct print 
protocol
> > work done in PWG-C.
> >
> > Of course it would be an ideal solution if only 1 protocol
> > exists in the 1394 printing world, which covers ANY printing
> > application, and I assume everyone has persued this idea
> > in the beginning.
> > However, the reality is that the priority of requirements
> > differ among printing applications (PC printing, direct printing)
> > and some protocol features which are necessary in 1 solution
> > may not be needed in others.
> >
> > Coming up with 1 printing profile wich covers both PC printing
> > and direct printing may be a difficult task, and may end up as
> > an incomplete solution for both printing applications.
> > One example may be connection-less service. "IF" it is decided 
that
> > the PC printing solution does not need this feature, I do not 
feel
> > it is necessary to keep it just to support an incomplete 
direct-print.
> > (I'm not saying that PC printing doesn't need connection-less. )
> >
> > I think the concensus we had till a while ago ,that
> > there would be a "thick" stack and a "thin" stack still lives.
> > The idea was that there may(will) be more than 1 stack for 
printers,
> > and FDS is intended to be a solution to "tie" the physical
> > functionality, "the printer" whatever the stack may be.
> >
> > The current activity, that PWG works on an ideal PC
> > printing solution (PWG profile) while the PWG-C works on an
> > ideal direct print solution (Direct-print protocol)is a
> > very realistic idea.
> > The first priority for both groups is for each to come up with
> > a good solution for their initial scope,
> > and don't become too generic from the beginning.
> >
> > >From this point of view, my frank question would be;
> >
> > "Should the PWG profile proposal be considered as a
> >  counter-proposal to the PWG-C Direct-Print Protocol
> >  proposal?"
> >
> > I think it is very good work, and hope to participate in it,
> > but I was just curious that PWG and PWG-C may be working on
> > 2 of the same things.
> >
> > FYI: The direct-print market in Japan, though not as big as
> >      the PC printer market is an area that cannot be ignored,
> >      with direct print capable printers from Panasonic, Casio,
> >      Epson,Sharp and most digital camera vendors.
> >      Direct printing is somewhat a trend in Japan,becoming more
> >      than a niche market.
> >      I think this comes from the difference in the number of PCs
> >      inside the homes, between the US and Japan.
> >
> >
> >
> > -----------------------------------------
> > Atsushi Nakamura
> > -----------------------------------------
> > **************!! NOTICE !!*****************
> > *TEL,FAX,and EMAIL(2) has changed         *
> > *from Sept.8,1997                         *
> > *******************************************
> >
> > 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):Atsushi_Nakamura@cbj.canon.co.jp
> > email(2):atsnaka@bsd.canon.co.jp
> > -----------------------------------------
>
>


-----------------------------------------
Atsushi Nakamura
-----------------------------------------
**************!! NOTICE !!*****************
*TEL,FAX,and EMAIL(2) has changed         *
*from Sept.8,1997                         *
*******************************************


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):Atsushi_Nakamura@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------

