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: Thu Oct 25 2001 - 19:43:35 EDT

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

    Hi Michael,

    Agreed - the proliferation of option (2) below (many booleans) would be
    awful.

    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?

    Cheers,
    - Ira McDonald

    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'.

    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Thursday, October 25, 2001 12:45 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:
    > ...
    > Doesn't the empty string do that, too? :)
    >
    > <ira>
    > No - the empty string says there is NOT a destination for Printer
    > pushed notifications.
    > </ira>

    Hmm, then we'd be better off specifying that an IPPGET subscription
    should not specify a recipient then, right? :)

    > ...
    > (1) Redefine 'notify-recipient-uri' to allow empty string
    > to indicate "client fetches notifications in-band via IPP or
    > out-of-band by some non-IPP protocol".

    See my comment above...

    > (2) Add a new boolean operation attribute and Subscription
    > Description attribute such as 'notify-ippget' (method
    > specific, as we already did with email notifications)
    > that is an ALTERNATIVE to the presence of 'notify-recipient-uri'
    > in the Job Creation operation and on the Subscription object.

    I really, really, really, really, (really!) don't like this
    approach. It fosters so much bloat and non-standardization it
    isn't funny. Imagine a couple dozen of these "notify-xyz"
    attributes floating around, with no interoperability.

    *If* we need to have an extra attribute to indicate the type
    of subscription, it should be something generic like "notify-scheme"
    which refers to the method name (usually the URI scheme name, but
    "ippget" for IPPGET, etc.) so that future additions don't involve
    attribute creep. It also neatly sidesteps the IETF registration
    issue with "ippget".

    In short, here is my proposal:

        1. Add a notify-scheme (type2 keyword) attribute to the
           notification spec. This will be a REQUIRED subscription
           attribute (i.e. returned with Get-Subscriptions or
           Get-Subcription-Attributes)...
        2. REQUIRE *either* notify-recipient-uri *or* notify-scheme
           in the subscription creation request.
        3. Make notify-recipient-uri REQUIRED in the mailto and indp
           specs, and notify-scheme REQUIRED in the ippget spec
           (for the subscription creation request).

    Comments?
       

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



    This archive was generated by hypermail 2b29 : Thu Oct 25 2001 - 19:45:00 EDT