Ira,
Yes, and I have a feeling there will be others... :/
> On Oct 27, 2020, at 5:51 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>> Hi Mike,
>> Thanks.
>> So should we move all the dateTime attributes up to RECOMMENDED for all three levels
> of IPP 2.0, 2.1, 2.2 in our revision later in 2021?
>> 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 at gmail.com> (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434
>>> On Tue, Oct 27, 2020 at 5:36 PM Michael Sweet <msweet at msweet.org> wrote:
> Ira,
>> Sigh, yes it looks like we basically took a pass on all of the dateTime attributes, so yes the best we can do for those versions is to add a bunch of recommended stuff. But then I think a lot of IPP 2.x is in that boat anyways so why not more?
>>> > On Oct 27, 2020, at 3:07 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
> >
> > Hi Mike,
> >
> > In the PWG Standard 5100.12-2015, *none* of the "date-time-xxx" attributes are
> > listed at any level (2.0, 2.1, or 2.2) - I just searched for them again.
> >
> > We could at least make them RECOMMENDED at all three version levels and
> > continue to make them REQUIRED in IPP Everywhere, right?
> >
> > 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 at gmail.com> > (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434
> >
> >
> > On Tue, Oct 27, 2020 at 1:31 PM 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/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
> >
> >
> >
>> ________________________
> Michael Sweet
>>>
________________________
Michael Sweet