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