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@hpbs2024.boi.hp.com Mon Jun 23 09:04:34 1997
> From: "Sylvan Butler" <SBUTLER@hpbs2024.boi.hp.com>
> X-Real-Sender: SYLVAN
> Organization: Hewlett-Packard, Boise
> To: Robert.Herriot@Eng (Robert Herriot)
> Date: Mon, 23 Jun 1997 10:02:48 -0700
> Subject: Re: IPP>PRO: sorry, but binary is better
> CC: ipp@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@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 |
>