IPP> RE: JMP> HELD vs NEEDS-ATTENTION

IPP> RE: JMP> HELD vs NEEDS-ATTENTION

IPP> RE: JMP> HELD vs NEEDS-ATTENTION

Patrick Powell papowell at dickory.sdsu.edu
Thu May 29 12:24:08 EDT 1997


Having thought about this,  I realize that I really don't care
WHICH form we use,  as long as there is ONE form (format) that is
common between the JMP and IPP protocols/standards.


Note:  while I want one set,  I wouldn't be opposed to two sets of 'names'
with a well defined (i.e. -cast into standard) mapping between the two sets.


Patrick Powell


	From: "Caruso,Angelo" <Angelo_Caruso at wb.xerox.com>
	Subject: RE: JMP> HELD vs NEEDS-ATTENTION


	There seem to be two extremes on this whole issue. On the one side 
	 there are those who would like all their favorite states included in 
	 one easy to use job state object. On the other side are those who want 
	 to keep the job state object ultra simple and have lots of job state 
	 reasons. Both points of view have been backed up by many good 
	 arguments. Last week at the IPP teleconference it seemed that a 
	 reasonable COMPROMISE was reached. Unfortunately, several key JMP 
	 folks were not present for that discussion and now we're waffling on 
	 the whole issue again. Based on todays mail volume there does not 
	 appear to be any end in sight.


	For the record, here is my position.


	IPP and JMP should use EXACTLY the same set of job states and the same 
	 state reasons (the agreement reached at the last IPP/JMP 
	 teleconference seemed reasonable to me). How are we to expect the PWG 
	 to be taken seriously if we simultaneously create two specifications 
	 with different job models? The rest of the world expects and deserves 
	 a consistent set of standards from this working group! Please don't 
	 respond again how easy it is to map between the two different state 
	 models. I understand the mapping because I have been following the 
	 discussions. But the rest of the world will not find the mapping to be 
	 so obvious. If we learned anything from the Printer MIB interop 
	 testing it is that interpreting ONE model correctly is hard enough. 
	 Now, we are on the verge of generating two different models to 
	 represent the same thing. It's time to find a compromise.


	Thanks,
	Angelo



More information about the Ipp mailing list