Pete,
According to the text, the generic extensibility frame serves two purposes:
o Carriage of opaque data within H.225.0 messages o Negotiation of supported features
So what carries "opaque" data? A genericFeature? The comment I made before was:
``I don't like the idea of calling it a "generic feature", because the structures in themselves are not "features". One uses the "generic parameter" structures in order to implement "features".''
I certainly do see why you make such a fuss over this simple field name change. There has been absolutely no change in functionality. We merely moved away from the word "package" to avoid a name collision with H.248.
Paul
----- Original Message ----- From: "Pete Cordell" pete@TECH-KNOW-WARE.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Thursday, July 06, 2000 7:47 AM Subject: Re: Comments on H.225v4 and H.323v4
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.comFor 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