Rich, Karl,
The problem with calling the construct in question a parameter is that it also contains parameters. When the text explaining it goes on about the parameter and the parameter, you don't know what variant of parameter is being discussed.
Also, it does not convey the intention of the construct. If a feature requires multiple parameters to communicate, they would all be contained in a single construct. GenericParameter may give people the impression that multiple 'genericParameter' constructs would be used for this. Hence the naming is mis-leading.
The concept (which I'm sure Paul* must know a lot better than I do - we're merely the bozos that conceived and wrote it) is that the features are negotiated, and then the features are used. The package - as was - is what the features use to actually communicate.
If calling it genericFeature is not acceptable then call it genericFeatureData, or featureData. Calling it genericParameter is just too confusing, and it does not convey the intention of contribution. The term genericParameter should not be used.
Pete.
*I can't see where Paul said the comment that this refers to BTW
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================
----- Original Message ----- From: Rich Bowen rkbowen@CISCO.COM To: ITU-SG16@mailbag.cps.intel.com Sent: 05 July 2000 19:16 Subject: Re: Comments on H.225v4 and H.323v4
Morgan,
Rich/Paul, I have the following comments on H.225v4 and H.323v4.
H.225 /p168: neededfeatures has been moved from conferenceGoal to
elsewhere
in the Setup message. I understand from Pete that inclusion of neededFeatures in the conferenceGoal has caused problems for Cisco gateways. Moving neededFeatures out of the conferenceGoal however, means that feature negotiation can never be used with versions other than H.323v4. If we
are
not going to use the conference Goal, (and the use of conferenceGoal is
our
preferred option!), It would be better to leave out the term
neededFeatures
altogether and use desiredFeatures.
This topic was discussed on the list a couple of weeks ago. To summarize, adding the field to the conferenceGoal was controversial. (It is not correct that this would be a problem for Cisco gateways.) Adding it to the Setup-UUIE is a possible alternative that had fewer objections, so I left it there as a placeholder with the understanding that if the issue is not resolved by November, it can be removed at that time. I personally don't have a strong opinion about the placement or presence of this field.
H.323 /p75: The change of name from 'package' to 'parameter' is inappropriate. If the name has to be changed from 'package', it should be changed to genericFeature.
H.225 /ANNEX H: There should be a global change of terminology from genericParameter to generic Feature.
I agree with Paul's comment, that the term "feature" encompasses more than the intended purpose of this field. There were two objectives stated in TD-50/Osaka: tunneling opaque data and negotiating features. The field in question achieves the tunneling of opaque data. Any name that reflects that purpose would be fine with me.
- Rich
Regards,
Morgan Potter
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com--
Richard K. Bowen Cisco Systems, Inc. VoIP Session Protocols Research Triangle Park, NC, USA
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com