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