[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Fwd: [e-lang] Protocol implementation errors

• To: xml-dev@l...
• Subject: Re: Fwd: [e-lang] Protocol implementation errors
• From: Tyler Close <tyler@w...>
• Date: Fri, 3 Oct 2003 13:15:41 -0400
• In-reply-to: <r02000200-1028-709B591EF5C411D7B7360003937A08C2@[192.168.124.11]>
• References: <r02000200-1028-709B591EF5C411D7B7360003937A08C2@[192.168.124.11]>

On Friday 03 October 2003 13:10, Simon St.Laurent wrote:
> In my explorations, ASN.1 toolkits felts more to me like data-binding
> kits than XML parsers.  There doesn't seem to be much notion of anything
> like an "ASN.1 infoset", a set of containers and properties you can
> explore without necessarily knowing the bindings.  ASN.1 feels
> effectively schema-driven, designed from the outset to be optimized for
> a world where processes are tightly bound.  There aren't general ASN.1
> "parsers" in the same sense that there are XML parsers, or at least
> there weren't last time I looked.

This lack of layering might be a contributing factor to the
persistence of bugs in ASN.1.

The merging of the "infoset" and the "schema" can be seen as
merging of the lexer and the parser. By complicating the lexer,
ASN.1 has made itself more vulnerable to bugs commonly associated
with a lexer, such as buffer overflow.

I offer this thought only as a plausible theory. I think the
burden is still on the ASN.1 advocates to explain why past
failures will not be repeated.

Tyler

-- 
The union of REST and capability-based security:
http://www.waterken.com/dev/Web/

• References:
  • Re: Fwd: [e-lang] Protocol implementation errors
    • From: "Simon St.Laurent" <simonstl@s...>

• Prev by Date: Re: Fwd: [e-lang] Protocol implementation errors
• Next by Date: RE: Fwd: [e-lang] Protocol implementation errors
• Previous by thread: Re: Fwd: [e-lang] Protocol implementation errors
• Next by thread: RE: Fwd: [e-lang] Protocol implementation errors
• Index(es):
  • Date
  • Thread