Subject: [IPP] WG Last Call of IPP Scan Service specification

From: "Zehler, Peter" <[email-masked]>
Date: Fri, 9 May 2014 14:35:28 +0000

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: [email-masked]<mailto:[email-masked]>
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
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Soma Meiyappan <[email-masked]>
Date: Wed, 14 May 2014 02:34:07 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Zehler, Peter
Sent: Friday, May 09, 2014 10:35 PM
To: [email-masked]
Subject: [IPP] WG Last Call of IPP Scan Service specification

All,

Peter Zehler

---

From: Ira McDonald <[email-masked]>
Date: Mon, 19 May 2014 11:23:15 -0400

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: [email-masked]
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 <
[email-masked]> wrote:

> 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:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Zehler,
> Peter
> *Sent:* Friday, May 09, 2014 10:35 PM
> *To:* [email-masked]
> *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.
>
>
>
> 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.
>
> Email: [email-masked]
> 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
>
>
>
>
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 20 May 2014 15:37:30 -0400

Ira,

On May 19, 2014, at 11:23 AM, Ira McDonald <[email-masked]> wrote:
> ...

I think you mean "printer-current-time", right?

Yes, it is probably an oversight, but probably not critical since Clients don't care so much about the current time as they do the time when something happens.  Relative printer time can be calculated using printer-up-time.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Ira McDonald <[email-masked]>
Date: Tue, 20 May 2014 15:58:42 -0400

Hi Mike,

Yes, I did mean "printer-current-time" (a terribly obscure name).

But relative time isn't relevant for "printer-config-change-date-time",
right (requires real clock date/time)?

Cheers,
- Ira

On Tue, May 20, 2014 at 3:37 PM, Michael Sweet <[email-masked]> wrote:

> Yes, it is probably an oversight, but probably not critical since Clients
> don't care so much about the current time as they do the time when
> something happens.  Relative printer time can be calculated using
> printer-up-time.
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 20 May 2014 20:59:21 -0400

Ira,

> right (requires real clock date/time)?

What I mean is that if the printer reports a date/time value then the Client doesn't need to calculate one using its current date/time less the difference of printer-up-time and printer-config-change-time.  And similarly it does not need to depend on the printer as the source of the date/time.

---

From: Soma Meiyappan <[email-masked]>
Date: Wed, 21 May 2014 03:09:37 +0000

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:[email-masked]]
Sent: Monday, May 19, 2014 11:23 PM
To: Soma Meiyappan; Ira McDonald; Peter Zehler
Cc: [email-masked]
Subject: Re: [IPP] WG Last Call of IPP Scan Service specification

Hi Soma,

mailto: [email-masked]<mailto:[email-masked]>

On Tue, May 13, 2014 at 10:34 PM, Soma Meiyappan <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pete et al,

I have a concern about

Regards,
Somasundaram.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Zehler, Peter
Sent: Friday, May 09, 2014 10:35 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [IPP] WG Last Call of IPP Scan Service specification

All,

Peter Zehler

Xerox Research Center Webster
Email: [email-masked]<mailto:[email-masked]>
Voice: (585) 265-8755<tel:%28585%29%20265-8755>
FAX: (585) 265-7441<tel:%28585%29%20265-7441>
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

_______________________________________________
ipp mailing list
[email-masked]<mailto:[email-masked]>
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Wed, 21 May 2014 08:54:15 -0400

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 <[email-masked]> wrote:

> On Tue, May 13, 2014 at 10:34 PM, Soma Meiyappan <[email-masked]> wrote:
> Hi Pete et al,
>  
> I have a concern about
>

---

From: Ira McDonald <[email-masked]>
Date: Wed, 21 May 2014 09:22:10 -0400

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

On Wed, May 21, 2014 at 8:54 AM, Michael Sweet <[email-masked]> 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.
>
>
> 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.
>
>
>
> *From:* Ira McDonald [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Monday, May 19, 2014 11:23 PM
> *To:* Soma Meiyappan; Ira McDonald; Peter Zehler
> *Cc:* [email-masked]
> *Subject:* Re: [IPP] WG Last Call of IPP Scan Service specification
>
>
>
> Hi Soma,
>

---

From: Soma Meiyappan <[email-masked]>
Date: Wed, 21 May 2014 13:37:50 +0000

Hi Mike,

Making printer-xxx-date-time & printer-current-time REQUIRED for consistency across the 3 primary specifications will be fine as long as devices that do not have a notion of calendar time can provide "no-value" as RFC 2911 allows for "printer-current-time" (and attributes whose value is derived from that). But, that is effectively making it STRONGLY RECOMMENDED, in principle, isn't it?

Personally, I feel that making something REQUIRED typically sets an expectation on the validity/accuracy of the data that the attribute provides although there is no explicit claim/requirement on the validity/accuracy made in the underlying specification.

Thanks and Regards,
Somasundaram.

From: Michael Sweet [mailto:[email-masked]]
Sent: Wednesday, May 21, 2014 8:54 PM
To: Soma Meiyappan
Cc: Ira McDonald; Peter Zehler; [email-masked]
Subject: Re: [IPP] WG Last Call of IPP Scan Service specification

Soma,

On May 20, 2014, at 11:09 PM, Soma Meiyappan <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ira,

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.

Cc: [email-masked]<mailto:[email-masked]>

Hi Soma,

I have a concern about

Regards,
Somasundaram.

All,

Peter Zehler

---

From: Michael Sweet <[email-masked]>
Date: Wed, 21 May 2014 09:45:02 -0400

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.

---

From: Ira McDonald <[email-masked]>
Date: Wed, 21 May 2014 11:12:13 -0400

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

On Wed, May 21, 2014 at 9:45 AM, Michael Sweet <[email-masked]> 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 given that the printer-xxx-change-date-time attributes are required
>> in IPP Everywhere, I think we still want them required for IPP Scan.
>>
>>
>> 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.
>>

---

From: "William A Wagner" <[email-masked]>
Date: Wed, 21 May 2014 12:06:09 -0400

I find myself in the unusual position of concurring with (almost) all. 

1.       If attributes expressed in date-time are required, then the printer
presumably knows (or can determine) current date time and
"printer-current-time" should be required.

2.       This should be consistent across IPP imaging services

3.       The notion of requiring an attribute but not requiring that the
date-time value be valid was, if I recall correctly, a concession to the
limitations of low-cost printers that seems to have persisted.  I suggest
that this is inappropriate for a networked printer today. 

4.       I agree that making an attribute required cannot be considered an
editorial correction fixable by an errata (even if it was an oversight).

Thanks,

Bill Wagner

From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael
Sweet
Sent: Wednesday, May 21, 2014 9:45 AM
To: Ira McDonald
Cc: [email-masked]
Subject: Re: [IPP] WG Last Call of IPP Scan Service specification

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.

Hi Mike and Soma,

Cheers,

- Ira

 <http://sites.google.com/site/blueroofmusic>
 <http://sites.google.com/site/highnorthinc>

Soma,

 

On May 20, 2014, at 11:09 PM, Soma Meiyappan <[email-masked]>
wrote:

Hi Ira,

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. 

Thanks and Regards,

Somasundaram.

Hi Soma,

Pete Zehler.

and 3 below the table).

Cheers,

 <http://sites.google.com/site/blueroofmusic>
 <http://sites.google.com/site/highnorthinc>

On Tue, May 13, 2014 at 10:34 PM, Soma Meiyappan
<[email-masked]> wrote:

Hi Pete et al,

I have a concern about

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: [email-masked] [mailto:[email-masked]] On Behalf Of Zehler,
Peter
Sent: Friday, May 09, 2014 10:35 PM
To: [email-masked]
Subject: [IPP] WG Last Call of IPP Scan Service specification

All,

Our intent is to move IPP Scan Service to PWG Formal Vote before the August
2014 F2F.

Peter Zehler

Xerox Research Center Webster
Email: [email-masked]
Voice: (585) 265-8755 <tel:%28585%29%20265-8755> 
FAX: (585) 265-7441 <tel:%28585%29%20265-7441> 
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701