FYI, we are currently discussing the issue within the Q.14 e-mail reflector, and the Q.14 experts are looking at a one possible solution that may link a version number to the support of the two ASN.1 version.With this mechanism, version 0 (and possibly version 1) would refer to the ASN.1 definition published in the 06/1998 T.38 spec, and version 2 or higher would refer to the ASN.1 definition published in the 03/2002 T.38 spec. I believe a decision will be made at the Q.14 May 2003 Geneva meeting. Dominic.
-----Original Message----- From: Boyle, Kevin [NCRTP:3Z40:EXCH] Sent: Friday, March 14, 2003 2:16 PM To: ITU-SG16@echo.jf.INTEL.COM Subject: Re: T.38 potentially broken by recent Corrigendum
All,
It is my understanding that the ellipsis was intended to be there, and that it wasn't until folks started implementing that it was noticed that it got dropped somewhere between the editor's hands and publication. There was a TD in the Feb 2000 meeting noting this typo. I can produce it if anyone wants to see it.
It is also my understanding that care was taken to ensure that all known vendors were made aware of the change at the time.
Kevin
-----Original Message----- From: Klaghofer Karl ICN EN HS D 11 [mailto:karl.klaghofer@SIEMENS.COM] Sent: Friday, March 14, 2003 3:44 AM To: ITU-SG16@echo.jf.INTEL.COM Subject: AW: T.38 potentially broken by recent Corrigendum
Paul,
I fully agree with you, that the T.38 (1998) asn.1 and the Revision of T.38 (2002) asn.1 needs to be backwards compatible.
Regards, Karl Klaghofer Siemens
-----Ursprüngliche Nachricht----- Von: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Gesendet: Montag, 3. März 2003 03:21 An: ITU-SG16@echo.jf.INTEL.COM Betreff: T.38 potentially broken by recent Corrigendum
Folks,
I just recently discovered that the ITU-T published a corrigendum to T.38 (1998) that apparently breaks backward compatibility for all T.38 devices currently deployed that follow the original 1998 specifications. The particular document in question is Corrigendum 1, which was approved in 2000 and subsequently published in May 2001. You can download the corrigendum document for free from this site: http://www.itu.int/rec/recommendation.asp?type=folders http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC- T.38 &lang=e&parent=T-REC-T.38
The issue at hand is a change in the ASN.1 syntax found in Annex A/T.38. The particular data structure is shown here:
Data-Field ::= SEQUENCE OF SEQUENCE { field-type ENUMERATED { hdlc-data, hdlc-sig-end, hdlc-fcs-OK, hdlc-fcs-BAD, hdlc-fcs-OK-sig-end, hdlc-fcs-BAD-sig-end, t4-non-ecm-data, t4-non-ecm-sig-end, ... }, field-data OCTET STRING (SIZE(1..65535)) OPTIONAL }
The syntactical change was the addition of an ellipsis at the end of the ENUMERATED "field-type". In the published 1998 specification, this ellipsis did not exist.
What I would like to know is whether this change impacts your product or not. I am aware of many deployed devices on the market today that employs the 1998 syntax without this ellipsis. I would like to find out to what extent this change is going to present problems for companies represented on various lists and, if I get sufficient support, I want to take a contribution to the ITU-T SG16 meeting in May to try to resolve this problem in such a way as to not break backward compatibility and interoperability.
I am looking forward to your replies.
Kindest Regards, Paul E. Jones ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@lists.intel.com