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 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. 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. Regards, Morgan Potter ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Morgan,
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.
I proposed this change, because the word "package" conflicted with H.248 "packages" and I thought that it was too confusing. GenericParameter seemed like a reasonable name. 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". How about "generic fields" or "generic elements"? I still prefer "generic parameter" over those. Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
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
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
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.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
Pete,
According to the text, the generic extensibility frame serves two
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@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Paul E. Jones <paulej@PACKETIZER.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: 07 July 2000 02:12 Subject: Re: Comments on H.225v4 and H.323v4 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
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
multiple 'genericParameter' constructs would be used for this. Hence
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
before that the 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
> >
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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
participants (4)
-
<Morgan Potter> -
Paul E. Jones -
Pete Cordell -
Rich Bowen