AW: Syntax method of GEF extension definition

Pete Cordell pete at TECH-KNOW-WARE.COM
Tue Jul 31 09:38:48 EDT 2001

FYI - I will remove the syntax method of definition from the next version of


Pete Cordell
pete at
+44 1473 635863

----- Original Message -----
From: Horvath Ernst <ernst.horvath at SIEMENS.AT>
To: <ITU-SG16 at mailbag.cps.INTEL.COM>
Sent: 10 July 2001 08:34
Subject: AW: Syntax method of GEF extension definition


I fully agree with Terry.

Let me add that the H.450 series use ROSE, which is pure ASN.1, as a formal
method for the same kind of specifications as GEF. I admit that the
definitions in H.450.1 look repulsively complex, but the individual
supplementary service modules in H.450.x are very straightforward even for
extensive services. And it's that latter quite intuitive notation that
people use when defining new syntax.
If there is need for a third formal method for GEF, I would opt for an ASN.1
based mechanism on the lines of H.450.

Ernst Horvath
Siemens AG

> -----Ursprüngliche Nachricht-----
> Von: Terry L Anderson [mailto:tla at LUCENT.COM]
> Gesendet am: Dienstag, 10. Juli 2001 04:41
> An: ITU-SG16 at mailbag.cps.INTEL.COM
> Betreff: Re: Syntax method of GEF extension definition
> Pete
> Sorry for not responding earlier.  I am one of those who
> expressed concern for
> this section of the document during the discussion in Porto
> Seguro.  I share
> your concern about the difficulty of using ASN.1 for these
> specification since
> I struggled with learning the value specification form for
> use in Annex R, but
> I believe that your first method (Encoded in Raw Method) is
> satisfactory for
> this and is what we eventually used in Annex R.  I also
> believe that the table
> method is suitable for simple cases of values without
> structure.  I am not
> convinced that we need a third method and don't believe that
> introducing a new
> syntax specification language helps make this simpler.  If
> this method were
> used in a future annex it requires all users to learn yet one more
> specification language - no matter how well designed, this
> adds considerably to
> the difficulty of using that Annex.  You suggest that since
> it is optional
> people are not obliged to use it, but if the author of an
> Annex chooses to use
> it all users of that annex now become obliged to.
> I have not analyzed your new language in detail, but new
> languages (and
> especially abstract ones) usually take considerable
> time/effort before they are
> complete and correct and documented unambiguously.  Perhaps
> you are better than
> most language writers and admittedly this is not a large
> language but I can
> hardly believe that it will not take a few iterations before
> it is "done".
> But even if the current form is perfect, my concern is
> introducing yet one more
> language for a task that has two simpler solutions that I
> believe cover the
> need.
> My vote is "it goes".
> Pete Cordell wrote:
> > Hi All,
> >
> > As you may know, the most recent version of H.GEF.1
> included a syntax based
> > method of defining GEF extensions.  I defined this so that
> people wouldn't
> > get confused with trying to interpret a syntax based
> definition as pure
> > ASN.1.  My principle is, if you are defining something that
> is different to
> > something that is already used, then make it obviously different.
> >
> > I'm fairly comfortable that the syntax is complete.  Also,
> if people don't
> > want to use that method of GEF definition they are not
> obliged to.  I
> > personally would therefore like to keep it in.
> >
> > However, we live in a democracy.  Therefore, the person
> that gives me the
> > highest bid can decide whether it stays or goes!
> >
> > Meanwhile, people can vote on whether it stays or goes by
> e-mailing me
> > directly.  I will then summarise and post the results to
> the list.  In the
> > event of a draw I'll keep it in.
> >
> > All the best,
> >
> > Pete.
> >
> > =============================================
> > Pete Cordell
> > Tech-Know-Ware
> > pete at
> > +44 1473 635863
> > =============================================
> >
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at
> --
> It's not a lie. It's a gift for fiction.
> ------------------------------------------------------------
> Terry L Anderson              mailto:tla at
> Tel:908.582.7013   Fax:908.582.6729
> Lucent Technologies/INS/Voice Over IP Access Networks
> Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> (Lucent internal)

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at

More information about the sg16-avd mailing list