<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<META content='"MSHTML 4.72.3110.7"' name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#000000 size=2>I've attached a few comments below to clarify
some of the issues raised by Abdallah...</FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT> </DIV>
<DIV><FONT size=2>Pete</FONT></DIV>
<DIV><FONT color=#000000
size=2><BR>=============================================<BR>Pete Cordell<BR><A
href="mailto:pete@tech-know-ware.com">pete@tech-know-ware.com</A><BR>=============================================<BR></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
<DIV><FONT face=Arial size=2><B>-----Original Message-----</B><BR><B>From:
</B>Abdallah Rayhan <<A
href="mailto:arayhan@NORTELNETWORKS.COM">arayhan@NORTELNETWORKS.COM</A>><BR><B>To:
</B><A
href="mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM">MEGACO@STANDARDS.NORTELNETWORKS.COM</A>
<<A
href="mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM">MEGACO@STANDARDS.NORTELNETWORKS.COM</A>><BR><B>Date:
</B>14 October 1999 16:05<BR><B>Subject: </B>APC-1711, 1712
review<BR><BR></DIV></FONT><FONT face=Arial><FONT
color=#3333ff></FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>I took a pass through APC-1711 and APC-1712 and I would like
to post my analysis</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>on the mailing list. I don't claim my analysis to be complete,
however I tried to point</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>out the main problems I came across while reading APC-1711
ABNF. My primary</FONT></FONT> <BR><FONT face=Arial><FONT color=#3333ff>goal
is the final ABNF and not the ASN.1 for two reasons. First, I am not an
ASN.1</FONT></FONT> <BR><FONT face=Arial><FONT color=#3333ff>expert, so I
would leave critiquing it to the ASN.1 experts. Second, it
would</FONT></FONT> <BR><FONT face=Arial><FONT color=#3333ff>be a big
distraction to the IETF having the MEGACO ABNF at an advanced</FONT></FONT>
<BR><FONT face=Arial><FONT color=#3333ff>stage with a set of testbenches
(ANNEX G). Hence, I will try to focus on APC-1711 ABNF</FONT></FONT>
<BR><FONT face=Arial><FONT color=#3333ff>which I call ABNF1711 and
MEGACO/H.248 ABNF which I call ABNF248.</FONT></FONT><FONT face=Arial><FONT
color=#3333ff></FONT></FONT> </BLOCKQUOTE>
<BLOCKQUOTE
style="BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">Just
to reassure you, the level of ASN.1 understanding required to work with the
definition in 1711 is fairly easy to acquire. I would say slightly
easier then ABNF, but then we're talking about fairly straight forward
things in both cases so the differences are not really significant.
I've attempted to put a bit of a tutorial about ASN.1 in APC-1712. I'm
happy to expand this if it is felt to be desirable (I didn't want to go too
far straight away in case the editors jumped on me!). In short, if you
know C, SEQUENCE == struct, CHOICE == union (except type in union is also
stored), and each parameter is "name type" rather than "type
name". Each parameter can also be optional, in which case
OPTIONAL appears at the end, and/or can appear multiple times, in which case
the format is "name SEQUENCE OF type". Knowing that you
should be able to pick up the rest by looking at 1711. (I for one
learnt ASN.1 just by looking at examples of it.)
<P><FONT face=Arial><FONT color=#3333ff>To start with I have noted that the
ABNF1711 does not take the ABNF248 as is</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>but modifies it to suite ASN.1 encoding ( is
ASN.1 so restrictive that it does not</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>allow ABNF248 syntax ? ) These discrepancies
are found in: (I started noting</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>the different PRs but then found myself marking almost
every one.)</FONT></FONT>
<P><FONT face=Arial><FONT color=#3333ff>- Tagging every value.</FONT></FONT>
<BR><FONT face=Arial><FONT color=#3333ff>ABNF1711:</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>PkgdName = LBRKT PkgItemID [ PkgName
] RBRKT</FONT></FONT> <BR><FONT face=Arial><FONT color=#3333ff>PkgName
= LBRKT "/" ( ( "PE" EQUAL Name ) /
"*" ) RBRKT</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>PkgItemID = ( ( "PI" EQUAL Name )
/ "*" )</FONT></FONT>
<P>This is one construct the ASN.1 definition has a lot of trouble
with. One proposal is just to make this an IA5String (in ASN.1
speak). It can then be coded in the same way as ABNF1711.</P>
<P><FONT face=Arial><FONT color=#3333ff>ABNF248:</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>pkgdName = [ (PackageName |
"*") SLASH ] (ItemID | "*" )</FONT></FONT>
<BR><FONT face=Arial><FONT color=#3333ff>PackageName =
NAME</FONT></FONT> <BR><FONT face=Arial><FONT color=#3333ff>ItemID =
NAME</FONT></FONT><FONT face=Arial><FONT color=#3333ff></FONT></FONT>
<P>A similar comment applies to this also, i.e. making IA5String removes the
problem.</P>
<P><FONT face=Arial><FONT color=#3333ff>You need "PE=" before
package name and "PI=" before ItemID.</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>These differences appear in many production
rules.</FONT></FONT>
<P><FONT face=Arial><FONT color=#3333ff>- Extra brackets as illustrated in
the previous example. In ABNF1711,</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>there is a curly bracket before and after PkgdName while
ABNF248 does not</FONT></FONT> <BR><FONT face=Arial><FONT color=#3333ff>have
that. This is all over ABNF1711.</FONT></FONT><FONT face=Arial><FONT
color=#3333ff></FONT></FONT>
<P>The IA5String would also remove the need for the curly-wurlies around
this.</P>
<P><FONT face=Arial><FONT color=#3333ff>- Extensions do not appear any where
in ABNF1711 while they are a major</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>feature of ABNF248.</FONT></FONT><FONT face=Arial><FONT
color=#3333ff></FONT></FONT>
<P>Right, extensions to the ASN.1 are implicit. By that I mean that,
every SEQUENCE and CHOICE can be extended. That's way there are a few
more braces and there are restrictions on what is untagged. The
encoding rules philosophy is that it should be possible to skip any
parameter, and then re-start parsing the next parameter without losing
parameters, and without interpreting tags as values and so on.</P>
<P><FONT face=Arial><FONT color=#3333ff>-ABNF1711 changes the syntax of the
MEGACO constructs.</FONT></FONT><FONT face=Arial><FONT
color=#3333ff></FONT></FONT>
<P><FONT face=Arial><FONT color=#3333ff>ABNF1711:</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff> RequestedActions = LBRKT
RequestedAction [ "E" EQUAL SecondEventsDescriptor ]</FONT></FONT>
<BR><FONT face=Arial><FONT color=#3333ff> [ "SG"
EQUAL SignalsDescriptor ] [ "IC" ]
RBRKT</FONT></FONT><FONT face=Arial><FONT color=#3333ff></FONT></FONT>
<P><FONT face=Arial><FONT color=#3333ff>ABNF248:</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>requestedActions =
requestedAction LWSP [COLON LWSP embeddedSignalEvents ] [COLON LWSP
InterceptToken ]</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>embeddedSignalEvents = firstEmbedding [COMMA
firstEmbedding]</FONT></FONT>
<P><FONT face=Arial><FONT color=#3333ff>as you can see the first level of
embedding (firstEmbedding) is chopped in ABNF1711.</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>As a matter of fact, it changes the syntax
into something different.</FONT></FONT><FONT face=Arial><FONT
color=#3333ff></FONT></FONT>
<P><FONT face=Arial><FONT color=#3333ff>-ABNF1711 enforces ordering of
descriptors and parameters while the ABNF248</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>does not. This issue was raised before and
the resolution was made to enforce no order</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>since there is no relationship between
descriptors, e.g., modems or muxes, whichever comes</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>first does not affect the
other.</FONT></FONT><FONT face=Arial><FONT color=#3333ff></FONT></FONT>
<P>I think I know what your referring to here, but I can't find it now that
I look for it. But basically, the order of tagged parameters after the
last untagged parameter is not important. It's a limitation of my ABNF
skills that prevented me from being able to express both the multiplicity
(if that's the right word for how many times a thing appears) and also say
that it could appear in any order.</P>
<P><FONT face=Arial><FONT color=#3333ff>- ABNF248 uses COMMA as a separator
for commands, descriptors</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>and parameters. This concept is gone in
ABNF1711.</FONT></FONT><FONT face=Arial><FONT color=#3333ff></FONT></FONT>
<P><FONT face=Arial><FONT color=#3333ff>- ABNF1711 changes the syntax and
the semantics of MEGACO, e.g.,</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>ABNF1711:</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>NotifyReply = LBRKT TerminationID [ "ER" EQUAL
ErrorDescriptor ] RBRKT</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>You always have TerminationID regardless of whether it is
NotifyReply error or not,</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>and ErrorDescriptor is tagged.</FONT></FONT><FONT
face=Arial><FONT color=#3333ff></FONT></FONT>
<P><FONT face=Arial><FONT color=#3333ff>ABNF248</FONT></FONT> <BR><FONT
face=Arial><FONT
color=#3333ff>notifyReply = NotifyToken
( commandError | [EQUAL TerminationID])</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>commandError = EQUAL TerminationID LBRKT
errorDescriptor RBRKT</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>TerminationID is optional in pure notify reply and mandatory
in notify error.</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>ErrorDescriptor is not tagged.</FONT></FONT><FONT
face=Arial><FONT color=#3333ff></FONT></FONT>
<P><FONT face=Arial><FONT color=#3333ff>Also, ABNF1711:</FONT></FONT>
<BR><FONT face=Arial><FONT color=#3333ff>SecurityParmIndex = ( 1( BASE64 )
BASE64END )</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>SequenceNum = ( 1( BASE64 ) BASE64END )</FONT></FONT>
<BR><FONT face=Arial><FONT color=#3333ff>AuthData = ( 5( BASE64 ) BASE64END
)</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>BASE64 = 4( BASE64CHAR )</FONT></FONT>
<BR><FONT face=Arial><FONT color=#3333ff>BASE64END = 4( BASE64CHAR ) /
( 3( BASE64CHAR ) "?" ) / ( 2( BASE64CHAR ) "??"
)</FONT></FONT> <BR><FONT face=Arial><FONT color=#3333ff>Where did
"?" and "??" come from ?</FONT></FONT><FONT
face=Arial><FONT color=#3333ff></FONT></FONT>
<P>John has put the wrong modifier type for this OCTET STRING. It
should be HEX OCTET STRING, which would result in the use of the two hex
values per octet representation. </P>
<P>I don't think base64 is used in megaco, but the reason for changing the
base64 padding character is using = is ambiguous. It's not clear in
the case when parsing parameters that have been added after the definition
that the parser knows about whether the = are separating a tag from a value,
or part of the value. A simple way to resolve this is to change the
padding character. I think this is been done in some other protocol
(can't remember which) and it's not difficult to do. Even if you have
a black box base64 encoder you can always fix it up later by doing if(
last-char == '=' ) last-char = '?' and same for the next to last.</P>
<P><FONT face=Arial><FONT color=#3333ff>ABNF248:</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>SecurityParmIndex =
8(HEXDIG)</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>SequenceNum
= 8(HEXDIG)</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>AuthData
= 32*64(HEXDIG)</FONT></FONT>
<P>If the correct modifier is used as described above, the revised form of
this becomes </P>
<P>SP = 4 OCTET</P>
<P>SN = 4 OCTET</P>
<P>AD = 16*32( OCTET )</P>
<P>OCTET = ( HEXDIG HEXDIG )</P>
<P><FONT face=Arial><FONT color=#3333ff>These are some of the differences.
If we review each PR, no PR in ABNF1711</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>will be saved. So I will stop
here.</FONT></FONT><FONT face=Arial><FONT color=#3333ff></FONT></FONT>
<P><FONT face=Arial><FONT color=#3333ff>I don't know if the kind of
constraints ABNF1711 enforces on the ABNF are due to</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>to the ASN.1 encoding constraints or because
of ASN.12ABNF.</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>Whatever the reasoning is, APC1711 should focus on completing
the ASN.1</FONT></FONT> <BR><FONT face=Arial><FONT color=#3333ff>description
and generate similar testbenches as in the MEGACO I-D either</FONT></FONT>
<BR><FONT face=Arial><FONT color=#3333ff>binary or text, or both. The binary
will be definitely different than the text because of</FONT></FONT>
<BR><FONT face=Arial><FONT color=#3333ff>tagging, however the text should be
same as the test benches written so far.</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>In theory, bin and text should reflect the
same protocol and should introduce the least</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>entropy into the syntax.</FONT></FONT><FONT
face=Arial><FONT color=#3333ff></FONT></FONT>
<P>I agree with you that at the moment we have a serious issue that megaco
might become two protocols; one binary, one text. I can also see that
they may well diverge if we are not careful. We probably differ on the
best way to prevent that though :).</P>
<P><FONT face=Arial><FONT color=#3333ff>My recommendation is that rather
than writing ASN.12ABNF tool, APC1711</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>should write examples that use the ASN.1 and
bin2text and text2bin tools in order to</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>test the ASN.1 encoding. Once that is out of
the way and we know that the ASN.1 is ok,</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>we could look into tools like ASN.12ABNF
presuming that it would generate ABNF</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>that is equivalent to ABNF248 syntactical and
semantical wise. Otherwise, ABNF1711</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>approach is unproductive and waste of effort
trying to verify every PR of ABNF1711.</FONT></FONT>
<P>I'm not sure how you see the bin2text and text2bin working. Perhaps
you could explain this further. </P>
<P><FONT face=Arial><FONT color=#3333ff>In addition to that, if we assume
that the ASN.1 is ok and the ASN.12ABNF is</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>ok, from what I saw both are not, is there
any guarantee that when they change</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>the ASN.1, that will not introduce problems into the ABNF ? My
feeling is that</FONT></FONT> <BR><FONT face=Arial><FONT color=#3333ff>it
would be a source of confusion and we would need to review the ABNF
and</FONT></FONT> <BR><FONT face=Arial><FONT color=#3333ff>probably hand
craft some PRs to make it consistent and ambiguous free.</FONT></FONT>
<BR><FONT face=Arial><FONT color=#3333ff>If that is that is the case, why
should we throw out ABNF248 which</FONT></FONT> <BR><FONT face=Arial><FONT
color=#3333ff>we have tested and have a high degree of confidence in. We are
very familiar</FONT></FONT> <BR><FONT face=Arial><FONT color=#3333ff>with
ABNF248; we know the ins and outs of it; and we know how to fix any
problem</FONT></FONT> <BR><FONT face=Arial><FONT color=#3333ff>without
disturbing the rest of the grammar. How would ABNF1711 do that
?</FONT></FONT><FONT face=Arial><FONT color=#3333ff></FONT></FONT>
<P>One reason the ASN.1 definition is having a tough time matching the ABNF
is because its fundamental to the way it works to be consistent and avoid
ambiguity. By defining how parameters are encoded in a consistent way,
and ensuring that that encoding allows them to be readily skipped when they
are not understood means there's less (hopefully no) chance that you end up
with something that's ambiguous, especially when a v1 implementation parses
a v2 message etc. Fortunately, ABNF248 is already pretty consistent which is
way its not an impossible task for the ASN.1.</P>
<P><FONT face=Arial><FONT color=#3333ff>As for ASN.1, it is not compatible
with the standard. This means that ASN.1 compilers</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>can not produce a correct
code.</FONT></FONT><FONT face=Arial><FONT color=#3333ff></FONT></FONT>
<P><FONT face=Arial><FONT color=#3333ff>regards</FONT></FONT> <BR><FONT
face=Arial><FONT color=#3333ff>Abdallah Rayhan</FONT></FONT>
<P>My over all feeling is that a lot of effort has been put in to the ASN.1
close to the ABNF. I'll admit it doesn't result in exactly the same
ABNF as 248, but I hope that we can still be part of the consensus forming
process that defines the ABNF if the functionality is not changed. Or
put another way, I hope we are not precluded from being able to suggest
changes to the ABNF because we are also trying to describe it in
ASN.1. I'm also aware that this approach was adopted to get us out of
the text vs. binary black hole. If this initiative fails then we are
back to that, something that I would expect that none of us would want to go
back to. So let's work together and try and sort this out once and for
all.<BR><FONT face=Arial><FONT color=#3333ff></FONT></FONT>
</P></BLOCKQUOTE></BODY></HTML>