|
[EDI-L Mailing List Archive Home]
[Message List]
[Reply To This Message]
Re: ANSI ASC X12: BIN and BDS segments
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" <
> > 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
>
> 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.
|
|
Subscribe in XML format
| RSS 2.0 |
|
| Atom 0.3 |
|
|
Cart
