Hi Ira,
I think all 2.x levels should REQUIRE the "date-time-at-xxx" and "printer-current-time", since any printers that have an un-initialized clock can always use the 'unknown' out-of-band value, to reduce the variability between levels. Even basic printers ought to be able to do that at this point if they are implementing IPP, don't you think?
Smith
/**
Smith Kennedy
HP Inc.
*/
> On Oct 27, 2020, at 9:22 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>> Hi Mike,
>> About where we RECOMMEND or REQUIRE the "date-time" attributes:
>> In eventual IPP/2.x update, I suggest that IPP/2.1 (Enterprise) and
> IPP/2.2 (Production) should REQUIRE the "date-time" attributes (since
> this will after all be a major update to the previous PWG Standard of
> IPP/2.x).
>> Rick Landau (Dell) and I ran up against this issue way back when we
> were doing mappings to DMTF CIM classes (where real date-time was
> already ubiquitous).
>> WDYT?
>> Cheers,
> - Ira
>>> Ira McDonald (Musician / Software Architect)
> Chair - SAE Trust Anchors and Authentication TF
> 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>
> (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434
>>> On Mon, Oct 26, 2020 at 9:09 PM Michael Sweet <msweet at msweet.org <mailto:msweet at msweet.org>> wrote:
> Ira,
>> > On Oct 26, 2020, at 8:34 PM, Ira McDonald <blueroofmusic at gmail.com <mailto:blueroofmusic at gmail.com>> wrote:
> >
> > Hi,
> >
> > The lack of REQUIRED "printer-current-time" to populate "date-time-at-xxx"
> > attributes is an *old* problem - noticed in the first draft of IPP 2.0. In RFC
> > 8011, it's still (incorrectly) RECOMMENDED, which breaks the preferred
> > "date-time-at-xxx" attributes (the only useful ones in a Job Log) - and RFC
> > 8011 is the authoritative source definition in the IANA IPP Registry, so this
> > can't simply be fixed in a PWG 5100.x spec (I think?).
>> So dateTime attributes were all optional in IPP/1.1 and IPP/2.0. And we updated the definition of printer-current-time to include the 'unknown' syntax since it was already explicitly allowed in RFC 2911, just not included in the syntax definition for printer-current-time...
>> The issue for the registry is that when I updated the registrations for RFC 8011 I didn't update the printer-current-time syntax to match the document. I'll include a fix for that in my next dump for IANA.
>> The issue for IPP Everywhere is that 1.0 didn't explicitly require it but *did* require date-time-at-xxx - clearly the intent was to require printer-current-time but we missed it. IPP Everywhere 1.1 makes it RECOMMENDED and notes that the omission from 1.0 was an error since we *did* require date-time-at-xxx. IPP Everywhere 2.0 will be able to make it REQUIRED.
>> Anyways...
>> ________________________
> Michael Sweet
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20201027/d2926339/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/20201027/d2926339/attachment.sig>