Re: [IPP] Update registration for "printer-current-time" Printer Description attribute in IANA Registry; was Re: Minutes posted from today's concall

Hi Smith,

Thanks for the clarification.

Mike has been suggesting for some time that we should never create any more
numbered versions of IPP.  Instead, we should use "ipp-features-supported"
and
"[format]-features-supported" for better clarity.  I agree with Mike.

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 WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://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@gmail.com
<blueroofmusic@gmail.com>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Tue, Oct 27, 2020 at 3:09 PM Kennedy, Smith (Wireless & IPP Standards) <
smith.kennedy@hp.com> wrote:

> 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@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@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@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/highnorthinc
> >> mailto: blueroofmusic@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@msweet.org>
> wrote:
> >> Ira,
> >>
> >> > On Oct 26, 2020, at 8:34 PM, Ira McDonald <blueroofmusic@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
>
>
>
>