>Do others in the Sense group agree with Tom's approach, or would you
>prefer to take my previously published approach of "starting from the
>beginning" and getting the basics down first?
I have to say I agree with Tom to a large extent. IPP and the Job MIB
rely on each other. The main thing missing from the Job MIB are events.=
While some of us have implemented private registration and filters for
clients desiring Job MIB feedback, the JMP, as a team, stopped short of=
standardizing job events due to the perception of insurmountable SNMP
limitations and/or the fact that SNMPv3 is addressing these issues.
Job MIB / IPP event profile...
Consumers - Anyone who has submitted a print job and wants to know it=
's
position/progress
- Job tracking/accounting applications that want to know wh=
en
a job has completed so they can "harvest" final values
- Printer and/or print "farm" operators who need to track j=
obs
or who have, effectively, become "end-users"
Publishers - IPP/JobMIB/SENSE printers
- IPP/JobMIB/SENSE print servers
Events - Job (id) Pending,
- Job (id) Printing,
- Job (id) Page n of m Printed,
- Job (id) Copy x of y Printed,
- Job (id) Interrupted (reason),
- Job (id) Finishing Complete,
- Job (id) Complete,
Event message - This needs some thought, but along with each event some=
additional information could be carried, like "octets processed, total
octets" or "position in queue" - as overall progress indicators thus
utilizing the fact that each job will generate several events to overco=
me
the possibility of an individual datagram being lost.
Of course, my simplified event profile in no way covers all of DPA and
probably doesn't follow IPP or the JobMIB strictly - it's just a pragma=
tic
example.
Harry Lewis - IBM Printing Systems
---- Forwarded ---
owner-sense@pwg.org on 11/04/97 12:12:26 PM
Please respond to owner-sense@pwg.org @ internet
To: hastings@cp10.es.xerox.com @ internet
cc: sense@pwg.org @ internet
Subject: Re: SENSE> Where to go from here?
Tom,
I'm not sure we're on the same wavelength here. Maybe you can help
me understand your position a bit more clearly.
> To followup on the suggestion for a bottom up approach for embedded
> implementation, I'd like to suggest that it be for an embedded IPP
> printer. (Jay, consider this a second 2x4).
Talking about requirements for an embedded IPP printer is fine,
however it should be noted that Sense pre-dated IPP by over a year,
and I really don't want to ignore the original requirements.
(And thanks anyway, but one 2x4 is enough for me right now.)
More importantly, though, is the need to get a firm consensus on
the underlying requirements of event notification in the printer
environment. That is, before we talk "spec" with regard to IPP,
we really should be talking about the general feature requirements,
including proposed scenarios described who needs what kind of events,
and what kinds of components are expected to handle those events.
> There should be a white paper that describes the scenario for bringin=
g
> up a SENSE server and the IPP printer with an embedded publisher.
>
> [...snip...]
>
> The white paper that I'm proposing is like a MIB spec.
If you want to see such a white paper *very* quickly, then perhaps
you can write one yourself?
> Also forget the requirements. SENSE is obviously very general.
> No one is questioning that. Lets "cut to the chase" as you are fond
> of saying, and get a spec for IPP's use of SENSE. Maybe you even nee=
d to
> coin a term for the spec that says how a particular set of developers=
> use SENSE for a particular application, something like a "SENSE profi=
le".
Forget the requirements? Beg your pardon?
Sure, I like cutting to the chase, but that doesn't mean you
jump clear over the primary issues that need to be resolved.
> I think we need an IPP profile spec first. Then we can see if there =
also
> needs to be a general printing profile, or whether the IPP profile re=
ally
> works for most printing.
Sure, that is certainly one approach to spec'ing out things. But
as I said earlier, we first need to talk about what an "event" is,
and who (and what) produces/consumes an event.
> So the IPP profile spec needs:
>
> 1. List the publication properties by name and semantics. Tying them=
> to IPP attribute semantics will make this much faster to write and
> understand.
>
> 2. List the edition propertied by name and semantics. Same as the
> publication properties.
>
> 3. Indicate the scenario of populating the SENSE server. Who does wh=
at.
I don't think we should be necessarily talking about a "Sense server"
at this point. Instead, let's just focus on the producers and
consumers of events, then see where we go from there.
I think it was Carl-Uno who said (during the Boulder meeting) that
he'd like to see how Sense would work without having an intermediate
server. Upon further consideration, I now tend to agree. And that's
what I believe the Sense project should be focusing on at this time.
> People will go read the SENSE documentation to get what they don't
> understand from the first draft "SENSE IPP Profile".
As a generic observation, that's a good point, Tom.
Do others in the Sense group agree with Tom's approach, or would you
prefer to take my previously published approach of "starting from the
beginning" and getting the basics down first?
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@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 --
----------------------------------------------------------------------
=