Subject: Re: [IPP] What to remove from latest JPS2v2 draft to create first draft of "IPP Enterprise Printing Extensions"?

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Wed, 6 Mar 2019 18:20:08 +0000

I have a draft of IPP Enterprise Printing Extension (EPE) I'm chipping away at - here's what it has thus far:

Added:
job-password-length-supported (from Job Password Repertoire registration)
job-password-repertoire-configured/-supported (from Job Password Repertoire registration)
job-print-password/-default/-supported (to be debated)
job-storage/-default/-supported (to be debated)

Removed:
feed-orientation/-default/-supported
job-save-disposition/-etc (all related Job Template, Job Description and Printer Description attributes)
job-creation-attributes-supported
job-hold-until-time/-supported
job-ids/-supported (REQUIRED)
job-spooling-supported
media-col.media-tooth
media-col.media-grain
media-col.media-thickness
media-col-database
printer-detailed-status-messages
which-jobs-supported
Cancel-Jobs
Cancel-My-Jobs
Close-Job

Kept:
job-password
job-password-encryption
proof-print/-default/-supported
Additional keywords for "which-jobs" ('proof-print' and 'stored' defined locally, 'saved' to be deprecated)

I have a few questions too:

Questions:
job-cancel-after/-default/-supported --> Job Extensions v1.1? If not, why not?
job-delay-ouptut-until/-default/-supported --> Job Extensions v1.1? If not, why not?
job-delay-output-until-time/-supported --> Job Extensions v1.1? If not, why not?
job-phone-number/-default/-supported --> Job Extensions v1.1? Separate registration? (Use case is ambiguous...)
job-recipient-name/-default/-supported --> Job Extensions v1.1? Separate registration? (Use case is ambiguous...)
job-retain-until/-default/-supported --> Job Extensions v1.1? If not, why not?
job-retain-until-time/-default/-supported --> Job Extensions v1.1? If not, why not?

> On Feb 28, 2019, at 3:17 PM, Michael Sweet <[email-masked]> wrote:
> 
> These all have a clear focus on jobs and job submission/creation and are definitely not limited to the scope of Enterprise Printing.  There is a slight process issue we need to discuss, however: the new Job Extensions will have conformance requirements for required operations and attributes that were not in v1.0 of Job Extensions but *were* in v1.0 of JPS2 - the errata process doesn't allow us to change conformance requirements without going through PWG Last Call and Formal Vote, but then we are kindof merging JOBEXT and JPS2 into a single errata update and publishing a new Enterprise Printing specification with updated JPS2 content.  Fuzzy logic... :)

We should account for this in Process 4.0 somehow.

> 
> Anyways, since this constitutes all of the non-obsoleted/migrated content from JPS2, I'd prefer to update things in one shot rather than processing two documents.

+1

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

---

From: Michael Sweet via ipp <[email-masked]>
Date: Wed, 06 Mar 2019 13:44:19 -0500

Smith,

> On Mar 6, 2019, at 1:20 PM, Kennedy, Smith (Wireless & Standards Architect) <[email-masked]> wrote:
> ...
> Kept:
> job-password
> job-password-encryption

OK, so I'll define the standard which-jobs values in Job Extensions, and you'll define the new ones for EPE?

> job-cancel-after/-default/-supported --> Job Extensions v1.1? If not, why not?

More advanced job management seems more enterprise-y to me, but I'm good either way.

> job-delay-output-until-time/-supported --> Job Extensions v1.1? If not, why not?

Likewise, these seem like an enterprise job scheduling feature.

> job-recipient-name/-default/-supported --> Job Extensions v1.1? Separate registration? (Use case is ambiguous...)

Recipient/contact information for the job seems like an enterprise or light-production use case.

> job-retain-until-time/-default/-supported --> Job Extensions v1.1? If not, why not?

I believe these were intended to resolve the ambiguity with how long a proof print/stored job is retained.  Also, I don't think we want a job-retain-until-time-default, since the value is an absolute dateTime value (unless we make -time an integer and add a -date version for dateTime?)

>> On Feb 28, 2019, at 3:17 PM, Michael Sweet <[email-masked] <mailto:[email-masked]>> wrote:
>> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Wed, 6 Mar 2019 20:41:06 +0000

> On Mar 6, 2019, at 11:44 AM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 
>> On Mar 6, 2019, at 1:20 PM, Kennedy, Smith (Wireless & Standards Architect) <[email-masked] <mailto:[email-masked]>> wrote:
>> ...
>> Kept:
>> job-password
>> job-password-encryption

That's what I was thinking, and then I'll reference Job Extensions v1.1.

> More advanced job management seems more enterprise-y to me, but I'm good either way.

No problem - I will leave it in EPE.

> Likewise, these seem like an enterprise job scheduling feature.

I will leave these in EPE.

> Recipient/contact information for the job seems like an enterprise or light-production use case.

OK

> I believe these were intended to resolve the ambiguity with how long a proof print/stored job is retained.

I thought they could be used more generally but I'm fine with them staying in EPE.

>  Also, I don't think we want a job-retain-until-time-default, since the value is an absolute dateTime value (unless we make -time an integer and add a -date version for dateTime?)

Hmmm, how about just having "job-retain-until" (type2 keyword) and "job-retain-until-time" (integer) and not bother with "job-retain-until-date" (dateTime)?

---

From: Michael Sweet via ipp <[email-masked]>
Date: Wed, 06 Mar 2019 16:02:52 -0500

Smith,

> On Mar 6, 2019, at 3:41 PM, Kennedy, Smith (Wireless & Standards Architect) via ipp <[email-masked]> wrote:
> ...

Let's discuss this at the next concall - I can see a use for both (retain the job for 24 hours, retain the job until the next scheduled update), and a Client can calculate the number of seconds to a specific date/time, but there are still some vagaries due to submission delays and whether the IPP job ticket is used directly and immediately or if it gets "relayed" to the destination output device that is doing the retaining...

---

From: Ira McDonald via ipp <[email-masked]>
Date: Wed, 6 Mar 2019 16:44:48 -0500

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Wed, Mar 6, 2019 at 4:03 PM Michael Sweet via ipp <[email-masked]> wrote:

>  Also, I don't think we want a job-retain-until-time-default, since the
> value is an absolute dateTime value (unless we make -time an integer and
> add a -date version for dateTime?)
>
>
> Hmmm, how about just having "job-retain-until" (type2 keyword) and
> "job-retain-until-time" (integer) and not bother with
> "job-retain-until-date" (dateTime)?
>
>
> Let's discuss this at the next concall - I can see a use for both (retain
> the job for 24 hours, retain the job until the next scheduled update), and
> a Client can calculate the number of seconds to a specific date/time, but
> there are still some vagaries due to submission delays and whether the IPP
> job ticket is used directly and immediately or if it gets "relayed" to the
> destination output device that is doing the retaining...
>

---

From: Ira McDonald via ipp <[email-masked]>
Date: Wed, 6 Mar 2019 16:50:49 -0500

Hi,

I just read this entire thread carefully.

I agree with all of your joint conclusions (good work Smith and Mike),
*except* for "job-retain-until-xxx".

I consider the lack of "job-retain-until-xxx" an architectural mistake
in IPP/1.1.  So I'd like it to be present in Job Extensions, so that
some version lower than IPP/2.2 (Enterprise) can reliably use it.
I suggest making it RECOMMENDED in IPP/2.0 and REQUIRED
in IPP/2.1 and above.

Cheers,
- Ira

---

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Wed, 6 Mar 2019 21:50:51 +0000

Perhaps we need to be clear in the definition of "job-retain-until-time" that relative times are measured starting from the time specified by the Job's "date-time-at-completed"?

Smith

> On Mar 6, 2019, at 2:02 PM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 
>> On Mar 6, 2019, at 3:41 PM, Kennedy, Smith (Wireless & Standards Architect) via ipp <[email-masked] <mailto:[email-masked]>> wrote:
>> ...

---

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Wed, 6 Mar 2019 21:52:18 +0000

Hi Ira,

I support the move to Job Extensions for the reasons you provided below, and because I think it might be useful in a more general case.

Smith

> On Mar 6, 2019, at 2:50 PM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> http://sites.google.com/site/blueroofmusic <https://protect-us.mimecast.com/s/gV7KCKrBnBFWnRPJCMjvnA?domain=sites.google.com>
> http://sites.google.com/site/highnorthinc <https://protect-us.mimecast.com/s/Ten6CL9DoDC91zVvSqqkRO?domain=sites.google.com>
> mailto: [email-masked] <mailto:[email-masked]>
> On Wed, Mar 6, 2019 at 4:03 PM Michael Sweet via ipp <[email-masked] <mailto:[email-masked]>> wrote:
> Smith,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/rnF_CM8gpgI3ZnDlSJ31k5?domain=pwg.org>

---

From: Michael Sweet via ipp <[email-masked]>
Date: Thu, 07 Mar 2019 11:57:55 -0500

Well, if we put job-retain-until in Job Extensions 1.1, then we should probably put job-delay-output-until in JOBEXT as well (since now we'll have a bunch of Job Template attributes in JOBEXT that control scheduling/job lifecycle decisions)

Just remember that in JOBEXT all of this will be OPTIONAL anyways.

I will also post a RFC for another attribute to close the last lifecycle hole (how long a job stays in history).

> On Mar 6, 2019, at 4:50 PM, Ira McDonald via ipp <[email-masked]> wrote:
> 
> Hi,
> 
> http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>

---

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Thu, 7 Mar 2019 17:43:40 +0000

I'm good with all of these being in Job Extensions v1.1:

job-delay-output-until...
job-retain-until...
job-history-interval-supported/-configured

> On Mar 7, 2019, at 9:57 AM, Michael Sweet via ipp <[email-masked]> wrote:
> 
>> On Mar 6, 2019, at 4:50 PM, Ira McDonald via ipp <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>> 
>> http://sites.google.com/site/blueroofmusic <https://protect-us.mimecast.com/s/zCydC9rB5BFKzQ09tEq9FK?domain=sites.google.com>
>> http://sites.google.com/site/highnorthinc <https://protect-us.mimecast.com/s/QWZiC0Rp6psWkVxZi2HGo_?domain=sites.google.com>
>> https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/LqgrC82A5AhMX1GLfnkXWj?domain=pwg.org>
>> https://www.pwg.org/mailman/listinfo/ipp <https://protect-us.mimecast.com/s/LqgrC82A5AhMX1GLfnkXWj?domain=pwg.org>
> 
> https://protect-us.mimecast.com/s/LqgrC82A5AhMX1GLfnkXWj?domain=pwg.org

---

From: Ira McDonald via ipp <[email-masked]>
Date: Thu, 7 Mar 2019 16:42:52 -0500

Hi Mike,

Even in a minor errata version, I thought we could add a RECOMMENDED
(SHOULD) attribute, because it doesn't break backward compatibility?

Shouldn't the retention and job history attributes (and probably others) be
RECOMMENDED in Job Extensions?

I shudder at perpetuating IPP specs that are a basket of OPTIONAL
attributes.  That doesn't help interoperability particularly.

Cheers,
- Ira

On Thu, Mar 7, 2019 at 11:58 AM Michael Sweet <[email-masked]> wrote:

> Well, if we put job-retain-until in Job Extensions 1.1, then we should
> probably put job-delay-output-until in JOBEXT as well (since now we'll have
> a bunch of Job Template attributes in JOBEXT that control scheduling/job
> lifecycle decisions)
>

---

From: Michael Sweet via ipp <[email-masked]>
Date: Thu, 07 Mar 2019 16:55:09 -0500

Ira,

Yes, RECOMMENDED/SHOULD is OK, and I am making most of the attributes RECOMMENDED anyways.

I think the real question is whether we make the JOBEXT update a 1.1 or 2.0?

(see my other message...)

> On Mar 7, 2019, at 4:42 PM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Mike,
> 
> On Thu, Mar 7, 2019 at 11:58 AM Michael Sweet <[email-masked] <mailto:[email-masked]>> wrote: