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 it
or the client requested no wait mode, the Printer returns the
"notify-get-interval" in the Event Notification Attributes Group.
OK?
Tom
-----Original Message-----
From: mjoel at netreon.com [mailto:mjoel at netreon.com]
Sent: Friday, July 20, 2001 02:05
To: ipp at 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
sound?
Marty
"Hastings, Tom N" <hastings at cp10.es.xerox.com> on 07/19/2001 11:07:01 PM
To: mjoel at netreon.com
cc: "Hastings, Tom N" <hastings at cp10.es.xerox.com>, "Ira at Xerox XR&T
McDonald (E-mail)" <IMcDonald at 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
are
supplied the uri MUST have the ippget scheme and MUST match the
Subscription
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
also
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?
Comments?
Tom
-----Original Message-----
From: mjoel at netreon.com [mailto:mjoel at 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 :-)
Marty
"Hastings, Tom N" <hastings at cp10.es.xerox.com> on 07/19/2001 12:52:00 PM
To: mjoel at netreon.com
cc: hastings at cp10.es.xerox.com, "Ira at Xerox XR&T McDonald (E-mail)"
<IMcDonald at crt.xerox.com>
Subject: RE: IPPGET Document Review
Marty,
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
"notify-recipient-uri"
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
into
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
for
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
layers).
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>
Tom
-----Original Message-----
From: mjoel at netreon.com [mailto:mjoel at netreon.com]
Sent: Thursday, July 19, 2001 10:56
To: hastings at 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
fix
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
when
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
the
"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:
scheme.
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
the
uri
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.
Marty