IPP> NOT ISSUE 3 in Updated IPP Event Notifications spec posted, 7/22/99

IPP> NOT ISSUE 3 in Updated IPP Event Notifications spec posted, 7/22/99

IPP> NOT ISSUE 3 in Updated IPP Event Notifications spec posted, 7/22/99

kugler at us.ibm.com kugler at us.ibm.com
Tue Jul 27 16:13:53 EDT 1999


 <379da96e.ec64b4- at easysw.com> wrote: 
original article:http://www.egroups.com/group/ipp/?start=6044
> 
> > ISSUE 3:  For TCP/IP delivery, what about leaving the connection
> > open versus having to reestablish a connection for each event?  Who
> > specifies: client in subscription, Printer implementation,
> > Notification Recipient, Administrator?
> 
> There are at least two problems with this - notifications may come at
> widely-spaced intervals (causes problems with non-permanent links),

However, if notifications come frequently, opening a new connection for
each will be very inefficient.  Could you explain problems with
non-permanent links?  

> and since the IPP notification by itself has no way of telling the
> receiver what the total length of the message is (forget the end tag -
> it could be lost in transit) a client could find itself waiting
> indefinitely for the rest of a message that will never come.
> 
> Better to send a single IPP notification and close the link so there
> is no doubt on the receiving end that the entire message has been
> received or not.
> 
Reminds me of HTTP/0.9 -- what if the connection is closed prematurely
for some reason?  You still don't know that you've received the entire
message.  You're worried about trying to receive more than one message,
but I'm worried about receiving less than one messgae.  Anyway, how
would an end tag get lost on a reliable transport like TCP?  

    -Carl




More information about the Ipp mailing list