SDP Mail Archive: Re: SDP> Suggestions for discussion at SDP session next week

Re: SDP> Suggestions for discussion at SDP session next week

Carl Kugler (
Fri, 15 May 1998 14:24:21 -0400

On Thu, 14 May 1998 14:04:02 -0700 , Robert Herriot
(robert.herriot@Eng.Sun.COM) wrote:
>My comments are below
>Bob Herriot
>> > The solutions:
>> > a) notification: the IPP group is close to a solution
>> > b) the primary issue is being able to determine the printer status=
, i.e.
>> > did the connection fail because the printer is down or just busy.O=
>> > simple solution is to have a printer read on a UDP port dedicated =
>> > returning a status summary whenever it receives a request on the p=
ort. If
>> > the incoming bytes are limited and have simple options, the printe=
r will
>> > never be tied up for long on each transaction and will always be a=
ble to
>> > a client know if it is alive and whether there are any problems. =
Then if
>> > connection fails, it is because the printer is down or the IP addr=
ess is
>>But isn't this one of the SDP requirements:
>> 7. The SDP protocol must be completely Transport independent.
>>and wouldn't this solution be dependent on UDP and IP?
>My point is that IPP/SDP is and should be transport independent but no=
>transport absent. We should not define mechanisms in an IPP/SDP layer =
>are better handled at a lower transport layer, particularly when those=
>layers already are already defined to do the work for us for transport=
>such as TCP/.IP and UDP/IP, and are likely to do so for parallel, USB =
and 1394.

Then I think it would be clearer if you talked in terms of "streaming",=

"datagrams" (discrete messages), and "multiplexing" instead of specific=

protocol names and concepts like TCP, UDP, and ports.

>> > c) this is essentially the same problem as b) and has the same
>> > if a write times out, the client can query status and determine th=
>> > d) I think that we should rely on TCP/IP to get the bytes to their=

>> > destination. The most likely failure between client and paper is t=
>> > network. Loss of data inside the printer seems like such a remote =
>> > that it isn't worth making the protocol more complicated to solve =
>>Again, Transport independent?
>Yes I expect any other transport to provide reliability, ordering, etc=
. It
>should not be IPP/SDP
>job to do this.
>I find it interesting that an old TIPSI requirements document dated 9/=
>states the intention of removing transport layer functionality that is=
>in TIPSI and that some people still want to add to IPP.
>Layering is an important concept. We need to use it for IPP/SDP.

Then I think your proposal should state that it prereqs a duplex transp=
that facilitates reliable streaming, datagrams, multiplexing.