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 <blueroofmusic at gmail.com> wrote:
>> 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
>> 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/blueroofmusic>
>http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: blueroofmusic at gmail.com <mailto:blueroofmusic at gmail.com>
> PO Box 221 Grand Marais, MI 49839 906-494-2434
>>>> On Thu, Mar 7, 2019 at 11:58 AM Michael Sweet <msweet at apple.com <mailto:msweet at apple.com>> 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)
>> 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 <ipp at pwg.org <mailto:ipp at pwg.org>> wrote:
>>>> 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
>>>> 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/blueroofmusic>
>>http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
>> mailto: blueroofmusic at gmail.com <mailto:blueroofmusic at gmail.com>
>> PO Box 221 Grand Marais, MI 49839 906-494-2434
>>>>>>>> On Wed, Mar 6, 2019 at 4:03 PM Michael Sweet via ipp <ipp at pwg.org <mailto:ipp at pwg.org>> wrote:
>> Smith,
>>>>> On Mar 6, 2019, at 3:41 PM, Kennedy, Smith (Wireless & Standards Architect) via ipp <ipp at pwg.org <mailto:ipp at pwg.org>> 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...
>>>> _________________________________________________________
>> Michael Sweet, Senior Printing System Engineer
>>>> _______________________________________________
>> ipp mailing list
>>ipp at pwg.org <mailto:ipp at pwg.org>
>>https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
>> _______________________________________________
>> ipp mailing list
>>ipp at pwg.org <mailto:ipp at pwg.org>
>>https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>
_________________________________________________________
Michael Sweet, Senior Printing System Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190307/501e3d0e/attachment.html>