> On Mar 6, 2019, at 11:44 AM, Michael Sweet <msweet at apple.com> wrote:
>> Smith,
>>> On Mar 6, 2019, at 1:20 PM, Kennedy, Smith (Wireless & Standards Architect) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> wrote:
>> ...
>> 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)
>> OK, so I'll define the standard which-jobs values in Job Extensions, and you'll define the new ones for EPE?
That's what I was thinking, and then I'll reference Job Extensions v1.1.
>>> I have a few questions too:
>>>> Questions:
>> 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.
No problem - I will leave it in EPE.
>>> 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?
>> Likewise, these seem like an enterprise job scheduling feature.
I will leave these in EPE.
>>> 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...)
>> Recipient/contact information for the job seems like an enterprise or light-production use case.
OK
>>> 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?
>> 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)?
>>>>> On Feb 28, 2019, at 3:17 PM, Michael Sweet <msweet at apple.com <mailto:msweet at apple.com>> 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
>>>>>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190306/3f67aa26/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190306/3f67aa26/attachment.sig>