IPP> Last Call Comment: Job and Printer time attributes shou ld be REQUIRED

IPP> Last Call Comment: Job and Printer time attributes shou ld be REQUIRED

Ron Bergman rbergma at dpc.com
Fri Apr 30 17:06:58 EDT 1999


Tom,

I have watched this discussion go into various states of disarray.  It
seemed to finally settle into a reasonable reality, until I saw this
latest message.

Don't we just want to say... "Do the best you can to obtain the correct
local time." ?  Why are you trying to put a tolerance on this?  So if I
can't guarantee +/- 5 minutes, I better not report clock time?  What is so
magical about 5 minutes?  (Normally during the day I don't know the time
to the nearest hour...  but I degress.)

The specification should be precise where required.  If precision is not
required, no tolerance need be specified.


	Ron Bergman
	Hitachi Koki Imaging Solutions



On Fri, 30 Apr 1999, Hastings, Tom N wrote:

> Patrick,
> 
> We agree that we don't want to mandate an accurate time.
> 
> How about adding a clarification to the Printer's "printer-current-time"
> attribute like:
> 
>    The accuracy of the value MAY be on the order of plus or minus five
> minutes.
> 
> Tom
> 
> -----Original Message-----
> From: papowell at astart4.astart.com [mailto:papowell at astart4.astart.com]
> Sent: Tuesday, April 27, 1999 17:29
> To: hastings at cp10.es.xerox.com;
> SHIVAUN_ALBRIGHT at HP-Roseville-om2.om.hp.com
> Cc: ipp at pwg.org
> Subject: RE: IPP> Last Call Comment: Job and Printer time attributes
> shou ld be REQ UIRED
> 
> 
> > From ipp-owner at pwg.org Tue Apr 27 12:05:43 1999
> > From: "Hastings, Tom N" <hastings at cp10.es.xerox.com>
> > To: SHIVAUN_ALBRIGHT at HP-Roseville-om2.om.hp.com
> > Cc: ipp at pwg.org
> > Subject: RE: IPP> Last Call Comment:  Job and Printer time attributes shou
> > 	ld be REQ UIRED
> > Date: Tue, 27 Apr 1999 12:00:22 -0700
> >
> > Shivaun,
> >
> >
> > 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. 
> 
> I am totally blown away at all this discussion about time.
> 
> I will simply note that of the various locations that I have
> visited (over a couple of dozen this month),  only 1 (one) had the
> SERVER time within 1 minute of WWV,  and this was because it periodically
> went out and got it from a WWV receiver.
> 
> I think that this standards group needs a bit of a reality check.
> 
> I suspect strongly that the 'no-value' will become the operational
> standard.
> 
> Patrick Powell
> 




More information about the Ipp mailing list