Subject: IPP> IPP and OMG PF coordination.

From: paul murray <[email-masked]>
Date: Tue, 7 Jan 1997 11:46:37 PST

Folks:

There has been some questions about how to go about coordinating the OMG RFP6 effort and the IETF IPP effort. In order to kick this discussion off. I will begin from the assumption that these two things should, a-priori, be coordinated. The four tidbits of information that I have obtained from the IPP folks are that they are:

        1. Assume ISO DPA 2M level conformance for attributes ( as is the current OMG RFP resp.).
        2. Have been asked (by IETF area coordinators) to provide MIME 
           (Multipurpose Internet Mail Extensions) wrappers for job attributes/docs.
        3. Have been asked (by IETF area coordinators) to consider using a simple tcp/ip 
           based protocol of their own from a transport.
        4. Believe ( at least the majority of the working group members ) that they
           should use HTTP as the transport protocol.

 (You IPP folks that are on the CC list please correct the above if I seem to be full of Squash and Zucchini!)

>From the beginning there has been an issue for the OMG Print Facility work of whether we should only work on a client side job submission protocol or should be take advantage of new language in the OMG Object Management Architecture that allows us to work on a framework for developing a facility. The current RFP submission is more along the lines of a framework. The vehicle for specifying what document characteristics are being asked for is currently called the "Job Specifier". Building the Job Specifier in a Print Facility server is similar to what is done in ISO-DPA. Building the Job Specifier in the client, writing it to a file, appending the document data to the file and sending the file to the server is like what you have for the "Job Ticket" style of job submission. ( ...should we might worry about conformance with Postscript 3.0 ???)

        I propose the following:

        1. Change our design for the "Job Specifier" to include a MIME based wrapper
        2. Maintain CORBA as the control protocol and design our own (simple) data transfer protocol
        3. Launch the data transfer protocol based on MIME info.
        4. Maintain tight coordination with the DPA 2M level work being done with IPP and use it
           as the basis of our first job exec. module.
        5. Integrate the IPP control protocol (when they decide on a transport) as a gateway.

                                        Thanks:

                                                Paul Murray     
                                                Xerox

---

From: [email-masked] (JK Martin)
Date: Tue, 7 Jan 97 18:08 EST

Paul,

>         5. Integrate the IPP control protocol (when they decide on a transport) as a gateway.

Regarding item #2 above, exactly what do you mean by:

   "...design our own (simple) data transfer protocol"

Why wouldn't you use whatever ends up being designed as a result of
the IPP effort?

	...jay

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