"Hastings, Tom N" wrote:
> ...
> 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.
> 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
> 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.
> 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
> 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
> 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 is RECOMMENDED, and maybe spell out the reasons why.
> ISSUE 07: For Event No Wait mode, should we add a way for the Notification
> Recipient to have the Printer filter out returning Event Notifications that
> the Notification Recipient has already received in order to reduce the
> duplicates (that will usually happen, else events will be lost)? Or should
> we just depend on most usage using Event Wait Mode, so that there aren't
> duplicates? 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.
MS> I think we have to do this - otherwise we put a greater burdon
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...)
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 08:28:54 EDT