IPP> Last Call Comment: Job and Printer time attributes shou ld be REQUIRED (part of Issue 17)

IPP> Last Call Comment: Job and Printer time attributes shou ld be REQUIRED (part of Issue 17)

IPP> Last Call Comment: Job and Printer time attributes shou ld be REQUIRED (part of Issue 17)

Hastings, Tom N hastings at cp10.es.xerox.com
Fri Apr 30 18:19:14 EDT 1999


Thanks for the suggestion.  So how about:

     The time does not have to be that precise in order to work in
     practice.

Tom

-----Original Message-----
From: Ron Bergman [mailto:rbergma at dpc.com]
Sent: Friday, April 30, 1999 15:07
To: Manros, Carl-Uno B
Cc: Hastings, Tom N; ipp at pwg.org
Subject: RE: IPP> Last Call Comment: Job and Printer time attributes
shou ld be REQUIRED


Carl-Uno,

A simple statement such as in my previous email...

    "Do the best you can to obtain the correct local time."

Or to restate from your email...

    "The time does not have to be that precise in order to work in
     practice."

The specification of a tolerance in this case is not appropriate.  Here
words much are better.

	Ron Bergman
	Hitachi Koki Imaging Solutions



On Fri, 30 Apr 1999, Manros, Carl-Uno B wrote:

> Ron,
> 
> I think Tom was just trying to come up with some kind of indicator that
the
> time does not have to be that precise in order to work in practice, most
of
> the time. Some people seem to have assumed that the time has to be
> absolutely exact.
> 
> Do you have a more generic way of saying it?
> 
> Carl-Uno
> 
> > -----Original Message-----
> > From: Ron Bergman [mailto:rbergma at dpc.com]
> > Sent: Friday, April 30, 1999 2:07 PM
> > To: Hastings, Tom N
> > Cc: ipp at pwg.org
> > Subject: RE: IPP> Last Call Comment: Job and Printer time attributes
> > shou ld be REQUIRED
> > 
> > 
> > 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