I don't see any partial buffer problems in the encoding we
have chosen. In fact, with respect to a byte-stream delivery
interface (TCP) and using 8-bit clean I/O calls (no fgets),
IMHO, the term "partial buffer" doesn't even have any meaning.
Randy
Robert Herriot wrote:
>> After thinking about the partial buffer problem with respect to the
> three possible encodings, the ONLY ENCODING THAT SEEMS TO HAVE A PROBLEM
> IS THE ONE WE CHOSE. That is why we need to continue the discussion.
>> In my last email I described the algorithm for the HTTP-like version
> which fills a buffer upto CRLF, thus avoiding buffer overlap issues.
>> With the binary encoding, I would expect that it would fread the two
> byte length (call it n) and then fread n bytes of name/value in order
> to avoid messy buffer overlaps. It would do this twice for each
> parameter. So the reading of bytes would be intimately associated with
> the parsing. But Sylvan's GrabAttr seems to assume a buffer that
> already has the name and the attribute. How does Sylvan do this
> without parsing the two lengths at the high level and in GrabAttr.
>> Sylvan, could you give more details about how you handle the buffer
> overlap problem with binary encoding? I have suggested a method
> above, but you seem to have some other way.
>> Bob Herriot
>> > From SBUTLER at hpbs2024.boi.hp.com Mon Jun 23 09:04:34 1997
> > From: "Sylvan Butler" <SBUTLER at hpbs2024.boi.hp.com>
> > X-Real-Sender: SYLVAN
> > Organization: Hewlett-Packard, Boise
> > To: Robert.Herriot at Eng (Robert Herriot)
> > Date: Mon, 23 Jun 1997 10:02:48 -0700
> > Subject: Re: IPP>PRO: sorry, but binary is better
> > CC: ipp at pwg.org> > Priority: normal
> > X-mailer: Pegasus Mail v3.31
> > Content-Length: 2098
> > X-Lines: 53
> >
> > >This buffer problem exists for both the current IPP proposal and for
> > >the previous binary proposal that you prefer. The two byte binary
> > >integer could span buffers and a parameter name or value buffer could
> >
> > The upper layer can trivially ensure that the buffer contains X bytes
> > of data, where X is large enough to hold at least a two byte attribute
> > name and a two byte value length. Once the lengths are known then
> > the proper amount for values is easy to collect.
> >
> > With an ASCII encoding the upper layer has to guess, or check for
> > proper terminators.
> >
> > >buffers seems rather messy to me because the break can occur during any
> > >element. It sees like a good place to generate lots of occasional bugs.
> >
> > Yes, except with binary it is not messy at all.
> >
> > >putting a " " (space character) just after the last character in the
> > >buffer to stop the scan-for-space algorithm.
> >
> > That would work, if you must scan.
> >
> > >You also observed that with CRLF and a maximum line length, it is easy
> > >to ensure that a buffer has a full unit because functions, such as fgets
> > >read upto the next CRLF. Perhaps we need to revisit the solution that
> >
> > Unless you have to interoperate with implementations that visually
> > checked (instead of looking at a sniffer hex dump) for "lines". Like
> > with HTTP servers today, even though the spec reads CRLF you still
> > find CR (from mac?), LF (from unix?) and the desired CRLF (I wouldn't
> > be suprised to find some LFCR's out there).
> >
> > > CR in a value is represented by =0C
> > > LF in a value is represented by =0A
> > > = in a value is represented by =3D
> >
> > You will probably need to escape anything less than %x20 and perhaps
> > anything greater than %x7E.
> >
> > In fact, instead of developing our own escape rules we should, as you
> > probably did, just pick one.
> >
> > This is just so ugly, considering the purpose is for two computers to
> > talk to each other over a link that is 8-bit clean.
> >
> > >Perhaps this pure textual solution is easier to program once you consider
> > >the buffer problem.
> >
> > I don't find it so.
> >
> > sdb
> >
> > | Sylvan Butler | sbutler at boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 |
> >
--
Randy Turner