Subject: IPP> more on IPP and OMG PF coordination.

From: paul murray <[email-masked]>
Date: Tue, 7 Jan 1997 14:27:15 PST

Here is a resend with corrections:

There has been some questions about how to go about coordinating the OMG RFP6 response 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 about IPP are:

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

>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 we 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 Xerox/Novell/ICL/Digital OMG CF-RFP6 submission is more along the lines of a framework. The vehicle for specifying what document characteristics are being asked for, by a client, 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 the "Job Ticket" style of job submission. ( ...should we might worry about conformance with Postscript 3.0 ???)

        I propose the following for the OMG printing facility:

        1. Change the design for the "Job Specifier" to include MIME based wrappers
        2. Maintain CORBA as the control protocol and design our own (simple) data transfer protocol,
           later integrating IPP data transfer protocol when available.
        3. The server launches the data transfer protocol based on MIME info.
        4. Maintain tight coordination with the work being done with the IPP attribute model and use it
           as the basis of our default job exec. module.
        5. Integrate the IPP control protocol (when they decide on a transport) as a gateway.

        Note: IPP may not make a distinction between control and data transfer protocols.

                                        Thanks:

                                                Paul Murray     
                                                Xerox

---

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

Paul,

> Here is a resend with corrections:

I'm not sure what triggered a "resend with corrections", but I did
notice that you changed the item on which I had previously commented:

>         2. Maintain CORBA as the control protocol and design our own
>            (simple) data transfer protocol, later integrating IPP data
>            transfer protocol when available.

What is the OMG's timing such that you feel compelled to design your own
data transfer protocol instead of simply waiting for the IPP results?  I
realize that you state an intention to integrate the IPP method when
available, but you still seem pretty intent on designing your own protocol
without even knowing what the IPP will end up with.

As far as I know, the IPP schedule remains the same, ie, the first draft
should be done by the summer of 1997.  Is your schedule much more aggressive
than that such that you don't think the OMG can wait for the IPP results?

I would have thought that part of the "coordination" you mentioned in
your message had (at least) something to do with playing a part in the
definition of the transport requirements, etc.

Am I missing something here?

Please don't get me wrong; the OMG certainly can do whatever it wants
to do.  But if real coordination is desired, then an immediate declaration
of duplicate activities (ie, transfer protocol design) seems orthogonal
to that desire.

Hey, if nothing else, the IPP group would *sure* like to hear YOUR ideas
for a transfer protocol!  ;-)

	...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   --
----------------------------------------------------------------------

---

From: paul murray <[email-masked]>
Date: Tue, 7 Jan 1997 19:36:29 PST

>than that such that you don't think the OMG can wait for the IPP results?

The OMG final submission is due in April this year.
We have actually already issued the initial submission.

Just to catch up on the conversation here, could someone fill me in on

        1. What have the IPP folk been thinking of doing for implementing
           asynchronous print server error messages through HTTP? 
           (Assuming that you use HTTP)

        2. Is the IPP protocol being designed as a simple client-to-server
           protocol. Will print server to print server communications issues
           be considered later as a separate standard.

        3. Taking ... say the windows 95 environment as an example, where 
           would the IPP protocol be positioned? How about in Unix.

        4. What are the thoughts as to local spooling before submission
           (responding to server down errors etc.) 

        5. Has there been any discussion of doing print pre-presentation
           (like print preview)

                                -paul.

---

From: [email-masked] (Robert Herriot)
Date: Wed, 8 Jan 1997 14:43:26 -0800

> From [email-masked] Tue Jan  7 17:54:07 1997
.).
>            (Multipurpose Internet Mail Extensions) wrappers for job attributes/docs.

Actually the IPP proposal suggested MIME.  All the details did not make
it into the first draft. The IETF suggestions corroborated a direction
we were already taking.