Re: [ASN.1] ASN.1 beginner questions nagging at my brain....

2003-08-18 Thread seberino
Steven

I really appreciate the info.  I've slowly thought about all you
said and hopefully have some impressive questions regarding
your prose if you don't mind...

Q1:
Why would XML Schema designers ever have been motivated to
create it in the first place??  The only reason I can think
of to have a more abstract representation like ASN.1 is to
allow different encodings.  But, if we assume XML Schema
guys want XML to take over the world then this seems
counterproductive.  On the other hand, if they are open
to other encodings, why not just use ASN.1 with XER when
they want XML???

Q2:
If I'm not mistaken XML is Unicode/ASCII based.  If we
call this an encoding language or transfer syntax then how
come people have problems with little endian and big endian differences??
Endianness problems are a result of the bit details not being
specified in full detail right?? Does this mean one flaw with
XML and Unicode is that they don't rigorously specify enough
details about the locations of ones and zeroes like BER, DER, PER, etc.??

Thanks again,

Chris


On Thu, Aug 14, 2003 at 02:11:25PM +1000, Steven Legg wrote:
 
 Hi Chris,
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
  [EMAIL PROTECTED]
 
  The following basic questions are nagging at my brain
  
  Q1: XML is a universal standard data format that is gaining
  popularity fast.  What is the role of
  ASN.1 in a world with XML?? Is it a competing standard??
  Does it add any /more/ value?
  
  Q2: I read about ASN.1 specifying a binary format for data.
  I think this may be the (only?) extra contribution ASN.1 has
  that XML does not have.  If so, why does ASN.1 also
  specify an ASCII format??? Perhaps it would have been
  more useful to /just/ make ASN.1 specify a standard
  way to encode XML in binary?
 
 Let me put things into the right context first.
 
 ASN.1 is a language for describing the structure of data in
 abstract terms. The A in ASN.1 stands for Abstract after all.
 By itself an ASN.1 specification does not specify the concrete
 representation of the data in transmission or storage. The concrete
 representation is known as the transfer syntax in ASN.1 terms and
 is determined by the application of one of a set of encoding rules.
 Each set of rules has different properties with respect to
 space efficiency, time efficiency and readability (among other
 things) of the resulting transfer syntax.
 
 XML is essentially analogous to a transfer syntax. There are encoding
 rules for ASN.1 (e.g. XER and DXER) which format data as XML.
 XML is not in competition with ASN.1. Comparing XML to ASN.1 is
 like comparing concrete to architects' drawings. Rather, ASN.1
 is analogous to, and in competition with, XML Schema, RELAX NG
 and DTDs.
 
 An obvious advantage of ASN.1 is that the same data (semantically)
 can be formatted in other ways (syntactically) by applying different
 encoding rules. For example, a very compact binary representation
 results from using PER. Currently the only transfer syntax for
 XML Schema or RELAX NG is XML.
 
 With respect to XML formatted data, ASN.1, XML Schema and RELAX NG
 are broadly similar in what they express although they differ in
 the details. Each of these languages has some features which have
 no equivalent in the other languages. For example, ASN.1 has a much
 richer repertoire for defining restricted types (constrained types)
 than the other languages. There is work in progress by the ITU-T and
 ISO to extend ASN.1 so that it has at least the expressibility of
 XML Schema.
 
 A notable feature of XML Schema and RELAX NG is that the syntax of
 the schema languages they define is also XML, whereas the syntax
 of ASN.1 specifications is unique. It does not correspond to a
 transfer syntax generated by any of the encoding rules. However there
 is an IETF draft of a specification for representing ASN.1 specifications
 in XML syntax called ASN.1 Schema. That specification brings to ASN.1
 all the advantages attributed to XML Schema and RELAX NG in having an
 XML syntax.
 
 I note that RELAX NG specifications now have an non-XML compact
 representation. RELAX NG has followed the reverse path to ASN.1!
 To refine the analogies, an ASN.1 specification is analogous to
 the compact syntax for RELAX NG (there is no equivalent for XML Schema
 as far as I know) and an ASN.1 Schema document is analogous to
 an XML Schema document or RELAX NG grammar document. XML is just
 a transfer syntax.
 
 For most new XML-based applications it won't make much difference
 whether they are specified in ASN.1/ASN.1 Schema, XML Schema or RELAX NG.
 All three schema languages can do the job. Some applications will have
 particular requirements that can be best met by only one of these
 languages, which will make that language the best choice, though
 often the choice of schema language will come down to the application
 designers' prejudices and what they are 

RE: [ASN.1] ASN.1 beginner questions nagging at my brain....

2003-08-14 Thread Steven Legg

Hi Chris,

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
 [EMAIL PROTECTED]

 The following basic questions are nagging at my brain
 
 Q1: XML is a universal standard data format that is gaining
 popularity fast.  What is the role of
 ASN.1 in a world with XML?? Is it a competing standard??
 Does it add any /more/ value?
 
 Q2: I read about ASN.1 specifying a binary format for data.
 I think this may be the (only?) extra contribution ASN.1 has
 that XML does not have.  If so, why does ASN.1 also
 specify an ASCII format??? Perhaps it would have been
 more useful to /just/ make ASN.1 specify a standard
 way to encode XML in binary?

Let me put things into the right context first.

ASN.1 is a language for describing the structure of data in
abstract terms. The A in ASN.1 stands for Abstract after all.
By itself an ASN.1 specification does not specify the concrete
representation of the data in transmission or storage. The concrete
representation is known as the transfer syntax in ASN.1 terms and
is determined by the application of one of a set of encoding rules.
Each set of rules has different properties with respect to
space efficiency, time efficiency and readability (among other
things) of the resulting transfer syntax.

XML is essentially analogous to a transfer syntax. There are encoding
rules for ASN.1 (e.g. XER and DXER) which format data as XML.
XML is not in competition with ASN.1. Comparing XML to ASN.1 is
like comparing concrete to architects' drawings. Rather, ASN.1
is analogous to, and in competition with, XML Schema, RELAX NG
and DTDs.

An obvious advantage of ASN.1 is that the same data (semantically)
can be formatted in other ways (syntactically) by applying different
encoding rules. For example, a very compact binary representation
results from using PER. Currently the only transfer syntax for
XML Schema or RELAX NG is XML.

With respect to XML formatted data, ASN.1, XML Schema and RELAX NG
are broadly similar in what they express although they differ in
the details. Each of these languages has some features which have
no equivalent in the other languages. For example, ASN.1 has a much
richer repertoire for defining restricted types (constrained types)
than the other languages. There is work in progress by the ITU-T and
ISO to extend ASN.1 so that it has at least the expressibility of
XML Schema.

A notable feature of XML Schema and RELAX NG is that the syntax of
the schema languages they define is also XML, whereas the syntax
of ASN.1 specifications is unique. It does not correspond to a
transfer syntax generated by any of the encoding rules. However there
is an IETF draft of a specification for representing ASN.1 specifications
in XML syntax called ASN.1 Schema. That specification brings to ASN.1
all the advantages attributed to XML Schema and RELAX NG in having an
XML syntax.

I note that RELAX NG specifications now have an non-XML compact
representation. RELAX NG has followed the reverse path to ASN.1!
To refine the analogies, an ASN.1 specification is analogous to
the compact syntax for RELAX NG (there is no equivalent for XML Schema
as far as I know) and an ASN.1 Schema document is analogous to
an XML Schema document or RELAX NG grammar document. XML is just
a transfer syntax.

For most new XML-based applications it won't make much difference
whether they are specified in ASN.1/ASN.1 Schema, XML Schema or RELAX NG.
All three schema languages can do the job. Some applications will have
particular requirements that can be best met by only one of these
languages, which will make that language the best choice, though
often the choice of schema language will come down to the application
designers' prejudices and what they are familiar with.

What makes ASN.1 important in the crowd is the body of prior art.
There are numerous examples of existing, widely deployed, mature
applications defined in terms of ASN.1. It seems to me that there
are too many people seeking to redefine these applications from scratch
just so that they can use XML when it makes much more sense to
regard ASN.1 as an XML schema language and just apply a different
set of encoding rules to the existing application.

 Q3: Why do we /need/ a standard binary format?? The Transport Layer
 of the TCP/IP network stack has been happily moving tons of
 bits thru the Internet via sockets and port for years without
 any need for a standard way to represent ones and zeroes!!!
 
 Granted it is true that there is no standardization of *how*
 or *what* gets sent thru the Transport Layer.  In the Application
 Layer, applications make up their own standard FTP, SSH,
 TELNET, HTTP each define their own protocol.  I suppose we could
 start making applications all use ASN.1 instead of reinventing
 the wheel but why would that be useful?
 
 Q4: Many papers on ASN.1 define it's functionality in terms
 of two upper