Hi Tom,
I like this simplification. I agree that the Job Creation operation
results (status codes) are already seriously complicated by the
(multiple) Subscription objects that can be affixed to the Job
Creation operation.
Cheers,
- Ira McDonald
High North Inc
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Monday, October 22, 2001 2:23 PM
To: ipp (E-mail); IPP FAX DL (E-mail)
Cc: Kugler Carl (E-mail); Lewis Harry (E-mail)
Subject: IFX> NOT - IPPGET Delivery Method ISSUE 01: Event Wait Mode for
Job Cr eation operations
I've been thinking more about ISSUE 01:
ISSUE 01: Although we agreed to extend Job Creation operations to
support Event Wait Mode, it seems to be an unnecessary complication, since
the Printer MUST keep events for at least 15 seconds. So OK NOT to add the
"notify-wait" (boolean) operation attribute to Job Creation operations and
NOT have to have Job Creation responses return Event Notification Groups (in
addition to returning Subscription Attribute Groups).
I think the following simplifications would make it straightforward to
support as an extension to Job Creation operations:
1. Just add "notify-wait" (boolean) as a Job Creation (Create-Job,
Print-Job, Print-URI) operation attribute and a Validate-Job operation
attribute.
A client MAY supply
A Printer MUST support both values, if it supports Get-Notifications
operation.
2. Just add "notify-get-interval" (integer(0:MAX)) operation attribute to
the Job Creation response.
A Printer MUST support if it supports Get-Notifications.
If a client setup an 'ippget' Subscription object in the Job Creation
operation, a Printer MAY return "notify-get-interval" in which case a client
MUST try the Get-Notifications again according to the interval returned.
A Printer MUST support if it supports Get-Notifications. (Then there is no
need for more Printer Description attributes to say whether Wait Mode is
supported for Job Creation operations; it MUST be if Get-Notifications is
supported.)
3. In order not to complicate the status code coming back in the Job
Creation response (which already as multiple groups coming back for each
Subscription object and each group has its own "notify-status-code" as well
as the operation having an "overall" status code, how about saying that the
Job Creation response MUST NOT include any Notification Events. If the
client requests Event Wait Mode in the Job Creation operation ("notify-wait"
= 'true'), the Printer MUST return any Notification Events in subsequent
responses, so that the status code for the Notification Events is exactly as
it is in Get-Notification responses.
How does that sound?
Then the agreement reached in Toronto to specify Event Wait Mode for Job
Creation would be met. The same Get-Notifications response code would be
invoked by the Job Creation operations.
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Friday, October 19, 2001 03:37
To: ipp (E-mail); IPP FAX DL (E-mail)
Subject: IFX> NOT - IPPGET Delivery Method down-loaded - REQUIRED for
IPPFAX
I've posted the updated IPPGET Event Notification Delivery Method that is
REQUIRED for IPPFAX:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-011017.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-011017.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-011017-rev.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-011017-rev.doc
The -rev version show the revisions since the July 17, 2001 version.
It has all of the agreements reached at the August 1, IPP FAX meeting in
Toronto and the subsequent 3 telecon, August 11, 14, and 17. See the
telecon and meeting notes for the list of the changes.
I'll send a .txt I-D later Friday. Please send any comments to the mailing
list. We'll also review at the IPPFAX WG meeting, next Wednesday, October
24 in San Antonio.
There are two issues:
ISSUE 01: Although we agreed to extend Job Creation operations to
support Event Wait Mode, it seems to be an unnecessary complication, since
the Printer MUST keep events for at least 15 seconds. So OK NOT to add the
"notify-wait" (boolean) operation attribute to Job Creation operations and
NOT have to have Job Creation responses return Event Notification Groups (in
addition to returning Subscription Attribute Groups).
ISSUE 02: How unique do we need the "notify-recipient-uri" (uri)
URL now that the Printer doesn't use anything but the scheme in the URL to
match on?
Here are the major changes:
1. Removed the "notify-recipients-uri" operation attribute from
Get-Notifications, so no URI matching.
2. Changed "notify-subscription-id" (integer(1:MAX)) to
"notify-subscription-ids" (1setOf integer(1:MAX)); the client MUST supply
with at least one value. Printer MUST support multiple-values.
3. Added "notify-sequence-numbers" (1setOf integer(1:MAX)) to be parallel
and be a floor to the Event Notifications sequence numbers returned. The
client SHOULD supply. Printer MUST support multiple-values.
4. In Event Wait Mode, each response is a full IPP response.
5. Moved "notify-get-interval" back to the operations attributes group in
the response.
6. Added 'successful-ok-events-complete to indicate that there will be no
more events for this Subscription object.
7. The Printer MUST support Event Wait Mode.
8. The client can end Event Wait Mode (without closing the connection) by
sending "notify-wait" = 'false' any time. The Printer can end Event Wait
Mode (without closing the connection) by returning "notify-get-internal"
operation attribute any time (including immediately).
9. Changed the lower limit for "ippget-event-life" from 1 to 15 seconds and
recommend 60 seconds to agree with the PWG Job Monitoring MIB (RFC 2707).
Thanks,
Tom