TH> My comments are prefixed with TH> TH> If anyone cares to add more comments, I suggest that they TH> also prefix their initials to their comments so we can tell TH> from whom they came in this single document. TH> Tom Return-Path: From: rbergma@dpc.com Date: Mon, 30 Sep 1996 09:15:34 PDT Illegal-Object: Syntax error in To: address found on alpha.xerox.com: To: gate"pwg@pwg.org"@gate.dpc.com ^ ^-missing end of address \-extraneous tokens in address Apparently-To: pwg@pwg.org To: Subject: RE[2]:Updated Definitions for the Job Monitor Project Sender: owner-pwg@pwg.org I want to thank Jay Martin, Gail Songer, and Scott Isaacson for the comments on my latest posting for the Job Monitor Project. We may get more done outside of the meeting than will be accomplished in NYC!!!! Jay wrote in response to my proposed JMP agenda: > Before making a couple of comments, I should mention that perhaps I am > not quite up to speed on the latest draft for the MIB objects. Do you > think you could post a pointer to the path of the file (on the ftp > server) that contains the latest draft? My draft was posted via email on 26-SEPT titled "Updated Definitions for the Job Monitor MIB". The original document from Tom Hastings was distributed at the July meeting (Portland) and should be on the pwg-ftp site as jmp-spec.doc & .ps. (I am not able to verify this since I can only access the ftp server from my home.) TH> The spec with the agreements from the July meeting was posted one TH> week before the August meeting on 20-Aug in: TH> ftp://ftp.pwg.org/ftp/pwg/snmpmib/jobs-mib/jmp-spec.doc .psr > Some comments about your posting: >> I propose that jobCopiesRequested" be change to >> "jobCopiesCompleted" and moved into the accounting group. The >> remaining items should be removed. > Could it be that both kinds of objects are desirable? (Yeah, this > coming from the person who says "No more than 20 objects!!"...) > If we support both, then would we have reasonable measure of relative > completion for the job? (Or is "job progress" better denoted from > other proposed objects?) My original thought was the user knows how many copies he requested and only needs to know how many have been completed. But on second thought, some users (myself included) have a short memory and also someone other than the person who submitted the job may find this a useful parameter. Sounds like a keeper. GOOD POINT!!! TH> Also remember that there are two roles of users that the MIB is TH> trying to help: end-users and operators. The operator needs to TH> know how many copies are requested. >> 4. What value does "jobName" add to the identification group? Is >> this value sufficient to warrant the inclusion of this object? >> I propose that this object be removed. > Just as in our recent discussions about the need for an "administrative > name" for a printer (in the Printer MIB), it would seem both natural and > useful to have an equivalent object for a job. Anyone else out there > have a similar feeling? (Or counter-feeling?) We presently have (using the names from my email) jobName and also jobDocument, which is the name of the document. The proposal was jobName would be unique and jobDocument would not, for the case where the same file was submitted multiple times. My real question is: Can this be supported by current job submission protocols and is it of any value? The time stamp can be used to determine the order the jobs were submitted and does provide some uniqueness. (I just do not want to include too many objects that will never be used.) TH> Both DPA and FTP have separate concepts of job name versus TH> document name. But in both protocols, neither is necessarily TH> unique. Both supply the end-user with a convenient handle on TH> the job and document in the job. In both protocols, there can TH> be more than one document per job, so that it is important to TH> have separate concepts. For implementations that don't support TH> multiple documents per job, the document table will only have TH> one entry, so no big overhead to have the document name in a TH> separate table. >> 5. Are items #2 and #3 in the identification group needed? These >> objects appear to provide only routing information. I do not >> feel that routing information adds any value for job monitoring. >> These objects do not add any significant information required >> for job identification. > Quite frankly, tackling the problem of "job routing" is pretty scary > to me. My biggest fear along this line is that in order to maintain > integrity of the MIB data for a job, several (relatively) independent > processes--quite likely on different network hosts--will have to update > certain job values at certain times. This could be a real killer, both > in terms of implementation and access control. > Anyone else share these feelings? I believe it is obvious that I do!!! Any thirds? TH> These upstream and downstream ids become necessary if there TH> are more than one entity in a given system that implements the TH> Job Monitoring MIB. For example, a printer, a supervisor, and TH> a spooler (or a Novell forwarding printer agent). Each entity TH> assigns its own job id when it receives the job. If software TH> and/or an operator needs to reconcile the information from two TH> different agents in order to relate a job contained in one with TH> the forwarded copy in another, there needs to be a way to understand TH> how the job ids map. > One last comment, of a general nature. Could it be that in order to > satisfy DPA-related capabilities, we should define TWO Job MIBs, one > for "basic" needs, and a second version that augments the "basic" > version? This is a good suggestion!!! I encourage Tom Hastings to comment! TH> I think that having a basic MIB and another that augments the TH> basic MIB maybe a good idea. Then this more complicated stuff TH> like these Ids can go into the second MIB, provided that the TH> second MIB can augment the first. TH> Could the basic MIB be for end-users and status/accounting TH> and the second MIB be for operators with job parameters TH> and the complicated upstream, downstream job id objects? TH> A separate question is whether we do both MIBs in parallel TH> or as separate projects one after the other? TH> An alternative is to have the TH> additional groups in the same MIB, but under conditional mandatory TH> rather than required, provided that there is a clear specification TH> as to when the conditional mandatory group becomes mandatory. Jay also wrote in response to my updated definitions: > Some comments and questions on the object definitions: >> 2. jobIdOnPktSrc: (String, max TBD) This object specifies ..... > What is the significance of the "Pkt" portion of the name? That is, > what does it stand for? (Packet?) I believe that it was to mean "Packet". To be honest, I did not put a great deal of though into this name. Note that this is one of the objects that I would like to remove. If we decide to keep, it deserves a more descriptive name. >> 4. jobIdOnDevice: (String, max TBD) This object identifies the job on >> the device which is currently processing the job. The processing device >> includes, but is not limited to, printers, faxes, scanners, spoolers, >> and files servers. The value of this object may change for systems that >> include intermediate devices such as file servers and spoolers. > The last sentence in this paragraph is pretty scary IMHO. When it says > "The value of this object may change...", what does this mean exactly? > Does it mean the format will (may?) be different depending on the types > of intermediate systems? Or does it mean the value (and possibly the format) > may change during the life of the Job? My intention here was to allow one object to be specified regardless of the device that currently has the job. For example, in the model that contains an external spooler; When the job is in the spooler waiting for the printer, the spooler would provide its internal job identifier. When the job is passed to the printer, the job id would change to that of the printer. (A means of determining which device is currently reporting may also be required. I originally thought that one of the other proposed objects would provide this. But now that I look again, a new object may have to be included.) This object should not be required to identify the job. The combination of jobIdOnClient and jobOwner must uniquely identify the job. This object would allow identification of this job if another method of interrogating the device was to be used. I don't feel that this object is critical for this MIB.) TH> We are getting confused as to which ids we are talking about. TH> The agreements from Portland (reflected in the Aug spec which TH> no one seems to be reading) are: TH> 1. Job client id (on the original client) TH> 2. Job upstream id (upstream from the server implementing this JM MIB) TH> 3. Job current id (on the server implementing this JM MIB) TH> 4. Job downstream id (downstream from the server implementing this JM MIB) TH> Number 3: Job current id is very much required, since that is TH> assigned by the server receiving the job. In DPA and BSD, the TH> server assigns unique job ids, since they are under control of TH> the server that is receiving the jobs. Without the server TH> quarantee that the job ids are unique, the server is lost, since TH> we can only encourage clients to generate unique ids, but we can't TH> force them to. TH> Perhaps the other ids could go into a second MIB? >> 5. jobType: (enum) This object specifies the type of service requested >> to process the job. > Can we get some examples here? Sounds like an interesting object, but only > if a *single* parameter can reasonably denote the service required. You reminded me that this issue was discussed in Portland. The agree- ment was to make this a bit-mapped word. This would allow a job to be print, fax, etc. (I should have read the minutes!) TH> Yes, the updated Aug spec from the July Portland meeting TH> has the enum bit encoded to show the following TH> Print(0): The job contains some document production instructions that specify printing Scan(1): The job contains some document production instructions that specify scnning Fax in(2): The job contains some document production instructions that specify receive fax Fax out(4): The job contains some document production instructions that specify sending fax Get file(8): The job contains some document production instructions that specify accessing files or documents Put file(16): The job contains some document production instructions that specify storing files or documents Mail list(32): The job contains some document production instructions that specify distribution of documents using an electronic mail system. >> 6. jobOwner: (String, max TBD) This object identifies the client that >> submitted the job. The method of assigning this name will be system >> and/or site specific but the method must insure that the name is unique >> to the network visible to the client and target device. > Warning, Will Robinson!! Ensuring network-wide uniqueness is virtually > impossible without some stated rules. For example, this value could be > relatively arbitrary, but MUST have (as a prefix, or suffix, or whatever) > a valid, fully-qualified hostname, or something like that. I agree 100%. This will be added to my action item list. (Assigned to Will Robinson!!!) TH> Why does the name have to be network unique in the MIB? TH> I would hope that job owner would be network unique within TH> a particular job submission protocol, but a device might TH> be supporting serveral job protocols at once. While it might TH> be nice to require network uniqueness across the network and TH> across all job submission protocols, I don't see how we can TH> guarantee it, unless we require the SNMP agent to prefix the TH> job owner within a job protocol with a prefix that identifies TH> the job submission protocol, sort of TH> like a URL. So maybe we could require uniqueness in this object. >> 7. jobChannel: (enum) This object defines an equivalent to the print >> job delivery channel as defined in the Printer MIB. >May god forgive us all. ;-) If jobMagicCookie works, this may not be needed!!! >> 8. jobMagicCookie: (??) This object defines the protocol path from the >> physical layer to the jobChannel. The format of this object will be >> similar to the work in process for the Printer MIB. > The use of the term "protocol path" to describe this kind of "wartly" > object is interesting. Is this a reasonable term? Does it really express > the concept? (Whatever that may be.) Note that the corresponding object > in the Printer MIB does not attempt to define such a concept as "protocol > path" Perhaps it should? It seems to me that a "protocol path" is what we would like to define. TH> Can you give an example? >> 10. jobDocument: (String, max TBD) This object defines a name for the >> job. The name is typically expected to be the file or file/path name of >> the source of the job. The name does not need to be globally unique. >> (The name would typically be repeated if several jobs from the same file >> are simultaneously in the job queue.) > How is this different than "jobName"??? My point exactly. (See comments on jobName) TH> It is important for those protocols that support multiple TH> documents per job: DPA, LPD, PostScript and PCL, to name a few TH> that more than one document name be permitted for a job when TH> that job has more than one document. TH> In the Aug spec from the July Portland agreements we have: TH> 9. Job name (assigned by job owner) TH> 10. Document name(s) (or file-names) >> 13. jobDeviceName: (String, max TBD) This object specifies the >> administratively defined name of the target device. > I would strongly suggest that the value for this object be the same as > the new "administrative name" object in the Printer MIB, iff the target > device is Printer MIB-compliant, etc. Although I did not explicitly state, this is my intention. TH> Already agreed to in Portland and in the August spec as: TH> Corresponds to the new object being added to the Printer MIB: TH> prtGeneralDeviceName >> JOB PARAMETERS: >> >> *** THE VALUE OF THESE PARAMETERS HAS BEEN QUESTIONED, *** >> *** SINCE THIS IS NOT A JOB SUBMISSION PROTOCOL *** >> *** PROPOSE THAT ONLY THE ITEMS THAT INDICATE STATUS OR *** >> *** PROVIDE ACCOUNTING INFORMATION BE RETAINED !!! *** > You're right, Ron. Drawing the line between "monitoring" and "submission" > can be quite difficult. Perhaps these objects can be deferred to the very > end of the project; that way if a project gets started for a standard > network printing protocol, these two efforts can be combined to create > commonly defined objects, etc. Good point!!! TH> I disagree. We keep forgetting that either end-users or the TH> operator may want to see what key job submission parameters are TH> on the job, so that they can check what is going to happen. TH> Especially, if the operator is involved in scheduling or TH> changing devices to accommodate jobs that have been waiting a TH> long time for, say, transparencies to be loaded, or, say B size TH> paper, instead of transparencies, etc. TH> See Goal U2 - The current states fo the user's job (user queries) TH> See Goal OP3 - What resources does each job need. TH> I've copied the agreed goals from the charter to the front of TH> of the jmp-spec.doc, so we won't forget our agreed goals. >> STATUS AND ACCOUNTING PARAMETERS: >> >> 1. jobState (enum ?) This object defines the current state of the job. >> (e.g. queued, printing, completed, etc.) > Seems like a good object, but we won't know until someone posts a proposed > list of states. Only then will we be able to know how applications will be > able to use this object (if at all). I do believe that this will be a difficult part of the project. But this will be a very important parameter to have available. TH> The current spec (jmp-spec.doc) from July and August has a TH> complete set of job states with descriptions and a state diagram. >> 2. jobStateReason (bit map) This object provides additional information >> regarding the the jobState. > A bit map?? That would make it a finite set, right? If so, then someone > should post some example values. I expected this would require more work. A text string may also be appropriate here. TH> The current spec has a long list of job state reasons taken TH> from ISO DPA, X/Open PSIS, and even lists which reasons go with TH> which job states. TH> I agree that a job-state-message object is needed, in addition to TH> the bit map. Then an implementation can further refine the TH> job state and job state reason. However, such a text string TH> can only be for humans, not for programs to take action on, TH> so we need the bits too. TH> The jmp-spec.doc already has such an object: TH> 4. Job State Reason Message >> 3. jobDeviceUsed (hrDeviceIndex) This object identifies the physical >> device or devices used to complete the job. >> *** FURTHER WORK IS REQUIRED TO DEFINE THIS OBJECT AND *** >> *** ITS RELATION TO THE REMAINING OBJECTS !!! *** >> *** SHOULD A SEPARATE PACKET BE RETURNED FOR EACH DEVICE OR *** >> *** TRY TO COMBINE ALL INTO ONE ??? *** >> *** HOW IS ALL THIS INFORMATION TO BE COMBINED ??? *** > Not sure what you mean about having a "separate packet be returned for > each device". Can you explain a bit more on this? This object is derived from the DPA set to account for multiple devices used to complete a job. If the job MIB is resident on each of these devices, then a supervisor must either get the separate information from each device and combine or return each as received from the individual devices. If a combined pack is returned, do we need to identify the relationship between the other objects and the devices? TH> The jmp-spec.doc has this object: TH> 2. Physical device(s) being used TH> and says that this object is a table that contains TH> the hrDeviceIndex for each device that this job is using. TH> So the NMS can go to each device MIB (printer MIB, etc) and TH> get the status. TH> On the other hand, if we don't want the Job Monitoring MIB to TH> require implementation of other device MIBs, we could add TH> a second object in this table that has the device state for TH> the device. The first object could be left empty if there is TH> no corresponding device MIB. >> 4. jobOctetsCompleted (Counter64) This object defines the number of >> octetes currently processed by the device. For multiple copies >> generated from a single data stream, the value shall be incremented as >> if each copy was printed from a new data stream without resetting the >> count between copies. > What is the rationale for handling copies in this manner? Doesn't it > seem useful to know how many data bytes actually flew across the network > as part of the job? Yeah, you could use a "copies completed" object to > derive the actual bytes transferred, but really, what value is having > a total byte count calculated in the manner described above? Perhaps > a real world application scenario description would help here? Again, this is from the DPA set. I agree with your comment and propose that this be changed to jobOctetsReceived. TH> Lets discuss. The reason that DPA defines the octet count TH> the way it does, is so that the user can determine the progress TH> of the job, no matter whether the implementation prints the TH> the copies on one device or several, whether the printer TH> prints an entire copy and then the next, or whether it prints TH> all copies of each sheet and put it into a collater. TH> So if the user knows the size of the job and the number of TH> copies, the user (or the NMS) can put up a good thermometer for TH> how far the job is completed, independent of the actual technique TH> used to make multiple copies. TH> It seems to me that its only network gurus that might want to TH> know how many bytes have been transferrred over the network TH> to the device. For devices that buffer and/or spool the job TH> the octets received indicate nothing about how far along the TH> job is as far as producing sheets. TH> Remember goal OP5: Some idea of how long each job will take. TH> octets-completed gives a running estimate of how the job is TH> progressing, independent of technology. TH> So it seems much more useful to have the DPA octets-completed TH> than the number of octets transferred to the device. >> 11. jobWarningCount (Counter32) This object contains a count of the >> number of warning events that occurred during the processing of the job. > Without being able to know what kinds of warnings occurred, what is the > value of this object? That is, what are the semantics of the job entry > if this value is non-zero? (That is, what can/should an application do > if this value is non-zero?) This object only provides an indication of a problem. Do we need to include further details? Anyone care to comment? TH> The warning count provides some feedback to users and operators TH> as to whether the job is encountering recoverable conditions, TH> such as font not found or image exceeding imageable area, etc. TH> These two objects help with goal U2: "The current status of the TH> user's job (user queries)" and goal U3: "Error and diagnostic TH> information for jobs that did not successfully complete" since TH> the warning and error count remains even if the job is aborted. >> 12. jobErrorCount (Counter32) This object contains a count of the >> number of error events that occurred during the processing of the job. > Same comments as #11. Ditto! TH> Errors are more serious, than warnings. TH> It is up to each system and PDL interpreter TH> what is considered a warning and what TH> is considered an error. There is no way that our MIB will TH> specify. Its is just useful to have both errors and warnings TH> in my experience for designers and implementors to count separately. >> 13. jobPositionInQueue (Counter32) This object indicates the number of >> jobs preceeding this job in the print queue. > This sounds like an implementation problem. If it is expected that the > agent maintains all jobs as entries in a job table, then isn't the job > index a better qualifier for this kind of information? If this object > remains as described above, then every time a job is removed from the > table (due to completion of processing), then ALL OTHER job entries will > have to have this object updated. This is not a typical situation in > MIB-land, is it? (Sounds like a real implementation pain, both for the > agent and the mgmt application.) I am not sure that I fully understand this comment. If the value of the object is generated upon request there should not be a problem. We can discuss further. TH> Yes, there is no need for a agent to keep data up to date, just TH> on the off chance that an SNMP Get might come. The agent can TH> wait until it gets a Get request to compute the value of certain TH> objects. The jobPositionInQueue is just such an object. TH> The job table itself is probably ordered by submission time of the TH> job, but that is not mandated. So the order of the jobs to TH> print depends on the scheduling algorithm and is not always TH> FCFS. So this object is the number of jobs likely to run before TH> this job gets a chance. TH> The jm-spec.doc has the object as: TH> 13. Number of pending jobs currently scheduled to process before TH> this job. (number-of-intervening-jobs) TH> We probably want to not require a queue, since some implemenations TH> don't have queues. So number-of-intervening-jobs TH> (numberOfInterveningJobs) is probably a better name. >> 19. pdlUsed (enum) This object defines the PDL(s) used by the job. > It would seem imperative to reconcile this object to the equivalent > Printer MIB object, no? Yes. TH> The jm-spec.doc indicates that the data type is: TH> PrtInterpreterLangFamilyTC from the Printer MIB TH> and that it is a table for each job, since a job can use TH> more than one PDL. > All in all, things are coming along. This is good. However, we still > seem to be floundering with respect to having solid, proven rationale > for many of these objects. (What problem are we trying to solve? And > how does this object solve that problem?) > This may seem like a bit of a strange proposal, but do you think it would > be useful to assign a "sponsor" for each of the proposed objects; that is, > have a person responsible for the definition, qualification and rationale > for each object? That way when a question arises, that person would be > the one to respond and otherwise "defend" the object as necessary. Good point!!! If Tom Hastings gets this email in time I would recommend that we try to start obtaining "sponsors". Otherwise, I will make this an issue in November. TH> I think that we should also use our goals from our charter that TH> I've copied to the front of jm-spec.doc. How about indicating TH> for each object which goal or goals the object is addressing TH> perhaps in priority order? Gail wrote: >>5. jobMedia (?) This object indicates the media used for this table >>entry. I propose that this be the prtInputIndex. Information regarding >>the media can then be obtained from the Printer MIB. > This is the same assumption that TIP/SI makes: the paper that is currently in > the tray is the same as the paper that WAS in the tray when the job was > printed. > While most of the time this is true statement, it is not a guarantee. If this > mib is to be used as an accounting tool, don't we want to provide accurate > information? Another good action item. Any "sponsors"? TH> Since accounting is one of our goals (see jm-spec.doc): TH> "A1: A record of resources used and printer usage data for TH> charging uses or groups for resources used." TH> we have to record the media for a period after the job completes TH> and for which the media could be changed for the next job. TH> Also identifying media like any other resource makes media TH> not special. See objects 15-18 in jm-spec.doc: TH> "15. Consumables consumed. Presumably a type (enum) indicating the TH> kind of resource, a name (text string) for each resource, and an TH> amount (and maybe an enum to indicate what units the amount is in). TH> Relates to Resources requested. TH> TH> 16. consumable name TH> TH> 17. consumable-unit TH> TH> 18. amount-consumed" ----------------------------------------------------------------------- Ron Bergman Dataproducts Corp rbergma@dpc.com