IPP Mail Archive: RE: IPP> RE: IPPGET Document Review

IPP Mail Archive: RE: IPP> RE: IPPGET Document Review

RE: IPP> RE: IPPGET Document Review

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Jul 20 2001 - 14:47:45 EDT

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

    Sounds even better that when "notify-get-interval" is returned, it is always
    returned in a separate Event Notification Attributes Group and with nothing
    else in the group (and never as an operation attribute, even on the server
    busy error return). Then the Printer always puts it in the same place when
    it returns the "notify-get-interval" attribute. And the client always looks
    for it in each Event Notification Attributes Group, even when the server
    returns the busy error.

    There is no real reason why a response cannot have real data in a group
    (though in our other operations, error information comes back in the
    Operation Attribute group and the Unsupported Attribute Group).


    -----Original Message-----
    From: mjoel@netreon.com [mailto:mjoel@netreon.com]
    Sent: Friday, July 20, 2001 06:46
    To: ipp@pwg.org
    Subject: RE: IPP> RE: IPPGET Document Review

    Hi Tom,

    Why ever allow notify-get-interval to be in the operation attributes group?
    Even when the printer returns server-error-busy, why can't it follow that
    operation attributes group with an event notification attributes group that
    only contains notify-get-interval?


    "Hastings, Tom N" <hastings@cp10.es.xerox.com>@pwg.org on 07/20/2001
    02:33:50 AM

    Sent by: owner-ipp@pwg.org

    To: mjoel@netreon.com
    cc: ipp@pwg.org

    Subject: RE: IPP> RE: IPPGET Document Review

    Exactly. So the only use of the "notify-get-interval" as an Operation
    attribute will be when the Printer is too busy to return any events and
    rejects the request and returns the 'server-error-busy' status code.
    Whether the client requests wait and the Printer no longer wants to honor
    or the client requested no wait mode, the Printer returns the
    "notify-get-interval" in the Event Notification Attributes Group.



    -----Original Message-----
    From: mjoel@netreon.com [mailto:mjoel@netreon.com]
    Sent: Friday, July 20, 2001 02:05
    To: ipp@pwg.org
    Subject: IPP> RE: IPPGET Document Review

    Hi Tom,

    Why allow notify-get-interval in the operations group at all? You
    suggested that if a printer has been sending events in a wait mode, and
    wants to stop, it can send an event group that is empty except for that
    attribute, and that the client must then disconnect. Why not always use
    that method? So if a Get-Notifications is received with a wait request,
    and the printer doesn't want to wait, it can send any event groups,
    followed by an event group that only contains notify-get-interval (followed
    by end-of-attributes-tag). Or like you suggested, it can do the same if it
    decides to end wait mode after it has been sending events. How's that


    "Hastings, Tom N" <hastings@cp10.es.xerox.com> on 07/19/2001 11:07:01 PM

    To: mjoel@netreon.com
    cc: "Hastings, Tom N" <hastings@cp10.es.xerox.com>, "Ira at Xerox XR&T
          McDonald (E-mail)" <IMcDonald@crt.xerox.com>

    Subject: RE: IPPGET Document Review

    Ira and I are liking your idea that the client can supply either
    "notify-subscription-id" or the "notify-recipient-uri" or both. If both
    supplied the uri MUST have the ippget scheme and MUST match the
    object. If only the "notify-subscription-id" is supplied, the
    "notify-recipients-id" in the Subscription Object MUST match 'ippget'.

    Secondly, now that the Printer can request termination of wait mode in any
    response by including the "notify-get-interval" attribute in the Event
    Notification Attributes group (with or without other attributes), why not
    make that the only way when the Printer is returning events (instead of
    having the "notify-get-interval" be returned as an operation attribute?

    Then the only use of the "notify-get-interval" attribute as an operation
    attribute would be when the Printer is too busy to return anything, except
    the error code and the "notify-get-interval" operation attribute?



    -----Original Message-----
    From: mjoel@netreon.com [mailto:mjoel@netreon.com]
    Sent: Thursday, July 19, 2001 14:55
    To: Hastings, Tom N
    Subject: RE: IPPGET Document Review

    Hi Tom,

    Below are a couple comments to your comments, marked <<--MJ-->>, which
    isn't an ego thing, just trying to make it easy for you to find them :-)


    "Hastings, Tom N" <hastings@cp10.es.xerox.com> on 07/19/2001 12:52:00 PM

    To: mjoel@netreon.com
    cc: hastings@cp10.es.xerox.com, "Ira at Xerox XR&T McDonald (E-mail)"

    Subject: RE: IPPGET Document Review


    Thanks for your careful review. See my comments preceded by TH>

    There are two issues that you raise. I talked with Ira and we have
    proposals for each issue. Do you agree? If so, I'll just write it up that
    way. If not, we can go to the DL today.

    1. Now that the client can supply "notify-subscription-id" and
    "notify-recipient-uri" in a Get-Notifications request, what are the client
    requirements for supplying these two operation attributes?

    a. MAY supply "notify-subscription-id" and MUST supply

    b. MUST supply one or the other, but not both.

    c. MUST supply one or both.

    Ira and I suggest c, and I think you did too. OK?

    <<--MJ-->> I'm leaning towards b, but I guess c is ok. So they could
    specify a subscription id, which is valid, but a uri that doesn't match,
    which will cause an error.

    Actually, for the "notify-subscription-id" I wrote that the client SHOULD
    supply "notify-subscription-id", if known and events from that single
    Subscription object are wanted, OK?
    <<--MJ-->> yes, I like that.

    I assume that the Printer MUST check that the client send conforming
    interchange and MUST reject a request with "client-error-bad-request", if
    the client didn't conform.

    2. If the Printer accepts an initial request for wait mode, but later
    decides that it no longer wants to keep the channel open, what does it do?
    The Printer can't return the "notify-get-interval" operation attribute with
    a value, since it can only return operation attributes in the first
    response. Alternatives:

    a. If it returns the 'end-of-attributes-tag', the client will be misled
    thinking that there aren't any future events that could happen. So I'm
    definitely against that.

    b. return an empty Notification Attribute group (this doesn't help the
    client know when to ask again).

    c. introduce a "notify-status-code" attribute (like INDP response), that
    indicates the status of an attribute group. It only needs to be included
    when the Printer is ending wait mode. In this case, the status code would
    be 'please-disconnect-and-try-again'. Then we'd also need to include the
    "notify-get-interval" attribute in that group to indicate when the client
    should try again.

    d. just introduce the "notify-get-interval" attribute as an attribute
    returned as the single attribute in the Event Notification Attributes group
    with the value to try again.

    e. Returning an HTTP chunk with zero data was suggested. (I don't like
    confusing layers).

    f. Is there an HTTP header we could use? (Again, I don't like confusing

    g. Printer just closes down the channel. (But the client doesn't know when
    to try again).

    I like d and suggest that I just write it up that way, OK?

    <<--MJ-->> I like that the best also

    see my replies to your other comments preceded by TH>


    -----Original Message-----
    From: mjoel@netreon.com [mailto:mjoel@netreon.com]
    Sent: Thursday, July 19, 2001 10:56
    To: hastings@cp10.es.xerox.com
    Subject: IPPGET Document Review

    Hi Tom,

    Here are my comments regarding the IPPGET document you sent to me.

    The abstract should say it's a pull method, not push and pull, as you
    changed in the introduction.

    Section 5 item 3: I don't think that needed changing. Do uri comparison
    rules apply when just saying that its scheme needs to be ippget: ?
    TH> I disagree, but I can tone it down to case-insensitive match of the
    scheme (see 10.5.2).

    Section 5, after the list of items: It now says "the Printer MUST continue
    to send Event Notifications as they occur until all of the associated
    Subscription Objects are cancelled", shouldn't that now be MAY?
    TH> I agree that the MUST continue to return events occurs in three or four
    places and needs to be fixed since the Printer now has the choice. I'll
    up somehow with a reference to the Printer's choice.

    Regarding the last sentence of that paragraph, didn't we decide that
    Cancel-Subscription would delete associated events, but that other
    subscription deletion causes (expired per-printer subscription or job
    termination) would not delete those events? I don't recall.
    TH> Here is what I wrote:
    A Subscription Object is cancelled either via the Cancel-Subscription
    operation or by the Printer (e.g., the Subscription Object is cancelled
    the associated Job completes and is no longer in the Job Retention or Job
    History phase - see the "ippget-event-time-to-live (integer(0:MAX))"
    attribute discussion in section 7.1).

    TH> We agreed that Cancel-Subscription would delete any unexpired events,
    but that job completion keeps the Subscription object and its events for
    "ippget-event-time-to-live" and the Job object for at least that long.
    Doesn't my paragraph say that?

    <<--MJ-->> Since it's possible to store event objects separate from
    subscription objects, it is possible for a subscription object to go away
    (for a reason other than Cancel-Subscription) without any of its events
    going away. This is, of course, implementation-dependent. What you have
    is fine, since they should probably be allowed to get the job info when
    they find out the job completed.

    Section 5,1, regarding "subscription-id", I think the last sentence of the
    first paragraph, "The Printer MUST send additional... notify-wait...true",
    should be deleted, since it's the printer's choice.
    TH> Agreed.

    Section 5.1, regarding "notify-recipient-uri", doesn't seem uri matching
    rules needs to be mentioned, only that it must be a uri with an ippget:
    TH> It has to be a case-insensitive scheme match for ippget.
    <<--MJ-->> Good point.

    Section 5.1, 2nd paragraph: I'm not sure why notify-recipient-uri is
    required if subscription-id is given. We never discussed that.
    TH> See above, so the client can supply one or both.
    If you are going to say it must match, there is where it should refer to
    matching rules.
    TH> Agreed.

    Section 5.1, last sentence in 3rd paragraph: "The Printer MUST send
    additonal...notify-wait...true", should be deleted, since it's the
    printer's choice.
    TH> Agreed.

    Section 5.1, regarding "notify-wait", 3rd sentence, "...'true', the Printer
    MUST send..." should be MAY, and in the same sentence, "and it MUST
    continue..." should be MAY.
    TH> I need to relate it to the Printer's choice of accepting wait or
    requesting change to no wait.

    Section 5.2, Group2: the 2nd paragraph should be deleted.
    TH> Agreed.

    Section 5.2, Group 3, 1st paragraph: grammar fix: "all un-expired Event
    Notification" should be plural.
    TH> Done.

    Section 8, "defined" not "define".
    TH> Yes.

    Section 11, item 2: I was trying to let the client know when it was done
    receiving a burst of event notifications without having to deal with http
    chunking, but I guess that works. Also, what if the printer started in
    wait mode, and later wants to stop? Does it just close the connection?
    Should it send an end-of-attributes tag? Should it send an empty chunk?
    TH> Printer returns an Event Notification Attributes group with a single
    "notify-get-interval" attribute indicating how long from now to try again.
    See above.


    This archive was generated by hypermail 2b29 : Fri Jul 20 2001 - 14:54:05 EDT