<!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>