Attendees: Marty Joel (Netreon), Ira McDonald (High North), Pete Zehler
(Xerox), Ron Bergman (Hitachi-Koki), Carl Kugler (IBM), Tom Hastings
(Xerox)
Summary:
1. We discussed all IPPGET issues and resolved all of them (see below),
except one:
2. ISSUE 11: (Get-Notifications return a time or just a boolean for the next
poll). We are still debating whether it is possible for the Printer to
return a time to next poll that is every larger than the Event Life time?
If the Printer ever returns a larger value, the client could miss an event,
unless the Printer magically increases its Life for that (those)
Subscription object(s).
3. We also agreed to add Event Wait Mode to Job Creation operations as a
REQUIRED feature of supporting IPPGET (but allowing a Printer to always
renege - see ISSUE 09 which REQUIRES that the Printer support Event Wait
Mode, but only RECOMMENDS that the Printer accept Event Wait Mode requests
(to help reduce network traffic from polling). This addition is one of the
features that IBM had included in their original server directed polling
proposal. See ISSUE 02 resolution discussion.
4. We also agreed to limit the range of the "ippget-event-life" Printer
Description attribute to be 15 seconds or more in the syntax (integer
(15:MAX)) and the RECOMMENDED value of at least 60 seconds which agrees with
the PWG Job Monitoring MIB (RFC 2707). See ISSUE 03 resolution discussion.
5. We did not get to any IFX issues.
6. We will hold another telecon to address the IFX issues, next Tuesday
(same time, same numbers):
Tuesday, August 14, 8-10 AM PDT (11-1 PM EDT)
Phone: 1(712) 884-1555, (Xerox folks: 8*596-5170), passcode: 654970
The agreements reached are preceded by AGREED>.
Please respond if there are any disagreements with the agreements.
Tom
Agreements
A. IPPGET Delivery Method (<draft-ietf-ipp-notify-get-04.txt>), posted 7/23:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717-rev.pdf .doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.pdf .doc
Michael Sweet (MS), Marty Joel (MJ), Mike Bartman (MB), Carl Kugler <CK>,
and Tom Hastings (TH) have indicated their answers (before the telecon)
to one or more issues which I have copied. I've attempted to filter out
the back and forth and include conclusions only.
IPPGET Delivery Method ISSUE (Issues 1-7 were posted to the list on 7/27
for the Toronto meeting, but time did not permit them to be discussed). The
remaining issues 8-12 have been brought up on the IPP mailing list after
7/27.
ISSUE 01 (see section 12): Should we use application/multiplexed
(draft-herriot-application-multiplexed-03.txt) which can chunk mime types
using content lengths, instead of multi-part/related, which uses boundary
strings?
MS> How close is the multiplexed draft to being published as an RFC that
we can actually reference?
MS> I'd suspect that more client software will be able to handle the
multi-part/related MIME type encoding than the new multiplexed
encoding, however, so my vote is to stick with multi-part/related.
<MJ> After reading the draft spec, I see no benefit of using multiplexed
for IPP.
AGREED> We will use multi-part/related, not application/multiplexed.
Multi-part/related is not a problem for the Printer. Its the client that
has to search for the boundary string and that code is already deployed.
Application/multiplexed was designed more for mixing streams of binary data
into a main stream, such as XML.
ISSUE 02: For Event Wait Mode, OK to make each successive response after
the first a complete IPP response, instead of just the Event Notification
Attributes Groups?
Then each response looks like a complete response with its own status code.
Also complete responses might be necessary on some other transport. Also we
can move the "notify-interval" attribute back to the Operation Attributes
Group where it belongs, since it applies to all events being returned in
that response.
MS> OK
<MJ> OK
AGREED> Yes. Then each response is a full IPP response which is more
suitable for any transport. Also each response can be generated by any IPP
responder and parsed by an IPP parser.
AGREED> We also agreed to add Event Wait Mode with multiple responses to
Job Creation operations as a REQUIRED feature of supporting IPPGET (but
allowing a Printer to always renege - see ISSUE 09 which REQUIRES that the
Printer support Event Wait Mode, but only RECOMMENDS that the Printer accept
Event Wait Mode requests (to help reduce network traffic from polling).
This addition is one of the features that IBM had included in their original
server directed polling proposal.
So the Job Submission Client can supply a "notify-wait" (boolean) with a
'true' value in any Job Creation Operation (Print-Job, Print-URI,
Create-Job) which will have the same semantics as for the Get-Notifications
operation. If the Printer wants to renege, the Printer MUST still accept
the request and return the "notify-get-interval" with the value by which the
client needs to be reconnected in order not to miss any events.
We didn't discuss the Document Creation operations (Send-Document and
Send-URI) as to whether the client could also supply "notify-wait" (boolean)
with either value and whether the Printer can return the
"notify-get-interval" to renege.
ISSUE 03: OK to clarify that the Per-Job Subscription Object and the
associated Job object MUST persist after the job completes (job completed,
canceled, or aborted) in the Job Retention or Job History phases (see
[RFC2911] section 4.3.7.2)?
Otherwise, a Notification Recipient that is polling would not get the Event
Notification, if it polled after the job completed, but before the Event
Lease Time expired.
MS> Yes, this should be the expected behavior, with the subscription
and job disappearing only after all events have expired.
<MJ> Good argument -- you have my OK.
AGREED> Yes.
AGREED> We also agreed to limit the range of the "ippget-event-life" Printer
Description attribute to be 15 seconds or more in the syntax (integer
(15:MAX)) and the RECOMMENDED value of at least 60 seconds which agrees with
the PWG Job Monitoring MIB (RFC 2707) jmGeneralJobPersistence and
jmGeneralAttributePersistence objects.
AGREED> We also agreed that the "ippget-event-life" value is the value by
which the client must be reconnected in order not to miss any events. So
the client has to initiate the Get-Notifications enough sooner, so that the
request has been accepted by the Printer in order to be guaranteed not to
miss events.
ISSUE 04: OK to clarify that a client or a Printer MAY disconnect the
underlying transport connect for any operation, including the Event No Wait
Get-Notifications operation and the Event Wait Get-Notifications operation
when the Printer isn't willing to honor the initial request or reneges in a
later response?
So a client could keep the connection open for multiple Event No Wait
Get-Notifications. Before a Printer disconnects it needs to wait enough
time to make sure that any IPP response has had time to get back to the
client before disconnecting, otherwise the client might not see the
response.
MS> OK
<MB> Don't confuse TCP/IP keep alive with HTTP/1.1 Persistent Connections.
Either the client or the Printer can close the HTTP/1.1 connection by
including the "Connection: close" header line in the request or the
response, respectively. From RFC 2068:
===========
HTTP/1.1 defines the "close" connection option
for the sender to signal that the connection will be closed after
completion of the response. For example,
Connection: close
in either the request or the response header fields indicates that
the connection should not be considered `persistent' (section 8.1)
after the current request/response is complete.
HTTP/1.1 applications that do not support persistent connections MUST
include the "close" connection option in every message.
===========
Also:
===========
8.1.2 Overall Operation
A significant difference between HTTP/1.1 and earlier versions of
HTTP is that persistent connections are the default behavior of any
HTTP connection. That is, unless otherwise indicated, the client may
assume that the server will maintain a persistent connection.
===========
So we should only talk about connections in the Encoding and Transport
section.
AGREED> We agreed to add something about HTTP persistent connections to the
IPPGET Encoding and Transport section, but that it applies to all
operations, not just to Get-Notifications, though the discussion is
particularly germane to the Get-Notifications operation.
ISSUE 05: OK to add 'successful-ok-events-complete' status code for a
Get-Notifications response whether Event No Wait or Event Wait mode?
MS> OK
<MJ> OK
Here is more detail:
The Printer MUST return the 'successful-ok-events-complete' status code to
indicate when this return is the last return for all Subscription objects
that match the request, whether or not there are Event Notifications being
returned. This condition occurs for Event Wait Mode Notification Recipients
waiting for responses when the Subscription Object is: (1) canceled with a
Cancel-Subscription operation, (2) deleted when the Per-Printer Subscription
lease time expires, or (3) when the 'job-completed' event occurs for a
Per-Job Subscription. This condition also occurs for a Get-Notifications
request that a Notification Recipient makes after the job completes, but
before the Event Lease Time expires.
Here is a complete table of combinations of "notify-wait", "status-code",
"notify-interval", and Event Notification Attributes Groups for
Get-Notification initial (Wait and No Wait) Responses and subsequent Event
Wait Mode Responses (which may be staying in Wait Mode or may be requesting
the Notification Recipient to leave Wait Mode):
Event
client sends: Printer returns: Notification
"notify-wait" "status-code" "notify-get-interval" Attribute Groups
------------- ------------- --------------------- ----------------
1.'false'/omitted 'successful-ok' MUST return N maybe
2.'false'/omitted 'not-found' MUST NOT MUST NOT
3.'false'/omitted 'busy' MUST return N MUST NOT
4.'false'/omitted 'events-complete' MUST NOT 'job-completed'
5. 'true' 'not-found' MUST NOT MUST NOT
6. 'true' 'busy' MUST return N MUST NOT
7. 'true' 'successful-ok' MUST NOT MUST
8. 'true' 'successful-ok' MUST return N maybe
9. 'true' 'events-complete' MUST NOT 'job-completed'
or maybe other
Explanation:
1-4: client requests Event No Wait
5-9: client request Event No Wait
2,5: Subscription object not found, or was canceled earlier; client should
NOT try again.
3,6: server busy, tells client to try later; client should try again in N
seconds.
4: client polled after job completed, but before Event Lease Time expired,
and got the 'job-completed' event, so the client shouldn't bother trying
again; client should NOT try again later.
7: Printer returns one or more Event Notifications and is ok to stay in
Event Wait Mode; the client waits for more.
8: Printer wants to leave Event Wait mode. Can happen on the first
response (with events) or happen on a subsequent response with or without
Event Notifications; the client should try again in N seconds.
9. Printer either (1) returns 'job-completed' event or (2) the Subscription
Object was canceled by either a Cancel-Job or a Per-Printer Subscription
expired without being renewed. For case (1), at least one event MUST be
returned, while for case (2), it is unlikely that any Events are returned;
the client should NOT try again.
AGREED> We agreed to add 'successful-ok-events-complete' and to include the
table of combinations for clarification.
ISSUE 06: Section 12 says: "The Printer MAY chunk the responses, but this
has no significance to the IPP semantics." Is this sufficient, or is
HTTP/1.1 chunking REQUIRED in order to support the multi-part/related MIME
type?
MS> I don't think we have to make this a requirement, because a HTTP
response with no content type has essentially the same semantics
for a wait-mode Get-Notifications request. The only time this
becomes an issue is if the client wants to keep the HTTP connection
alive after the final successful-ok-events-complete message part.
MS> Just make chunking RECOMMENDED, and maybe spell out the reasons why.
<MJ> Chinking isn't required for multipart, and I wonder if they are even
compatible.
<MB> Not quite. Chunking is intended for cases where the total length of a
message can not be determined at the time the HTTP header is transmitted.
When a web page is being generated "on the fly" for example. You can
specify chunking, send the header, then send each part of the response as it
is generated, then signal "that's all!" when you know you've sent it all.
Chunking may also be removed by the transmission linkage if it wants
to...for example a proxy server could convert a chunked message into a
non-chunked message, so using chunking for anything other than occasional
convenience is a bad idea.
Again from RFC 2068:
===========
3.6 Transfer Codings
Transfer coding values are used to indicate an encoding
transformation that has been, can be, or may need to be applied to an
entity-body in order to ensure "safe transport" through the network.
This differs from a content coding in that the transfer coding is a
property of the message, not of the original entity.
transfer-coding = "chunked" | transfer-extension
transfer-extension = token
===========
Despite the fact that chunking is a required part of HTTP 1.1, and IPP 1.0
uses HTTP 1.1, I've run into servers that don't do chunking...which is a
real PITA for me doing printing, since *all* of my stuff is generated "on
the fly" by the formatting parts of the client. The only way I can know up
front how long a Print-Job message will be is to spool the job, then read it
back once I have it all. This slows printing considerably when the link is
fast and the server has a large buffer, since the spooling adds a lot of
disk activity to the process. It's easy to say, "if it isn't compliant,
just don't print to it", but in practical, angry customer, terms, we need to
print anyway if there's any way at all to do so, so I have to treat chunking
as optional, despite the hassle and performance problems.
Just FYI, here's the RFC 2068 stuff on chunking requirements:
===========
All HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer coding, and MUST ignore transfer coding extensions
they do not understand. A server which receives an entity-body with a
transfer-coding it does not understand SHOULD return 501
(Unimplemented), and close the connection. A server MUST NOT send
transfer-codings to an HTTP/1.0 client.
===========
> Can multipart and chunking coexist?
I don't see any reason why they couldn't. Chunking is a transmission level
issue, multipart is above that. Chunking is how you get a block of bytes
from point A to point B, while multipart is a question of what that block of
bytes looks like.
AGREED> We agreed to add something to the Encoding and Transport section
about chunking and multi-part/related. Also add a note to allay implementer
fears that HTTP proxies might collect chunked responses over time and only
send them back together as a single unchunked response (with a Content
Length instead) much delayed as HTTP/1.1 allows. However, in practice, no
proxy wants to have an infinite buffer. Also no proxy wants to hold up
responses, since users would be furious. So not to worry.
ACTION ITEM (Carl): Propose some text to the mailing list.
ISSUE 07: It has been suggested on the mailing list that the Notification
Recipient could supply pairs of the "notify-sequence-number" and
"subscription-id" and the Printer would only return events with a higher
sequence number on a Get-Notifications request. Thus the Printer would
eliminate duplicate events.
a. Change "notify-subscription-id" (integer(1:MAX)) operation attribute to:
"notify-subscription-ids" (1setOf integer(1:MAX))
ISSUE 07a: We have "notify-subscription-id" (integer(1:MAX)) as an operation
attribute of Renew-Subscription and Cancel-Subscription operations. Should
we make this new 1setOf attribute differ by more than just the letter "s",
say, "notify-subscription-ids-requested"?
AGREED> NO. Its OK to have this operation attribute differ by just a
single letter "s" when it is the 1setOf form of the singular. So we will
have "notify-subscription-ids" (1setOf integer(1:MAX)) in Get-Notifications
and "notify-subscription-id" (integer(1:MAX)) in Cancel-Subscription and
Renew-Subscription operations. OK to just add "s" for
notify-sequence-numbers (1setOf integer(1:MAX)).
b. Add "notify-sequence-numbers" (1setOf integer(1:MAX)) operation
attribute as a parallel attribute. If supplied, the Printer
only returns Events with that sequence number or higher sequence number for
the ith Subscription object identified by the ith subscription id in
"notify-subscription-ids", thereby, eliminating duplicates events on a
Subscription Object basis. If "notify-sequence-numbers" has fewer (or no)
values than "notify-subscription-ids", the Printer assumes a value of 1 (all
unexpired events are returned). If "notify-sequence-numbers" has more
values
than "notify-subscription-ids", the extra values are ignored.
Note: this is a case of "parallel" attributes which we said we didn't want
to do again. However, these attributes are NOT on an object so there is not
problem with setting parallel attributes and these attributes can never get
into a directory (where the order might get changed). Most cases will be
just one value for each attribute as well.
MS> I think we have to do this - otherwise we put a greater burden
on the server (which has to format and send the extra events),
the network link (which has to carry more data), and the client
(which has to process extra events and throw old ones away.)
MS> By putting this functionality in the server, we eliminate a lot
of overhead at the expense of slightly greater complexity
(basically an integer comparison for each event sent by the
server...)
<MJ> I realize this complicates the spec a bit, but I think it makes ippget
more versatile, and addresses Michael's excellent point of improving
performance and bandwidth.
<MJ> Better to eliminate uri searching, since Get-Subscriptions can be used
for that. [See ISSUE 12 below about getting rid of uri searching]
AGREED> We agreed to REQUIRE the Printer to support both
"notify-subscription-ids" and "notify-sequence-numbers" operation attributes
with multiple values. The client MUST supply at least one value for the
"notify-subscription-ids" attribute.
AGREED> We also agreed that any number of different clients can do a
Get-Notifications for a Subscription object subject only to access control.
Therefore, the Printer MUST NOT discard Events until the Event Life Time
expires, no matter how many times it returns the corresponding Event
Notification in Get-Notification responses. Also the same client can issue
multiple Get-Notifications for the same Subscription Object and get back the
same events, as long as they haven't expired. So there is no concept of a
single listener for a Subscription Object.
ISSUE 08: was really a duplicate of ISSUE 07, so ignore it.
ISSUE 09: Make Event Wait Mode OPTIONAL for a Sender and a Receiver?
Currently the spec REQUIRES the Receiver to support both values of the
"notify-wait" operation attribute ('true' and 'false').
With the Notification Recipient being able to request the Receiver to filter
out duplicates, is it ok to allow the Receiver to always force the
Notification Recipient back to Event No Wait Mode with the
"notify-get-interval" operation attribute of when to poll next?
Or should Event Wait Mode be RECOMMENDED for the Receiver?
What about RECOMMENDED for the Sender?
MS> I think event-wait-mode should be OPTIONAL but RECOMMENDED. There
will always be client and server implementations that can't do the
multipart encoding, or can't spare the extra socket resources.
MS> Since we already have defined the fallback behavior for both client
and server, this should not pose a problem.
<CK> For no-wait-mode you don't need multipart. But multi-part is critical
for wait-mode if we are going to send complete application/ipp responses
for each part, since the version, status, and request-id are positional
fields.
MS> It might be useful to provide a new "notify-wait-supported"
attribute that the client can query with the Get-Printer-Attributes
request to see ahead of time if the server can support wait mode,
although with the caveat that the server may choose not to honor
individual requests in the interests of resource management.
<MJ> I like the idea of making Event Wait Mode RECOMMENDED for both the
Sender and Receiver. I don't know if notify-wait-supported is needed,
since I don't see how that would change the Sender's behavior. Does
the Sender care if it sends a request for wait mode and receives a
try-again time, versus sending a non-wait mode and receives a
try-again time?
<TH> How about REQUIRING a Receiver to support Event Wait Mode for at least
one connection? Then the normal IPPFAX case of one Sender and one Receiver
works nicely with Event Wait Mode.
AGREED> After much discussion, we agreed that the Printer MUST accept
requests for Event Wait Mode (in Get-Notifications and Job Creation
operations) with either the 'true' or 'false' value. And we agreed that a
Printer SHOULD honor the request. However, it is conforming for a Printer
to always renege and return the "notify-get-interval" (though such an
implementation would not be following the recommendation).
The reason that it would be unwise to require Event Wait Mode for even one
connection on an IPPFAX Printer, is the case of a long job being submitted.
There would be a significant time between receipt of the last page and the
printing of that last page, during which the Printer MAY want to be
accepting other jobs. Also a Job that is submitted with "job-hold-until"
set for a long time in the future should not be able to tie up a connection
until that time. Or a job that needs resources to be configured before it
can be processed on a spooling printer that can process other jobs.
AGREED> A client MUST accept the "notify-get-interval" and re-issue the
Get-Notifications (with or without "notify-wait" = 'true') in order to get
more events.
AGREED> We don't need to add a new Printer Description attribute to
indicate whether or not the Printer always reneges on Event Wait Mode
requests. The client MUST be able to work with such a Printer. So the
client may as well always request Event Wait Mode, whether or not the
Printer really can do it and then take the appropriate action when the
Printer reneges.
ISSUE 10: OK to change IPPGET "ippget-event-time-to-live" to
"ippget-event-lease-duration"?
MS> maybe we can simplify the name/terminology: ippget-event-life?
We *are* talking about the lifetime of an event, not a lease
time for a subscription (the lease terminology makes sense for
subscriptions because you ask for a subscription for a specific
time period, but events are generated by the printer and aren't
"leased" by the client, right?
TH> How about going with Michael's suggestion for the name:
"ippget-event-life" and defining the term Event Life in IPPGET:
Event Life: The length of time in seconds after an Event occurs during
which the Printer will return that Event in an Event Notification in a
Get-Notifications response. After the Event Life elapses, the Printer will
no longer return an Event Notification for that Event in a
Get-Notifications response.
which replaces the IPPGET terms:
Event Notification Lease: The lease that is associated with an Event
Notification. When the lease expires, the Printer discards the associated
Event Notification.
Event Notification Lease Time: The expiration time assigned to a
lease that is associated with an Event Notification.
AGREED> yes.
AGREED> To clarify that the value of the "ippget-event-life" is the time by
which a client must be reconnected to the Printer in order not to miss any
events. So the client must factor in a fudge time in order to issue the
Get-Notifications request in time to have the Printer accept it before the
Event Life elapses.
ISSUE 11: Should the Printer return a "end-wait" (boolean) attribute,
rather than a "notify-get-interval" (integer) with the number of seconds to
try again later?
<MJ> Regarding the whole try-again time issue, I don't think the Receiver
should be sending that, and should indicate the desire to stop or not
start wait mode with a boolean or a status code. The Sender can do a
Get-Printer-Attributes to learn how long events are retained. The
Sender knows by when it must issue another Get-Notifications to avoid
the risk of losing events. If it isn't in keep-alive mode, the Sender
must take into account how long it might take to connect, so the
returning of the number of seconds to wait before trying again is
misleading.
<TH> Or we could clarify the "notify-get-interval" attribute that the
Printer is returning to be the value of the Printer's
"ippget-event-life" Printer Description attribute and the client needs to
take into the account the time to make the connection.
AGREED> That the "notify-get-interval" operation attribute returned in the
response MUST be at least as long as the value of the "ippget-event-life"
Printer Description attribute.
NOT AGREED> However, if the value is greater than the Printer's
"ippget-event-life" value, then a Notification Recipient could miss an event
if it didn't poll at the "ippget-event-life" rate. What to do?
We are still debating whether it is possible for the Printer to return a
time to next poll that is ever larger than the Event Life time? If the
Printer ever returns a larger value, the client could miss an event, unless
the Printer magically increases its Life for that (those) Subscription
object(s).
So is returning a boolean the best the Printer can ever do?
ISSUE 12: Get rid of URI searching/matching for IPPGET?
Delete the "notify-recipient-uri" operation attribute from
Get-Notifications.
The Notification Recipient client MUST supply the "notify-subscription-ids"
operation attribute and MAY supply the "notify-sequence-numbers". The
subscription id MUST specify a Subscription Object that matches the scheme
(case insensitive) IPPGET.
<TH> When the Sender is also the Notification Recipient, the Sender will
know the subscription id as a response to the Job Creation operation, then
the subscription id is much more specific. When some other client is the
Notification Recipient, it probably will have operator privileges anyway;
otherwise it cannot get events from any Sender's Subscription Object. But
if it has operator privileges, it can more simply create a Per-Printer
Subscription Object using the Create-Printer-Subscription operation for a
long term lease and use its subscription id.
If an IPPFAX Printer is used by several groups, each with their own
secretary, then each group should have its own URL. Depending on
implementation, each URL either specifies a different Printer object on
the same implementation or a single Printer object supports multiple
IPPFAX URLs. [See IFX ISSUE 43 below].
AGREED> Yes.