My comments on Ron's updated definitions

My comments on Ron's updated definitions

Tom Hastings hastings at cp10.es.xerox.com
Tue Oct 1 02:36:02 EDT 1996


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: <pwg-owner at pwg.org>  
From: rbergma at 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 at pwg.org"@gate.dpc.com  
		^		 ^-missing end of address  
		 \-extraneous tokens in address  
Apparently-To: pwg at pwg.org  
To: <hastings at cp10.es.xerox.com>  
Subject: RE[2]:Updated Definitions for the Job Monitor Project Sender:  
owner-pwg at 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 at dpc.com  
  



More information about the Pwg mailing list