IPP Mail Archive: RE: IPP> machine readable etc. - why Harry

IPP Mail Archive: RE: IPP> machine readable etc. - why Harry

RE: IPP> machine readable etc. - why Harry is right

From: Carl Kugler/Boulder/IBM (kugler@us.ibm.com)
Date: Wed Aug 23 2000 - 12:13:13 EDT

  • Next message: Carl Kugler/Boulder/IBM: "RE: IPP> machine readable etc. - why Harry is right"

    Sorry for the confusion; I was only trying to determine which of the files
    at ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ contains the current spec. For
    example, is it

    or is it



    I think they're different versions of the same spec, even though one is
    named ipp-notify-get and the other is ipp-notify-poll.


    "McDonald, Ira" <imcdonald@sharplabs.com> on 08/23/2000 09:07:28 AM

    To: "'Herriot, Robert'" <Robert.Herriot@pahv.xerox.com>, Carl
    cc: pmoore@peerless.com, "McDonald, Ira" <imcdonald@sharplabs.com>, Harry
          Lewis/Boulder/IBM@IBMUS, bwagner@digprod.com, ipp@pwg.org
    Subject: RE: IPP> machine readable etc. - why Harry is right

    Hi Bob and Carl,

    I checked on this - IANA registered URLs in the IETF Tree
    MUST NOT contain hyphens (see bottom of page 3 in RFC 2717,
    Registration Procedures for URL Scheme Names, November 1999).

    - Ira McDonald

    -----Original Message-----
    From: Herriot, Robert [mailto:Robert.Herriot@pahv.xerox.com]
    Sent: Tuesday, August 22, 2000 2:50 PM
    To: Carl Kugler/Boulder/IBM; Herriot, Robert
    Cc: pmoore@peerless.com; McDonald, Ira; Harry Lewis/Boulder/IBM;
    bwagner@digprod.com; ipp@pwg.org
    Subject: RE: IPP> machine readable etc. - why Harry is right

    > -----Original Message-----
    > From: Carl Kugler/Boulder/IBM [mailto:kugler@us.ibm.com]
    > I like it!
    > Some minor points:
    > - In 5. b) the server should terminate the response with a zero-length
    > chunk, if Transfer-Encoding: chunked. On receipt of this
    > termination, the
    > client should close the connection.

    I agree

    > - I think you still need "suggested-ask-again-time-interval" and
    > "begin-to-expire-time-interval" to handle the case of really long idle
    > times; for example, when subscribing for Job notifications
    > on a Job with
    > "job-hold-until" specified.

    Perhaps this case can be ignored. I was hoping to avoid this complexity,
    I'm not sure if a Printer would want to guarantee to hold on to all Event
    Notifications for several hours. Suppose at noon, someone sets
    "job-hold-until" to 'night' and then at 4pm changes it to 'evening' or
    'no-hold'. If the Printer has told the client to query again at the
    beginning of the 'night' shift or even several hours before night shift,
    Job may have completed with many Event Notifications by then.

    > -Carl
    > P.S. What is the current "ippget" spec? And is it ipp-get
    > or ipp-poll? I
    > found a document called ipp-notify-poll on the outside, that is titled
    > "ipp-get" on the inside.

    It had been "ipp-get", but in Pittsburgh we decided to remove the hyphen.
    URLs can have hyphens, but none in the IANA registry have hyphens. We
    decided to call it "ippget". So the next release will have "ippget".

    Perhaps, you were thinking that "ippget" should be called "ipppoll" and the
    one and I am proposing called "ippget"?

    Bob Herriot

    > "Herriot, Robert" <Robert.Herriot@pahv.xerox.com> on
    > 08/22/2000 02:39:24 PM
    > To: pmoore@peerless.com, "McDonald, Ira" <imcdonald@sharplabs.com>
    > cc: Harry Lewis/Boulder/IBM@IBMUS, bwagner@digprod.com, ipp@pwg.org,
    > "Herriot, Robert" <Robert.Herriot@pahv.xerox.com>, Carl
    > Kugler/Boulder/IBM@IBMUS
    > Subject: RE: IPP> machine readable etc. - why Harry is right
    > There is a simple extension to "ippget" that does what Harry
    > wants. I'll
    > call the solution "ippgetw" for "ipp get and wait"
    > 1. The user subscribes for this Delivery Method in the same way as for
    > "ippget" but instead uses the "ippgetw" scheme in the
    > "notify-recipient-uri".
    > 2. The Subscription tells the Printer what Events the listener is
    > interested
    > in.
    > 3. The client obtains the Event Notifications by performing the
    > Get-Notifications operation with the same URL as in the
    > "notify-recipient-uri". This is just like "ippget" except that Event
    > Notifications keep coming in the response.
    > 4. The Printer performs the Get-Notifications operation as follows
    > a) it finds all Subscriptions associated with the specified
    > "notify-recipient-uri" (like "ippget").
    > b) it returns all Event Notifications that it is holding for the
    > specified Subscription objects (like "ippget"). This means that
    > the client doesn't miss any events between the time of
    > Subscription
    > and the Get-Notifications operation. This step could be omitted
    > if it is OK to lose Event Notifications when the client is not
    > performing the Get-Notifications operation.
    > c) it returns Event Notifications as they occur (unlike
    > "ipp-get").
    > 5. The Get-Notifications operation terminates in the following ways:
    > a) the client closes the connection. The Printer continues to save
    > Event Notifications as specified in step 4b) until all
    > Subscriptions
    > associated with the "notify-recipient-uri" are canceled.
    > b) the Printer closes the connection when there are no longer any
    > Subscription Objects for the specified URL (in
    > "notify-recipient-uri"), e.g. when a Job completes and
    > associated
    > Subscription Objects are removed.
    > c) a time-out or failure occurs. The actions are the same
    > as step 5a.
    > Note: unlike "ippget", the Printer doesn't need to return
    > "suggested-ask-again-time-interval" or "begin-to-expire-time-interval"
    > because the client performs the Get-Notification operation as soon as
    > possible. But according to step b), the Printer does keep Event
    > Notifications for a short period of time, at least when there is no
    > connection open. The Printer need not keep Event
    > Notifications after it
    > sends them if there is no requirement for two clients to use
    > the same value
    > of "notify-recipient-uri" and no requirement for a client to
    > get lost Event
    > Notification by reopening the connection.

    This archive was generated by hypermail 2b29 : Wed Aug 23 2000 - 12:22:09 EDT