Comments on H.225v4 and H.323v4
pete at TECH-KNOW-WARE.COM
Thu Jul 6 07:47:19 EDT 2000
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
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.
*I can't see where Paul said the comment that this refers to BTW
pete at tech-know-ware.com
+44 1473 635863
----- Original Message -----
From: Rich Bowen <rkbowen at CISCO.COM>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: 05 July 2000 19:16
Subject: Re: Comments on H.225v4 and H.323v4
> > Rich/Paul,
> > I have the following comments on H.225v4 and H.323v4.
> > H.225 /p168: neededfeatures has been moved from conferenceGoal to
> > 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
> > not going to use the conference Goal, (and the use of conferenceGoal is
> > preferred option!), It would be better to leave out the term
> > 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 at 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 at mailbag.intel.com
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com
More information about the sg16-avd