Re: H323 version labeling - FW: h323 Annex E support
Paul:
I think you are incorrect on this. In SG16 implementors guides have always been treated as normative, and clearly are not implementors guides in the sense that you mention. They are formally approved by the entire SG, and become effective 'normative' after that approval.
Dale Skran
-----Original Message----- From: Lyons, Terry [mailto:TLyons@sonusnet.com] Sent: Thursday, January 10, 2002 12:08 PM To: ITU-SG16@echo.jf.INTEL.COM Subject: H323 version labeling - FW: h323 Annex E support
-----Original Message----- From: Lyons, Terry Sent: Thursday, January 10, 2002 12:06 PM To: 'imtch323implementors@mail.imtc.org'; ITU-SG16@mailbag.cps.INTEL.COM Cc: Lyons, Terry Subject: H323 version labeling - FW: h323 Annex E support
Maybe we should talk in terms of dot releases, eg. v3.0 and v4.0 are the official ITU-T Recommendations whereas v3.1 and v4.1 are the Implementers Guide changes.
The need is to be clear about what H323 version an endpoint conforms to or a protocol stack supports. Calling different things, eg. H323 (11/2000) and H323 IG (6/2001), by the same name "v4" can lead to misunderstanding.
- TLyons@sonusnet.com +1 732 625-3003 ext 212
-----Original Message----- From: Paul Long [mailto:plong@ipdialog.com] Sent: Wednesday, January 09, 2002 12:19 PM Subject: Re: h323 Annex E support
Paul,
No, the concensus was that the IG is NOT normative because the ITU does not sanction its "normativeness" in any way, but it appears that we have made a de facto decision to informally pretend that it is normative. I know for sure that the H.324 IGs were NOT normative. In fact, the H.324 IG is what its name indicates--an actual guide for implementors, not an corregendum, which is what the H.323 IG really is (it's also an addendum, but that's another issue altogether). I don't know about T.120 or H.320, but I'd be willing to bet that their IGs, if they had any, were also NOT normative.
Paul Long ipDialog, Inc.
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Wednesday, January 09, 2002 10:27 AM To: Lyons, Terry Cc: imtch323implementors@mail.imtc.org Subject: [imtch323implementors] Re: h323 Annex E support
Terry,
Arguably, the IG is not normative. However, since the first day, ITU-T SG16 has used the implementers guides as a normative texts. This is done, not only with H.323, but also with T.120, H.320, H.324, etc.
One could ignore the corrections applied to the IG, but doing so is quite dangerous. You can't simply ignore the changes made via the IG, because SG16 changes the ASN.1, not just add fields, and those changes will appear in the next revision of the Recommendations. Of course, we try to limit changes, but we usually do make a number of changes after the Recommendation is first approved and people start to finding problems. There are no plans to change the v4 syntax any further-- and I will fight any change-- but you can see the history of changes made for v4 on Packetizer. The last approved change was June 2001, yet the Recommendation was approved in November 2000.
It would be nice if we could first get implementations and then approve the Recommendation in a more solid state. Unfortunately, that's not possible for several reasons:
- Companies do not want to spend engineering resources on a moving
target 2) The standards work is usually way ahead of implementation 3) No matter how hard we try, there's likely to be something we miss 4) This is the way it has always been done-- tradition is hard to change
I presently have no intent to move the IG to series of amendments. We have been using this approach for 5 years with good results. Changing the text would require drafting a number of different documents and that process is also subject to error. I'm not opposed to it, but I doubt we'll find the volunteers to write all of the amendments: it's boring, non-rewarding work.
Paul
----- Original Message ----- From: "Lyons, Terry" TLyons@sonusnet.com To: "'Paul E. Jones'" paulej@packetizer.com; "Lyons, Terry" TLyons@sonusnet.com Cc: imtch323implementors@mail.imtc.org Sent: Wednesday, January 09, 2002 9:47 AM Subject: RE: h323 Annex E support
We all recognize, don't we, that the Implementers Guide is not a normative ITU Recommendation. The way that the ITU changes things is through an amendment or subsequent edition. I believe there was some discussion of just this point in the past.
The IG is best understood as a indication of what is coming next. The correct statment is that the fields are in v4, not v3.
- TLyons@sonusnet.com +1 732 625-3003 ext 212
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, January 08, 2002 11:44 PM To: Lyons, Terry Cc: imtch323implementors@mail.imtc.org Subject: Re: h323 Annex E support
Terry,
They were added to H.323v3 via the H.323 Implementers Guide approved in November 2000.
Paul
----- Original Message ----- From: "Lyons, Terry" TLyons@sonusnet.com To: "'Paul E. Jones'" paulej@packetizer.com Cc: imtch323implementors@mail.imtc.org Sent: Tuesday, January 08, 2002 11:12 AM Subject: RE: h323 Annex E support
Hmmm ... the fields are NOT in the ITU publication H.225.0(09/99) nor in the "Draft H.323 Core Document" H.225.0 Version 3 tabulated at http://www.packetizer.com/iptel/h323/ which links to
ftp://standard.pictel.com/avc-site/till_0012/9909_Gen/h225v3_decided_wcm_9 90
930
Endpoint ::= SEQUENCE { nonStandardData NonStandardParameter OPTIONAL, aliasAddress SEQUENCE OF AliasAddress OPTIONAL, callSignalAddress SEQUENCE OF TransportAddress OPTIONAL, rasAddress SEQUENCE OF TransportAddress OPTIONAL, endpointType EndpointType OPTIONAL, tokens SEQUENCE OF ClearToken OPTIONAL, cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, priority INTEGER(0..127) OPTIONAL, remoteExtensionAddress SEQUENCE OF AliasAddress OPTIONAL, destExtraCallInfo SEQUENCE OF AliasAddress OPTIONAL, ... }
- TLyons@sonusnet.com +1 732 625-3003 ext 212
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, January 08, 2002 12:56 AM Subject: RE: h323 Annex E support
C. S.,
Those fields are also in v3. See the ASN.1 file here: http://www.packetizer.com/iptel/h323/h2250v3.asn
As for how a v2 device will work, Annex E describes how the endpoint
may
initiate a call with Annex E and then fall back to TCP if it is
determined
that Annex E is not supported. Of course, this is less efficient in
terms
of call setup time, so using the v3/v4 fields are preferred.
Paul
----- Original Message ----- From: subbac@hss.hns.com To: "Paul, Manoj" mpaul@trillium.com Cc: imtch323implementors@mail.imtc.org Sent: Monday, January 07, 2002 3:48 AM Subject: [imtch323implementors] RE: h323 Annex E support
Hi paul,
These "alternateTransportAddress" and "useSpecifiedTransport" fields
are
present in h323V4.
In Case of H323V3 how to mention.
regards C. S. Rao
"Paul, Manoj" mpaul@trillium.com on 01/07/2002 01:49:59 PM
To: Subbarao Chanduri/HSSBLR, imtch323implementors@mail.imtc.org cc:
Subject: RE: [imtch323implementors] h323 Annex E support
Rao:
GK can indicate it's Annex E transport addresses in "alternateTransportAddress" field. It also indicates in "useSpecifiedTransport" to use TCP/Annex
E.
-Manoj Paul Trillium Digital Systems (Intel).
-----Original Message----- From: subbac@hss.hns.com [mailto:subbac@hss.hns.com] Sent: Monday, January 07, 2002 1:37 PM To: imtch323implementors@mail.imtc.org Cc: subbac@hss.hns.com Subject: [imtch323implementors] h323 Annex E support
Hi,
If Gatekeeper supports H323 Annex E. inresponse to Admission Request from an endpoint, through ACF, how gatekeeper informs the endpoint that it is
listening
on
two different Transport Addresses. i.e. one transport address (TA1) for Annex E messages. other transport Address (TA2) for TCP
messages.
As there is only one field in ACF to indicate the destination call signalling address, how endpoint come to know about the different addresses GK is listening.
regards C. S. Rao
Dale,
I agree that they have been _treated_ as normative, but they are not _in fact_ normative. An IG simply _records defects and corrections_ in one or more Recommendations while a Corrigendum _corrects_ a particular Recommendation. According to the ITU-T, the only way to correct a Recommendation is to issue a Corrigendum or revise the Recommendation. An IG is therefore a working document of which implementors are prudent to take notice but which does not have normative force.
Take a look at the ITU-T's "Author's Guide for drafting ITU-T Recommendations" for definitions of "corrigendum" and "implementors' guide." Also take a look at this passage in section 9.6.3 of the ITU-T's "Resolution 1, Rules of procedure of the ITU Telecommunication Standardization Sector (ITU-T): "...minor amendments may be covered by corrigenda rather than a complete reissue." No mention of IGs here; however, in section 9.6 of the same document, it says, "When a study group identifies the need for implementors >>>to be made aware of<<< defects ... in a Recommendation, one mechanism that may be employed is an Implementors' Guide. This Guide is an historical document >>>recording<<< all identified defects and their status of correction..." (emphasis mine). Therefore, an IG is informational; a Corrigendum is normative. If you think otherwise, please cite ITU-T text that backs up your assertion.
Paul Long ipDialog, Inc.
-----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@echo.jf.INTEL.COM]On Behalf Of Skran, Dale Sent: Thursday, January 10, 2002 11:30 AM To: ITU-SG16@echo.jf.INTEL.COM Subject: Re: H323 version labeling - FW: h323 Annex E support
Paul:
I think you are incorrect on this. In SG16 implementors guides have always been treated as normative, and clearly are not implementors guides in the sense that you mention. They are formally approved by the entire SG, and become effective 'normative' after that approval.
Dale Skran
-----Original Message----- From: Lyons, Terry [mailto:TLyons@sonusnet.com] Sent: Thursday, January 10, 2002 12:08 PM To: ITU-SG16@echo.jf.INTEL.COM Subject: H323 version labeling - FW: h323 Annex E support
-----Original Message----- From: Lyons, Terry Sent: Thursday, January 10, 2002 12:06 PM To: 'imtch323implementors@mail.imtc.org'; ITU-SG16@mailbag.cps.INTEL.COM Cc: Lyons, Terry Subject: H323 version labeling - FW: h323 Annex E support
Maybe we should talk in terms of dot releases, eg. v3.0 and v4.0 are the official ITU-T Recommendations whereas v3.1 and v4.1 are the Implementers Guide changes.
The need is to be clear about what H323 version an endpoint conforms to or a protocol stack supports. Calling different things, eg. H323 (11/2000) and H323 IG (6/2001), by the same name "v4" can lead to misunderstanding.
- TLyons@sonusnet.com +1 732 625-3003 ext 212
-----Original Message----- From: Paul Long [mailto:plong@ipdialog.com] Sent: Wednesday, January 09, 2002 12:19 PM Subject: Re: h323 Annex E support
Paul,
No, the concensus was that the IG is NOT normative because the ITU does not sanction its "normativeness" in any way, but it appears that we have made a de facto decision to informally pretend that it is normative. I know for sure that the H.324 IGs were NOT normative. In fact, the H.324 IG is what its name indicates--an actual guide for implementors, not an corregendum, which is what the H.323 IG really is (it's also an addendum, but that's another issue altogether). I don't know about T.120 or H.320, but I'd be willing to bet that their IGs, if they had any, were also NOT normative.
Paul Long ipDialog, Inc.
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Wednesday, January 09, 2002 10:27 AM To: Lyons, Terry Cc: imtch323implementors@mail.imtc.org Subject: [imtch323implementors] Re: h323 Annex E support
Terry,
Arguably, the IG is not normative. However, since the first day, ITU-T SG16 has used the implementers guides as a normative texts. This is done, not only with H.323, but also with T.120, H.320, H.324, etc.
One could ignore the corrections applied to the IG, but doing so is quite dangerous. You can't simply ignore the changes made via the IG, because SG16 changes the ASN.1, not just add fields, and those changes will appear in the next revision of the Recommendations. Of course, we try to limit changes, but we usually do make a number of changes after the Recommendation is first approved and people start to finding problems. There are no plans to change the v4 syntax any further-- and I will fight any change-- but you can see the history of changes made for v4 on Packetizer. The last approved change was June 2001, yet the Recommendation was approved in November 2000.
It would be nice if we could first get implementations and then approve the Recommendation in a more solid state. Unfortunately, that's not possible for several reasons:
- Companies do not want to spend engineering resources on a moving
target 2) The standards work is usually way ahead of implementation 3) No matter how hard we try, there's likely to be something we miss 4) This is the way it has always been done-- tradition is hard to change
I presently have no intent to move the IG to series of amendments. We have been using this approach for 5 years with good results. Changing the text would require drafting a number of different documents and that process is also subject to error. I'm not opposed to it, but I doubt we'll find the volunteers to write all of the amendments: it's boring, non-rewarding work.
Paul
----- Original Message ----- From: "Lyons, Terry" TLyons@sonusnet.com To: "'Paul E. Jones'" paulej@packetizer.com; "Lyons, Terry" TLyons@sonusnet.com Cc: imtch323implementors@mail.imtc.org Sent: Wednesday, January 09, 2002 9:47 AM Subject: RE: h323 Annex E support
We all recognize, don't we, that the Implementers Guide is not a normative ITU Recommendation. The way that the ITU changes things is through an amendment or subsequent edition. I believe there was some discussion of just this point in the past.
The IG is best understood as a indication of what is coming next. The correct statment is that the fields are in v4, not v3.
- TLyons@sonusnet.com +1 732 625-3003 ext 212
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, January 08, 2002 11:44 PM To: Lyons, Terry Cc: imtch323implementors@mail.imtc.org Subject: Re: h323 Annex E support
Terry,
They were added to H.323v3 via the H.323 Implementers Guide approved in November 2000.
Paul
----- Original Message ----- From: "Lyons, Terry" TLyons@sonusnet.com To: "'Paul E. Jones'" paulej@packetizer.com Cc: imtch323implementors@mail.imtc.org Sent: Tuesday, January 08, 2002 11:12 AM Subject: RE: h323 Annex E support
Hmmm ... the fields are NOT in the ITU publication H.225.0(09/99) nor in the "Draft H.323 Core Document" H.225.0 Version 3 tabulated at http://www.packetizer.com/iptel/h323/ which links to
ftp://standard.pictel.com/avc-site/till_0012/9909_Gen/h225v3_decided_wcm_9 90
930
Endpoint ::= SEQUENCE { nonStandardData NonStandardParameter OPTIONAL, aliasAddress SEQUENCE OF AliasAddress OPTIONAL, callSignalAddress SEQUENCE OF TransportAddress OPTIONAL, rasAddress SEQUENCE OF TransportAddress OPTIONAL, endpointType EndpointType OPTIONAL, tokens SEQUENCE OF ClearToken OPTIONAL, cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, priority INTEGER(0..127) OPTIONAL, remoteExtensionAddress SEQUENCE OF AliasAddress OPTIONAL, destExtraCallInfo SEQUENCE OF AliasAddress OPTIONAL, ... }
- TLyons@sonusnet.com +1 732 625-3003 ext 212
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, January 08, 2002 12:56 AM Subject: RE: h323 Annex E support
C. S.,
Those fields are also in v3. See the ASN.1 file here: http://www.packetizer.com/iptel/h323/h2250v3.asn
As for how a v2 device will work, Annex E describes how the endpoint
may
initiate a call with Annex E and then fall back to TCP if it is
determined
that Annex E is not supported. Of course, this is less efficient in
terms
of call setup time, so using the v3/v4 fields are preferred.
Paul
----- Original Message ----- From: subbac@hss.hns.com To: "Paul, Manoj" mpaul@trillium.com Cc: imtch323implementors@mail.imtc.org Sent: Monday, January 07, 2002 3:48 AM Subject: [imtch323implementors] RE: h323 Annex E support
Hi paul,
These "alternateTransportAddress" and "useSpecifiedTransport" fields
are
present in h323V4.
In Case of H323V3 how to mention.
regards C. S. Rao
"Paul, Manoj" mpaul@trillium.com on 01/07/2002 01:49:59 PM
To: Subbarao Chanduri/HSSBLR, imtch323implementors@mail.imtc.org cc:
Subject: RE: [imtch323implementors] h323 Annex E support
Rao:
GK can indicate it's Annex E transport addresses in "alternateTransportAddress" field. It also indicates in "useSpecifiedTransport" to use TCP/Annex
E.
-Manoj Paul Trillium Digital Systems (Intel).
-----Original Message----- From: subbac@hss.hns.com [mailto:subbac@hss.hns.com] Sent: Monday, January 07, 2002 1:37 PM To: imtch323implementors@mail.imtc.org Cc: subbac@hss.hns.com Subject: [imtch323implementors] h323 Annex E support
Hi,
If Gatekeeper supports H323 Annex E. inresponse to Admission Request from an endpoint, through ACF, how gatekeeper informs the endpoint that it is
listening
on
two different Transport Addresses. i.e. one transport address (TA1) for Annex E messages. other transport Address (TA2) for TCP
messages.
As there is only one field in ACF to indicate the destination call signalling address, how endpoint come to know about the different addresses GK is listening.
regards C. S. Rao
Dear all,
trust me on this, Paul is exactly right.
Simão -- Paul Long wrote:
Dale,
I agree that they have been _treated_ as normative, but they are not _in fact_ normative. An IG simply _records defects and corrections_ in one or more Recommendations while a Corrigendum _corrects_ a particular Recommendation. According to the ITU-T, the only way to correct a Recommendation is to issue a Corrigendum or revise the Recommendation. An IG is therefore a working document of which implementors are prudent to take notice but which does not have normative force.
Take a look at the ITU-T's "Author's Guide for drafting ITU-T Recommendations" for definitions of "corrigendum" and "implementors' guide." Also take a look at this passage in section 9.6.3 of the ITU-T's "Resolution 1, Rules of procedure of the ITU Telecommunication Standardization Sector (ITU-T): "...minor amendments may be covered by corrigenda rather than a complete reissue." No mention of IGs here; however, in section 9.6 of the same document, it says, "When a study group identifies the need for implementors >>>to be made aware of<<< defects ... in a Recommendation, one mechanism that may be employed is an Implementors' Guide. This Guide is an historical document >>>recording<<< all identified defects and their status of correction..." (emphasis mine). Therefore, an IG is informational; a Corrigendum is normative. If you think otherwise, please cite ITU-T text that backs up your assertion.
Paul Long ipDialog, Inc.
-----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@echo.jf.INTEL.COM]On Behalf Of Skran, Dale Sent: Thursday, January 10, 2002 11:30 AM To: ITU-SG16@echo.jf.INTEL.COM Subject: Re: H323 version labeling - FW: h323 Annex E support
Paul:
I think you are incorrect on this. In SG16 implementors guides have always been treated as normative, and clearly are not implementors guides in the sense that you mention. They are formally approved by the entire SG, and become effective 'normative' after that approval.
Dale Skran
-- ======================================================================== Simão Ferraz de Campos Neto, Scientist *All comments strictly my own* Vice-Chairman, SG16; Chair, WP3/16 (Media Coding) LMGT/COMSAT Tel: +1-301-428-4516 22300 Comsat Drive Fax: +1-301-428-9287 Clarksburg MD 20871 - USA E-mail: simao.campos@labs.comsat.com ======================================================================== ****** Practice random kindness and senseless acts of beauty ****** ========================================================================
participants (3)
-
Paul Long -
Simão Campos-Neto -
Skran, Dale