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 (kugler@us.ibm.com)
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=
ne
>> > simple solution is to have a printer read on a UDP port dedicated =
to
>> > 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
let
>> > a client know if it is alive and whether there are any problems. =
Then if
the
>> > connection fails, it is because the printer is down or the IP addr=
ess is
bad.
>>
>>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=
t
>transport absent. We should not define mechanisms in an IPP/SDP layer =
that
>are better handled at a lower transport layer, particularly when those=
lower
>layers already are already defined to do the work for us for transport=
s,
>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
solution.Namely,
>> > if a write times out, the client can query status and determine th=
eproblem.
>> > 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=
he
>> > network. Loss of data inside the printer seems like such a remote =
problem
>> > that it isn't worth making the protocol more complicated to solve =
this
problem.
>>
>>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/=
94
>states the intention of removing transport layer functionality that is=
still
>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=
ort
that facilitates reliable streaming, datagrams, multiplexing.

-Carl
=