IPP>PRO: protocol problem, WAS: sorry, but binary is better

IPP>PRO: protocol problem, WAS: sorry, but binary is better

IPP>PRO: protocol problem, WAS: sorry, but binary is better

Randy Turner rturner at sharplabs.com
Mon Jun 23 17:57:33 EDT 1997


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




More information about the Ipp mailing list