Comments on H.225v4 and H.323v4

[Pete Cordell]

Paul,

The data carried is opaque to 225.  However, it is fundamental to the actual
features.  The construct that used to carry this data was a package.  The
term package captures the idea of a multiplicity of data associated with a
feature, and also could imply associated procedures.  I do not want to loose
that in any re-naming.

All you have to do is read the start of the description in 323 to find out
that it is mighty confusing calling something a parameter which itself
contains multiple parameters.  For this and the other reasons mentioned in
earlier e-mails, the change to genericParameter does not clarify matters.

Hence, the last suggestion is for:

    genericFeatureData

or simply:

    featureData

(The generic was there merely to follow on from your use of generic in
genericParameter.  We don't mind whether is there or not.)

BTW, Thanks for your statement of support for us trying to get the name
right.  However hopefully we are not fussing with each other, but simply
trying to define a clear standard with tight time scales.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
pete at tech-know-ware.com
+44 1473 635863
=============================================

----- Original Message -----
From: Paul E. Jones <paulej at PACKETIZER.COM>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: 07 July 2000 02:12
Subject: Re: Comments on H.225v4 and H.323v4


> 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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com