- sg16-avd - lists.packetizer.com

FW: H.235 White Contribution
by gthom 26 Sep '97

26 Sep '97

Mr. Okubo, I have put the "revised" final version of H.235 in the incomming directory. I included a cover sheet for the meeting. It has also been sent today to the TSB. File name: h235wht1.doc please move it to the 9801GEN directory, delete h235wht.doc, and delete any other versions in the incomming directory. Thank you Gary ------------------------------------- Name: Gary Thom Company: Delta Information Systems, Inc. Phone: +1-215-657-5270 x23 Fax : +1-215-657-5273 E-mail: gthom(a)delta-info.com Date: 09/25/97 Time: 09:43:16 ------------------------------------- ----------End of Original Message---------- ------------------------------------- Name: Gary Thom Company: Delta Information Systems, Inc. Phone: +1-215-657-5270 x23 Fax : +1-215-657-5273 E-mail: gthom(a)delta-info.com Date: 09/26/97 Time: 10:29:32 -------------------------------------

1 0

H.246 White Contribution
by gthom 25 Sep '97

25 Sep '97

Mr. Okubo, I have put the final version of H.246 in the incomming directory. I included a cover sheet for the meeting. It has also been sent today to the TSB. File name: h246wht.doc please move it to the 9801GEN directory and delete any other versions in the incomming directory. Thank you Gary ------------------------------------- Name: Gary Thom Company: Delta Information Systems, Inc. Phone: +1-215-657-5270 x23 Fax : +1-215-657-5273 E-mail: gthom(a)delta-info.com Date: 09/25/97 Time: 09:43:16 ------------------------------------- ----------End of Original Message---------- ------------------------------------- Name: Gary Thom Company: Delta Information Systems, Inc. Phone: +1-215-657-5270 x23 Fax : +1-215-657-5273 E-mail: gthom(a)delta-info.com Date: 09/25/97 Time: 14:41:37 -------------------------------------

1 0

Correction of H.310 RAST-5 stack for H.320/H.321 interoperation
by Sakae Okubo 25 Sep '97

25 Sep '97

Dear Q.12/16 broadband system experts, The Sunriver experts group meeting agreed to correct the H.320/H.321 interoperation mode stack of H.310 RAST-5 terminals and to apply this correction to H.310 Version 1. This agreement was reported to WP1&2/16 meeting on 12 September and the guidance obtained there was to use the procedure defined in Section 8.7.2 of Resolution No. 1 (Geneva, 1996) as attached. I need to submit a white contribution containing the proposed changes. I intend to use Annex to APC-1300 for this purpose. As this is a rather heavy (very visible to everybody) procedure, I need your cooperation to review thoroughly the Annex to APC-1300 so that our correction is defectless. Please return your advice as soon as possible, by 7 October at the latest. Then I will send the white contribution to Geneva for reference in the Director's invitation to the January-February meeting of SG16. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ******************************************************************** Excerpt from Resolution No. 1 (Geneva, 1996) 8.7 Correction of defects 8.7.1 When a Study Group identifies the need for implementors to be made aware of defects (e.g. typographical errors, editorial errors, ambiguities, omissions or inconsistencies and technical errors) 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, from their identification to final resolution, and would be issued in the Study Group's COM Series of documents. 8.7.2 Defects identified since the approval of the latest issue of the Implementors' Guide (par. 8.7.1) and their proposed corrections are referenced in the Director's invitation to the next Study Group meeting so the Study Group can address them. The Chairman shall be accountable for a fair decision about the nature of the proposed corrections, in the spirit which is expressed in par. 8.5.2 above. After approval by the Study Group (see par. 8.5.3 to par. 8.5.6), the Director shall announce the corrections in a Circular-letter and the Study Group will update the Implementors' Guide accordingly. END

1 0

H.235 White Contribution
by gthom 25 Sep '97

25 Sep '97

Mr. Okubo, I have put the final version of H.235 in the incomming directory. I included a cover sheet for the meeting. It has also been sent today to the TSB. File name: h235wht.doc please move it to the 9801GEN directory and delete any other versions in the incomming directory. Thank you Gary ------------------------------------- Name: Gary Thom Company: Delta Information Systems, Inc. Phone: +1-215-657-5270 x23 Fax : +1-215-657-5273 E-mail: gthom(a)delta-info.com Date: 09/25/97 Time: 09:43:16 -------------------------------------

1 0

Report of the Sunriver meeting APC-1327
by Sakae Okubo 25 Sep '97

25 Sep '97

Dear SG16 colleagues, With the lack of comments, I have placed APC-1327 at the 9709_Sun directory as "confirmed by the participants". If you have found anything wrong, please advise me. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0

Directory 9801_Gen at the ftp site
by Sakae Okubo 25 Sep '97

25 Sep '97

Dear SG16 colleagues, As suggested at the Sunriver meeting, I have created the subject directory at the GCL ftp site. This is for the moment to place white contributions for decision at the January 1998 meeting of SG16. Later other files will also be placed here such as input and output TDs. Currently the followings are available; H222AM34.doc, H262AM34.zip, H321v2wh.zip. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0

Re: Corrections for H.225.0 V2.
by Euchner Martin ZT IK 3 25 Sep '97

25 Sep '97

Dear Glen, Attached is a word document that shows the additions and changes I made to the H.225 ASN.1. Could you please review and let me know if it is now correct, or what needs to change? I need to send the document in today (Thursday), so please reply as soon as possible. Perhaps you can help me understand something. The GRQ has an integrity field (SEQUENCE OF IntegrityMechanism) which I assume is used by the sender to indicate the algorithms available to the sender. meu>: That's right. Sender and receiver negotiate during GRQ/GFC whether to apply integrity on RAS messages and if yes, which integrity mechanism they choose; see IntegrityMechanism (digital signature, ISO9797, HMAC-xxx or non-standard). The ICV includes an algorithmOID (OBJECT IDENTIFIER), which I'm guessing indicates the algorithm used to compute the integrity check value. But, it looks to me that the possible algorithms under IntegrityMechanism are not represented in algorithmOID. For example, how can I represent hMAC-MD5 or nonStandard in ICV? Can you explain this to me? meu>: This is not quite correct. The algorithmID within the ICV structure is only used when the digital signature is applied as integrity mechanism. In this case, the algorithmOID tells the receiver by which digital signature algorithm the sender has computed the enclosed digital signature (e.g. RSA or DSS and applied hash functions etc.). However, this algorithmID is not used at all when the ICV is computed using symmetric techniques such as the HMAC methods or ISO9797. As both involved entities have agreed already on the integrity mechanism during GRQ/GCF there is no further need to indicate the applied integrity method within each RAS message; thus, it is not possible to change the integrity mechanism between RAS messages on the same RAS channel. I reviewed also the attached Word document which you sent me and recommend the following change to the ICV structure: I made the following changes: 1.) replaced the dash by a blank between OBJECT and IDENTIFIER 2.) replaced icv by signature in the comment. 3.) replaced the underscore _ by a blank between BIT and STRING. ICV ::= SEQUENCE { algorithmOID OBJECT IDENTIFIER, -- the algorithm used to compute the signature icv BIT STRING -- the computed cryptographic integrity check value -- or signature } That's all. I hope this helps and clarified your questions and allows you to complete and close H.225.0 V2! I will post this message also to our ITU-T reflector; however as round-trip time is very long - about one day for me - you will also get a direct mail from me which should get through much faster. Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 e-mail: Martin.Euchner(a)mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany -----------------------------------------------------------------------

1 0

"flowControlToZero message?"
by Paul Long 25 Sep '97

25 Sep '97

7.3.2/H.245v3 mentions the FlowControlToZero field of the H2250LogicalChannelAckParameters type and a "flowControlToZero message" (see quote below). However, I cannot find a definition for such a message in the H.245 ASN.1 syntax. Is this _not_ an H.245 message, has it just not been defined yet, or should this be a reference to the _FlowControl_ message with scope set to logicalChannelNumber? Regardless of the answer, this needs to be explained better in the Recommendation. "FlowControlToZero indicates whether the transmitter is allowed to start transmitting on the logical channel. If set to true, it indicates that the transmitter should not transmit on the logical channel until receiving a subsequent flowControlToZero message allowing it to do so. If set to false, or absent, the transmitter is allowed to begin transmitting immediately the channel is established." -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

1 1

Whither userInputSupportIndication?
by Paul Long 24 Sep '97

24 Sep '97

With the addition of UserInputCapability to H.245v3, the H.245v2 userInputSupportIndication choice of UserInputIndication is redundant and could cause interoperability problems due to the resulting ambiguity. Since H.245v2 is Decided, we cannot remove userInputSupportIndication from the H.245 ASN.1 syntax. Therefore, how shall we resolve there being two ways to signal whether a terminal is able to transmit the nonStandard, basicString, iA5String, or generalString forms of the alphanumeric choice of UserInputIndication? We could just "ignore" the problem and deprecate the use of the userInputSupportIndication choice either formally, i.e., written down, or informally. Or we could hope that referencing Recommendations do not require or allow userInputSupportIndication. -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

1 0

Corrections for H.245V3
by Euchner Martin ZT IK 3 24 Sep '97

24 Sep '97

Dear Mike, I checked H.245 V.3 from a security point of view and found out that the following issues have to be corrected: Subsection Conference Response definitions is missing definition of ReturnSig which should be as follows: ReturnSig ::= SEQUENCE { alias AliasAddress, responseRandom RandomVal, requestRandom RandomVal OPTIONAL, certificate TypedCertificate OPTIONAL - requested certificate } EncodedReturnSig ::= TYPE-IDENTIFIER.&Type (ReturnSig) The following definition seems not to be used by any H.245 ASN.1 and looks rather redundant; thus it should be removed: ChallengeString ::=OCTET STRING (SIZE(8..16)) Please incorporate these changes to the text. Thank you. Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 e-mail: Martin.Euchner(a)mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 e-mail: Martin.Euchner(a)mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany -----------------------------------------------------------------------

1 0