[IPP] WG Last Call of IPP Scan Service specification

[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 15:12:13 UTC 2014


Hi Mike and Soma,

You're both right of course (about validity assumptions and not changing
conformance requirements by making a new REQUIRED).

I'd be happy to promote "printer-current-time" to RECOMMENDED
(in errata specs).  In retrospect, I wish we had done it in IPP/2.0 SE.

I think that the Implementor's Guide should address the issue of validity
assumptions (e.g., recommend that Printers SHOULD NOT implement
any attribute for which they can only support 'no-value').

Note that the PWG Common Log (for Syslog, PWG 5110.3) follows
Syslog and makes accurate date/time REQUIRED in audit logs.

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 9:45 AM, Michael Sweet <msweet at apple.com> wrote:

> Ira,
>
> Given that it changes the conformance requirements, I don't think it can
> be done as an errata.  However, we *could* make it RECOMMENDED (much like
> we did when we published IPP/2.0 Second Edition for a number of
> attributes...)
>
> But we should definitely add this to the list of future changes for IPP
> Everywhere 2.0 / IPP Multifunction.
>
>
> On May 21, 2014, at 9:22 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>
> 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
>>
>>
>
>  _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140521/521907a1/attachment.html>


More information about the ipp mailing list