[
Lists Home |
Date Index |
Thread Index
]
Suggestions for an ASN.2 that is a cut-down, basic, ASN.1 abound. But the
problem is that for every feature you look at, there are real specicifications
out there that use it!
Also, please distinguish the ASN.1 notation from the encoding rules. This is a
one to many mapping.
Simplifying some encoding rules is certainly possible - BER does not really need
both definite and indefinite length encodings, but there were (and probably
still are) groups that would fight to the death for one or the other.
(Definite length is great for small things, is abysmal if you have to churn disk
to find the length before you send it at the head. Indefinite is usually an
extra octet, and is only possible if the contents are structured. It would be
hard to eliminate either in ASN.2.)
"Simplifying" the notation could mean removing things such as parameterisation -
Yuck! that is needed - or changing the syntax for easier parsing (in ECN the
start of a parameter list was introduced by "{<" rather than by just "{" to make
life easier for parsers. I am not sure that is really progress! There are as
many different and conflicting proposals for "simplifying" ASN.1 as there are
people involved with it!
A major effort was made to remove stuff and to correct earlier misdirections,
with the removal of the "macro notation" in the early 1990s, but we still hear
the echoes of the shouts and complaints about that!
More seriously, any established and well-used language/notation needs to grow
with the needs of its uses, with incremental additions, and with deprecation
only where really necessary. Of course, tutorials on "Simple ASN.1" or "ASN.1
for use today" would be good. But an ASN.2, with widespread removal fo
functions, probably would not.
John L
Michael Champion wrote:
>
> On Monday, Nov 3, 2003, at 11:08 America/Detroit, Bob Wyman wrote:
>
>>
>
>
>> Complete commercial implementations are available, it would be
>> hard to justify their cost if they weren't. The difference is that the
>> commercial projects are addressing the needs of hundreds of projects
>> which represent enough variety in their requirements that a full ASN.1
>> implementation is needed to satisfy them all. Also, since people are
>> paying money for the stuff, they tend to complain louder and expect
>> rapid response whenever it is found that something that they need from
>> an ASN.1 standard is not implemented properly in the commercial tool.
>>
>
> Sounds like SGML circa 1996! Maybe it's time for a serious refactoring
> of ASN.1 to find the 80/20 point in there. Maybe ASN.2 could be to
> ASN.1 what XML is to SGML.
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>
>
--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Development Services Ltd)
1 Blueberry Road
Bowdon j.larmouth@salford.ac.uk
Cheshire WA14 3LS
England
Tel: +44 161 928 1605 Fax: +44 161 928 8069
|
