[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: Tim.Bray@Sun.COM [mailto:Tim.Bray@Sun.COM] On Behalf Of Tim Bray
> Sent: Wednesday, April 14, 2004 13:46
> To: Rich Salz
> Cc: 'xml-dev'; bob@wyman.us; 'Elliotte Rusty Harold'
> Subject: Re: [xml-dev] RE: Schema vs Schema-free
>
>
> On Apr 14, 2004, at 9:27 AM, Rich Salz wrote:
>
> > No, it's a mismatch between the data-type folks and the markup-type
> > folks. And the data folks don't seem to realize that the
> current crop
> > of security functions requires them think like markup-type folks on
> > the wire.
>
> Indeed. And to pound my tired old drum, since I haven't for a few
> weeks: The only basis for interoperability in networked
> systems is at
> the level of bits-on-the-wire. You can pretend this isn't
> so, but it
> will always bite you.
Tim,
I don't see why the use of ASN.1 would not satisfy this constraint. Given
an ASN.1 specification, and given a value for a data type defined in it, and
given the name of the encoding rules used, the bits on the wire are defined
unambiguously.
There are two kinds of encoding rules: canonical and non-canonical.
- If you use canonical encoding rules, the bits on the wire are not only
unambiguously defined, but also *exactly* defined for any possible abstract
value (however complex).
- If you use non-canonical encoding rules, there is a minor variability due
to "encoder's options". I am not aware that the existence of encoder's
options in BER has ever been a problem except when a unique on-the-wire
representation is needed. In such cases, people can choose DER/CER or
canonical PER. (By the way, non-canonical PER is actually canonical in most
cases.)
The restriction of ASN.1 is that all parties *must* agree on a set of type
definitions. Normally, you cannot make an arbitrary unilateral change to
the type definitions and hope that you will still be able to reobtain the
abstract value that is represented in a message.
In return for this constraint, ASN.1 gives you speed, compactness, and
flexibility. Indeed, this very flexibility enables ASN.1 to encode abstract
values in XML, and decode them and re-encode them at will between XML, PER,
BER, etc. Since abstract values exist independently of representation, we
have "pluggable" representations.
This provides a clean conceptual model of transcoding instances between XML
and other representations. The price for this is the "invariability of the
specification".
In addition, in ASN.1 there are provisions for versioning and dynamic
extensibility, which mitigate the issue of invariability of the
specification.
I have yet to hear a convincing argument that ASN.1 is inherently less
interoperable than XML. Historical accidents, such as buggy software, are
not relevant.
Alessandro Triglia
OSS Nokalva
-Tim
>
|
