Harry, Jay, et al,
Harry has posted the original request quite some time ago and I have not
seen any objections. The new proposal is "close enough" to the original
that I doubt that it will raise any objections.
Unless a comment is received by the end of this week, the proposal is
declared accepted!!
Ron
On Thu, 20 Nov 1997, Jay Martin wrote:
> I haven't done due diligence on your proposal, Harry, but I believe
> the proposal is acceptable as presented. It's also pretty apparent
> (or should be to most folks by now!) that you are not proposing
> "theoretical" additions; instead, these proposals are the direct
> result of IBM's current product development surrounding the proposed
> Job MIB.
>> Real world needs always out-weigh those proposals submitted in the
> vein of "just in case someone needs it"... ;-)
>> Ron (Mr. Chairman): would a "deadline for objections" be possible
> so that Harry et al can get a better handle on planning?
>> ...jay
>> ----------------------------------------------------------------------
> -- JK Martin | Email: jkm at underscore.com --
> -- Underscore, Inc. | Voice: (603) 889-7000 --
> -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
> ----------------------------------------------------------------------
>>> Harry Lewis wrote:
> >
> > I tried to send this a couple times... appoligize if older versions catch up
> > later.
> >
> > There hasn't been a whole lot of discussion regarding my proposal (below) other
> > than Ron indicating he believes it should be accepted.
> >
> > I would like to modify it slightly, in a manner which I believe better
> > accomplishes the goal of distinguishing between collated and uncollated copies
> > yet results in fewer changes to the Mib.
> >
> > To put it as simply as I can, I propose to add
> >
> > currentCopyNumber
> > currentDocumentNumber
> > copyType
> >
> > and to keep
> >
> > sheetsCompletedCurrentCopy
> > impressionsCompletedCurrentCopy
> > documentCopiesCompleted
> > jobCopiesCompleted
> >
> > The example flows the same as before:
> >
> > For a 3 impression job with a request for 3 copies.
> >
> > Uncollated 3/3 (copyType = External Collation)
> > --------------
> >
> > sheetsCompleted sheetsCompletedCurrentCopy currentCopyNumber
> > --------------- -------------------------- -----------------
> > 1 1 1
> > 2 1 2
> > 3 1 3
> > 4 2 1
> > 5 2 2
> > 6 2 3
> > 7 3 1
> > 8 3 2
> > 9 3 3
> >
> > Collated 3/3 (copyType = Internal Collation)
> > ------------
> >
> > sheetsCompleted sheetsCompletedCurrentCopy currentCopyNumber
> > --------------- -------------------------- -----------------
> > 1 1 1
> > 2 2 1
> > 3 3 1
> > 4 1 2
> > 5 2 2
> > 6 3 2
> > 7 1 3
> > 8 2 3
> > 9 3 3
> >
> > The reason for the change from currentSheetNumber and currentImpressonNumber is
> > that there may be several sheets in the paper path, (different) impressions may
> > be ripping and printing at the same time etc. It's very hard to say which is
> > the "currentImpression" or "currentSheet" but easier to say which is the
> > current copy. It is easy to say which sheet has just completed (stacked).
> >
> > Note that, while drivers should protect from this, it is theoretically possible
> > to mix collated and uncollated copies (try it with your favorite printer...
> > it's fun!). At this point, attributes like current copy really break down. We
> > feel, rather then try and define even more attributes to handle this
> > pathological case we should just say behavior of the MIB, at this point, is
> > device specific.
> >
> > Harry Lewis
>