Syntax method of GEF extension definition

Terry L Anderson tla at LUCENT.COM
Mon Jul 9 22:40:38 EDT 2001


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 tech-know-ware.com
> +44 1473 635863
> =============================================
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com

--
It's not a lie. It's a gift for fiction.
------------------------------------------------------------
Terry L Anderson              mailto:tla at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tla.vcf
Type: text/x-vcard
Size: 448 bytes
Desc: Card for Terry L Anderson
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20010709/d930236d/attachment-0003.vcf>


More information about the sg16-avd mailing list