Tom,
The way the spec is written, it seems that an IPPFAX Sender would be
required to support redirection in any case.
The spec says (section 2.1):
Statement (sic) of the
form "the IPP Client MUST ..." apply if the
client
supports the IPPGET Event Delivery Method, since this extension
is REQUIRED if the client supports the IPPGET Delivery
Method.
This is more an issue with the spec than with IPPFAX, but isn't it
illegal/impossible to add required extensions?
Dennis
"Hastings,
Tom N"
<mailto:hastings@cp10.es?Subject=Re:
IFX> ISSUE: Is IPPFAX protocol with IPPGET going to use the re-direct
mechanism?&In-Reply-To=<OF7439219B.536DB5A0-ON87256CB4.0052284B-87256CB4.0052917C@us.ibm.com>
To: mailto:ifx@pwg.org?Subject=Re:
IFX> ISSUE: Is IPPFAX protocol with IPPGET going to use the re-direct
mechanism?&In-Reply-To=<OF7439219B.536DB5A0-ON87256CB4.0052284B-87256CB4.0052917C@us.ibm.com>
.xerox.com>
cc:
Sent
by: Subject: IFX> ISSUE: Is IPPFAX protocol with IPPGET going to use the
re-direct mechanism?
mailto:owner-ifx@pwg.org?Subject=Re:
IFX> ISSUE: Is IPPFAX protocol with IPPGET going to use the re-direct
mechanism?&In-Reply-To=<OF7439219B.536DB5A0-ON87256CB4.0052284B-87256CB4.0052917C@us.ibm.com>
01/19/03
06:24 PM
Here is an issue I sent out on October 11, but there has been no answer.
ISSUE 05: for the IPPFAX WG, which is REQUIRING support of IPPGET Delivery
Method: Is redirection an option of an IPPFAX Receiver? If yes, then the
IPPFAX Sender MUST support redirection as specified in this document.
The spec which has the redirect mechanism in it is:
[not-srv],
"Distributed Notification Service and IPPGET Client Behavior",
Hastings, T.,
Lewis, H., and I. McDonald, October 10, 2002, work in
progress,
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-dist-not-service-021010.pdf
Thanks,
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:mailto:hastings@cp10.es.xerox.com?Subject=Re:
IFX> ISSUE: Is IPPFAX protocol with IPPGET going to use the re-direct
mechanism?&In-Reply-To=<OF7439219B.536DB5A0-ON87256CB4.0052284B-87256CB4.0052917C@us.ibm.com>]
Sent: Friday, October 11, 2002 15:14
To: mailto:ipp@pwg.org?Subject=Re:
IFX> ISSUE: Is IPPFAX protocol with IPPGET going to use the re-direct
mechanism?&In-Reply-To=<OF7439219B.536DB5A0-ON87256CB4.0052284B-87256CB4.0052917C@us.ibm.com>
Cc: mailto:ifx@pwg.org?Subject=Re:
IFX> ISSUE: Is IPPFAX protocol with IPPGET going to use the re-direct
mechanism?&In-Reply-To=<OF7439219B.536DB5A0-ON87256CB4.0052284B-87256CB4.0052917C@us.ibm.com>
Subject: IFX> NOT - New PWG IPP Distributed Notification Service and
IPPGET Client Behavior available
Ira McDonald, Bob Herriot, Harry Lewis, Carl Kugler, and I have made a
number of passes over the new PWG draft standard 5100.6-D0.1. Its
entitled:
"IPP Distributed Notification Service and IPPGET Client
Behavior". It has
the redirection mechanism that was removed from the IETF
IPPGET Delivery
Method spec. The conformance requirements for IPPGET clients
is unchanged
in this document from what they were in the IETF IPPGET draft.
We think
the
redirection mechanism is still very sound from a security
point of view,
but
we're being cautious by moving it to this PWG spec,
while we send the IETF
IPPGET and Base Notification spec drafts forward to
the IESG.
ISSUE for the IPPFAX WG, which is REQUIRING support of IPPGET Delivery
Method: Is redirection an option of an IPPFAX Receiver? If yes, then the
IPPFAX Sender MUST support redirection as specified in this document.
The files are available at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-dist-not-service-021010.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-dist-not-service-021010.doc
Here is the Abstract:
Abstract: This document specifies an OPTIONAL IPP Distributed Notification
Service for use with the "Internet Printing Protocol (IPP): Event
Notifications and Subscriptions" specification (ipp-ntfy). This IPP
Distributed Notification Service enables multiple trusted IPP Printers to
off-load IPP Event Notification Delivery to a shared Notification Server
for
any Event Delivery Method. The Notification Server (instead of the
Printer)
deals with the burden of delivering Event Notifications. For
the IPPGET
Delivery Method (get-method), the Notification Server, rather
than the IPP
Printer, takes over the burden of keeping a large number of
long duration
connections open for outstanding Get-Notifications operations.
This document also specifies additional REQUIRED behavior for any client
supporting the IPPGET Delivery Method.
Conformance: This extension is
REQUIRED for all IPP clients that support
the IPPGET Event Notification
Delivery Method. This extension is OPTIONAL
for IPP Printers that support
the IPPGET or any other Event Notification
Delivery Method.
Ira McDonald has written a companion spec for the protocol between the
Printer and the Notification Server which we will post shortly as another
PWG Draft. Its entitled: "Distributed Notification Service - Printer to
Notification Protocol (PNSP). We briefly considered combining them, but
didn't because using PNSP isn't required in order to redirect the
Get-Notifications request. Also having too many conformant interfaces in a
single document becomes too cumbersome to understand which statements apply
to which interface.
Here are the Changes from the redirection in the original IPPGET Delivery
Method [get-method]:
17.1 Changes from [get-method] to make version 0.1
1.
Invented the title: "The Printer Working Group
Standard for
Internet
Printing Protocol (IPP): Distributed Notification Service and
IPPGET Client
Behavior"
2.
Removed this redirection functionality from the
IETF IPPGET
[get-method]
specification and put it in this document.
3.
Section 2.2: Defined "IPPGET Client",
"Notification Server",
and
"Distributed Notification Service" terms.
4.
Clarified that this specification is the Interface
between
an IPP Client
and a Distributed Notification Service, in case the IPP
Printer exercises
the option of using a Notification Server to deliver
Event
Notifications.
5.
Section 5.3: Maintained the client requirement to
support
the
redirection for any client that supports the IPPGET Event Delivery
Method
(see [get-method]). In other words, any client that supports the
Get-Notifications operation is required to support the redirection in case
the Printer exercises this option.
6.
Clarified that this Notification Server may
deliver Event
Notifications
for any Push Delivery Method and for the IPPGET Pull Delivery
Method.
7.
Section 4.1: Added the "printer-notify-server-uri"
(1setOf
uri) Printer
Description attribute so that the Printer could be configured
for none
('no-value' out-of-band value), one, or more than one Notification
Server.
8.
Sections 5.2 and 6.1: Clarified that the
"redirect-uri"
(uri) operation
attribute and the 'redirection-other-site' status code are
for use with the
Get-Notifications operation response only, but could be
used by operations
defined in the future or existing operations if the IPP
protocol minor
version number incremented.
9.
Section 5.1: Clarified that the Printer MAY return
the
"redirect-uri"
(uri) operation attribute depending on any
implementation-defined reasons
which could be dynamically varying. Gave
examples, such as on the number of
open channels and the authorization of
the user.
10.
Section 7.3: Added conformance requirements for a
Notification Server,
acting in combination with a Printer, to provide a
Distributed Notification
Service.
11.
Section 15: Added the Informative Appendix that
describes
PNSP.
This archive was generated by hypermail 2b29 : Mon Jan 20 2003 - 10:07:52 EST