I see a way in which your comments added a new wrinkle, although I may be
mistaken. I didn't get the impression in the previous messages that we
were discussing mandating that a *client* support IPPGET if it supports any
notification mechanisms--I read Carl's "notification implementations" as
discussing IPP servers only.
What does it mean that a client "support" a mandatory notification
mechanism? If the client has no interest in actually using that mechanism,
it doesn't make sense to force the client to implement it anyway, then just
not use it. Am I missing something?
IBM Printing Systems
"Hastings, Tom N"
<email@example.com To: Carl <firstname.lastname@example.org>
.xerox.com> cc: email@example.com
Sent by: Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications - Commen ts by April 15
04/09/02 07:32 PM
I support the proposal to REQUIRE a Notification Delivery Method so that
interoperability between a conforming client and a conforming Printer is
enhanced for Notifications.
I also support the proposal to make IPPGET be that REQUIRED Delivery Method
by changing the IPP Notifications and Subscriptions document (which is an
OPTIONAL IPP extension document) in the following ways:
1. REQUIRE that a Printer support the IPPGET Delivery Method, if the
supports IPP Notifications.
2. REQUIRE that a client support the IPPGET Delivery Method, if it supports
3. RFC 2910 already RECOMMENDs that a Printer support TLS, so saying the
same thing in the Notifications and Subscriptions document would be
redundant, but we could still do that.
Compared to our other two Delivery Methods (MAILTO and INDP), the IPPGET
Delivery Method has the following advantages:
a. it is the easiest Delivery Method to support
b. it is in-band so it doesn't create any additional firewall problems
c. it is also useful for LAN job submission (with no firewall)
d. it doesn't create any more administrative problems
e. it is REQUIRED for IPPFAX conformance.
f. and doesn't have any SPAM problems (since the job submitter is polling
and/or keeping a channel open for notification events).
The IPPGET spec also should be changed:
4. We should also change the IPPGET spec itself from its current
"RECOMMENDED" to "REQUIRED" as a Delivery Method for an IPP Printer to
From: Carl [mailto:firstname.lastname@example.org]
Sent: Saturday, March 30, 2002 13:30
To: Carl; email@example.com
Subject: IPP> RE: Mandatory Delivery Method for Notifications - Comments
by April 15
Resend, with spelling corrected etc. The earlier message slipped away
I had finished it.
Ned Freed communicated in an earlier message to the IPP WG, that the IESG
found it unacceptable that we had not choosen ONE mandatory delivery method
for notifications. They would also like to see that delivery method mandate
the use of security.
As those of you who were around about two years ago remember, we could not
reach agreement about mandating any of the delivery methods.
However, in the meantime the members of the IPPFAX project in the Printer
Working Group has reached an agreement that they will require all IPPFAX
implementions to implement the 'ippget' delivery method, and it also
requires support for TLS security.
Hence, I would like to put up the following strawman proposal to the IPP WG
members to satisfy the IESG comments:
1) Change the main Notifiction document to require that 'ippget' delivery
MUST be included for all notification implementations, but any of the other
two methods can also be implemented as an option.
2) Put that rule also into the three delivery method documents, so it is
crystal clear what the rule is.
3) Further, in the 'ippget' delivery document, we specify that TLS security
MUST be supported.
If we can reach agreement on this, I will instruct the IPP editor to
implement these changes.
I would like to get your reactions back on this proposal no later than
Chair of IETF IPP WG
10701 S Eastern Ave #1117
Henderson, NV 89052, USA
This archive was generated by hypermail 2b29 : Wed Apr 10 2002 - 11:56:21 EDT