home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipp-lpd-ipp-map-00.txt < prev    next >
Text File  |  1997-07-15  |  22KB  |  722 lines
  1.  INTERNET-DRAFT                                              Tom Hasting
  2.                                                        Xerox Corporation
  3.                                                              Bob Herriot
  4.                                                   Sun Microsystems, Inc.
  5.                                                              Norm Jacobs
  6.                                                   Sun Microsystems, Inc.
  7.                                                               Jay Martin
  8.                                                         Underscore, Inc.
  9.                                                            July 13, 1997
  10.  
  11.  
  12.                  Mapping between LPD and IPP Protocols
  13.  
  14.                   <draft-ietf-ipp-lpd-ipp-map-00.txt>
  15.  
  16.                           Expires Jan 13, 1998
  17.  
  18.  
  19. Status of this Memo
  20.  
  21.      This document is an Internet-Draft.  Internet-Drafts are working
  22.      documents of the Internet Engineering Task Force (IETF), its areas,
  23.      and its working groups.  Note that other groups may also distribute
  24.      working documents as Internet-Drafts.
  25.  
  26.      Internet-Drafts are draft documents valid for a maximum of six
  27.      months and may be updated, replaced, or obsoleted by other
  28.      documents at any time.  It is inappropriate to use Internet-Drafts
  29.      as reference material or to cite them other than as "work in
  30.      progress."
  31.  
  32.      To learn the current status of any Internet-Draft, please check the
  33.      "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  34.      Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  35.      munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  36.      ftp.isi.edu (US West Coast).
  37.  
  38.                                 Abstract
  39.  
  40.      This Internet-Draft specifies the mapping between (1) the commands
  41.      and operands of the "Line Printer Daemon (LPD) Protocol" specified
  42.      in RFC 1179 and (2) the operations and parameters of the Internet
  43.      Printing Protocol (IPP).  One of the purposes of this document is
  44.      to compare the functionality of the two protocols.  Another purpose
  45.      is to facilitate implementation of gateways between LPD and IPP.
  46.  
  47.      WARNING:  RFC 1179 was not on standards track.  While RFC 1179 was
  48.      intended to record existing practice, in some areas it fell short.
  49.      However, this specification maps between (1) the actual current
  50.      practice of RFC 1179 and (2) IPP.  This document does not attempt
  51.      to map the numerous divergent extensions to the LPD protocol that
  52.      have been made by many implementors.
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61. Hastings, Herriot, Jacobs, Martin                   [Page 1]
  62.  
  63.  
  64.  
  65.  
  66.  
  67.            Mapping between LPD and IPP Protocols          June 27, 1997
  68.  
  69.  
  70.  
  71.  
  72.                            TABLE OF CONTENTS
  73.  
  74.  
  75. 1. INTRODUCTION........................................................3
  76.  
  77.  
  78. 2. TERMINOLOGY.........................................................3
  79.  
  80.  
  81. 3. MAPPING BETWEEN  LPD COMMANDS AND IPP OPERATIONS....................3
  82.  
  83.  3.1 Print any waiting jobs ...........................................4
  84.  
  85.  3.2 Receive a printer job ............................................4
  86.  
  87.  3.3 Send queue state (short) .........................................5
  88.  
  89.  3.4 Send queue state (long) ..........................................5
  90.  
  91.  3.5 05 - Remove jobs .................................................6
  92.  
  93.  
  94. 4. MAPPING BETWEEN LPD SUB-COMMANDS AND IPP OPERATIONS.................6
  95.  
  96.  4.1 01 - Abort job () ................................................6
  97.  
  98.  4.2 02 - Receive control file ........................................7
  99.  
  100.  4.3 03 - Receive data file ...........................................7
  101.  
  102.  
  103. 5. MAPPING OF LPD CONTROL FILE LINES TO IPP OPERATION INPUT PARAMETERS.7
  104.  
  105.  
  106. 6. BIBLIOGRAPHY.......................................................10
  107.  
  108.  
  109. 7. AUTHOR'S ADDRESSES.................................................10
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121. Hastings, Herriot, Martin                           [Page 2]
  122.  
  123.  
  124.  
  125.  
  126.  
  127.            Mapping between LPD and IPP Protocols          June 27, 1997
  128.  
  129.  
  130.  
  131.                Mapping between the LPD and IPP Protocols
  132.  
  133. 1. Introduction
  134.  
  135. The reader of this specification is expected to be familiar with the IPP
  136. Model and Semantics specification [1], the IPP Protocol specification
  137. [2], and the Line Printer Daemon (LPD) protocol specification [3] as
  138. described in RFC 1179.
  139.  
  140. RFC 1179 was written in 1990 in an attempt to document existing LPD
  141. protocol implementations.  Since then, a number of undocumented
  142. extensions have been made by vendors to support functionality specific
  143. to their printing solutions.  All of these extensions consist of
  144. additional control file directives.  This document does not address any
  145. of these vendor extensions.  Rather it addresses existing practice
  146. within the context of the features described by RFC 1179.  Deviations of
  147. existing practice from RFC 1179 are so indicated.
  148.  
  149. In the area of document formats, also known as page description
  150. languages (PDL), RFC 1179 defines a fixed set with no capability for
  151. extension.  Consequently, some new PDL's are not supported, and some of
  152. those that are supported are sufficiently unimportant now that they have
  153. not been registered for use with the Printer MIB[4] and IPP[1] [2],
  154. though they could be registered if desired.  See the Printer MIB
  155. specification [4] and/or the IPP Model specification [1] for
  156. instructions for registration of document-formats with IANA.  IANA lists
  157. the registered document-formats as "printer languages".
  158.  
  159. Other LPD commands are intended to work on "text" only formats and so
  160. are inappropriate for many contemporary document formats that completely
  161. specify each page.
  162.  
  163. This document addresses the protocol mapping for both directions:
  164. mapping of the LPD protocol to the IPP protocol and mapping of the IPP
  165. protocol to the LPD protocol.
  166.  
  167. 2. Terminology
  168.  
  169. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  170. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL" in this
  171. document are to be interpreted as described in RFC 2119 [6].
  172.  
  173.  
  174. The syntax of the LPD commands is given using ABNF [6].
  175.  
  176. The following tokens are used in order to make the syntax more readable:
  177.     LF stands for %x0A (linefeed)
  178.  
  179.  
  180.  
  181. Hastings, Herriot, Martin                           [Page 3]
  182.  
  183.  
  184.  
  185.  
  186.  
  187.            Mapping between LPD and IPP Protocols          June 27, 1997
  188.  
  189.  
  190.     SP stands for %x20.  (space)
  191.  
  192. 3. Mapping between  LPD Commands and IPP Operations
  193.  
  194. This section describes the mapping between  LPD on-the wire and IPP
  195. operations.  Each of the following sub-sections appear as sub-sections
  196. of section 5 of RFC 1179.
  197.  
  198. 3.1 Print any waiting jobs
  199.  
  200. Command syntax:  %x01 Printer-queue-name LF
  201.  
  202. In LPD, this comment starts the daemon, if it isn't already running.
  203. Such an equivalent operation is not provided in IPP, since the IPP
  204. Printer is assumed to always be running, where as in LPD, the client
  205. makes sure that the daemon is running using this command.
  206.  
  207. If an LPD-to-IPP mapper receives this LPD command, it SHALL ignore it
  208. and send no IPP operation.
  209.  
  210. An IPP-to-LPD mapper SHALL send this LPD command after it has finished
  211. sending all pending `Receive a printer job' commands.
  212.  
  213. 3.2 Receive a printer job
  214.  
  215. Command syntax:  %x02 Printer-queue-name LF
  216.  
  217. An LPD-to-IPP mapper SHALL map the 'Receive a printer job' command to
  218. either:
  219.  
  220.      . the Print-Job operation with a single data file or
  221.  
  222.      . the Create-Job operation followed by a Send-Document operation
  223.        for each data file.
  224.  
  225. If a job consists of a single data file, the PrintJob operation is
  226. RECOMMENDED.
  227.  
  228. If a job consists of more than one data file, Create Job followed by
  229. Send-Document for each data file is REQUIRED.  If the IPP Printer
  230. doesn't support the Create-Job and Send-Document operations, the LPD-to-
  231. IPP mapper SHALL submit each data file as a separate Print-Job operation
  232. (thereby converting a single LPD job into multiple IPP jobs).
  233.  
  234. ISSUE: Ok that I changed so that the mapper shall break a multi-document
  235. job into separate jobs, one IPP job for each LPD data file, instead of
  236. error return?
  237.  
  238.  
  239.  
  240.  
  241. Hastings, Herriot, Martin                           [Page 4]
  242.  
  243.  
  244.  
  245.  
  246.  
  247.            Mapping between LPD and IPP Protocols          June 27, 1997
  248.  
  249.  
  250. NOTE: if Create-Job is used, it MUST precede the Send-Document operation
  251. even if the LPD control file, which supplies attributes for Create-Job,
  252. arrives after all documents.
  253.  
  254. An IPP-to-LPD mapper SHALL map the following IPP operations to this LPD
  255. command:
  256.  
  257.      . Print-Job
  258.  
  259.      . Print-uri
  260.  
  261.      . Create-Job followed by Send-Document or Send-URI for each
  262.        document
  263.  
  264. The mechanism for mapping between an LPD Printer-queue-name operand and
  265. the IPP "printer-uri" parameter is not defined in this document.
  266.  
  267. ISSUE: error code conversion.
  268.  
  269. See the next section for the mapping of the LPD "second level commands"
  270. to IPP input-parameters.
  271.  
  272. 3.3 Send queue state (short)
  273.  
  274. Command syntax:  %x03 Printer-queue-name *( SP ( User-Name / job-number)
  275. )
  276.  
  277. If the LPD command contains only the Printer-queue-name operand, the
  278. LPD-to-IPP mapper SHALL use the Get-Attributes operation of the
  279. corresponding IPP Printer to get printer-state information and the Get-
  280. Jobs operation of the Printer to get information about all of the jobs.
  281. With Get-Attributes, it SHALL request the "printer-state" and "printer-
  282. state-reasons" attributes.  With Get-Jobs, it SHALL request the "number-
  283. of-intervening-jobs", "job-originating-user", "job-name", "document-
  284. name" (or "document-uri"), and "job-k-octets".
  285.  
  286. NOTE:  RFC 1179 does not specify what attributes are returned in
  287. response to a 'Send queue state' (short) command, but leaves it up to
  288. implementation.  The IPP attributes specified in this specification
  289. reflect existing practice.
  290.  
  291. NOTE:  This specification does not specify how the LPD-to-IPP mapper
  292. maps: (1) the LPD Printer-queue-name operand to the IPP "printer-uri"
  293. parameter or (2) the LPD job-number operand to the IPP "job-uri"
  294. parameter, since the format of these URIs is opaque in the IPP protocol
  295. and is implementation-dependent.
  296.  
  297.  
  298.  
  299.  
  300.  
  301. Hastings, Herriot, Martin                           [Page 5]
  302.  
  303.  
  304.  
  305.  
  306.  
  307.            Mapping between LPD and IPP Protocols          June 27, 1997
  308.  
  309.  
  310. If the LPD command contains one or more User-name operands, the LPD-to-
  311. IPP mapper SHALL get all the jobs as above using the Get-Jobs operation
  312. on the Printer and then do its own filtering on the returned value of
  313. the "job-originating-user" attribute for each job.
  314.  
  315. If the LPD command contains only job-number operands, the LPD-to-IPP
  316. mapper SHALL either (1) get all the jobs as above using the Get-Jobs
  317. operation on the Printer and then do its own filtering or (2) get each
  318. specified job individually using separate Get-Attributes operations
  319. (multiple jobs may be requested in a single IPP connection with multiple
  320. Get-Attribute operations, one for each job).
  321.  
  322. The IPP-to-LPD mapper shall use the long version of this command. See
  323. that command.
  324.  
  325. 3.4 Send queue state (long)
  326.  
  327. Command syntax:  %x04 printer-name *( SP ( user-name / job-number) )
  328.  
  329. Same mapping as the 'Send queue state' (short) command.  The IPP client
  330. supplies a longer list of requested attributes to the Get-Jobs or Get-
  331. Attributes operations.
  332.  
  333. The LPD-to-IPP mapper should specify additional attributes than the ones
  334. listed for the 'Send queue state' (short) command.
  335.  
  336. NOTE:  RFC 1179 does not specify what attributes are returned in
  337. response to a 'Send queue state' (short) command, but leaves it up to
  338. implementation.
  339.  
  340. The IPP-to-LPD mapper shall use this command to get what attributes it
  341. can from the LPD server.
  342.  
  343. 3.5 05 - Remove jobs
  344.  
  345. Command syntax:  %x05 Printer-queue-name SP agent *(SP (User-name / job-
  346. number))
  347.  
  348. The agent operand is the user-name of the user initiating the 'Remove
  349. jobs' command.  The special user-name 'root' indicates a privileged
  350. user.
  351.  
  352. The LPD-to-IPP mapper shall map this command to the Cancel-Job
  353. operation.
  354.  
  355. This command with the Printer-queue-name operand and one job-number
  356. operand is the same as the IPP Cancel-Job operation when the client
  357. supplies just the job URI.  Multiple jobs may be canceled in IPP in a
  358.  
  359.  
  360.  
  361. Hastings, Herriot, Martin                           [Page 6]
  362.  
  363.  
  364.  
  365.  
  366.  
  367.            Mapping between LPD and IPP Protocols          June 27, 1997
  368.  
  369.  
  370. single connection with multiple Cancel-Job operations.  In IPP only a
  371. privileged operator may cancel jobs belonging to another user.
  372.  
  373. NOTE: This specification does not specify how the LPD-to-IPP mapper
  374. maps: (1) the LPD Printer-queue-name to the IPP "printer-uri" or (2) the
  375. LPD job-number to the IPP "job-uri", since the format of these URIs is
  376. opaque in the IPP protocol and is implementation-dependent.
  377.  
  378. There is no IPP equivalent for the LPD 'Remove jobs' command with just
  379. the Printer-queue-name operand supplied, since IPP provides no way to
  380. cancel the current job.
  381.  
  382. There is no IPP equivalent for the LPD 'Remove jobs' command with a
  383. User-name operand supplied, since IPP provides no way to cancel a job
  384. specified by user name.
  385.  
  386. The LPD-to-IPP mapper shall map a Cancel-Job operation to this command.
  387.  
  388. There are some major issues about setting the agent.
  389.  
  390. 4. Mapping between LPD Sub-Commands and IPP Operations
  391.  
  392. This section describes the mapping between LPD sub-commands and IPP
  393. operations.  Each of the following sub-sections appear as sub-sections
  394. of section 6 of RFC 1179.  The operands of the sub-commands appear in
  395. parens in the sub-headings
  396.  
  397. 4.1 01 - Abort job ()
  398.  
  399. Sub-command syntax:  %x01
  400.  
  401. This sub-command is intended to abort any job transfer in process.  If
  402. an IPP Create-Job operation and/or a Send-Document operation were
  403. performed on behalf of the receive job command that is being aborted, an
  404. IPP Cancel-Job operation should be issued for  the job URI that was
  405. returned by the Printer on which the Create-Job operation was performed.
  406. Also, any temporary files created while processing the 'Receive job
  407. request' should be cleaned up, and the connection to the client should
  408. be closed.  Finally, this sub-command is implied if at any time the
  409. connection between the LPD client and server is terminated before an
  410. entire print job has been transferred via an LPD 'Receive job request'.
  411.  
  412. ISSUE: is IPP defined at this point to abort a job whose connection is
  413. closed before the job has been fully received. If so, that is an
  414. alternate and simpler way to abort the job.
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421. Hastings, Herriot, Martin                           [Page 7]
  422.  
  423.  
  424.  
  425.  
  426.  
  427.            Mapping between LPD and IPP Protocols          June 27, 1997
  428.  
  429.  
  430. 4.2 02 - Receive control file
  431.  
  432. Sub-command syntax:  %x02 Number-of-bytes-in-control-file, Name-of-
  433. control-file
  434.  
  435. This sub-command is roughly equivalent to the IPP Create-Job operation.
  436. Once the control file has been has been received, it's contents should
  437. be translated, and an appropriate IPP Create-Job operation performed.
  438.  
  439. However, some information, such as Document-Name go in the Send-Document
  440. operation.
  441.  
  442. 4.3 03 - Receive data file
  443.  
  444. Sub-command syntax:  %x03 Number-of-bytes-in-data-file Name-of-data-file
  445.  
  446. This sub-command is roughly equivalent to the IPP Send-Document
  447. operation.  If the control file has been previously received, and it's
  448. corresponding IPP Create-Job operation performed, an IPP Send-Document
  449. operation can be performed using the job URI returned by the IPP Create-
  450. Job operation.
  451.  
  452. When performing the Send-Document operation, the size of the document
  453. data MUST be specified.  Unfortunately RFC-1179 alludes to a method for
  454. passing an arbitrary length data file.  This is described as being done
  455. by using an octet-count of zero, however the description isn't complete,
  456. and in practice, no implementations allow sending or receiving arbitrary
  457. length data files.
  458.  
  459. 5. Mapping of LPD control file lines to IPP Operation Input Parameters
  460.  
  461. This section describes the mapping from LPD control file lines to IPP
  462. operation input parameters for the Print-Job, Create-Job, and Send-
  463. Document operations.  Each of the following sub-sections appear as sub-
  464. sections of section 7 of RFC 1179.
  465.  
  466. ISSUE: somewhere, we need to map the LPD query format to IPP attributes.
  467.  
  468. In LPD text operands have a maximum length of 31 or 99 while IPP input
  469. parameters have a maximum of 255 characters.  Therefore, no data is lost
  470. when mapping from LPD to IPP.  However, when mapping from IPP to LPD,
  471. there may be some data loss if the IPP parameters exceed the maximum
  472. length of the LPD equivalent operands.
  473.  
  474. In the following table, IPP input parameter names are indicated in
  475. double quotes (") and input parameter values are indicated in single
  476. quotes (').  Values of the IPP "document-format" attribute that could be
  477. registered, but are not currently, are indicated with "**".
  478.  
  479.  
  480.  
  481. Hastings, Herriot, Martin                           [Page 8]
  482.  
  483.  
  484.  
  485.  
  486.  
  487.            Mapping between LPD and IPP Protocols          June 27, 1997
  488.  
  489.  
  490. Where there is a one-to-one mapping, both directions are specified.
  491. Where IPP has none, the LPD-to-IPP the attribute is ignored, and in the
  492. IPP-to-LPD the LPD feature is left unspecified.
  493.  
  494.    LPD command           Equivalent IPP input parameter(s)
  495.  
  496. C  Class for banner      None.
  497.    page
  498.  
  499. H  Originating Host      "job-originating-host"
  500.  
  501. I  Indent Printing       None.
  502.  
  503. J  Job name for banner   "job-name"
  504.    page
  505.  
  506. L  Print banner page     "job-sheets" = any but 'none'
  507.                          Absence of an `L' directive
  508.                          indicates that ``job-sheets=none''
  509.                          is set.
  510.  
  511. M  Mail When Printed     "notification-events" = 'job-
  512.                          completion' and "notification-
  513.                          method" = 'mailto://Job-
  514.                          originating-user@job-originating-
  515.                          host'
  516.  
  517. N  Name of source file   "document-name" This is on a per
  518.                          data file basis
  519.  
  520. P  User identification   "job-originating-user"
  521.  
  522. S  Symbolic link data    None.
  523.  
  524. T  Title for pr          None.
  525.  
  526. U  Unlink data file      None.
  527.  
  528. W  Width of output       None.
  529.  
  530. 1  troff R font          None.
  531.  
  532. 2  troff I font          None.
  533.  
  534. 3  troff B font          None.
  535.  
  536. 4  troff S font          None.
  537.  
  538.  
  539.  
  540.  
  541. Hastings, Herriot, Martin                           [Page 9]
  542.  
  543.  
  544.  
  545.  
  546.  
  547.            Mapping between LPD and IPP Protocols          June 27, 1997
  548.  
  549.  
  550.  
  551. c  Plot CIF file         "document-format" = 'CIF' **
  552.  
  553. d  Print DVI file        "document-format" = 'TeX DVI' **
  554.  
  555. f  Print formatted file  "document-format" = 'Automatic'
  556.  
  557.                          In practice, this value is often
  558.                          overloaded. It is often used with
  559.                          any format of document data
  560.                          including PostScript and PCL data.
  561.  
  562. g  Plot file             "document-format" =
  563.                          'BSDPlotLibrary' **
  564.  
  565. k  reserved for          None.
  566.    Kerberized clients
  567.    and servers           This is unimplemented in LPD
  568.                          implementations.  It was a place
  569.                          holder for future work that never
  570.                          occurred.
  571.  
  572. l  Print file leaving    "document-format" = 'Automatic'
  573.    control characters
  574.                          In practice, this is often used as
  575.                          a rough equivalent to the `f'
  576.                          directive.  Again it may mean one
  577.                          of many document formats.
  578.  
  579. n  Print ditroff output  "document-format" = 'ditroff' **
  580.    file
  581.  
  582. o  Print Postscript      "document-format" = 'ps'
  583.    output file           "document-format" = 'PS'(7)
  584.  
  585.                          o is recognized by LPD-to-IPP, but
  586.                          never generated in IPP-to-LPD.
  587.                          Rather `f' is used.
  588.  
  589.                          This was not implemented in any
  590.                          RFC-1179 implementations until
  591.                          very recently in WinNT.
  592.  
  593. p  Print file with 'pr'  None.
  594.    format
  595.                          It therefore is equivalent to `f'
  596.                          or `l'
  597.  
  598.  
  599.  
  600.  
  601. Hastings, Herriot, Martin                          [Page 10]
  602.  
  603.  
  604.  
  605.  
  606.  
  607.            Mapping between LPD and IPP Protocols          June 27, 1997
  608.  
  609.  
  610.  
  611. r  File to print with    "document-format" = 'FORTRAN' **
  612.    FORTRAN carriage
  613.    control
  614.  
  615. t  Print troff output    "document-format" = 'troff' **
  616.    file
  617.  
  618. v  Print raster file     "document-format" = 'RasterFormat'
  619.                          **
  620.  
  621. z  reserved for future   None.
  622.    use with the
  623.    Palladium print       This was reserved for the MIT
  624.    system                Palladium print system, but was
  625.                          never used by that system.
  626.  
  627. 6. Bibliography
  628.  
  629. [1] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet
  630. Printing Protocol/1.0: Model and Semantics", <draft-ietf-ipp-model-
  631. 02.txt>, July 1997.
  632.  
  633. [2] R. Herriot, S. Butler, P. Moore, R. Turner, "Internet Printing
  634. Protocol/1.0: Protocol specification", <draft-ietf-ipp-protocol-00.txt>,
  635. July 1997.
  636.  
  637. [3] L. McLaughlin, "Line Printer Daemon Protocol", RFC 1179, August
  638. 1990.
  639.  
  640. [4] Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, J.,
  641. "Printer MIB", RFC 1759, March 1995.
  642.  
  643. [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement
  644. Levels", RFC 2119 , March 1997
  645.  
  646. [6] D. Crocker et al., ``ugmented BNF for Syntax Specifications:
  647. ABNF', draft-ietf-drums-abnf-02.txt.
  648.  
  649. 7. Author's Addresses
  650.     Thomas N. Hastings
  651.     Xerox Corporation
  652.     701 S. Aviation Blvd., ESAE-231
  653.     El Segundo, CA 90245
  654.  
  655.     Phone: 310-333-6413
  656.     Fax:   310-333-5514
  657.     EMail: hastings@cp10.es.xerox.com
  658.  
  659.  
  660.  
  661. Hastings, Herriot, Martin                          [Page 11]
  662.  
  663.  
  664.  
  665.  
  666.  
  667.            Mapping between LPD and IPP Protocols          June 27, 1997
  668.  
  669.  
  670.  
  671.     Robert Herriot
  672.     Sun Microsystems Inc.
  673.     2550 Garcia Ave., MPK-17
  674.     Mountain View, CA 94043
  675.  
  676.     Phone:  415-786-8995
  677.     Fax:   415-786-7077
  678.     Email:  robert.herriot@eng.sun.com
  679.  
  680.     Norm Jacobs
  681.     Sun Microsystems Inc.
  682.     1430 Owl Ridge Rd.
  683.     Colorado Springs, CO 80919
  684.  
  685.     Phone:  (719) 532-9927
  686.     Fax:   (719) 535-0956
  687.     Email:  Norm.Jacobs@Central.sun.com
  688.  
  689.     Jay Martin
  690.     Underscore Inc.
  691.     41-C Sagamore Park Rd.
  692.     Hudson, NH 03051-4915
  693.  
  694.     Phone:  (603) 889-7000
  695.     Fax:  (603) 889-2600
  696.     Email:  jkm@underscore.com
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721. Hastings, Herriot, Martin                          [Page 12]
  722.