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 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 at gmail.com
<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
>>>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20201027/4a63e045/attachment.html>