[IPP] {Disarmed} I've uploaded v33 of JPS2 for face to face; but 4 issues remain - PLEASE REPLY before the face2face

[IPP] {Disarmed} I've uploaded v33 of JPS2 for face to face; but 4 issues remain - PLEASE REPLY before the face2face

Tom Hastings tom.hastings at verizon.net
Thu Apr 1 00:33:50 UTC 2010


I've uploaded v33 of JPS2 for the face to face meeting next week:

 

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v23-20100330-rev.pdf

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v23-20100330-rev.doc

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v23-20100330.pdf

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v23-20100330.doc

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v23-20100330-clean.pd
f

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v23-20100330-clean.do
c

 

The change log for v33 and v32 is:


17.130 March 2010 (v23)


1.       Section 5.3 Close-Job Operation: Added sub-sections for Close-Job
Request and Response.

2.       Figure 4 - Sequence Diagram for 1 Hold, 1 Delay Output, and 4
Regular Jobs: Improved figure and added sub-states of Waiting for Marker to
the 'processing' state and Waiting for Processor to the 'processing-stopped'
state.


17.229 March 2010 (v22) - during telecon


1.       Fixed some things in Figure 1, Figure 2, and Figure 3.

2.       Figure 4 - Sequence Diagram for 1 Hold, 1 Delay Output, and 4
Regular Jobs:  Added this Figure.

3.       Section 12 IANA Considerations: Assigned the part number 11 for
this PWG 5100.11 document.

4.       Section 12.3 Type2 enum attribute value registrations:  Assigned
enum hex values to Cancel-Jobs (0x0038), Cancel-My-Jobs (0x0039),
Resubmit-Job (0x003A), and Close-Job (0x003B) - to agree with IPP 2.0
document.

 

There are still 4 issues to resolve.  I'd like to start the discussion on
the email list, since we have only three quarters of an hour at the face to
face.  They are:

 

ISSUE 1:  What "job-state-reasons" value should an implementation use that
is treating "job-delay-output-until[-time] the same as
"job-hold-until[-time]" and puts the job into 'pending-held':

'job-delay-output-until-specified' vs. 

'job-hold-until-specified'

 

ISSUE 2: We don't have a description for the new
'job-delay-output-until-specified' value to go into section 10.3 Additional
values for "job-state-reasons".

 

ISSUE 3: Is the Sequence Diagram Figure 4 OK (it is drawn for the
implementation that processes other jobs after the delay output job has
partially processed before the delay date-time arrives)?

 



Figure 4 - Sequence Diagram for 1 Hold, 1 Delay Output, and 4 Regular Jobs

 

 

Here is the current text for helping to resolve ISSUE 1 and ISSUE 2:


7.5   job-delay-output-until-time (dateTime)


The OPTIONAL "job-delay-output-until-time" Job Template attribute permits
the client to specify a date and time in the future after which the Printer
is to delay the output.  If the specified date and time has not yet arrived,
the Printer MUST set the job's "job-state-reasons" value to
'job-delay-output-until-specified'.  However, the Printer MAY perform
processing before the specified date and time occurs, but the Printer MUST
NOT produce any output until the date and time occurs.  

A Flow Diagram for Job Creation with the "job-delay-output-until-time"
attribute is shown in Figure 2 below.  A Sequence Diagram for a job with
"job-hold-until-time", a job with "job-delay-output-until-time", and 4
ordinary print jobs is shown in Figure 4 below.  The semantics of the
"job-delay-output-until-time" attribute are similar to the
"job-hold-until-time" Job Template attribute (see Section 7.6 and Table 6,
except that for the "job-delay-output-until-time" attribute the job is not
put into the 'pending-held' state while waiting for the date and time to
occur.  Instead, the Printer MAY process the job normally (i.e., by putting
the job into the 'pending' and 'processing' states).  However, the Printer
MUST NOT produce any output until the specified date and time occurs.  If
the Printer completes the processing and the specified date and time has not
yet occurred, the Printer MUST put the job in the 'processing-stopped' state
and MUST NOT delay processing or output for any other jobs while waiting for
the specified date and time to occur.  When the date and time does occur,
the Printer MUST remove the 'job-delay-output-until-specified' value from
the job's "job-state-reasons" attribute.  Then the job can be scheduled and
processed, i.e., the job enters the 'processing' state and produces the
output.

The current text has the following statement that allows an implementation
to implement "job-delay-output-until[-time]" the same as
"job-hold-until[-time]":

If the Printer implementation is not able to put such delayed output jobs
into the 'processing-stopped' state and process other jobs, the Printer
implementation MUST behave identically to that of the "job-hold-until-time"
attribute and put the job into the 'pending-held' state immediately (instead
of 'pending' and 'processing'), set the "job-state-reasons" to
'job-hold-until-specified' (instead of
'job-delay-output-until-specified')[th1] <>  , and wait for the specified
date and time to occur to begin processing the job (see the description of
the "job-hold-until-time" attribute in 7.6).  

 

 

I favor REQUIRING such an implementation that is behaving like
"job-hold-until[-time] to use the "job-state-reasons" value that goes with
"job-hold-until[-time], namely 'job-hold-until-specified', which (always)
holds the job in any implementation.

 

I thought it would be confusing to Printer implementers, clients, and users,
if the 'job-delay-output-until-specified' value either held a job or did not
depending on implementation.

 

Here is my proposal for the 'job-delay-output-specified' "job-state-reasons"
value to go into section 10.3 where the other new values are specified:

 

'job-delay-output-specified[th2] <>  ': The value of the job's
"job-delay-output-until" or "job-delay-output-until-time" attribute was
specified with a time period that is still in the future AND the
implementation is one which is able to partially process the job without
producing any output until the delay period occurs or the date and time
arrives while allowing other jobs to process and produce output in the
meantime.  This value MUST [th3] <>  be supported if the
"job-delay-output-until" or "job-delay-output-until-time" Job Template
attribute is supported with an implementation that starts processing the job
before the delay period occurs or the date and time arrives.  Otherwise, the
implemenation MUST use the 'job-hold-until-specified' value.  See sections
7.4 and 7.5.

 

It is parallel to the [rfc2911] 'job-hold-until-specified' value which is:

'job-hold-until-specified':  The value of the job's "job-hold-until"
attribute was specified with a time period that is still in the future.  The
job MUST NOT be a candidate for processing until this reason is removed and
there are no other reasons to hold the job.  This value SHOULD be supported
if the "job-hold-until" Job Template attribute is supported.   

 

Please reply with comments before the face to face.

 

Thanks,

Tom

  _____  

 [th1] <> ISSUE 1: OK that such an implementation MUST set the
"job-state-reasons" to 'job-hold-specified', instead of
"job-delay-output-until-specified', so that
"job-delay-output-until-specified' is NEVER a hold reason?

 [th2] <> ISSUE 2: This description OK?

 [th3] <> ISSUE 4: OK to make this a MUST when RFC 2911 has SHOULD?


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20100331/8843e7ca/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 11070 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20100331/8843e7ca/attachment-0001.gif>


More information about the ipp mailing list