Sorry, I should have been more clear that I was suggesting we should update the normative requirements to make all levels (if we have levels) REQUIRE the "date-time-at-xxx" and "printer-current-time" whenever we decide to create an "IPP/3".
> On Oct 27, 2020, at 11:31 AM, Michael Sweet <msweet at msweet.org> wrote:
>> Smith,
>> IPP 2.1 and 2.2 require the dateTime attributes. IPP 2.0 doesn't, and we can't really change that for IPP 2.0 since the versioning is pretty well hardcoded (a good reason never to do that again... :)
>>> > On Oct 27, 2020, at 11:52 AM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com> wrote:
> >
> > 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> >> (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> wrote:
> >> Ira,
> >>
> >> > On Oct 26, 2020, at 8:34 PM, Ira McDonald <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
> >>
> >>
> >>
> >
>> ________________________
> Michael Sweet
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20201027/3fc18b17/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/3fc18b17/attachment.sig>