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/blueroofmusichttp://sites.google.com/site/highnorthinc
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> 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> 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/highnorthinc> 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> wrote:
>>> Smith,
>>>> On Mar 6, 2019, at 3:41 PM, Kennedy, Smith (Wireless & Standards
>> Architect) via ipp <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>>https://www.pwg.org/mailman/listinfo/ipp>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20190307/d749765b/attachment.html>