This has been a good discussion. I can see how the redirect *could* be used
for just redirecting Get-Notifications without redirecting anything else, so
it is separate from the HTTP redirection. Also it does seem that this
redirection doesn't need any new job ids or anything, since each
Get-Notifications request always supplies the Subscription Id which such a
shared Notification Server can allocate in a single pool that is used by all
Printers that use the Notification Server.
So the only problem left with leaving redirection in, is that we really do
need to add another conformance requirement for clients that support IPP
Notifications, namely, that the client MUST honor the
'redirection-other-site' status code if the Printer returns it in a
Get-Notifications response and re-try the Get-Notifications request on the
indicated URL. And we should also add that the client SHOULD remember the
redirect-uri for subsequent Get-Notifications requests for this Subscription
object.
If we agree to keep this Get-Notifications redirection in the spec, then I
suggest that we add the following conformance requirement for clients in
section 12.2 (if the client supports Get-Notifications):
4. MUST honor the 'redirection-other-site' status code (see section
10.2), if the Printer returns it in the Get-Notifications response, and
re-try the Get-Notifications operation using the URL returned by the Printer
in the "redirect-uri" (uri) operation attribute (see section 5.2.3). In
such cases, the client SHOULD retain this URL for subsequent
Get-Notification requests for the same Subscription object.<?xml:namespace
prefix = o ns = "urn:schemas-microsoft-com:office:office" />
So OK to keep redirection in the IPPGET spec, as long as clients MUST
support it (in case the Printer does)?
And it would be good to explain the redirection idea a little more and how
it could be used by a Notification Server that many Printers could use. If
there is consensus to keep it in, I'll draft some suggested explanatory text
to explain its intended usage.
Thanks,
Tom
-----Original Message-----
From: Harry Lewis [mailto:harryl@us.ibm.com]
Sent: Thursday, July 18, 2002 15:48
To: Robert Herriot
Cc: Hastings, Tom N; McDonald, Ira; ipp@pwg.org; TTRONSON@novell.com; Carl
Kugler
Subject: Re: IPP> Re: FW: Last Call comment to remove redirect URL and
status code fromIPPGET
Sorry, I'm just catching up on this thread. Redirect was a concept Carl and
I introduced in our original write-up for the native in-band IPP
notifications (which later became "ipp-get" with a lot of good content and
rigor added by Bob, Tom and others. Bob's recollection is accurate. HTTP
redirection is more general than intended for our purposes. IPP Notification
redirect was intended to allow the normal IPP subscription process (i.e. a
subscription for job progress notification could be associated with print
job submission) but facilitate the actual management of notifications
occurring on a proxy or server. Something like the Job MIB, for example,
could actually be used by the server to track job progress at the printer.
I really don't see any reason to remove this feature. I do think it should
be optional (and maybe a better explanation of it's purpose added).
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"Robert Herriot" <bob@herriot.com>
Sent by: owner-ipp@pwg.org
07/18/2002 03:42 PM
To: "McDonald, Ira" <imcdonald@sharplabs.com>, "'Ted
Tronson'" <TTRONSON@novell.com>, <ipp@pwg.org>
cc: "Hastings, Tom N" <hastings@cp10.es.xerox.com>
Subject: Re: IPP> Re: FW: Last Call comment to remove
redirect URL and status code fromIPPGET
I don't remember who advocated the redirect feature, but I think that it was
put in to
solve a problem that the HTTP layer cannot deal with.
As I remember the assumption was that a printer (the URI target) might
support
the normal IPP operations, but might not support ipp-get (e.g. it doesn't
retain the
event history). Instead the printer would rely on some other server to
handle ipp-get --
hence the need for the ipp-get redirect. At the HTTP level, all ipp
operations would
be redirected. With the ipp-get redirect, only ipp-get would be redirected.
I don't believe that the presence of HTTP redirect is a reason to delete the
feature. Rather
we need to know that no one implements the feature and no one plans to
implement it in the
future. If that is the case, then there is a good reason to delete the
feature from the document.
Bob Herriot
----- Original Message -----
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Ted Tronson'" <TTRONSON@novell.com>; <ipp@pwg.org>
Sent: Thursday, July 18, 2002 11:45 AM
Subject: RE: IPP> Re: FW: Last Call comment to remove redirect URL and
status code fromIPPGET
> Hi,
>
> Thanks Ted Tronson, Ron Bergman, Carl-Uno Manros, and others.
>
> To clarify: All IPP operations (present and future) will still have
> HTTP-level support for 'redirect'. Tom and I are merely proposing
> to discard (before the RFC) what we think is a duplicate 'redirect'
> mechanism at the IPP-level.
>
> If we ever bind IPP over another transport/session protocol in
> the future, we'll probably want to add to the IPP Model an
> in-band 'redirect-uri' and 'redirect-job-id' pair of operation
> response attributes.
>
> Cheers,
> - Ira McDonald
> High North Inc
>
> -----Original Message-----
> From: Ted Tronson [mailto:TTRONSON@novell.com]
> Sent: Thursday, July 18, 2002 12:08 PM
> To: ipp@pwg.org
> Subject: IPP> Re: FW: Last Call comment to remove redirect URL and
> status code fromIPPGET
>
>
> I see no reason to have the redirection URL. In the past in might have
> been a good idea, but in our present implementation I don't think it
> would be needed.
>
> Ted Tronson
> Sr. Software Engineer
> iPrint Engineering
> 801-861-3338
> Novell, Inc., the leading provider of Net services software
> www.novell.com
>
> >>> "Hastings, Tom N" <hastings@cp10.es.xerox.com> 07/18/02 09:23AM
> >>>
> Harry, Carl, Hugo, and Ted,
>
> Do any of you want to keep the redirection URL attribute and status
> code in
> IPPGET, or can we delete it from IPPGET? Ira and I were guessing that
> maybe
> the idea of redirection may have come from the Novell idea of using a
> separate Notification Server for a number of Printers. On the other
> hand,
> maybe with IPPGET where the Notification Recipient is going the
> Get-Notifications operation that maybe each Printer would be more
> likely to
> do the notification, rather than handing the responsibility off to a
> separate Notification Server.
>
> Please see the reasons that Ira and I gave in our Last Call comment on
> IPPGET for deleting this application layer redirection from IPPGET.
>
> If you need redirection, you can always use the HTTP redirection.
>
> Thanks,
> Tom and Ira
>
> -----Original Message-----
> From: Carl [mailto:carl@manros.com]
> Sent: Wednesday, July 17, 2002 23:15
> To: Hastings, Tom N
> Cc: Ira McDonald; Carl-Uno Manros
> Subject: RE: Last Call comment to remove redirect URL and status code
> from IPPGET
>
>
> Tom,
>
> Can you still remember who wanted this in there in the first place?
> IBM
> perhaps? Or Novell?
>
> Would be good to find that out before we delete it, but otherwise I am
> for
> the simplification.
>
> Carl-Uno
>
> Carl-Uno Manros
> 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@manros.com
>
> > -----Original Message-----
> > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
> > Sent: Wednesday, July 17, 2002 6:21 PM
> > To: ipp@pwg.org
> > Cc: Carl
> > Subject: Last Call comment to remove redirect URL and status code
> from
> > IPPGET
> >
> >
> > 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@manros.com]
> > Sent: Saturday, July 13, 2002 13:37
> > To: ipp@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@manros.com
> >
> >
>
>
This archive was generated by hypermail 2b29 : Fri Jul 19 2002 - 17:49:24 EDT