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)

Ron Bergman rbergma at dpc.com
Fri Apr 30 18:24:31 EDT 1999


Tom,

very good!


 	Ron Bergman
 	Hitachi Koki Imaging Solutions


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

> 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