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/blueroofmusichttp://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>