Ira McDonald and I were talking about the IPPGET which has a "redirect-uri"
operation attribute that MAY be returned in a Get-Notifications response
when the 'redirection-other-site' status code returned. Here is all of the
text in the document that deals with redirection:
5.2 Get-Notifications Response
redirection-other-site: The Printer does not handle this operation and
requests the Notification Recipient to perform the operation again with the
uri specified by the "redirect-uri" Operation Attribute in the response.
See section 10.2.
5.2.3 redirect-uri (uri)
The value of this attribute is the uri that the Notification Recipient MUST
use for a subsequent Get-Notifications operation. The Printer MAY support
this attribute. This attribute MUST be returned in the Operation Attributes
Group if and only if the Printer returns the 'redirection-other-site' status
code (see section 10.2).
10.2 redirection-other-site (0x0300)
This status code means that the Printer doesn't perform that
Get-Notifications operation and that the "redirect-uri" operation attribute
(see section 5.2.3) in the response contains the uri that the Notification
Recipient MUST use for performing the Get-Notifications operation. If the
client issues subsequent Get-Notifications operations, it MUST use the value
of the "redirect-uri" operation attribute returned by the Printer as the
target of the operation.
12.1 Printer Conformance
8. MUST support the "redirection-other-site" status code defined 10.2,
if it redirects Get-Notifications operations;
Presumably a client MUST support the 'redirection-other-side' status code if
it ever is returned by a Printer in a Get-Notifications response, though
section 12.2 Client Conformance doesn't mention this.
We suggest that we delete all of the above text from the IPPGET spec, so
that there is no redirect status code and no "redirect-uri" operation
attribute for the following reasons:
1. The HTTP Layer already has redirect for all operations, not just
Get-Notifications. Introducing a competing redirection mechanism into the
application layer seems a mistake. What happens if they both occur?
2. Redirection has a number of problems for Get-Notifications, in that if a
Printer is using a Notification Server to return events, along with other
Printers, then getting job attributes from the Job object on a job event
means that the job-ids for each of the Printers have to be allocated in a
non-conflicting way for each of the Printers. Or alternatively, the Printer
needs to return not only a "redirect-uri", but also possibly a new-job-id,
if the job id has changed.
3. If we ever wanted to put IPP semantics on another transport, we can
decide then whether to introduce the redirection concept into IPP
application layer for all operations (and fix the problems listed above) or
use the transport's redirect mechanism.
4. Removing this redirect mechanism makes it simpler for a client using
Get-Notifications, since the client won't have to deal with it. And since
IPPGET is proposed to be the REQUIRED notification method, simplifying
IPPGET for clients is a good idea.
Comments?
Tom
-----Original Message-----
From: Carl [mailto:carl at manros.com]
Sent: Saturday, July 13, 2002 13:37
To: ipp at pwg.org
Subject: IPP> ADM - IPP Working Group Last Call for "(IPP): Event
Notifications and Subscriptions" and "(IPP): The 'ippget'Delivery Method
for Event Notifications " by July 31, 2002
All,
This is a working group Last Call for the "Internet Printing Protocol (IPP):
Event Notifications and Subscriptions" and the "Internet Printing Protocol
(IPP): The 'ippget'Delivery Method for Event Notifications".
Versions of these documents have been forwarded to the Internet
Draft directory as <draft-ietf-ipp-not-spec-09.txt> and
<draft-ietf-ipp-notify-get-07.txt>.
PDF and Word versions of the drafts are also posted at the ietf-ipp web
site:
ftp://ftp.pwg.org/pub/pwg/ipp/
The Last Call notice follows:
This is a formal request for final comments within the IETF IPP
Working Group for two documents. "Internet Printing Protocol (IPP):
Event Notifications and Subscriptions" and the "Internet Printing Protocol
(IPP): The 'ippget' Delivery Method for Event Notifications", which have
earlier been forwarded to the IESG for consideration as Standards Track
RFCs. These are IPP Working Group products, which have been thoroughly
discussed since mid 1998. The latest revisions are the result of feedback
from our Area Director Ned Freed and Working Group discussions earlier
this year. The most significant change is that the 'ippget' delivery method
is now mandated for all implementations of the IPP Event Notifications,
while additional delivery methods can be used as an option.
The purpose of a working group Last Call is in the style of "speak now or
forever hold your peace" in case there are fundamental objections, which
have not gotten previous or adequate discussion, or minor errors which need
correction.
Last Calls are for a minimum of 2 weeks. The period for the Working Group
comments will close on July 31, 2002(US Pacific time reference).
The relevant documents are:
Title : Internet Printing Protocol (IPP): IPP Event
Notifications and Subscriptions
Author(s) : R. Herriot, T. Hastings
Filename : draft-ietf-ipp-not-spec-09.txt
Pages : 101
Date : 03-Jul-02
This document describes an OPTIONAL extension to the Internet
Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910).
This extension allows a client to subscribe to printing related
Events. Subscriptions are modeled as Subscription Objects. The
Subscription Object specifies that when one of the specified Events
occurs, the Printer sends an asynchronous Event Notification to the
specified Notification Recipient via the specified Push or Pull
Delivery Method (i.e., protocol).
A client associates Subscription Objects with a particular Job by
performing the Create-Job-Subscriptions operation or by submitting a
Job with subscription information. A client associates Subscription
Objects with the Printer by performing a Create-Printer-Subscriptions
operation. Four other operations are defined for Subscription
Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew-
Subscription, and Cancel-Subscription.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-spec-09.txt
-----
Title : Internet Printing Protocol (IPP): The 'ippget'
Delivery Method for Event Notifications
Author(s) : R. Herriot, T. Hastings
Filename : draft-ietf-ipp-notify-get-07.txt
Pages : 37
Date : 03-Jul-02
This document describes an extension to the Internet Printing
Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910). This
document specifies the 'ippget' Delivery Method for use with the
'Internet Printing Protocol (IPP): Event Notifications and
Subscriptions' specification. When IPP Notification [ipp-ntfy] is
supported, the Delivery Method defined in this document is the
REQUIRED Delivery Method for clients and Printers to support. They
MAY support additional Delivery Methods.
The 'ippget' Delivery Method is a Pull Delivery Method. When an
Event occurs, the Printer saves the Event Notification for a period
of time called the Event Life. The Notification Recipient fetches
(pulls) Event Notifications using the Get-Notifications operation.
If the Notification Recipient has selected the Event Wait Mode option
to wait for additional Event Notifications, the Printer continues to
return Event Notifications to the Notification Recipient as Get-
Notification responses as Events occur using the connection
originated by the Notification Recipient.
Either the Notification Recipient or the Printer can terminate Event
Wait Mode without closing the connection.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipp-notify-get-07.txt
Sincerely,
Carl-Uno Manros
Chair of the IETF IPP WG
10701 S Eastern Ave #1117
Henderson, NV 89052, USA
Tel +1-702-617-9414
Fax +1-702-617-9417
Mob +1-310-251-7103
Email carl at manros.com