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

From: "Tom Hastings" <[email-masked]>
Date: Wed, 07 Apr 2010 03:52:53 -0700

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.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: [email-masked] [mailto:[email-masked]] On Behalf Of Tom
Hastings
Sent: Wednesday, March 31, 2010 17:34
To: [email-masked]
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.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.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Wed, 7 Apr 2010 07:49:34 -0700

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-clean.pdf
> ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v24-20100406-clean.doc
>  
> 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)?
>  
> 
> 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
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Hastings
> 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-clean.pdf
> ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext10-v23-20100330-clean.doc
>  
> 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.
> 
> 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)?
>  
> 
> 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.  
>  
>  [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?
> believed to be clean. _______________________________________________
> ipp mailing list
> [email-masked]

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair