Posted for Dean.
---------- Forwarded message ----------
Date: Sat, 17 Mar 2007 23:50:33 -0400 (EDT)
From: Dean Anderson <dean(_at_)av8(_dot_)com>
To: Pekka Savola <pekkas(_at_)netcore(_dot_)fi>, John C Klensin
<john-ietf(_at_)jck(_dot_)com>,
Simon Josefsson <simon(_at_)josefsson(_dot_)org>,
Brian E Carpenter <brc(_at_)zurich(_dot_)ibm(_dot_)com>,
Stephane Bortzmeyer <bortzmeyer(_at_)nic(_dot_)fr>,
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>,
Ted Hardie <hardie(_at_)qualcomm(_dot_)com>, Tom Yu
<tlyu(_at_)mit(_dot_)edu>,
Andy Bierman <ietf(_at_)andybierman(_dot_)com>, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com>,
David Kessens <david(_dot_)kessens(_at_)nokia(_dot_)com>
Cc: iesg(_at_)ietf(_dot_)org, ietf(_at_)ietf(_dot_)org
Subject: Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to
Experimental RFC
I would appreciate it is someone would repost this to the IETF list.
First, I want to say that I support an ASN.1 compiler in C++ and am
considering a rewrite of that compiler's translated runtime to ADA to
leverage some of ADA's advantages. While some people think ASN.1 is
obsolete, it is still a very efficient way to describe protocols and
generate their codecs. ASN.1 has attractive security properties, once
the security flaws are removed from the ASN.1 translator, of course.
However, that effort, once performed in the translator, subsequently
benefits and protects all users with no code changes. ASN.1 is
complicated, but robust and usually worth the effort.
XML, by contrast, is quick and dirty and inefficient; the protocol/codec
equivalent of a scripting language. The world needs both scripting
languages and compiled languages, and likewise I see a need for both XML
and ASN.1.
So, I have some mixed feelings about this document. The motivation for
this work is entirely unclear to me. Why is the X.693 XML Encoding Rules
(XER) Specification insufficient for encoding ASN.1 in XML? If XER is
truly deficient, perhaps it should be amended, and so this issue belongs
with the ITU, not the IETF. But I am unable to divine the deficiency in
XER from reading this document.
But also, if X.693 is insufficient, the next question is why is X.692
Encoding Control Notation insufficient? (well, I suppose its too new)
I suggest that one investigate XER and also X.692 Encoding Control
Notation, rather than specify a new and incompatible alternative.
In reading the document, I think a little too much is made of the issue
of ambiguity in ASN.1 specifications; they are only ambiguous if you
want to translate in a single pass with a LALR(1) parser generator.
But, I looked at Section 6 of the draft for some insight, and found this
claim:
Note that the notation of ASN.1 is ambiguous where a Type is both
prefixed [X.680-1] (e.g., tagged) and constrained. For example, the
notation "[0] INTEGER (0..10)" could be interpreted as either a
tagged ConstrainedType or a constrained TaggedType. For the purposes
of the translation into ASN.X, the constraint is assumed to have
higher precedence than the prefix, so the above notation would be
taken to be a tagged ConstrainedType.
Looking at my copies of X.680 and X.680 Amendment 1, I find no reason to
see that there is any ambiguity in the quoted example. Also, X.680
Amendment 1 seems to have no relevance to the paragraph, so I'm
wondering if the reference is a mistake.
In fact, X.680 Amendment 2, Section F.6 gives numerous examples of
tagged constrained types of similar form as the example above.
A closer look reveals no ambiguity:
The productions in question are defined in X.680 Section 16.2 and 30.1,
I have abbreviated them:
Type ::= BuiltinType | ReferencedType | ContrainedType
BuiltinType ::= ... |
TaggedType
TaggedType ::= Tag Type
Tag ::= "[" Class ClassNumber "]"
where Class can be empty, as it is in the quoted example.
Definition 3.8.64 gives a definition for the meaning of tagged types:
"A type defined by referencing a single existing type and a tag; the new
type is isomorphic to the existing type but distinct from it."
However, there is no ambiguity since tag and constraint are attributes
of a type, and it doesn't matter which comes first. ASN.1 compilers
which I am familiar with perform this as follows (Bison/c++)
TaggedType
: Tag Type
{
$2->SetTag($1.tagClass, $1.tagNumber,
Module->GetDefaultTagMode());
$$ = $2;
}
ConstrainedType
: Type Constraint
{
$1->AddConstraint($2);
}
| TypeWithConstraint
;
Bison translates this without conflicts. A longest string of terminals
always results in a ConstrainedType being reduced before a TaggedType is
reduced to Type. Bison and yacc resolve shift/reduce conflicts as
"shift" unless otherwise directed by operator precedence rules.
Suppose the parser stack contains:
Tag ([0])
Type (INTEGER)
The next symbol is "("
A shift (the default) implies that ConstrainedType will always be
reduced before TaggedType.
However, reducing at this point produces exactly the same result, so I
fail to see how this construct is ambiguous. There must be different
meanings in order to be ambiguous, and there is only one meaning. The
single result is a distinct type that is tagged and constrained.
It is true that a full parser of ASN.1 is impossible to implement in a
single pass with a LALR(1) parser because of ambiguities in the notation
which are resolved many tokens later. Multiple parsing passes resolve
those ambiguities. However, it is not the case that the ASN.1 notation
is unresolvably ambiguous.
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf