Syntax method of GEF extension definition
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
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
SG16 People, As a former SG16 participant (1998-2000) I would like to say farewell to those who I knew. I am taking an early retirement offer from Lucent, starting after July 13. (I am not quite ready for real retirement yet, so if you know of any job openings, please let me know.) We had some very interesting times at the Torino, Santiago, Berlin, Monterey, and Geneva meetings, especially the H.248 "discussions". I value the friendships I made and wish you all well. After July 13, my email address is robert.abrams@worldnet.att.net. Bob Abrams ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (3)
-
Pete Cordell -
Robert Abrams -
Terry L Anderson