IPP Mail Archive: RE: IPP> ippget Design Needs Work [use mul

IPP Mail Archive: RE: IPP> ippget Design Needs Work [use mul

RE: IPP> ippget Design Needs Work [use multi-part/related?]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Mon Jul 23 2001 - 16:34:05 EDT

  • Next message: Michael Sweet: "Re: IPP> ippget Design Needs Work [use multi-part/related?]"


    Your idea to make each response of a Get-Notifications operation which has
    multiple responses (so-called Event Wait Mode), a complete IPP response has
    a lot of advantages. Unfortunately, I wasn't able to incorporate it into
    the Internet Draft which was due two hours later (which I made by 5 minutes
    with the other changes that had been agreed to). However, I will update the
    document the middle of this week and publish a new version (even though it
    can't be an Internet-Draft until after the IETF London meeting, August
    6-10). We can still work on the new draft and that new draft will be for
    the IPP FAX WG meeting in Toronto, August 1.

    To build on your suggestion:

    1. Each response of a multi-response Get-Notifications will be a separate
    application/ipp part under a MIME multi-part/related type.

    2. Each response will be the usual and complete IPP encoding for a response:

    - a "version-number",
    - a "status-code", -- that applies to all the events in the part
    - the "request-id" that was supplied in the corresponding request

    - Group 1: Operation Attributes Group:

    "printer-up-time" (integer(1:MAX)) - which is the time that the response is
    being sent and goes for all the events that are being returned.

    "redirect-uri" (uri) (if redirection needed)

    AND we can move the "ipp-get-interval (integer(0:MAX)) back to the
    Operations Group, instead of returning it by itself in the last Event
    Notification Attributes Group.

    - Group 2: Unsupported Attributes Group - if any unsupported attributes

    - Group 3 to N: Event Notification Attributes Group

    3. At the end of each response part, we can end with the normal
    'end-of-attributes' tag, rather than invent a new 'end-of-part' tag (or have
    no tag).

    4. Which leaves how to indicate that this is really the last response, i.e.,
    that there are no more Subscription objects left that match? Marty Joel
    suggests that there be a completely separate response part with its own
    status code. The status should be the 'client-error-not-found' which is the
    status returned when there are no Subscription Objects found, whether this
    is the first Get-Notifications response or the last.


    I'll produce an updated version of the spec with this idea incorporated
    (unless there is objection on the mailing list), towards the middle of this
    week. I'll also cleanup some things that I missed in the rush to get the
    Internet-Draft out by last Friday, 5:00 EDT. This version will be input to
    the IPPFAX WG meeting in Toronto, August 1.

    Please send any other comments to the IPP DL on the draft which I posted
    last Friday and sent to the Internet-Drafts Editor.


    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Friday, July 20, 2001 14:26
    To: Michael Sweet
    Cc: mjoel@netreon.com; ipp@pwg.org
    Subject: RE: IPP> ippget Design Needs Work [use multi-part/related?]


    You make some good points about having each separate response to a single
    Get-Notifications request in Event Wait Mode, be a complete application/ipp
    response (from RFC 2911):

    - a "version-number",
    - a "status-code",
    - the "request-id" that was supplied in the corresponding request, and
    - the attributes that are REQUIRED for that type of response (Operation
    Attributes Group, Unsupported Attributes Group, and Event Notification
    Attributes Groups).

    We may also want to include a (new) end-of-segment tag (RFC 2910 encoding)
    at the end of each response (= a multi-part/related part) but the last which
    would end with 'end-of-attributes' tag.

    Then the IPP application layer would also know when to start processing
    events. Imagine if we also want to convey IPP with a different transport
    layer, say, XML. So we would also want an in-band tag to indicate that all
    the current events are present.

    BTW, I was able to update the draft-ietf-ipp-notify-get-04.txt draft in time
    to make the Internet-Drafts cutoff by 5 minutes today. They replied with 4
    minutes to go to the 5:00 PM EDT deadline. I included the
    multi-part/related, but not repeating the initial stuff each time.

    We definitely need more work on this and need to include an example
    encoding, complete with multi-part/related headers to make sure we
    understand how this works.

    Since the IPP FAX WG has agreed that IPPGET is the REQUIRED Delivery Method
    for IPPFAX, perhaps they can continue the discussion in Toronto, August 1,
    though we definitely should continue on the mailing list as we are as well.

    This document is definitely not ready for WG last call quite yet.


    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Friday, July 20, 2001 12:06
    To: Hastings, Tom N
    Cc: mjoel@netreon.com; ipp@pwg.org
    Subject: Re: IPP> ippget Design Needs Work [use multi-part/related?]

    "Hastings, Tom N" wrote:
    > ...
    > Your idea of using multi-part/related with each part being an
    > application/ipp part. The first part is the initial response with all the
    > pending Event Notifications (and doesn't end with the
    > 'end-of-attributes-tag'). Each subsequent part is one or more additional
    > Event Notification Attributes Groups that have occurred as a "bunch" (and
    > doesn't end with the 'end-of-attributes-tag'). The last part will contain
    > one or more Event Notification Attributes Groups and an
    > 'end-of-attributes-tag' when there are no more events possible (all
    > Subscription objects in the scope of the Get-Notifications are gone or the
    > Printer wants to end wait mode and returns the "notify-get-interval"
    > attribute in a separate Event Notification Attributes Group).
    > ...

    I think that we need to make each part a valid/standard
    IPP message of its own:

        1. The application/ipp type defines an IPP "message" that
           can be a request or response. The format is identical
           save for a different interpretation of the operation
           or status code field.

        2. It will simplify client and server implementations -
           only 1 type of IPP data stream needs to be supported.

        3. It will allow the parts to be received in any order -
           not too important for the current HTTP transport, but
           might be important for other types of transports.

        4. It mirrors what the mailto and indp methods do - that
           is, one standard message format for each collection of

    I think the only issue is what the status code field will
    contain in the parts - should they all contain the same code,
    or should each IPP message contain the current server status
    (e.g. successful-ok-too-many-events)?

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

    This archive was generated by hypermail 2b29 : Mon Jul 23 2001 - 16:38:57 EDT