I've uploaded v24 [sic] of JPS2 for the face to face meeting today:
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v24-20100406-rev.pdfftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v24-20100406-rev.docftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v24-20100406.pdfftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v24-20100406.docftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v24-20100406-clean.pd
f
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v24-20100406-clean.do
c
I answered the four issues listed below myself, since no one else responded.
The change log for v24 is:
17.16 April 2010 (v24)
1. Section 7.4 job-delay-output-until (type3 keyword | name(MAX)),
Section 7.5 job-delay-output-until-time (dateTime), and Figure 4 - Time
Sequence Diagram for 1 Hold, 2 Delay Output, and 4 normal Jobs: Added new
'job-delay-output-until-suspended' value for "job-state-reasons" attribute
when the job is suspended in the 'processing-stopped' state waiting for the
delay period or date-time to arrive.
2. Section 7.4 job-delay-output-until (type3 keyword | name(MAX)),
Section 7.5 job-delay-output-until-time (dateTime): Changed from using
'job-hold-until-specified' value for "job-state-reasons" attribute for
implementations that cannot partially process the job before the delay
output period or date-time arrives to always use the
'job-delay-output-until-specified' value.
3. Section 10.3 job-state-reasons (1setOf type2 keyword) Job
Description attribute" Added definition for
"job-delay-output-until-specified" value.
4. Section 10.3 job-state-reasons (1setOf type2 keyword) Job
Description attribute" Added definition for
"job-delay-output-until-suspended" value.
The four ISSUES were:
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'
I changed to always use 'job-delay-output-until-specified' for all
implementations. It's simpler to describe.
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".
I added these:
'job-delay-output-until-specified': The value of the job's
"job-delay-output-until" or "job-delay-output-utntil-time" Job Template
attribute was specified with a time period or date-time, respectively, that
is still in the future. The job MUST NOT produce output until this reason
is removed (whether or not the implementation holds the job - see sections
7.4 and 7.5. This value MUST be supported if the "job-delay-output-until"
or "job-delay-output-until-time" Job Template attribute is supported.
'job-delay-output-until-suspended': The value of the job's
"job-delay-output-until" or "job-delay-output-utntil-time" Job Template
attribute was specified with a time period or date-time, respectively, that
is still in the future AND the implementation has partially processed the
job but has suspended the job and put the job into the 'processing-stopped'
state until the time period or the date-time arrives while allowing other
jobs to be processed and product output (see sections 7.4 and 7.5). This
value MUST be supported if the "job-delay-output-until" or
"job-delay-output-until-time" Job Template attribute is supported with the
implementation that puts the job into 'processing-stopped' state (see
sections 7.4 and 7.5).
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[th1] <> 4 - Time Sequence Diagram for 1 Hold, 2 Delay Output, and 4
normal Jobs
ISSUE 4: 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?
No, I changed so that all implementations use
'job-delay-output-until-specified' value whether they hold the job or not.
The "job-state" says 'pending-held' if the implementation holds the job.
Tom
P.S. I should have said v23 and v22 in the following email:
_____
From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Tom
Hastings
Sent: Wednesday, March 31, 2010 17:34
To: ipp at pwg.org
Subject: [IPP] {Disarmed} I've uploaded v33 of JPS2 for face to face; but 4
issues remain - PLEASE REPLY before the face2face
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.pdfftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v23-20100330-rev.docftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v23-20100330.pdfftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v23-20100330.docftp://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')[th2] <> , 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[th3] <> ': 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 [th4] <> 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
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
_____
[th1] <> ISSUE: OK to add the 'job-delay-output-until-suspended'
"job-state-reasons" value?
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?
ISSUE 2: This description OK?
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/20100407/0a1fe47c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 11575 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20100407/0a1fe47c/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 73 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20100407/0a1fe47c/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.gif
Type: image/gif
Size: 11070 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20100407/0a1fe47c/attachment-0005.gif>
