Peter Zehler
XEROX
Xerox Architecture Center
Email: Peter.Zehler@usa.xerox.com
Voice: (716) 265-8755
FAX: (716) 265-8792
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 129-39B
Webster NY, 14580-9701
-----Original Message-----
From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com]
Sent: Friday, April 30, 1999 5:47 PM
To: Ron Bergman; Hastings, Tom N
Cc: ipp@pwg.org
Subject: RE: IPP> Last Call Comment: Job and Printer time attributes
shou ld be REQUIRED
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@dpc.com]
> Sent: Friday, April 30, 1999 2:07 PM
> To: Hastings, Tom N
> Cc: ipp@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@astart4.astart.com
[mailto:papowell@astart4.astart.com]
> Sent: Tuesday, April 27, 1999 17:29
> To: hastings@cp10.es.xerox.com;
> SHIVAUN_ALBRIGHT@HP-Roseville-om2.om.hp.com
> Cc: ipp@pwg.org
> Subject: RE: IPP> Last Call Comment: Job and Printer time attributes
> shou ld be REQ UIRED
>
>
> > From ipp-owner@pwg.org Tue Apr 27 12:05:43 1999
> > From: "Hastings, Tom N" <hastings@cp10.es.xerox.com>
> > To: SHIVAUN_ALBRIGHT@HP-Roseville-om2.om.hp.com
> > Cc: ipp@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
>