IPP Mail Archive: RE: IPP> ISSUE 17 - Job Time Event attributes (AGAIN)

RE: IPP> ISSUE 17 - Job Time Event attributes (AGAIN)

Anthony Porter (anthony.porter@computer.org)
Wed, 19 May 1999 14:44:06 +0200

Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Hastings, Tom N: "IPP> RE: question about "ipp-implementers-guide-990212" document"
Previous message: Hastings, Tom N: "IPP> NOT - New IPP Event Notifications paper posted"

Tom,
Yes, I am for Alt 1 but without the job-printer-up-time and without the
date-time-at-xxx recommendation.

I don't want a make a big issue of job-printer-up-time, but it seems a bit
out of place as an alias for printer-up-time and one could make the same
argument about printer-state and printer-state-reasons. It looks like the
sort of thing that can give rise to unforeseen problems. Examples might be:

1. The server has to return a long list of jobs and it takes some time. The
client receives a list with a slightly different job-printer-up-time in each
job.
2. The server returns jobs, but the print unit is down. The server should
probably return no-value for job-printer-up-time, but what does the client
make of this? The client does not know that the print unit is down. When
the client gets the printer attributes directly, it knows that it can ignore
printer-up-time if the printer-state-reason is 'shutdown'

I think that while the client has to poll the printer attributes regularly
in any case there is no need for this oddity. Remember that the client does
not have to poll the server for printer-up-time every time that it polls for
a job's attributes. The client can keep its own running copy of
printer-up-time. The client can suspect that the server may have reset
printer-up-time if it returns jobs with a time value of 0, or if new jobs
have a time-at-creation value of less than the number of seconds since the
last poll.

job-printer-up-time also introduces an unnecessary complication between 1.0
and 1.1.

But there, I won't say any more about it. If I write a client I shall make
sure that I don't use either job-printer-up-time or the date-time-at
attributes.

Anthony Porter
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: 18 May 1999 18:05
To: anthony.porter@computer.org
Cc: ipp
Subject: RE: IPP> ISSUE 17 - Job Time Event attributes (AGAIN)

Anthony,

I think you are suggesting that we agree on alternative 1, not alternative
2:

Alternative 1. REQUIRE the "time-at-xxx(integer)" time tick job attributes
and RECOMMEND the "date-time-at-xxx(dateTime) date time job attributes.

It is Alternative 2 that requires the client to support both. With
alternative 1, the client only needs to support the "time-at-xxx" to get
times, but MAY support both.

Michael Sweet also supports Alternative 1.

So far, no support for Alternative 2 on the DL (Printers MUST support the
time ticks set or the dateTime set or both sets of job attributes).

How about the rest of you?

As far as keeping the "job-printer-up-time" alias, I suggest that we keep
it, since it allows a client to get the printer-up-time in any Get-Jobs or
Get-Job-Attributes operation. Its not a real burden on Printers, since they
have to implement "printer-up-time" anyway, and its a convenience for
clients. This problem for clients was noted during the BakeOff2.

Thanks,
Tom

-----Original Message-----
From: Anthony Porter [mailto:anthony.porter@computer.org]
Sent: Tuesday, May 18, 1999 01:12
To: 'Hastings, Tom N'
Subject: RE: IPP> ISSUE 17 - Job Time Event attributes (AGAIN)

Tom,
No, you are right. The text you propose here is substantially the same as
the 1.0 version.

I am only worried about the proposed additions, because if the server may
return either 'time-at-xxx' or 'dateTime-at-xxx' the client will have to
support both. Also, although the time-at-xxx mechanism seems rather more
complex than the dateTime attributes. It does not rely on the clock in the
server being more or less correct.

I am sure that at Xerox or Microsoft the clocks are all set correctly, but
that seems to be an exception. All the printers and servers at this site
are 57 minutes fast because they are set by a server that is 3 minutes slow
and is still in the winter time zone. If you look at the message header for
my e-mail you will notice that our mail server is also about an hour fast.
I think that many IPP printers will operate behind a firewall and will not
be able to query internet time servers

Finally, I see no need to return job-printer-up-time for each job, because
once the client has the printer-up-time, it knows the time when
printer-up-time was set, and can use that to calculate future job times. It
only needs to requery printer-up-time once in a while, or if it suspects
that the server has reset it.

Since I am writing a server, it does not make any difference to me, I can
return any number of attributes. I just can't rely on the customers setting
the clock properly.
Anthony

-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: 17 May 1999 19:29
To: anthony.porter@computer.org
Cc: 'ipp'
Subject: RE: IPP> ISSUE 17 - Job Time Event attributes (AGAIN)

Anthony,

I'm confused by your comment for the following reasons:

1. IPP/1.0 did not require that any time be supported, so IPP/1.1 is an
improvement in that with either of the two alternatives proposed below, the
client can get time.

2. The IPP/1.1 allows the Printer to keep the "printer-up-time" running on
power up (as suggested by you on a previous mail message), because it says
"If the printer resets "printer-up-time" ... So the intent was to preserve
the IPP/1.0 implementation option to keep the tick clock running or reset on
power-ups.

Here is the full proposed new text for IPP/1.1:

4.4.27 printer-up-time (integer(1:MAX))

This REQUIRED Printer attribute indicates the amount of time (in
seconds) that this Printer instance has been up and running. The value
is a monotonically increasing value starting from 1 when the Printer
object is started-up (initialized, booted, etc.). This value is used to
populate the Event Time Job Description Job attributes "date-time-at-
creation", "date-time-at-processing", and "date-time-at-completed" (see
Section 4.3.12).

If the Printer object resets the value of "printer-up-time" on
subsequent power-ups, the Printer MUST reset this value to 1. If this
value is reset and the implementation has persistent jobs, then the
Printer MUST reset the Event Time Job Description Attributes that use
the 'integer' form, if supported, according to Section 4.3.13.

And the proposed referred Section 5.3.13 has the same "If the Printer resets
its "printer-up-time" following:

If the Printer resets its "printer-up-time" attribute to 1 on power-up
and has persistent jobs, then it MUST change all of its "time-at-
xxx(integer)" (time tick) job attributes whose events have occurred as
follows:

1. set to 0 to indicate that the event happened before the most
recent power up

2. set to the negative of the number of seconds before the most
recent power-up that the event took place, though the negative
number NEED NOT reflect the exact number of seconds

Do you think that the above proposed text is actually different from
IPP/1.0?
The intent was to allow the "printer-up-time" to continue as an
implementation option, such as in IPP/1.0.

Here is the "printer-up-time" from IPP/1.0 (RFC 2566):

4.4.26 printer-up-time (integer(1:MAX))

This REQUIRED Printer attribute indicates the amount of time (in
seconds) that this instance of this Printer implementation has been
up and running. This value is used to populate the Job attributes
"time-at-creation", "time-at-processing", and "time-at-completed".
These time values are all measured in seconds and all have meaning
only relative to this attribute, "printer-up-time". The value is a
monotonically increasing value starting from 1 when the Printer
object is started-up (initialized, booted, etc.).

If the Printer object goes down at some value 'n', and comes back up,
the implementation MAY:

1. Know how long it has been down, and resume at some value greater
than 'n', or
2. Restart from 1.

In the first case, the Printer SHOULD not tweak any existing related
Job attributes ("time-at-creation", "time-at-processing", and "time-
at-completed"). In the second case, the Printer object SHOULD reset

deBry, et al. Experimental [Page 110]

RFC 2566 IPP/1.0: Model and Semantics April 1999

those attributes to 0. If a client queries a time-related Job
attribute and finds the value to be 0, the client MUST assume that
the Job was submitted in some life other than the Printer's current
life.

-----Original Message-----
From: Anthony Porter [mailto:anthony.porter@computer.org]
Sent: Monday, May 17, 1999 01:45
To: 'Hastings, Tom N'; 'ipp'
Subject: RE: IPP> ISSUE 17 - Job Time Event attributes (AGAIN)

Of all the alternatives, I prefer the original 1.0 version. It had these
advantages:
1. The client could easily display job events accurately in client local
time.
2. The client only had to implement one method.
3. The server did not need a clock

and these disadvantages
1. The client had to request the printer-up-time periodically, although it
did not have to do this on each job request. There is no need for the
job-printer-up-time
2. The client might display incorrect times if the server both reset its
printer-up time and preserved jobs between polls.

The printer might have a clock for job accounting or other applications, and
if it did it could support printer-current-time and maintain printer-up-time
between power cycles, so that printer-up-time represented time since system
set-up. That would take care of the 2nd disadvantage.

The other alternatives complicate matters because they oblige the client to
support different methods for 1.0 and 1.1 servers, and they assume that the
server has the clock set to within a few minutes of the correct time. In
practice, there is widespread confusion among operators and system
administrators over the meaning of timezones, daylight time and the meaning
of UTC.

We could have done something else for 1.0, but the 1.0 solution seems
prefectly workable, and I think we should stick with it.

Anthony Porter
-----Original Message-----
From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of Hastings,
Tom N
Sent: 14 May 1999 03:26
To: ipp
Subject: IPP> ISSUE 17 - Job Time Event attributes (AGAIN)

Here is the text for ISSUE 17 again, which was re-opened at the IPP telecon
yesterday. The issue was that reviewers didn't like having the
"time-at-xxx" Event Time Job Description attributes have two attributes
syntaxes: 'integer' and 'dateTime'. So instead add three new
"date-time-at-xxx(dateTime)" job attributes.

This proposal has two alternatives (because we couldn't agree and ask for
feedback from the DL):

Alternative 1. REQUIRE the "time-at-xxx(integer)" time tick job attributes
and RECOMMEND the "date-time-at-xxx(dateTime) date time job attributes.

Alternative 2. A Printer MUST support either:

option a) the set of 3 "time-at-xxx(integer) and "job-printer-up-
time(integer) Job attributes

OR:

option b) the set of 3 "date-time-at-xxx(dateTime) Job attributes
and the "printer-current-time(dateTime)" Printer attribute

Implementations MAY support both options (a) and (b). It is RECOMMENDED
that option (b) be supported, if only one option is supported.

Here is the complete text for the issues with the alternative text embedded
in two places:

17) ISSUE: Client display of absolute time for job attributes?

What are clients doing with printers that don't support absolute time?
How can client display an absolute time that a job was submitted,
started processing, and completed (which is what is useful for a user)?

Possible Solution

Get Uptime from printer ("printer-up-time" - time system has been up in
seconds)

Get Job(s)

Calculate Display time = job tick time ("time-at-xxx" - in seconds that
system has been up) - uptime ("printer-up-time") + local client absolute
date and time. The down side is that the client has to get the
"printer-up-time" every time with a separate Get-Printer-Attributes
operation.

Alternatively: Add OPTIONAL job attributes: "date-time-at-creation
(dateTime)", "date-time-at-processing (dateTime)", and "date-time-at-
completion (dateTime)"

(Microsoft)

Suggested resolution:

1. Change the range on the 3 "time-at-xxx" job time attributes from
0:MAX as it is in IPP/1.0 to MIN:MAX:

time-at-creation(integer(MIN:MAX))
time-at-processing(integer(MIN:MAX))
time-at-completed(integer(MIN:MAX))

A negative value indicates an event that happened that many seconds
before the most recent power-up of the Printer; a 0 value means that the
event occurred at some unspecified time before the printer was powered
up most recently. Describe the 0 and negative values once in the time-
at-xxx section.

2. Change the current section 4.4.26 printer-up-
time(integer(1:MAX)) with respect to restarts. If the IPP/1.0
Printer resets the "printer-up-time" on power-up, it MUST reset the
"time-at-xxx" Job time attributes for any persistent jobs back to 0
to indicate that the event took place sometime before the most
recent power-up or to a negative value that represents the number
of seconds before the most recent power-up that the event took
place

3. Problem: Make it easier for clients to get clock time for job
events, make it easier for clients to correlate job events with
notifications which need to use date and time (since there may not be

intermediate servers to translate relative tick time to absolute
date/time), allow the Printer to not have to adjust the time attribute
values of all the persistent jobs on power-up, avoid the need for
intermediate IPP servers to translate relative tick time as responses
are cascaded back to original client.

Solution: add three new RECOMMENDED dateTime attribute syntax Job
Description attributes:

date-time-at-creation(integer(MIN:MAX) | dateTime)
date-time-at-processing(integer(MIN:MAX) | dateTime)
date-time-at-completed(integer(MIN:MAX) | dateTime)

Thus the value returned is the Printer's "printer-current-
time(dateTime)" when the event occurred. Now the client simply requests
whichever of these attributes and deal with which ever attributes it
gets back.

Clarify that the date and time does not have to be very accurate. The
time does not have to be that precise in order to work in practice.

If an implementation cannot get the dateTime, then it MUST return the
out-of-band 'no-value' value.

4. To solve the problem of the client having to make two trips to the
printer when displaying jobs:

first to get the "time-at-xxx" job attributes with Get-Jobs or Get-
Job-Attributes, and

second to get the "printer-up-time" with Get-Printer-Attributes,

we'll add a another job attribute:

job-printer-up-time(integer(1:MAX))

which is an alias for the Printer's "printer-up-time(integer(1:MAX))".

5. To help clients being able to depend on getting either a dateTime or
time tick, increase the conformance requirements. There are two
alternatives for doing so:

Alternative 1: change the 3 "time-at-xxx(integer)" job time
attributes from OPTIONAL to REQUIRED. This shouldn't be a burden,
since the corresponding printer attribute: "printer-up-time" is
already REQUIRED in IPP/1.0. Also the draft Printer MIB and MIB-II
require that a device have a clock tick capability. (and keep the
3 new date-time-at-xxx attributes as RECOMMENDED).

Alternative 2: In addition to the REQUIRED "printer-up-
time(integer)", also REQUIRE that a Printer support one of:

the 3 "time-at-xxx(integer)" job attributes and the "job-
printer-up-time(integer)"

the 3 "date-time-at-xxx(integer) job attributes and "printer-
current-time(dateTime)"

all 8 attributes

6. Clarify that if an implementation supports the "printer-current-
time(dateTime)" attribute by getting the time from some source such as
the network or an operator, but was unable to, that it MUST return the
out-of-band 'no-value' which means not configured (yet). See the
beginning of section 4.1 in the Model.

7. Clarify that the time zone NEED NOT be that used by people in the
vicinity of the Printer or device and that clients SHOULD convert
dateTime attributes to the time zone of the client before display to the
user.

8. Clarify that the "time-at-processing" is the first time the job
begins processing after the create operation or the most recent Restart-
Job operation.

IIG: Describe some of the many ways that implementations can get the
date and time:

1. Any network printer can get time from NTP Time server. See
RFC
1305. Also DHCP option 32 in RFC 2132 returns the IP address of
the NTP server.

2. Get the date and time at startup from a human operator

3. Have an operator set the date and time using a web
administrative interface

4. Get the date and time from incoming HTTP requests, though the
problems of spoofing need to be considered. Perhaps comparing
several HTTP requests could reduce the chances of spoofing.

5. Internal date time clock battery driven.

6. Query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"

Suggested text for section 4.1.14 dateTime

4.1.14 'dateTime'

The 'dateTime' attribute syntax is a standard, fixed length, 11 octet
representation of the "DateAndTime" syntax as defined in RFC 1903
[RFC1903]. RFC 1903 also identifies an 8 octet representation of a
"DateAndTime" value, but IPP objects MUST use the 11 octet
representation. A user interface will provide a mapping between
protocol dateTime values and displayable user-friendly words or
presentation values and phrases which are localized to the natural
language and date format of the user, including time zone.

Suggested text for the table in section 4.3:

*************************************************************************
Alternative 1:

End of Alternative 1 *****************************************************

*************************************************************************
Alternative 2:

Note 1: These attributes MUST be supported if the 3 RECOMMENDED "date-
time-at-xxx(dateTime)" attributes are not supported.

End of Alternative 2 ******************************************************

Suggested text for a new section 4.3.12 Event Time Job Description
Attributes:

Group the three "time-at-xxx" Job Description time attributes into a
single section so that the common semantics can be said once:

4.3.12 Event Time Job Description Attributes

This section defines the Job Description attributes that indicate the
time at which certain events occur for a job. If the job event has not
yet occurred, then the IPP object MUST return the 'no-value' out-of-band
value (see the beginning of Section 4.1). The "time-at-xxx(integer)"
attributes represent time as an 'integer' representing the number of
seconds since the device was powered up (informally called "time
ticks"). The "date-time-at-xxx(dateTime)" attributes represent time as
'dateTime' representing date and time (including an offset from UTC).

In order to populate these attributes, the Printer object copies the
value(s) of the following Printer Description attributes at the time the
event occurs:

1. the value in the Printer's "printer-up-time" attribute for the
"time-at-xxx(integer)" attributes

2. the value in the Printer's "printer-current-time" attribute for
the "date-time-at-xxx(dateTime)" attributes,

****************************************************************************
*
Alternative 2:

A Printer MUST support either:

option a) the set of 3 "time-at-xxx(integer) and "job-printer-up-
time(integer) Job attributes

OR:

option b) the set of 3 "date-time-at-xxx(dateTime) Job attributes
and the "printer-current-time(dateTime)" Printer attribute

Implementations MAY support both options (a) and (b). It is RECOMMENDED
that option (b) be supported, if only one option is supported.

and delete "REQUIRED" from the descriptions of each of the "time-at-xxx"
attributes below.

End of Alternative 2
********************************************************

1. set to 0 to indicate that the event happened before the most
recent power up

2. set to the negative of the number of seconds before the most
recent power-up that the event took place, though the negative
number NEED NOT reflect the exact number of seconds

Note: A Printer does not change the values of any "date-time-at-
xxx(dateTime)" job attributes on power-up.

4.3.12.1 time-at-creation (integer(MIN:MAX))

This REQUIRED attribute indicates the time at which the Job object was
created.

4.3.12.2 time-at-processing (integer(MIN:MAX))

This REQUIRED attribute indicates the time at which the Job object first
began processing after the create operation or the most recent Restart-
Job operation.

4.3.12.3 time-at-completed (integer(MIN:MAX))

This REQUIRED attribute indicates the time at which the Job object
completed (or was cancelled or aborted).

4.3.12.4 job-printer-up-time(integer(1:MAX))

This REQUIRED Job Description attribute indicates the amount of time (in
seconds) that the Printer implementation has been up and running. This
attribute is an alias for the "printer-up-time" Printer Description
attribute (see Section 4.4.27).

Note: A client MAY request this attribute in a Get-Job-Attributes or
Get-Jobs request and use the value returned in combination with
otherrequested Event Time Job Description Attributes in order to display
time
attributes to a user. The difference between this attribute and the
integer value of a "time-at-xxx" attribute is the number of seconds ago
that the "time-at-xxx" event occurred. A client can compute the wall-
clock time at which the "time-at-xxx" event occurred by subtracting this
difference from the client's wall-clock time.

4.3.12.5 date-time-at-creation (dateTime)

This RECOMMENDED attribute indicates the date and time at which the Job
object was created.

4.3.12.6 date-time-at-processing (dateTime)

This RECOMMENDED attribute indicates the date and time at which the Job
object first began processing after the create operation or the most
recent Restart-Job operation.

4.3.12.7 date-time-at-completed (dateTime)

This RECOMMENDED attribute indicates the date and time at which the Job
object completed (or was cancelled or aborted).

Suggested text for section 4.4.27 printer-up-time

4.4.27 printer-up-time (integer(1:MAX))

Suggested text for section 4.4.28 printer-current-time:

4.4.28 printer-current-time (dateTime)

This RECOMMENDED Printer attribute indicates the current date and time.
This value is used to populate the Event Time Job Description attributes
"time-at-creation", "time-at-processing", and "time-at-completed" (see
Section 4.3.12).

The date and time is obtained on a "best efforts basis" and does not
have to be that precise in order to work in practice. A Printer
implementation sets the value of this attribute by obtaining the date
and time via some implementation-dependent means, such as getting the
value from a network time server, initialization at time of manufacture,
or setting by an administrator. See [ipp-iig] for examples. If
animplementation supports this attribute and the implementation knows that
it has not yet been set , 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.

The time zone of this attribute NEED NOT be the time zone used by people
located near the Printer object or device. The client MUST NOT expect
that the time zone of any received 'dateTime' value to be in the time
zone of the client or in the time zone of the people located near the
printer.

The client SHOULD display any dateTime attributes to the user in client
local time by converting the 'dateTime' value returned by the server to
the time zone of the client, rather than using the time zone returned by
the Printer in attributes that use the 'dateTime' attribute syntax.

Next message: Hastings, Tom N: "IPP> RE: question about "ipp-implementers-guide-990212" document"
Previous message: Hastings, Tom N: "IPP> NOT - New IPP Event Notifications paper posted"