[IPP] WG Last Call of IPP Scan Service specification

[IPP] WG Last Call of IPP Scan Service specification

Ira McDonald blueroofmusic at gmail.com
Wed May 21 13:22:10 UTC 2014


Hi Mike and Soma,

Then I maintain that it's an error in IPP Everywhere, FaxOut, and Scan,
that the underlying "printer-current-time" (OPTIONAL in RFC 2911 and
in IPP/2.0 Second Edition) is not moved to REQUIRED.  I consider it
an editorial error (i.e., fixable by an errata) as it's an oversight.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
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
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434



On Wed, May 21, 2014 at 8:54 AM, Michael Sweet <msweet at apple.com> wrote:

> Soma,
>
> This is indeed something that needs to be documented in the implementor's
> guide, but in most cases the client just needs to see whether the date/time
> (or simply the up time in seconds) is different than last reported, and not
> if the change is newer.
>
> But given that the printer-xxx-change-date-time attributes are required in
> IPP Everywhere, I think we still want them required for IPP Scan.
>
>
> On May 20, 2014, at 11:09 PM, Soma Meiyappan <Soma.Meiyappan at conexant.com>
> wrote:
>
>  Hi Ira,
>
>
>
> Thank you very much for the summary from the F2F discussions on this
> topic.
>
>
>
> My question on the topic for FaxOut stems from the imaginable ways an IPP
> client may have been written to be dependent on
> printer-config-change-date-time for caching printer confifuation  and if it
> is a value that may be treated as trusted enough for that purpose. I am
> aware that ‘no-value’ is valid for these attributes (incl
> printer-current-time); but I am concerned about other valid (but
> inaccurate) dateTime values and the implications.
>
>
>
> If ‘printer-config-change-date-time’ is used purely for informational
> purposes (as a value to display in a report or a web-page and not
> necessarily in caching the printer configuration), I’ll not be too
> concerned. However, could it be used to determine if cached information
> about the printer needs to be refreshed? If yes, we may want to add a note
> targeted at IPP client writers, in the implementer’s guide, that this
> information MUST not be used for caching printer capabilities without other
> precautions including protection against the possibility of the printer
> reported time being inaccurate [RFC 2911 does not place any accuracy
> requirements] and printer-current-time (and derived attribute values) going
> back to the past for a number of reasons.
>
>
>
> Looking forward to hearing the forum’s thoughts on the topic.
>
>
>
> Thanks and Regards,
>
> Somasundaram.
>
>
>
>
>
> *From:* Ira McDonald [mailto:blueroofmusic at gmail.com<blueroofmusic at gmail.com>]
>
> *Sent:* Monday, May 19, 2014 11:23 PM
> *To:* Soma Meiyappan; Ira McDonald; Peter Zehler
> *Cc:* IPP at pwg.org
> *Subject:* Re: [IPP] WG Last Call of IPP Scan Service specification
>
>
>
> Hi Soma,
>
> Thanks for your careful reading of these IPP specs.
>
> We discussed this comment during the Thursday IPP WG session
>
> at the PWG F2F meeting last week, when looking at IPP Scan with
>
> Pete Zehler.
>
>
>
> The IPP F2F minutes state that this issue should be resolved on the
> IPP mailing list, but there was unanimous consensus in the meeting:
>
>
>
> (1) IPP FaxOut - these date-time attributes should remain REQUIRED
>
> (because they satisfy regulatory requirements for a Fax service).
>
>
> (2) IPP Scan - these date-time attributes should be changed to either
>
> RECOMMENDED (i.e., best practice) or simply OPTIONAL.
>
> Please note that in IPP Everywhere (PWG 5100.14), the attributes
>
> printer-config-change-date-time and printer-state-change-date-time
>
> attributes are REQUIRED in Table 6 for conformance (see notes 2
>
> and 3 below the table).
>
>
>
> Obviously, the underlying printer-date-time attribute should have
>
> the same conformance level as the change-xxx attributes in IPP
> Everywhere, IPP FaxOut, and IPP Scan.  This appears to me to
> be an oversight in these specs.
>
> Please comment further on this thread, to clarify your thoughts.
>
> Cheers,
>
> - Ira (co-chair of IPP WG)
>
>
>  Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> 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
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
>
>
>
> On Tue, May 13, 2014 at 10:34 PM, Soma Meiyappan <
> Soma.Meiyappan at conexant.com> wrote:
>
>  Hi Pete et al,
>
>
>
> I have a concern about
>
>
>
> printer-config-change-date-time
>
> printer-state-change-date-time
>
>
>
> These attributes figure in the REQUIRED table in section 4.3. The above
> attributes require the scan device to have a notion of wall clock time
> (whether it is accurate or not to the global wall clock time). To increase
> the chances of making use of that effectively & correctly, all clients
> would be required to use this somehow in reference to printer-current-time
> and not to the wall-clock time that the client might know through other
> sources. That makes me wonder if it is sufficient to have
> printer-state-change-time and printer-config-change-time as required and
> make xxxx-date-time as optional.
>
>
>
> I have a similar question on FaxOut; but at least on FaxOut, the devices
> are expected to have a notion of wall-clock time although the point about
> how clients should use that information with reference to
> printer-current-time still seems applicable.
>
>
>
> Regards,
>
> Somasundaram.
>
>
>
> *From:* ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] *On Behalf Of *Zehler,
> Peter
> *Sent:* Friday, May 09, 2014 10:35 PM
> *To:* IPP at pwg.org
> *Subject:* [IPP] WG Last Call of IPP Scan Service specification
>
>
>
> All,
>
> This message initiates the IPP Working Group last call of the IPP Scan
> Service specification updated per prototype experience and subsequent
> discussions.
>
>
>
> ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140509.pdf
>
> http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140509.pdf
>
>
>
> Please send all feedback to the IPP mailing list (reply-all works fine for
> this) and it will be collected and processed as quickly as possible.
>
> Our intent is to move IPP Scan Service to PWG Formal Vote before the
> August 2014 F2F.
>
>
>
> Peter Zehler
>
> Xerox Research Center Webster
> Email: Peter.Zehler at Xerox.com
> Voice: (585) 265-8755
> FAX: (585) 265-7441
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701
>
>
>
>
>
>
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>
>
>
>
>  _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140521/fd6f7a20/attachment.html>


More information about the ipp mailing list