I guess I'm a bit disappointed by your response in which you appear
to give credence to Tom's rather rash, "skip the requirements"
approach to progressing Sense.
Apparently neither of you got the gist of my earlier message in
which I stated that we had to get back to basics so that people
can understand how the current Sense architecture resulted in the
way that it did.
First things first, though. We REALLY NEED to get a consensus on
the basic requirements for Sense, and then talk about protocol
implications with respect to specific components we expect to have
involved in the exchange (ie, production/consumption) of events.
You've done a great job of making the initial sketch of the key
requirements specific to IPP/JMP (ie, producers, consumers and
initial set of high-level events).
Now what is needed is a discussion surrounding protocol considerations
and potential constraints. This topic is addressed in the Sense
requirements document, and I'd really like to get group consensus
on that document's contents before we proceed.
Fair enough? Or do you (or Tom) think we'd be wasting the group's
time talking about core requirements, etc?
...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 --
----------------------------------------------------------------------
Harry Lewis wrote:
>
> Jay asked...
>
> >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 when
> a job has completed so they can "harvest" final values
> - Printer and/or print "farm" operators who need to track jobs
> 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 overcome
> 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 pragmatic
> 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 bringing
> > 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 need 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 profile".
>
> 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 really
> > 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 what.
>
> 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 --
> ----------------------------------------------------------------------