IPP Mail Archive: RE: IPP> NOT - IPPGET Delivery Method - IS

IPP Mail Archive: RE: IPP> NOT - IPPGET Delivery Method - IS

RE: IPP> NOT - IPPGET Delivery Method - ISSUE 02 'ippget' URI

From: McDonald, Ira (IMcDonald@crt.xerox.com)
Date: Fri Oct 26 2001 - 15:53:44 EDT

  • Next message: Michael Sweet: "Re: IPP> NOT - IPPGET Delivery Method - ISSUE 02 'ippget' URI"

    Hi Michael,

    First, I suggest that any Subscription with a missing/empty
    "notify-recipient-uri" MUST support retrieval of those
    notifications via IPPGET in-band and MAY support one or
    more other client pull methods for notification retrieval.

    Second, I agree that we have an ambiguity about WHICH are
    the supported client pull methods, so how about a second
    attribute (strictly alternate to "notify-recipient-uri",
    so that one or the other MUST be in every Subscription),
    called "notify-pull-method (1setOf keyword)", so that the
    Printer attribute "notify-pull-method-supported" can enumerate
    all the client pull methods supported by an implementation.


    - Ira McDonald

    -----Original Message-----
    From: Mike Sweet [mailto:mike@easysw.com]
    Sent: Thursday, October 25, 2001 8:46 PM
    To: McDonald, Ira
    Cc: Hastings, Tom N; ipp (E-mail); IPP FAX DL (E-mail)
    Subject: Re: IPP> NOT - IPPGET Delivery Method - ISSUE 02 'ippget' URI

    McDonald, Ira wrote:
    > ...
    > So let's just say that methods that are client pull (not server
    > push) MUST NOT specify "notify-recipient-uri" in the Subscription
    > attributes group.
    > OK?

    No argument here.

    > PS - Recall that we can tell if IPPGET is supported (even though
    > it MUST NOT appear in 'notify-uri-schemes-supported') because of
    > 'operations-supported'.

    Right, but that doesn't tell us what operation to use for a
    specific subscription, right? :)

    Currently we can say that if there is no notify-recipient-uri,
    then use IPPGET and Get-Notifications for the subscription, but
    what about other methods that might need the same treatment?

    I know I'm nitpicking, but we need to make sure that the spec
    addresses these issues so that future extensions (and there *will*
    be more extensions I'm sure) can work together and not confuse

    Michael Sweet, Easy Software Products                  mike@easysw.com
    Printing Software for UNIX                       http://www.easysw.com

    This archive was generated by hypermail 2b29 : Fri Oct 26 2001 - 15:55:02 EDT