There is a little fly in the ointment... Even if you encode the content of the BIN/BDS payload in base64 or HEX or something easy to handle, you are likely to have the base64 encoded payload as individual "lines" instead of a long single stream. So, the communications protocols need to make sure they treat this delicate payload as "binary" instead of "text". It looks like lines of text, it apparently only contains printable characters...
But each one of those base64-encoded lines ends with a \n or a \r\n depending on the system you are using. And, if the communication system changes the line endings from \n to \r\n or viceversa (e.g., FTP from unix to windows) then the actual byte count of the payload has changed and no longer matches the size of the payload that was explicitly stated in BIN01. So, even with the base64 encoding of the payload, these are rather fragile objects. One option could be to "require" base64 encoding and to ignore the BIN01 value altogether, presuming the segment terminator will not be found in the base64 encoded payload. Other options are left to the imagination of the system developers :-) Kepa Zubeldia Claredi On Wednesday 23 March 2005 02:23 pm, Michael Mattias wrote: > > From: "Mike Rawlins" <[EMAIL PROTECTED]> > > There's been a bit of traffic on this, but I don't think any of the > > messages have quite answered your essential questions. You ask: > > > > >But how can this be, given that a communications protocol may be a 7-bit > > >protocol? If you use a 7-bit protocol, either you'd lose > > >bit 7 of each octet or it would be misinterpreted as a control character. > > >Or, does the use of BDS/BIN presuppose the use of an 8-bit > > >protocol? Or preempt the use of high-order characters? > > > > > >Or does the standard just assume that "you have the data, communications > > >is a totally separate consideration?" (Which really seems > > >strange given the origin and original design of ANSI ASC X12 data format). > > > Actually, the answer is sort of the last case, but with > >qualification This is the reason for the "Filter ID Code" in BDS01 and EFI16 (used with BIN). > > Aha! Partners may (or may have to!) agree on an encoding standard for BIN03 data consistent with their communications agreement! > > Now *that* makes sense!! (If not to the little guys I work with, it does to me). > > Thank you much. > > Michael Mattias > Tal Systems, Inc. > Racine WI > [EMAIL PROTECTED] > http://www.talsystems.com > > > > > > > > . > Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> > Access the list online at: http://groups.yahoo.com/group/EDI-L > > Yahoo! Groups Links > > > > > > > > -- This email contains confidential information intended only for the named addressee(s). Any use, distribution, copying or disclosure by any other person is strictly prohibited. . Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Access the list online at: http://groups.yahoo.com/group/EDI-L Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/EDI-L/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
