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

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

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Oct 26 2001 - 21:38:29 EDT

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

    I like what you guys have come up with. Thanks.

    I assume that the standard keyword value for "notify-pull-method" would be
    'ippget', right?

    One question:

    Why have the "notify-pull-method" Subscription Template attribute by
    multi-valued?

    For example, if 'ftp' were made a second pull method, then that is
    requesting the Printer to put some sort of file that the Notification
    Recipient is going to pull. And I guess that the Event Life time would have
    to be the same for both pull methods, since we have only one
    "ippget-event-life" Printer Description attribute. Or would we have one for
    the 'ippget' method using the Get-Notifications operation and one for FTP so
    we'd need another, say, "ftp-event-life" Printer Description attribute?

    If the Event Life's are different, I would think it might be problematic to
    have a single Subscription object for both methods. So how about
    simplifying the "notify-pull-method" Subscription Template attribute to be
    single valued? If you want both, the client has to create two Subscription
    Objects.

    Comments?

    Tom

    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Friday, October 26, 2001 13:29
    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:
    >
    > 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.

    Sounds reasonable.

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

    That'll work, thanks! 

    -- 
______________________________________________________________________
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 - 21:39:59 EDT