Re: [IPP] IPP Enterprise Printing Extensions v2.0 next draft - question on the F2F minutes

Michael Sweet via ipp <ipp@pwg.org> Wed, 20 May 2020 12:34 UTC

Return-Path: <ipp-bounces@pwg.org>
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641573A0945 for <ietfarch-ipp-archive@ietfa.amsl.com>; Wed, 20 May 2020 05:34:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level:
X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNArRCuJho7r for <ietfarch-ipp-archive@ietfa.amsl.com>; Wed, 20 May 2020 05:34:11 -0700 (PDT)
Received: from mail.pwg.org (mail.pwg.org [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id E47543A093A for <ipp-archive2@ietf.org>; Wed, 20 May 2020 05:33:29 -0700 (PDT)
Received: by mail.pwg.org (Postfix, from userid 1002) id 734C16738; Wed, 20 May 2020 12:33:25 +0000 (UTC)
Received: from mail.pwg.org (localhost [IPv6:::1]) by mail.pwg.org (Postfix) with ESMTP id 811EF3A80; Wed, 20 May 2020 12:33:22 +0000 (UTC)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: by mail.pwg.org (Postfix, from userid 1002) id 8F09A5058; Wed, 20 May 2020 12:33:20 +0000 (UTC)
Received: from mail.msweet.org (mail.msweet.org [173.255.209.91]) by mail.pwg.org (Postfix) with ESMTP id 31D0B1CB2 for <ipp@pwg.org>; Wed, 20 May 2020 12:33:20 +0000 (UTC)
Received: from mbp16.lan (host-148-170-144-200.public.eastlink.ca [148.170.144.200]) by mail.msweet.org (Postfix) with ESMTPSA id A129F80B3A; Wed, 20 May 2020 12:33:19 +0000 (UTC)
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
In-Reply-To: <83B37BA5-DF93-4FE1-BE28-D40A0F4B5BED@hp.com>
Date: Wed, 20 May 2020 08:33:18 -0400
Message-Id: <3A140B78-1881-4390-B17A-0BEE71A19F31@msweet.org>
References: <83B37BA5-DF93-4FE1-BE28-D40A0F4B5BED@hp.com>
To: Smith Kennedy <smith.kennedy@hp.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Cc: PWG IPP Workgroup <ipp@pwg.org>
Subject: Re: [IPP] IPP Enterprise Printing Extensions v2.0 next draft - question on the F2F minutes
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: ISTO-PWG Internet Printing Protocol workgroup discussion forum <ipp.pwg.org>
List-Unsubscribe: <https://www.pwg.org/mailman/options/ipp>, <mailto:ipp-request@pwg.org?subject=unsubscribe>
List-Archive: <http://www.pwg.org/pipermail/ipp/>
List-Post: <mailto:ipp@pwg.org>
List-Help: <mailto:ipp-request@pwg.org?subject=help>
List-Subscribe: <https://www.pwg.org/mailman/listinfo/ipp>, <mailto:ipp-request@pwg.org?subject=subscribe>
From: Michael Sweet via ipp <ipp@pwg.org>
Reply-To: Michael Sweet <msweet@msweet.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Errors-To: ipp-bounces@pwg.org
Sender: "ipp" <ipp-bounces@pwg.org>

Smith,

So the gist of this is that Clients are looking at the job-state-reasons attribute for 'job-password-wait' when the Job isn't completed, and so for EPX 2.0 we should modify the semantics of job-password to be that output is withheld until the End User enters the job-password value at the printer.  One possible implementation is to put the Job in the 'pending-held' state and delay processing until the password is entered.  Another is to let the Job start processing and then end up in the 'processing-stopped' state until the password is entered.  In these cases the Client will see 'job-password-wait' until the password is entered, and then Job will proceed to a terminating state ('completed', 'canceled', or 'aborted') after processing/output is done, as appropriate.

In the case of Release Printing, there is a third possibility where the Job is processed and put in a terminating state (either 'completed' or 'aborted') with the 'job-password-wait' keyword still present.  Since the Job has reached a terminating state, the state-reasons MUST NOT change once the password is entered for releasing the Job at a particular output device, but Clients stop monitoring Jobs at this point anyways and move on to the next Job in their local queues.

(The Release Printing variation isn't pretty, and maybe we should make the semantic that 'job-password-wait' is only added for Physical Devices?)


> On May 20, 2020, at 12:44 AM, Kennedy, Smith (Wireless & IPP Standards) via ipp <ipp@pwg.org> wrote:
> 
> Hi Mike,
> 
> In the minutes from the last F2F (https://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20200506.pdf) covering the review of IPP Enterprise Printing Extensions v2.0, it says this toward the bottom of page 4:
> 
> 	• ⁃  Decouple job-state from Job Release:
> 
> 		• ⁃  job-state-reasons provides the Release state information
> 
> 		• ⁃  While 1.0 says job-password holds a job, subsequent
> 
> implementation experience shows that processing a job is also a valid implementation semantic - any job-state is OK for job-password
> 
> 		• ⁃  Also valid for a Printer to hold a job that has a release action 
> 
> I'm wondering what this means and how this might affect the document. Are you saying that I need to change the language for "job-password" to soften it so that it isn't a hard requirement for the Job to be in the 'pending-held' state initially? I'm trying to not break backward compatibility so I'm not sure what to do with this.
> 
> Thanks for any help,
> 
> Smith
> 
> /**
>     Smith Kennedy
>     HP Inc.
> */
> 
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp

________________________
Michael Sweet



_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp