Pete,
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@LUCENT.COM] Gesendet am: Dienstag, 10. Juli 2001 04:41 An: ITU-SG16@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@tech-know-ware.com
+44 1473 635863
> For help on this mail list, send "HELP ITU-SG16" in a message to > listserv@mailbag.intel.com -- It's not a lie. It's a gift for fiction. ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com 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 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com