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