How about adding the following sentence to the "printer-current-time"
attribute:
An implementation MAY support this attribute by obtaining the date and time
by any number of implementation-dependent means at startup or subsequently.
Examples include: (1) an internal date time clock, (2) from the operator at
startup, (3) from HTTP headers supplied in client requests, and (4) from the
network, using NTP [RFC1305] or DHCP option 32 [RFC2132] that returns the
address of the NTP server. If an implementation supports this attribute by
obtaining the current time from the network (at startup or later), but the
time is not available, then the implementation MUST return the value of this
attribute using the out-of-band 'no-value' meaning not configured. See the
beginning of section 4.1.
Since the new "date-and-time-at-xxx" Job Description attribute refer to the
"printer-current-time", they will be covered also.
Tom
-----Original Message-----
From: SHIVAUN_ALBRIGHT@HP-Roseville-om2.om.hp.com
[mailto:SHIVAUN_ALBRIGHT@HP-Roseville-om2.om.hp.com]
Sent: Monday, April 26, 1999 16:29
To: hastings@cp10.es.xerox.com; ipp@pwg.org
Subject: RE: IPP> Last Call Comment: Job and Printer time attributes
should be REQ UIRED
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@cp10.es.xerox.com
> Sent: Monday, April 26, 1999 10:46 AM
> To: Non-HP-ipp /HP-Roseville,mimegw3/dd.HPMEXT1=ipp@pwg.org
> Cc: Non-HP-hastings
> /HP-Roseville,mimegw3/dd.HPMEXT1=hastings@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
>