IFX Mail Archive: RE: IFX> RE: IPP> NOT - IPPGET Delivery

IFX Mail Archive: RE: IFX> RE: IPP> NOT - IPPGET Delivery

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

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Oct 30 2001 - 20:57:43 EST

  • Next message: McDonald, Ira: "IFX> FW: RFC 3191 on Minimal GSTN address format in Internet Mail"

    Another advantage of having two Subscription Template attributes, one for
    pull methods and one for push methods:

    "notify-recipient-uri" (uri) for push methods
    "notify-pull-method" (type2 keyword) for pull methods

    is that such bi-directional protocols, such as ftp, can be defined as two
    separate IPP Delivery Methods, one for push and one for pull.

    In the case of the push method, the uri is "ftp://..."

    In the case of the pull method, the keyword is 'ftp' or maybe 'ippftp'.

    Again each Subscription object MUST have one or the other, but not both
    Subscription Template attributes.

    Tom

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Friday, October 26, 2001 18:38
    To: Michael Sweet; McDonald, Ira
    Cc: ipp (E-mail); IPP FAX DL (E-mail)
    Subject: IFX> 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 : Tue Oct 30 2001 - 20:58:07 EST