On Apr 7, 2010, at 3:52 AM, Tom Hastings wrote:
> 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.pdf>ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v24-20100406-rev.doc>ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v24-20100406.pdf>ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v24-20100406.doc>ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v24-20100406-clean.pdf>ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v24-20100406-clean.doc>> 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.
I actually think that allowing implementations to treat job-delay-output-until like job-hold-until is causing us more grief than it is worth. If we eliminate that loophole then the pending-held state is only used for jobs that also have job-hold-until, which IMHO is just as easy to implement and is a LOT cleaner!
>> 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)?
>> <image002.gif><image003.gif>
>> 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.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.pdf>ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v23-20100330-clean.doc>> 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)?
>> <image004.gif>
>> 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 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. _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
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/2f90a9f2/attachment-0001.html>