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
> > >
> >
>