Subject: IPP> Revised Charter Text for IPP

From: Carl-Uno Manros <[email-masked]>
Date: Mon, 23 Dec 1996 11:10:54 -0800

Harald and Keith,

below follows the revised proposed charter text for IPP, based on our 
discussions in San Jose and follow up discussions in the group afterwards.

The references to producing mappings to HTTP and LDAP have been deleted,
although some PWG members are likely to be working on those subject as
part of their prototyping efforts.

The subject of RFC 1179 was further discussed, and it turns out that not
a single vendor of printers or print servers has expressed any interest
in spending time and effort on the subject. Contrary to opinions expressed
in San Jose, RFC 1179 is not used by millions of users; they use one or
several of the mostly incompatible variations of LPR. One PWG member has 
dealt with writing gateways between 28 (!) different variations. The printer
industry considers RFC 1179 as historic and has no interest in spending
the time to try to make a proper IETF standard out of this RFC, that was
never even considered for the standards track (only informational).
Does any of you still have objections to leave RFC 1179 be?

I hope that we can now get your official OK for the WG, so that the real 
work can be continued without further delay.

I have also included a copy of the minutes from the BOF meeting in case 
you have not already picked them up from the IPP archive.

Best Regards and a Merry Christmas,

Carl-Uno

Carl-Uno Manros
Xerox Corporation
(send from home)

---

(DRAFT 12/23/96)

IETF Internet Printing Protocol (ipp) WG

Chair(s):
        Carl-Uno Manros   <[email-masked]>
 
Applications Area Director(s): 
        Keith Moore        <[email-masked]>
        Harald Alvestrand  <[email-masked]>
 
Area Advisor:
        TBD

Mailing List Information:
        General Discussion: <[email-masked]>
        To Subscribe:       <[email-masked]>
        Archive:            ftp://ftp.pwg.org/pub/pwg/ipp/

Editors:
        Scott Isaacson      <[email-masked]>
	Robert Herriot      <[email-masked]>
        Don Wright          <[email-masked]>
 
Description of Working Group:

The goal of this working group is to define a new application level 
distributed printing protocol as well as defining naming and service 
registration attributes for printing.  The protocol shall support a 
global, distributed environment where print service users (clients, 
applications, drivers, etc.) cooperate and interact with print service 
providers (servers, printers, gateways, etc.). 

The working group will leverage existing (and emerging) technologies 
for: authentication, authorization, privacy, and commercial transactions. 
The working group will describe a generic directory schema that supports 
printing, which can be mapped to existing standards for directories.

The working group shall strive to coordinate its activities with other 
printing-related standards bodies.

The new job submission protocol should strive not to preclude any 
types of output devices (e.g., fax, printer, gateway).  Also, the 
working group will define extensibility paths to maximize interoperability 
and minimize conflict.

The latest IETF requirements for management, security, and inter-
nationalization shall be covered.

Deliverables and Milestones:

Done -          Mailing list and archive

November 1996 - Submit first set of Internet-Drafts
	
December 1996 - BOF in IETF meeting in San Jose, CA, USA

March 1997 -    Submit Internet-Drafts

April 1997 -    Review of specification in IETF meeting in Memphis, TN, USA

May 1997 -      At least 2 implemented prototypes

May 1997 -      Submit document(s) to the IESG for Proposed Standard

Current Internet-Drafts:

   IPP-requirements: <draft-wright-ipp-req-01-txt>
   IPP-draft:        <draft-isaacson-ipp-inf0-00.txt>

Planned RFCs:

   Internet Printing Protocol: Requirements and Scenarios (Informational)
   Internet Printing Protoco/1.0: Model and Semantics (Standards Track)
   Internet Printing Protoco/1.0: MIME Encoding (Standards Track)
   Internet Printing Protoco/1.0: Directory Schema (Standards Track)

------

Internet Printing Protocol
Birds of a Feather Session

December 12, 1996

Minutes taken by: Don Wright <[email-masked]>

The meeting was called to order at 1:03 PM

Carl-Uno Manros (proposed WG Chair) reviewed the agenda for the meeting

Carl-Uno gave a short talk about the lack of IETF standards for printing.
He also discussed how this effort started under the Printer Working Group.

Don Wright presented an overview of the Internet printing requirements.  The
following were significant issues raised by the attendees:
	- firewalls
	- there are no "operators", only users
	- using HTTP as a transport
	- LPR/LPD/RFC1179 discussion

Carl-Uno presented the charter
	- Will address needs of normal, end-user roles
	- Will not address needs of the operator and administrator roles
	- The group will strive to build on existing standards and technologies
	- Would like to use existing standards for directories
	- The submitting protocol should not exclude other devices (fax, etc.)

Harald Alvestrand stated that HTTP 1.0 is not an IETF standard.  HTTP 1.1 is
a proposed standard that might be applicable to IPP.

Suggestion from the meeting -- don't explicitly tie IPP to HTTP.

Keith Moore: Should there be a scenario statement of how to use IPP without
a directry server?

Carl-Uno presented the planned drafts list which included:

Requirements (Informational)
MIME Types for IPP (Standards Track)
Application Protocol - IPP (Standards Track)
IPP on HTTP (Standards Track)
IPP Directory Support -LDAP Object Classes for Printers (Standards Track)

Carl-Uno presented the deliverables and milestones for the project.

There was a discussion as to whether the group should do the work on the
various drafts in parallel versus serial.  Several combinations of serial
and parallel were also discussed.  No conclusion.

Scott Isaacson presented the IPP protocol document.  The following issues
were raised:
	- Will the protocol support printer configuration - No, not in 1.0
	- Continued discussion on using HTTP.

Open Discussion:

1) Ray Lutz raised a concern that there was some overlap between the work
proposed by the proposed fax group and the proposed print group.  This
overlap will be assessed by the directors.

2) HTTP issue again.  Suggested using specific HTML as well to more strong
tie IPP to HTTP.

3) A concern was raised about running over HTTP to get through firewalls.
This plan was called "bogus" by one on the attendees.

4) Steve Zilles reminded the group that HTTP can be used in both directions
to not only send the job but also to retrieve status, etc.

5) Suggestion to define the MIME objects and encoding first.

6) Harald Alverstrand wanted the charter to be simplified by removing some
of the work items such as removing the LDAP mapping and the HTTP mapping.

7) More discussion about using RFC1179.  Someone suggested the group should
fix RFC 1179 as a part of this project.  There was no interest on the part
of the core group to do this.

Carl-Uno asked for a show of hands as to whether this effort was worthy of a
being charter.  Approximately half of the attendees felt it was.  When asked
who thought the effort shouldn't be charter, only 1 person raised his hand.
That person's convern was that the proposed charter was too broad.

The meeting ended at 3:08PM

---

---

From: Raymond Lutz <[email-masked]>
Date: Thu, 26 Dec 1996 15:03:13 -0800

The work envisioned by the IPP charter heavily overlaps with the work being
progressed by the internet facsimile group and charter. The functions of
the groups are remarkably similar. The ietf-fax group is looking at devices
which will accept a MIME object and either print it directly or translate
it to T.30 (group-3 fax). One of the primary objects considered by the fax
group for printing is the image/fax-format-tbd which is possibly generated
by a legacy fax device. However, other formats, such as text/plain, and
probably html are to be accepted and "printed" by the internet-fax gateway. 

The new protocol proposed for printing has been defined by the fax group as
a session-oriented approach, as opposed to document-oriented store and
forward. I have no doubt that the fax work will be accepted since there are
real $ improvements in fax transmission costs that can be realized.

The comments about LPD having 28 implementations seems to support further
work to refine this and reduce the number of variations.

I would like to propose that these groups are harmonized as follows:

IPP group will focus on a mime object for printer control (such as paper
type, binding, etc.) which can be combined with any relevant MIME type,
including printer language media-types.

This work can then be use in any protocol, such as SMTP or other simple
submission protocol, including by the facsimile group for transmission of
these hardcopy output suggestions to the receiving fax device or document
store. The hardcopy output suggestions can be maintained with the document
for future use. These controls are missing from popular terminal-oriented
media-types, such as html, PDF, etc.

2 cents.

-Raymond

>The meeting ended at 3:08PM

/***********************************************************************
** Raymond Lutz                             Voice: 619-447-3246
** Director R & D, Cognisys, Inc.           Fax:   619-447-6872 
** EC Chair, MFPA                           MFPA:  1-800-603-MFPA
** 1010 Old Chase Ave., Suite B             mailto:[email-masked]
** El Cajon (San Diego Co.), CA 92020 USA   http://www.cognisys.com           
**                                          http://www.mfpa.org
***********************************************************************/

---

From: Raymond Lutz <[email-masked]>
Date: Sat, 28 Dec 1996 23:23:04 -0800

At 01:39 PM 12/28/96 -0500, Keith Moore wrote:

>I believe "natural consequences" will cause the boundaries between these
>services to shift, but there will still be significant stratification 
>(or if you prefer, specalization) between these services that result.

Fair enough. It's going to be interesting to see how this will all pan out.
Again, I agree with your points when applied to the dominant application,
i.e. local printing, where you want a tightly coupled low-overhead
situation. For true "internet-printing" I think the decoupled scenario will
flourish, including the submission to Kinkos. Time will tell...

-Raymond

---

From: Raymond Lutz <[email-masked]>
Date: Sun, 29 Dec 1996 13:00:56 -0800

At 03:16 AM 12/29/96 -0500, Keith Moore wrote:
Raymond:
>>  For true "internet-printing" I think the decoupled scenario will

Keith:
>While I have no reason to doubt this, where do you think the market
>for such a service will come from?

It's nice to get such an open question. I have previously written white
papers on this topic, and as usual, I do indeed have some opinion. (Please
note that I use "Kinkos" below in most cases as a general name of copy
shops...)

As was mentioned by Beau Vrolyk of Xerox at the last IOC'96 conference in
S.D., "Kinko-net" is being established as we speak. I just looked at the
kinkos web site, and could see nothing showing there yet. However, since
Kinkos is nearly 100% Xerox copiers and other equipment, I'm sure Xerox has
some interest in helping Kinkos provide such as service. I don't have any
other inside information about this service, and maybe someone from Xerox
can provide additional details. However, we may have some problem in
getting cooperation since it is a competitive business. Unless cooperation
is somehow obilgitory, I doubt you will get information before the release
of such a service.

But let's consider what is actually needed by the customer of such a
service and at what level the interaction should take place. This is
actually fairly easy to determine. Just go down to your local copy-shop and
look at their job-submission form. It talks of the _desired result_ as seen
from the customer's eyes. It does _not_ reveal the internal intricacies of
their operation. Consider the following:

    Used in Job Submission    Not Used in Job Submission
    ----------------------    --------------------------
    Paper Size                Paper Tray #
    Paper Type (bond, etc)
    Paper Color
    Holes punched             Paper with holes vs. drilling
    stapled, where            Auto stapling vs. Manual
    simplex vs. duplex        double-sided copying vs. manual flipping
    sides of original         printer interpreter language
                               (jobs are scanned from originals, usually)
    binding type              binder device used
    Customer Name, etc.
    Customer Account #
    Customer Credit Card, etc.
    Submitter Name, etc.
    Contact Telephone #
    Delivery Name, etc.
    Desired Completion time   State of job queues

So, I will imagine that Kinkos will set up a cgi script-based submission
process to collect this information. If the Desired completion time is not
attainable, Kinkos will have to "negotiate" with the customer to reach a
mutually agreeable time for completion. This is a commitment on the part of
Kinkos, not just an estimate. If you arrive for pickup at the scheduled
time, they had better have the documents done or their customer will be lost.

Now, INTERNAL to the Copy Shop, they will submit these jobs in various ways
to their equipment and manage queues and the like. The configuration of
their equipment and the use of their resources is rarely (if ever) revealed
to the customer. The sort of submission envisioned by the ipp protocol
would certainly be a good thing to use here.

Also in Beau Vrolyk's presentation, he discussed the Doc-Tek printer. Most
printer people will know what these are... About 20' long, with computer
input (plus fork-lifts of paper) at one side and bound books being emitted
from the other. These are now accepting faxes, and results in a very
high-end MFP device. Indeed, all the hardcopy features mentioned above
would be sweet in such a submission process (despite your factual point
that these don't exist in most of the installed based of fax devices.)

Let's look at another application for true internet printing, where you are
at least getting out onto the public infrastructure. Consider a large
corporation, such as Safeway/Vons grocery stores. They have about 3000
store locations last time I checked. Let's say that they want to send a new
employee manual to each of the locations. At headquarters, the manual is
designed, and the various "hints" that are needed to completely reproduce
the booklet. (I still claim these should be designed as a MIME object, so I
will use that here). Headquarters sends each of the branches the employee
manual using SMTP and MIME. Using a distribution list of the 3000 stores is
quite handy in this case. The information sent is proposed as follows, each
in its own MIME media-type object:

   content
   content-descriptor
   hardcopy production hints
   job ticket

content:
--------
This is the same content as would be sent to a print queue for printing.

content-descriptor:
-------------------
This may be as simple as a media-type name. There are some other
meta-information that applies to the content itself which may be useful,
such as filename, creation date, author, copyright information, etc.

hardcopy production hints:
--------------------------
when the document is designed, the designer decides exactly how the
document should be produced. The various binding, paper type, and other
information I partially listed above would be applicable (see
ftp://ftp.mfpa.org/tdf_004.txt for more). These are "Hints" for the most
part since a given store location may wish to

  1) view the document on screen
  2) produce the document on the local printer
  3) forward the submission to kinkos (gee, wouldn't be nice if the same
format was used for submission??)
  4) not reproduce the document exactly as designed, but get something out
anyway.

job ticket:
-----------
These are primarily composed of the same attributes as the Production
Hints, but apply only for a single submission. Such things as #copies and
overrides to the production hints would be appropriate here.

I just don't think the ipp control paradigm makes much sense for this
application. Does Safeway headquarters really care about the state of the
queues of the various copiers in the 3000 store branches? Or worse yet, at
the specific Copy shop in the vicinity of the store?

Admittedly, Safeway may be better off hiring an offset printer to do this
work since 3000*(number of employees at each store) is large enough to be
significant. I'm sure however, that if the example is broken, we could come
up with a reasonable example that would make this point.

The problem with the IPP point of view is _scale_. It doesn't scale up to a
one-to-many situation. It is a highly-coupled protocol which is quite
appropriate for internal printing, but, I claim, worth little for the big
picture....

See ftp://ftp.mfpa.org/jobs_wp.w (Word 2.0 format) for the white paper I
mentioned on this topic.

Regards,
-Raymond

---

From: Raymond Lutz <[email-masked]>
Date: Sun, 29 Dec 1996 13:13:50 -0800

I agree with your split between the two applications. As far as "overlap"
is concerned, there is still some indirect overlap, since the document
received in the fax submission process will still need to be submitted to
local devices. I would think that a minimum of reformatting the controls
already received would be a good design goal.

I have done my part and broached this issue, since it needed to be. I am
happy with the airing of the issue, so I won't further clutter the airwaves
until we get closer on the charter issue. At that point, maybe we can
revisit this issue and see if it makes any sense or not.

-Raymond

At 08:19 PM 12/29/96 +0100, [email-masked] wrote:
>The fundamental difference that hasn't been mentioned so far between
>the "print" paradigm and the "fax" paradigm is that in the "print"
>paradigm, I generally want to create hard copy for my own use, on
>equipment that I have some control over (usually controlled by the same
>organization).
>
>In the "fax" case, I usually want to move an image into equipment owned
>by someone else, and they have the right to have a VERY heavy influence
>on how it is handled.
>
>Let's get away from discussing overlap in the abstract and back to
>discussing the specific printer charter; I haven't yet seen a charter
>that I'd be willing to approve, so at the moment there is nothing to
>overlap with.
>
>                Harald A
>
>

---

From: Carl-Uno Manros <[email-masked]>
Date: Mon, 30 Dec 1996 17:54:46 -0800

>that I'd be willing to approve, so at the moment there is nothing to

Harald,

I had hoped that we had taken into account all the comments that
we got in San Jose, including yours, but you still do not seem happy
with the revised version I sent you just before Christmas.

Could you be a little more precise about what you think is still 
wrong with the latest proposal, so that we can get it fixed?

Regards,

Carl-Uno