All,
I am in favor of the printer attributes printer-up-time and
printer-current-time being mandatory. I also favor the job attributes
date-time-at-creation, date-time-at-processing and date-time-at-completed
being mandatory. I do not object to time-at-creation, time-at-processing
and time-at-completed also being mandatory. I guess that is "Alternative 2"
with the addition of printer-current-time. (Remember that
printer-current-time's syntax is dateTime)
Pete
Peter Zehler
XEROX
Xerox Architecture Center
Email: Peter.Zehler at usa.xerox.com
Voice: (716) 265-8755
FAX: (716) 265-8792
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 129-39B
Webster NY, 14580-9701
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Monday, April 26, 1999 1:46 PM
To: ipp
Subject: IPP> Last Call Comment: Job and Printer time attributes should
be REQ UIRED
This last call comment on IPP/1.1 is:
The following OPTIONAL IPP/1.0 attributes should be changed to MANDATORY for
an IPP 1.1 Printer to support:
4.3.12 time-at-creation (integer(MIN:MAX)) Job Description attribute
4.3.13 time-at-processing (integer(MIN:MAX)) Job Description attribute
4.3.14 time-at-completed (integer(MIN:MAX)) Job Description attribute
Justification:
The IPP/1.0 4.4.26 printer-up-time (integer(1:MAX)) Printer Description
attribute is REQUIRED, so requiring the corresponding Job attributes for
IPP/1.1 is not a burden on an implementation.
We learned from the Printer MIB experience that not mandating prtAlertTime
was a serious problem and we changed it to be MANDATORY when going from the
proposed standard (RFC 1759) to draft standard (finished two years ago and
still not published as an RFC). The problem shows up when an application
started up and displayed the alert table. Without knowing the time of each
alert, it was very confusing for an operator. The operator didn't know
whether the alert was two days old or had just happened without the time of
each alert being included with the alert data.
Same with an IPP client displaying the job queue, either the completed jobs
or the jobs that haven't completed. Without knowing the time that the job
was submitted, started processing, or complete, the display of jobs is
rather useless to the user. Also many clients don't bother to support
attributes that are OPTIONAL for the IPP Printer to support.
ALTERNATIVE 1:
Instead, we could REQUIRE the new IPP/1.1 dateTime Job Description
attributes (that we have agreed to add as OPTIONAL in closing Issue 17):
4.3.x date-time-at-creation (dateTime) Job Description attribute
4.3.x date-time-at-processing (dateTime) Job Description attribute
4.3.x date-time-at-completed (dateTime) Job Description attribute
People have objected to making these new attributes REQUIRED, because on
some networks the date and time isn't available, such as home networks.
However, we could write the requirement such that the IPP/1.1 Printer
implementation had to attempt to get the time by some means, such as getting
the time from a networked NTP Time server, from an incoming HTTP request
(where it is always present), from the operator either at boot time or some
web administrative interface, or by having a persistent internal clock.
Failing such an attempt a conforming implementation would either NOT return
these Job attributes or return them using the out-of-band 'no-value' meaning
no configured value.
Note: For NTP, see RFC 1305. Also DHCP option 32 in RFC 2132 returns the IP
address of the NTP server.
ALTERNATIVE 2:
REQUIRE both the date-time Job attributes and the time Job attributes, i.e.,
both of the above.
Comments?
Tom