Subject: IPP>MOD - Jay's comment on complexity

From: Roger K Debry <[email-masked]>
Date: Thu, 20 Mar 1997 11:02:42 -0500

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

I agree with Jay. The model document often seems overly complex to me.
However, I understand the need to have a standard that scales from a small
workgroup to a large multi-campus enterprise, and cover normal office printing
as well as production printing.  I'm anxiously awaiting to see what we can do
in the conformance section to keep things simple for the simple case.

---

From: Tom Hastings <[email-masked]>
Date: Thu, 20 Mar 1997 14:05:11 PST

I agree with Roger.  Lets make sure that Jay and Harry are participating
when we discuss the conformance to IPP, so that we can make the simple
case simple to implement.

Tom

---

From: [email-masked] (Robert Herriot)
Date: Thu, 20 Mar 1997 17:36:40 -0800

I also have a concern about creeping complexity. I don't expect we will
resolve this issue for the March 26 draft, but I think that a major
thrust of our effort in the next month or so should be to tighten up
the model so that it keeps the simplicity that we all seem to want.

I feel like the feature creep comes from trying to solve too many
marginal problems. This suggests to me that the requirements document
isn't complete.  It doesn't address the issues that are leading to this
complexity. Instead, it mostly deals with issues that are entirely
outside the scope of the model. I have tried to get these issues into
the requirements document, but have not succeeded. I believe that the
requirements document needs to state the support or lack of support for
scenarios like fan-in, fan-out, attribute defaulting and other issues
that are adding to the model complexity.

Let me illustrate where part of the problem lies.  Fan-in has been a
hot issue in email messages today.  It exists for a world where the
user cannot control feature selection directly through some client
interface and instead controls feature selection via printer
selection.  Perhaps, we should assume that clients can select printer
features directly. The requirements document is silent on this whole
issue.  Fan-in also exists to restrict access to some features by some
users.  But I wonder if this requirement is also too marginal to deal
with for version 1.0.  

Fan-in is easy to address at the end-user level -- we just pretend they
are separate printers.  But at the administrative level, they will
become a nightmare.  For example, if an administrator changes the value
of media in Printer A, does it also affect Printer B if both A and B
fan-in to output device X. The answer should be yes because the paper
is really in X and both A and B are really just views of X. But if B is
intended to offer a restricted view of X, then perhaps the answer is no
because B should not have access to whatever was changed.

Bob Herriot

---

From: Harry Lewis <[email-masked]>
Date: Fri, 21 Mar 1997 10:03:42 -0500

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

Bob gives us an excellent outline of one specific area of complexity.

>Bob Herriot

I know there is a natural tendency to say "... but these problems must be
addressed".

I would just like to point back to development of RFC1759 where we also
addressed
fan in (ala MIB-II Interfaces Table) and fan out (ala hrMIB). These two topics
took up
a very large percentage of the RFC development time, introduced the most
convoluted
form of complexity and, today, are the least useful and most misunderstood,
mis-implemented portions of the Standard.

In the case, above, if A and B fan into device X, and the administrator changes
media
in X, then media really has changed for A and B, hasn't it? Restrictions on
choice of
media are probably best handled at the client or within the DPA layer, not at
the device.
Administrators have to use their heads, too. If they're changing media to
"blank checks"
I doubt they're going to rely on RFC2xIPP to prevent someone from inadvertently
winning the lottery.

Harry Lewis - IBM Printing Systems

---

From: JK Martin <[email-masked]>
Date: Fri, 21 Mar 1997 11:37:35 -0500 (EST)

I agree entirely with Harry's and Bob's recent comments on the complexity
issue.  (I'll try to call out some other complexity issues Real Soon Now.)

Bob really hit the nail on the head, though, with his discourse on the

> because B should not have access to whatever was changed.

After reading Bob's comments, I come away with the belief that if we
the PWG (representing the bulk of the printer and printing systems
industry) want to advance the state of printing in general, then we
should NOT support the existing "crutch" of "virtual printers" that
exist solely as a means of providing default job attributes.

I do, however, like the general concept of providing a "catalog" of
pre-formed "job tickets", similar to that found in NetWare.  (Similar
approaches have been taken using the general "forms" concept.)  However,
implementing such a capability via multiple "printer instances" results
in an absolute mess when you deal with the management and operational
aspects of the printing system.

I'd sure like to hear others' opinions on this subject.

	...jay