Hi all,
Thought I'd add my 2 cents. Michael Sweet's comments are marked "MS>".
Marty Joel ("<MJ>")
"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.
<MJ> After reading the draft spec, I see no benefit of using multiplexed
for IPP.
> 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
> 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> The subscription object must persist, not necessarily the job object.
An implementation could store per-job subscription objects that are
not
linked to job objects, and which are deleted at their expiration time,
even if the job object has already been deleted because its job
retention
and job history phases have elapsed.
> 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
<MJ> TCP guarantees that a send followed by a close will get through.
I don't think the mention of waiting for the response needs to be
stated.
The bad wait state in TCP is when a connection is terminated (by
either
end) without being closed. Either end can initiate a handshaked
close.
> 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
> 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.
<MJ> Chinking isn't required for multipart, and I wonder if they are even
compatible.
> 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...)
<MJ> Better to eliminate uri searching, since Get-Subscriptions can be used
for that.
This archive was generated by hypermail 2b29 : Sat Aug 04 2001 - 04:35:29 EDT