If I were writing a server for receiving IPP over a raw socket, I would=
prefer
not to have chunking at a lower layer because I would have to implement a
lower
layer to put the chunks back together for the upper layer. I would prefer to
read the encoded attributes directly off the socket and chunk only the
document
data. =20
Therefore I would end up with a slightly difference encoding for raw sockets
than for HTTP.
Bob Herriot
At 12:11 PM 3/13/98 , Turner, Randy wrote:
>
>I'm curious why the existing binary encoding is inherently dependent on
>chunking?....I thought chunking was a part of the transport of the
>encoding. I don't think there is anything inherent (or explicitly
>referenced) by the current encoding that involves chunking. You're right
>that another transport would have to solve the chunking problem, but
>it's a TRANSPORT issue, so this would naturally fall into a transport
>mapping document. If there was a bit or byte that specified HTTP
>chunking within the binary encoding, then this is a different story.
>
>Randy
>
>
> -----Original Message-----
> From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM]
> Sent: Friday, March 13, 1998 12:06 PM
> To: Turner, Randy; 'ipp@pwg.org'
> Subject: Re: IPP> IPP document set - naming convention(s)
>
> I think we had this discussion in Austin as part of Tom's
>proposal.=A0 We=20
> decided to change the name of the protocol document. Its new
>name is=20
> "Internet Printing Protocol/1.0: Encoding and Transport".=A0 We
>decided not to=20
> split the two documents.
>
> Although the IPP encoding is, in theory, transport independent.
>In fact, it=20
> depends on HTTP chunking. With an alternate transport, we would
>have to=20
> solve the chunking problem.=A0 It would be more efficient if the
>document data=20
> were the only part chunked, but that would require a change to
>the encoding=20
> layer.
>
> So, at this point, I don't endorse separating the two documents.
>
> Bob Herriot
>
> At 03:36 PM 3/12/98 , Turner, Randy wrote:
> >
> >Would anyone have any problem(s) splitting the protocol (not
>model)
> >document into two documents?
> >
> >Document 1 would be an encoding document
> >Document 2 would describe how to transport the encoding over
>HTTP 1.1
> >
> >?
> >
> >Randy
> >=20
>=20