Comments on H.225v4 and H.323v4

Paul E. Jones paulej at PACKETIZER.COM
Thu Jul 6 21:12:07 EDT 2000


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 at TECH-KNOW-WARE.COM>
To: <ITU-SG16 at 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 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
>
>
> > 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 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
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 mailing list