Tom,
My understanding from the New Orleans meeting was that the attribute for time
would be required, however, there would be instances where a printer would be
unable to report the time. For instance, printers that don't have an internal
clock may not be able to obtain the time when a time server is unavailable on
the network. I thought that we agreed to document what value should be
reported when this occurs. Has this been done yet?
The intent of requiring this attribute was to ensure that printer vendors made
an attempt to provide the time value, but not to require an internal clock on
all printers. The statement was made that optional features do not get
implemented and this was an attempt to improve the data reported by the client.
Shivaun Albright
Hewlett-Packard
> -----Original Message-----
> From: Non-HP-hastings
> /HP-Roseville,mimegw3/dd.HPMEXT1=hastings at cp10.es.xerox.com> Sent: Monday, April 26, 1999 10:46 AM
> To: Non-HP-ipp /HP-Roseville,mimegw3/dd.HPMEXT1=ipp at pwg.org> Cc: Non-HP-hastings
> /HP-Roseville,mimegw3/dd.HPMEXT1=hastings at cp10.es.xerox.com> 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
>